10.1 BGP Architecture, Neighbor States & Peering

10.1 BGP Architecture, Neighbor States & Peering

Border Gateway Protocol version 4 (BGP-4, defined in RFC 4271) is the standard exterior gateway protocol powering the global Internet routing ecosystem and modern large-scale enterprise WAN, data center spine-leaf fabrics, and Software-Defined Access (SD-Access/EVPN) networks. While Interior Gateway Protocols (IGPs such as OSPF, IS-IS, and EIGRP) are engineered for rapid convergence and shortest-path computation within a single administrative domain, BGP is designed for unmatched scalability, policy-based traffic steering, and inter-domain path-vector routing between autonomous systems.

+-----------------------------------------------------------------------------------+
|                         IGP VS. EGP / BGP COMPARISON MATRIX                       |
+-----------------------------------------------------------------------------------+
|  FEATURE                 INTERIOR GATEWAY PROTOCOLS (OSPF/EIGRP) | BGP-4 / MP-BGP  |
+------------------------------------------------------------------+----------------|
|  Primary Goal            Rapid convergence, lowest metric path   | Policy control |
|  Routing Algorithm       Link-State (Dijkstra) / Distance-Vector | Path-Vector    |
|  Transport Protocol      Native IP (Protocol 89 OSPF, 88 EIGRP)  | TCP Port 179   |
|  Metric System           Cost (Bandwidth) / Composite Metric     | Path Attributes|
|  Prefix Capacity         Tens of thousands of prefixes           | 1,000,000+     |
|  Neighbor Discovery      Automatic Dynamic Multicast Hellos      | Manual Unicast |
|  Administrative Scope    Single Autonomous System                | Inter & Intra  |
+-----------------------------------------------------------------------------------+

1. BGP Peering Architecture: eBGP vs. iBGP

An Autonomous System (AS) is a collection of IP networks and routers under a single administrative authority presenting a consistent, unified routing policy to the external world. Autonomous System Numbers (ASNs) were historically 2-byte integers (1 to 65,535, with private ranges 64,512 to 65,534), but modern enterprise networks and global transit providers deploy 4-byte ASNs (1 to 4,294,967,295, with private ranges 4,200,000,000 to 4,294,967,294) defined in RFC 6793.

BGP operates in two distinct modes based on the Autonomous System Numbers configured between peering routers:

1. External BGP (eBGP): Established between routers residing in different Autonomous Systems.
2. Internal BGP (iBGP): Established between routers residing in the same Autonomous System.

+-----------------------------------------------------------------------------------+
|                           eBGP VS. iBGP PEERING TOPOLOGY                          |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|    +-------------------------+                 +-------------------------+        |
|    |   AUTONOMOUS SYSTEM 100 |                 |   AUTONOMOUS SYSTEM 200 |        |
|    |                         |                 |                         |        |
|    |      [ Router A ]       |      eBGP       |      [ Router C ]       |        |
|    |       (AS 100) <===========================>       (AS 200)         |        |
|    |           ^             |   (TCP Port 179)|           ^             |        |
|    |           |             |   (TTL = 1)     |           |             |        |
|    |           | iBGP        |   (AD = 20)     |           | iBGP        |        |
|    |           | (TTL = 255) |                 |           | (TTL = 255) |        |
|    |           | (AD = 200)  |                 |           | (AD = 200)  |        |
|    |           v             |                 |           v             |        |
|    |      [ Router B ]       |                 |      [ Router D ]       |        |
|    |       (AS 100)          |                 |       (AS 200)          |        |
|    |                         |                 |                         |        |
|    +-------------------------+                 +-------------------------+        |
|                                                                                   |
+-----------------------------------------------------------------------------------+

Comprehensive eBGP vs. iBGP Architectural Comparison

2. TCP Port 179 Transport & BGP Message Types

Unlike IGPs that rely on raw IP protocols or link-local multicasts (such as OSPF on Protocol 89 or EIGRP on Protocol 88), BGP does not implement its own transport-layer error recovery, sequencing, or retransmission mechanisms. Instead, BGP runs directly over Transmission Control Protocol (TCP) on well-known port 179.

TCP Connection Establishment Model

• Manual Unicast Peering: BGP routers never send broadcast or multicast discovery packets. Every neighbor must be explicitly defined using the neighbor <ip-address> remote-as <asn> configuration command.
• Asymmetric Client/Server Negotiation: When configured, one router acts as the active TCP client (initiating a TCP SYN to remote port 179 from a dynamic high port), while the other acts as the passive TCP listener. If both routers initiate TCP SYN packets simultaneously, the router with the higher BGP Router ID / IP address maintains the active session, while the redundant TCP connection is torn down.
• MD5 Session Authentication: BGP supports RFC 2385 MD5 signature protection (neighbor <ip> password <secret>), computing a cryptographic hash over the TCP pseudo-header, TCP header, and BGP payload to thwart TCP RST spoofing and session hijacking attacks.

+-----------------------------------------------------------------------------------+
|                         BGP MESSAGE HEADER & PACKET TYPES                         |
+-----------------------------------------------------------------------------------+
|  Marker (16 Bytes: All 1s for sync) | Length (2 Bytes) | Type (1 Byte: 1 to 5)    |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  TYPE 1: OPEN                                                                     |
|  - Negotiates BGP version (4), local ASN, Hold Time, BGP Router ID, Capabilities  |
|                                                                                   |
|  TYPE 2: UPDATE                                                                   |
|  - Advertises new feasible routes (NLRI + Path Attributes) or withdraws dead routes|
|                                                                                   |
|  TYPE 3: NOTIFICATION                                                             |
|  - Signals fatal protocol or session errors; immediately resets session to IDLE   |
|                                                                                   |
|  TYPE 4: KEEPALIVE                                                                |
|  - 19-Byte header-only heartbeat sent periodically (default: 60s) to hold session |
|                                                                                   |
|  TYPE 5: ROUTE-REFRESH (RFC 2918)                                                 |
|  - Dynamically requests an inbound resend of prefixes without tearing down TCP    |
+-----------------------------------------------------------------------------------+

The Four Standard BGP Message Types

1. OPEN (Type 1): The initial message transmitted immediately after the underlying TCP 3-way handshake completes. It contains:
   • BGP Version: Must be version 4.
   • My Autonomous System: The 2-byte or 4-byte local AS number.
   • Hold Time: The maximum interval in seconds the router will wait for a Keepalive or Update before declaring the neighbor dead. Cisco default is 180 seconds (negotiates the lowest hold time between the two peers).
   • BGP Identifier (Router ID): A 32-bit integer formatted as an IPv4 address uniquely identifying the BGP speaker.
   • Optional Parameters (Capabilities Negotiation): Advertises support for Multiprotocol Extensions (MP-BGP for IPv6, VPNv4, EVPN), 4-byte ASN support, and Route Refresh capability.
2. UPDATE (Type 2): Transports routing information between peers. An UPDATE message contains:
   • Withdrawn Routes: A list of IP prefix/length pairs that are no longer reachable.
   • Path Attributes: The characteristics describing the advertised paths (e.g., AS_PATH, NEXT_HOP, LOCAL_PREF, MED, COMMUNITY).
   • Network Layer Reachability Information (NLRI): The destination IP prefixes reachable via the specified path attributes.
3. NOTIFICATION (Type 3): Generated when an unrecoverable error is detected (such as an AS number mismatch, hold timer expiration, malformed attribute, or authentication failure). It contains an Error Code, Error Subcode, and descriptive diagnostic data. Sending or receiving a NOTIFICATION message immediately closes the TCP session and resets the BGP state machine to IDLE.
4. KEEPALIVE (Type 4): A compact 19-byte message consisting solely of the BGP common header. It is transmitted at one-third of the negotiated Hold Time (Cisco default: every 60 seconds) to verify bidirectional session health when no UPDATE messages are actively queued.

3. The BGP 6-State Finite State Machine (FSM)

BGP neighbor adjacencies transition deterministically through six operational states defined in RFC 4271. Diagnosing BGP peering failures requires understanding the precise entry and exit criteria for each state.

+-----------------------------------------------------------------------------------+
|                         BGP SESSION ESTABLISHMENT SEQUENCE                        |
+-----------------------------------------------------------------------------------+
|  ROUTER 1 (AS 100, 192.168.1.1)                     ROUTER 2 (AS 200, 192.168.1.2)|
|                                                                                   |
|  [ IDLE ] ----------------------------------------------------------> [ IDLE ]    |
|  [ CONNECT ] ----( TCP SYN [Dst Port: 179] )------------------------> [ CONNECT ] |
|  [ CONNECT ] <---( TCP SYN-ACK [Src Port: 179] )-------------------- [ CONNECT ] |
|  [ CONNECT ] ----( TCP ACK )----------------------------------------> [ CONNECT ] |
|                                                                                   |
|  [ OpenSent ] ---( BGP OPEN: ASN 100, HoldTime 180, RID 1.1.1.1 )---> [ OpenSent ]|
|  [ OpenSent ] <--( BGP OPEN: ASN 200, HoldTime 180, RID 2.2.2.2 )---  [ OpenSent ]|
|                                                                                   |
|  [ OpenConfirm ] ( BGP KEEPALIVE )----------------------------------> [ OpenConfirm|
|  [ OpenConfirm ] <( BGP KEEPALIVE )---------------------------------- [ OpenConfirm|
|                                                                                   |
|  [ ESTABLISHED ] <======( BGP UPDATE Messages / Routing Exchange )==> [ ESTABLISHED|
+-----------------------------------------------------------------------------------+

Comprehensive State-by-State Breakdown

1. Idle State:
   • The initial starting point of any BGP session. The router initializes BGP memory structures, binds TCP port 179, and listens for incoming connections.
   • Upon a start event (e.g., configuring neighbor or executing clear ip bgp), BGP starts the ConnectRetry timer (default: 120 seconds), initiates a TCP 3-way handshake to the neighbor IP, and transitions to Connect.
   • Failure Indication: If a neighbor remains perpetually stuck in Idle, check whether the neighbor is administratively disabled (neighbor shutdown), if the local interface is down, or if the routing table lacks any route to reach the configured neighbor IP.
2. Connect State:
   • The router actively waits for the TCP 3-way handshake to complete with the remote peer.
   • If the TCP connection successfully establishes, BGP resets the ConnectRetry timer, transmits its BGP OPEN message, and transitions to OpenSent.
   • If the TCP connection attempt fails or the ConnectRetry timer expires before completion, BGP drops to the Active state.
3. Active State:
   • The router attempts to restart the TCP connection from its side after a previous failure.
   • If the TCP connection succeeds, the router sends an OPEN message and transitions to OpenSent.
   • If the ConnectRetry timer expires while in Active, BGP transitions back to the Connect state and resets the timer.
   • CRITICAL EXAM SCENARIO (Stuck in Active): A neighbor cycling in or perpetually stuck in Active indicates that TCP communication on port 179 is failing. Root causes include:
     • An Access Control List (ACL) or firewall dropping TCP port 179.
     • Mismatched update-source configuration (the router receives a TCP SYN from an IP that does not match its local neighbor <ip> statement).
     • Asymmetric routing or lack of a return path to the local source IP.
4. OpenSent State:
   • The local router has established its TCP connection and sent its BGP OPEN message. It is now waiting to receive the remote peer's OPEN message.
   • When the remote OPEN message arrives, the local router verifies:
     • BGP Version matches (version 4).
     • Neighbor ASN matches the locally configured remote-as.
     • BGP Router ID is valid and does not duplicate the local router's RID.
     • MD5 Authentication hash is verified.
   • If all parameters are valid, the router negotiates the Hold Time (selecting $\min(\text{Local Hold Time}, \text{Remote Hold Time})$), transmits a BGP KEEPALIVE, and transitions to OpenConfirm.
   • If any parameter mismatches (e.g., wrong AS configured), the router transmits a NOTIFICATION message and immediately resets to Idle.
5. OpenConfirm State:
   • The router waits for a BGP KEEPALIVE message from the neighbor confirming receipt and acceptance of its OPEN parameters.
   • Receipt of a valid KEEPALIVE transitions the session to Established.
   • If the Holddown timer expires or a NOTIFICATION is received, the session reverts to Idle.
6. Established State:
   • The BGP session is fully operational. Routers exchange UPDATE messages containing reachability information (NLRI) and path attributes.
   • The session is maintained by periodic KEEPALIVE messages (resetting the Holddown timer upon each arrival).
   • If the Holddown timer reaches zero without receiving an UPDATE or KEEPALIVE, or if an interface goes down, the router generates a NOTIFICATION (or TCP RST) and drops back to Idle.

Summary Table of BGP States and Troubleshooting

4. Loop Prevention: AS_PATH Checking & iBGP Split-Horizon

Because BGP is a path-vector protocol that does not maintain a complete link-state map of the network topology, it relies on two deterministic loop-prevention mechanisms operating at the Autonomous System boundary and within the AS core.

+-----------------------------------------------------------------------------------+
|                         BGP LOOP PREVENTION MECHANISMS                            |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  1. EXTERNAL BGP (eBGP): AS_PATH ATTRIBUTE INSPECTION                             |
|     - When an eBGP router advertises a route, it prepends its own AS number.      |
|     - When receiving a route from an eBGP peer, the router inspects the AS_PATH. |
|     - IF THE ROUTER'S OWN LOCAL ASN APPEARS IN THE AS_PATH -> SILENTLY DISCARDED!|
|                                                                                   |
|     AS 100 ---[ Adv 10.1.0.0/16 (AS-Path: 100) ]---> AS 200                     |
|        ^                                                |                         |
|        |                                                v                         |
|     AS 100 <---[ Adv 10.1.0.0/16 (AS-Path: 300 200 100) ]- AS 300                 |
|     (Router in AS 100 sees '100' in AS-Path -> DROPS UPDATE to prevent loop!)     |
|                                                                                   |
|  2. INTERNAL BGP (iBGP): THE iBGP SPLIT-HORIZON RULE                              |
|     - iBGP does NOT prepend local ASN to the AS_PATH (preserves path integrity).  |
|     - RULE: A route learned via an iBGP peer MUST NEVER be forwarded to another   |
|             iBGP peer.                                                            |
|     - CONSEQUENCE: Requires an iBGP Full Mesh or Route Reflectors / Confederations|
+-----------------------------------------------------------------------------------+

1. eBGP Loop Prevention: AS_PATH Inspection & AS Prepending

• AS_PATH Validation: Every time an eBGP speaker advertises a prefix to an external peer, it prepends its local ASN to the AS_PATH attribute list. When an edge router receives an inbound eBGP update, it immediately inspects the AS_PATH. If the router detects its own local Autonomous System Number anywhere within the AS_PATH sequence, it immediately discards the update. This guarantees that an update originating in AS 100 cannot loop through AS 200 and AS 300 and be re-injected back into AS 100.
• AS-Path Prepending for Traffic Engineering: Network administrators leverage this rule to influence inbound traffic. By prepending multiple copies of the local ASN to outbound eBGP updates sent to a secondary ISP (e.g., set as-path prepend 100 100 100), the external world perceives that path as having a higher hop count (longer AS_PATH), directing incoming enterprise traffic across the primary, unprepended uplink.

2. iBGP Loop Prevention: The iBGP Split-Horizon Rule

• The Architectural Dilemma: When routes are propagated between internal routers within the same Autonomous System, BGP does not modify or prepend the AS_PATH attribute. Because all internal routers share the same ASN, using AS_PATH internally would cause immediate false loop detection.
• The Split-Horizon Rule: To prevent internal routing loops without modifying AS_PATH, RFC 4271 establishes the iBGP Split-Horizon Rule: A router that learns a BGP route from an iBGP peer must never advertise that route to any other iBGP peer.
• The Full-Mesh Imperative: Because an intermediate iBGP router cannot relay an iBGP-learned route to downstream internal peers, every router in the AS must establish a direct iBGP peering session with every other router in the AS. For an enterprise network with $N$ BGP routers, the total number of required iBGP sessions scales quadratically:

$\text{Required iBGP Sessions} = \frac{N(N - 1)}{2}$

5. BGP Session Configuration & Peering Techniques

1. Loopback Peering & update-source loopback0

In enterprise networks, establishing BGP peering sessions to physical interface IP addresses creates a single point of failure: if the physical link flaps, the BGP TCP session drops, tearing down hundreds of thousands of routes even if redundant physical paths exist.

To achieve high availability, BGP sessions (particularly iBGP sessions) are established between stable logical Loopback interfaces.

• The TCP Source IP Rule: When BGP initiates a TCP connection, the local IP stack assigns the IP address of the outgoing physical interface as the packet's source IP. However, the receiving router expects the TCP SYN to originate from the specific IP defined in its local neighbor <ip> statement. If the source IP does not match, the receiving router rejects the TCP SYN.
• The Solution: The neighbor <ip> update-source Loopback0 command instructs the BGP process to source all BGP TCP packets from the designated loopback interface.

! Core-1 iBGP Configuration using Loopback0
Core-1(config)# router bgp 65001
Core-1(config-router)# bgp router-id 1.1.1.1
Core-1(config-router)# neighbor 2.2.2.2 remote-as 65001
Core-1(config-router)# neighbor 2.2.2.2 update-source Loopback0

2. eBGP Multihop & Connected Check

By default, Cisco IOS-XE enforces two strict constraints on external BGP (eBGP) sessions:

1. IP TTL of 1: Outgoing eBGP packets have their IP Time-To-Live header set to 1.
2. Directly Connected Check: The router verifies that the neighbor IP address resides on the same local subnet as one of its directly connected physical interfaces.

When configuring eBGP between loopback addresses (e.g., across dual physical links for load-balancing) or over multiple Layer 3 hops, the peering fails because the packet TTL decrements to 0 at the first transit hop, or the connected check fails.

+-----------------------------------------------------------------------------------+
|                         eBGP MULTIHOP TTL BEHAVIOR                                |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  [ Router A: AS 100 ] ========( Physical Link 1 )======== [ Router B: AS 200 ]     |
|  (Loopback: 10.1.1.1) ========( Physical Link 2 )======== (Loopback: 10.2.2.2)     |
|                                                                                   |
|  - Peering configured between 10.1.1.1 and 10.2.2.2 (Loopbacks).                  |
|  - Default TTL = 1: Packet reaches incoming physical port -> TTL decrements to 0! |
|  - Packet DROPPED before reaching Loopback interface!                             |
|  - FIX: 'neighbor 10.2.2.2 ebgp-multihop 2' (Sets TTL = 2, bypasses check).      |
+-----------------------------------------------------------------------------------+

• Configuration Commands:
  • neighbor <ip> ebgp-multihop <ttl>: Adjusts the outgoing IP TTL (from 1 to 255; if no number is specified, defaults to 255) and disables the directly connected check.
  • neighbor <ip> disable-connected-check: Bypasses the directly connected subnet check for single-hop eBGP neighbors while keeping TTL at 1 (useful when peering to a loopback directly over a single physical link).

3. Next-Hop Propagation & next-hop-self

• The iBGP Next-Hop Preservation Rule: When an ASBR learns a route from an external eBGP peer, the BGP NEXT_HOP attribute is set to the external peer's IP address. When that ASBR advertises the route to internal iBGP peers, BGP preserves the original external next-hop IP address unchanged.
• The Problem: Unless the external subnet is redistributed into the internal IGP (which is strongly discouraged for security and scalability), internal iBGP routers have no route to reach that external next-hop IP. If the next-hop is unreachable in the local routing table, BGP marks the route as inaccessible / invalid, refusing to install it into the RIB or forward traffic.
• The Solution: The neighbor <internal-peer-ip> next-hop-self command forces the ASBR to replace the external next-hop IP with its own local peering address (e.g., its Loopback0 IP) before re-advertising the prefix to iBGP peers.

6. Multiprotocol BGP (MP-BGP) & Address Families

Original BGP-4 (RFC 1771) was strictly designed to carry IPv4 unicast routing information. To support emerging network protocols without redesigning BGP from scratch, RFC 4760 introduced Multiprotocol Extensions for BGP-4 (MP-BGP).

MP-BGP decouples the underlying transport connection (which can be established over IPv4 or IPv6 TCP) from the network-layer prefixes carried in UPDATE messages. It introduces two new optional non-transitive path attributes:

• MP_REACH_NLRI (Multiprotocol Reachable NLRI, Attribute Type 14): Carries reachable network prefixes and next-hop addresses for specified address families.
• MP_UNREACH_NLRI (Multiprotocol Unreachable NLRI, Attribute Type 15): Carries withdrawn prefixes for specified address families.

Address Family Identifiers (AFI) & Subsequent AFIs (SAFI)

MP-BGP organizes routing contexts using standardized identifiers:

• AFI (Address Family Identifier): Defines the Layer 3 protocol (e.g., AFI 1 = IPv4, AFI 2 = IPv6, AFI 25 = L2VPN).
• SAFI (Subsequent Address Family Identifier): Defines the prefix handling type (e.g., SAFI 1 = Unicast, SAFI 2 = Multicast, SAFI 128 = MPLS VPN / VPNv4, SAFI 70 = EVPN).

+-----------------------------------------------------------------------------------+
|                         MP-BGP ADDRESS FAMILY ARCHITECTURE                        |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|               [ Global BGP Session Configuration (TCP Port 179) ]                 |
|               - neighbor 10.1.1.2 remote-as 65002                                 |
|               - neighbor 10.1.1.2 update-source Loopback0                         |
|                                    |                                              |
|         +--------------------------+--------------------------+                   |
|         |                          |                          |                   |
|         v                          v                          v                   |
|  +--------------------+   +--------------------+   +--------------------+         |
|  | address-family     |   | address-family     |   | address-family     |         |
|  | ipv4 unicast       |   | ipv6 unicast       |   | vpnv4              |         |
|  | - activate neighbor|   | - activate neighbor|   | - activate neighbor|         |
|  | - network 10.0.0.0 |   | - network 2001:db8:|   | - send-community   |         |
|  | - next-hop-self    |   | - next-hop-self    |   |   extended         |         |
|  +--------------------+   +--------------------+   +--------------------+         |
+-----------------------------------------------------------------------------------+

The no bgp default ipv4-unicast Command

By default, legacy Cisco IOS automatically activates every defined neighbor under the IPv4 unicast address family. In modern MP-BGP deployments (such as IPv6-only networks, MPLS L3VPNs, or EVPN fabrics), this legacy behavior creates unintended IPv4 sessions.

Executing no bgp default ipv4-unicast disables this automatic behavior, requiring the engineer to explicitly activate each neighbor within its intended address family using neighbor <ip> activate.

7. Cisco IOS-XE Configuration & Verification

1. MP-BGP Enterprise Edge Configuration (Dual-Homed eBGP + iBGP Core)

! Configure Enterprise Edge Router (Edge-1, AS 65001)
Edge-1(config)# router bgp 65001
Edge-1(config-router)# bgp router-id 1.1.1.1
Edge-1(config-router)# bgp log-neighbor-changes
Edge-1(config-router)# no bgp default ipv4-unicast

! Define External ISP Neighbor (eBGP over physical link)
Edge-1(config-router)# neighbor 203.0.113.2 remote-as 65100
Edge-1(config-router)# neighbor 203.0.113.2 description PRIMARY_ISP
Edge-1(config-router)# neighbor 203.0.113.2 password CiscoBGPPass123!

! Define Internal Core Neighbor (iBGP over Loopback)
Edge-1(config-router)# neighbor 10.255.255.2 remote-as 65001
Edge-1(config-router)# neighbor 10.255.255.2 description CORE-ROUTER-2
Edge-1(config-router)# neighbor 10.255.255.2 update-source Loopback0

! IPv4 Address Family Configuration
Edge-1(config-router)# address-family ipv4 unicast
Edge-1(config-router-af)# network 10.10.0.0 mask 255.255.0.0
Edge-1(config-router-af)# neighbor 203.0.113.2 activate
Edge-1(config-router-af)# neighbor 10.255.255.2 activate
Edge-1(config-router-af)# neighbor 10.255.255.2 next-hop-self
Edge-1(config-router-af)# exit-address-family

2. Comprehensive Verification Commands & Output

Edge-1# show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 65001
BGP table version is 142, main routing table version 142
2 network entries using 496 bytes of memory
2 path entries using 272 bytes of memory
2 BGP path attribute entries using 288 bytes of memory

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
203.0.113.2     4        65100     450     452      142    0    0 03:22:15        1
10.255.255.2    4        65001     380     382      142    0    0 02:45:10        4

Edge-1# show ip bgp
BGP table version is 142, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.10.0.0/16     0.0.0.0                  0         32768 i
 *>  0.0.0.0/0        203.0.113.2              0             0 65100 i
 *>i 10.20.0.0/16     10.255.255.2             0    100      0 i

3. Session Reset Mechanics: Hard Reset vs. Soft Reconfiguration vs. Route Refresh

! 1. Hard Reset (Tears down TCP port 179, flushes BGP table, severe outage)
Edge-1# clear ip bgp 203.0.113.2

! 2. Dynamic Soft Reset via Route Refresh (RFC 2918, zero packet loss, non-disruptive)
Edge-1# clear ip bgp 203.0.113.2 soft in
Edge-1# clear ip bgp 203.0.113.2 soft out

! 3. Soft Reconfiguration Inbound (Pre-RFC 2918 legacy method, stores raw updates in RAM)
Edge-1(config-router-af)# neighbor 203.0.113.2 soft-reconfiguration inbound