6.1 External BGP (eBGP) Peering, States, Neighbor Adjacencies, and Timers

External BGP (eBGP) Peering, States, Neighbor Adjacencies, and Timers

The Border Gateway Protocol Version 4 (BGP-4) is the exterior gateway routing protocol that interconnects autonomous systems across the global Internet and enterprise wide-area networks (WANs). While Interior Gateway Protocols (IGPs) such as OSPF and EIGRP are engineered to discover topology and calculate the fastest internal path within a single trust boundary, BGP is fundamentally a path-vector protocol designed to enforce administrative routing policies, exchange reachability between disparate organizations, and scale to hundreds of thousands of network prefixes.

---

BGP Characteristics and Autonomous Systems

Path-Vector Mechanics and Transport Architecture

Unlike link-state protocols that flood link states or distance-vector protocols that broadcast full routing tables to link-local multicast groups, BGP operates as a path-vector protocol:

• Explicit Unicast Peering: BGP does not use multicast discovery or discover neighbors dynamically. All BGP neighbor relationships (peers) must be explicitly configured with target IP addresses.
• Reliable TCP Port 179 Transport: BGP establishes a reliable transport connection over TCP port 179 before exchanging routing information. Operating over TCP delegates packet retransmission, sequence verification, flow control, and windowing to Layer 4, allowing BGP to focus entirely on route policy and reachability.
• Path Attributes: Rather than evaluating raw metrics such as bandwidth or delay, BGP associates every route with a collection of path attributes (such as the sequence of Autonomous System numbers traversed). This guarantees loop prevention across multi-provider enterprise architectures.

Autonomous System Numbers (ASNs)

An Autonomous System (AS) is a collection of IP networks and routers managed under a single technical administration and unified routing policy. AS numbers identify distinct administrative domains globally:

• 16-Bit (2-Byte) ASNs: Range from 1 to 65,535. Due to the expansion of global internet connectivity, the pool of unallocated 16-bit ASNs neared exhaustion in the late 2000s.
• 32-Bit (4-Byte) ASNs: Introduced by RFC 6793, expanding the address space to 1 through 4,294,967,295 (over 4.2 billion ASNs). 32-bit ASNs can be written in two formats:
  • asplain: Standard decimal integer representation (e.g., 65536, 131072). Modern Cisco IOS software uses asplain by default.
  • asdot: Dotted-decimal notation separating high-order and low-order 16-bit words: <high>.<low> (e.g., 65536 is written as 1.0, 131072 is written as 2.0).
• Public vs. Private ASNs:
  • 2-Byte Private ASNs: 64,512 to 65,534 (RFC 6996 / RFC 1930). Used for private enterprise backbones, multi-tenant data centers, and test environments. Must be stripped before entering the public Internet.
  • 4-Byte Private ASNs: 4,200,000,000 to 4,294,967,294.
  • Reserved ASNs: 0 (reserved, invalid) and 65,535 / 4,294,967,295 (reserved for special routing purposes).

---

External BGP (eBGP) vs. Internal BGP (iBGP)

BGP operates in two distinct operational modes depending on whether neighbors reside in different autonomous systems or the same autonomous system:

---

eBGP Peering Architecture: Directly Connected vs. Multihop

Directly Connected Peering (The Default Model)

By default, Cisco IOS assumes eBGP neighbors are directly connected over a shared physical link or subinterface. When sending BGP packets to an eBGP neighbor, the IP header Time-to-Live (TTL) is set to 1. If two routers are directly connected, the receiving router processes the packet at TTL=1 without decrementing it further.

Loopback Peering and ebgp-multihop

In high-availability enterprise edge designs, two border routers often connect via multiple physical links. If eBGP is configured using physical interface IP addresses, the failure of a single link tears down the BGP session even if the alternative physical link is healthy.

To achieve interface resilience, engineers peer using logical Loopback interfaces. However, loopback peering introduces two critical requirements:

1. Single-Hop Assumption (TTL 1 and the connected check): Cisco IOS treats eBGP neighbors as single-hop. It sends eBGP packets with TTL 1 and, by default, will not start a session to a neighbor address that is not on a directly connected subnet, so a loopback-to-loopback session stays in Idle. If the peer really is several router hops away, a TTL of 1 would also expire at the first intermediate router.
   • Remediation: Configure neighbor <IP> ebgp-multihop <ttl>, which raises the TTL and removes the connected check; ebgp-multihop 2 is enough for directly connected routers peering between loopbacks. For a directly connected peer, neighbor <IP> disable-connected-check also works while keeping TTL 1.
2. Source IP Mismatch: By default, BGP initiates TCP connections using the primary IP address of the physical egress interface. The remote peer expects packets from the configured neighbor address (the loopback IP) and rejects the TCP SYN.
   • Remediation: Configure neighbor <IP> update-source <interface> (e.g., neighbor 198.51.100.2 update-source Loopback0).

                      +---------------------------+
                      |   Primary Physical Link   |
               +----->|       203.0.113.0/30      |-----+
               |      +---------------------------+     |
               |                                        v
[Router R1 Loopback0]                        [Router R2 Loopback0]
  (198.51.100.1/32)                           (198.51.100.2/32)
      AS 65100 |                                        ^   AS 65200
               |      +---------------------------+     |
               +----->|    Backup Physical Link   |-----+
                      |       203.0.113.4/30      |   Requires ebgp-multihop 2
                      +---------------------------+   and update-source Loopback0

---

BGP Finite State Machine (FSM)

A BGP session progresses through six well-defined operational states defined in RFC 4271:

+--------+
|  Idle  | <-------------------------------------+
+--------+                                       |
    |                                            |
    v                                            |
+---------+     TCP Fail / ConnectRetry Expire   |
| Connect | ---------------------------------> +--------+
+---------+                                    | Active |
    |                                          +--------+
    | TCP Success                                  |
    v                                              | TCP Success
+----------+ <-------------------------------------+
| OpenSent |
+----------+
    |
    | Receive Valid Open
    v
+-------------+
| OpenConfirm |
+-------------+
    |
    | Receive Keepalive
    v
+-------------+
| Established |
+-------------+

---

BGP Message Types

BGP defines four discrete message types, all encapsulated within a standard 19-byte BGP packet header (16-byte marker, 2-byte length, 1-byte type):

---

BGP Timers and Negotiation Mechanics

BGP relies on two primary timers to monitor neighbor health and maintain session liveness:

• Keepalive Timer: The frequency at which Keepalive messages are transmitted (Cisco default: 60 seconds).
• Hold Time Timer: The maximum interval the router will wait to receive a Keepalive, Update, or Notification message before declaring the neighbor dead and tearing down the peering session (Cisco default: 180 seconds).

Negotiation Rule

During the exchange of Open messages, each peer proposes its locally configured Hold Time. The two routers negotiate and agree upon the LOWER of the two proposed Hold Time values. The Keepalive timer is then automatically calculated as one-third of the negotiated Hold Time.

• Example: If Router A proposes a Hold Time of 90 seconds (with 30s Keepalive) and Router B proposes a Hold Time of 180 seconds (with 60s Keepalive), both routers accept 90 seconds as the Hold Time and transmit Keepalives every 30 seconds.
• Zero Value: If a Hold Time of 0 is negotiated, keepalive messages are completely disabled, and the session never times out.

---

Cisco IOS eBGP Configuration Walkthrough

Scenario 1: Directly Connected eBGP (the blueprint case)

Topic 3.2.c focuses on eBGP between directly connected neighbors. Here R1 (AS 65100) and R2 (AS 65200) share the 203.0.113.0/30 link:

! Router R1
router bgp 65100
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 203.0.113.2 remote-as 65200
 !
 address-family ipv4 unicast
  neighbor 203.0.113.2 activate
  network 192.0.2.0 mask 255.255.255.0
 exit-address-family
!
ip route 192.0.2.0 255.255.255.0 Null0

No ebgp-multihop or update-source is needed: the neighbor address is on a connected subnet, so TTL 1 works and the TCP session is sourced from the interface address R2 expects. The network command advertises 192.0.2.0/24 only if that exact prefix is in the routing table, which is why the static route to Null0 is included.

Scenario 2: Enterprise Edge Peering over Loopbacks

Router R1 (Enterprise AS 65100) peers with ISP Router R2 (AS 65200) across two redundant links. BGP peering is established between loopback interfaces 198.51.100.1/32 (R1) and 198.51.100.2/32 (R2).

! Router R1 (Enterprise Edge)
interface Loopback0
 ip address 198.51.100.1 255.255.255.255
!
ip route 198.51.100.2 255.255.255.255 203.0.113.2
ip route 198.51.100.2 255.255.255.255 203.0.113.6
!
router bgp 65100
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 198.51.100.2 remote-as 65200
 neighbor 198.51.100.2 description Peer to ISP-R2
 neighbor 198.51.100.2 update-source Loopback0
 neighbor 198.51.100.2 ebgp-multihop 2
 neighbor 198.51.100.2 timers 30 90
!
 address-family ipv4 unicast
  neighbor 198.51.100.2 activate
  network 192.0.2.0 mask 255.255.255.0
 exit-address-family

---

Verification and Troubleshooting Peering Failures

Interpreting show ip bgp summary

The show ip bgp summary command provides an instantaneous snapshot of all BGP neighbors:

R1# show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 65100
BGP table version is 5, main routing table version 5
1 network entries using 248 bytes of memory
1 path entries using 136 bytes of memory

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
198.51.100.2    4        65200      48      52        5    0    0 00:34:12            8
203.0.113.10    4        65300       0       0        1    0    0 never    Active

Critical State/PfxRcd Rule: In the State/PfxRcd column:

• If an integer number is displayed (e.g., 8 or 0), the BGP session is Established! The number represents how many prefixes have been received from that peer. Even 0 indicates an established session with zero learned routes.
• If a word is displayed (e.g., Active, Idle, Connect, OpenSent), the session is NOT established, and the displayed word indicates the current FSM state.

Systematic Troubleshooting Checklist

When a BGP neighbor fails to reach Established, use the following diagnostic hierarchy:

1. Stuck in Idle:
   • Verify whether the neighbor is administratively disabled (neighbor <IP> shutdown).
   • Check if an underlying IP route to the neighbor exists in the routing table (show ip route <IP>). If no route exists, BGP cannot initiate TCP connections.
   • For eBGP to a loopback or any other non-connected address, check for a missing ebgp-multihop or disable-connected-check; without one of them, IOS will not start the session.
2. Stuck in Active:
   • Verify Layer 3 reachability with ping <IP> source <interface>.
   • Check for Access Control Lists (ACLs) or firewalls dropping TCP port 179 packets in either direction.
   • Verify that the neighbor's IP address matches identically on both sides.
   • For loopback peering, check that neighbor <IP> update-source Loopback0 is configured on both sides so each router sources the TCP session from the address its peer expects.
3. Stuck in OpenSent or OpenConfirm:
   • Mismatched AS numbers: Check that local remote-as matches the peer's configured AS.
   • Duplicate BGP Router ID: If both routers share the same Router ID (e.g., identical loopback IP configured by mistake), BGP aborts the connection.
4. Session Flaps Periodically or Drops During Large Route Exchanges:
   • MTU Mismatch / PMTUD Failure: Small BGP Keepalive packets (19 bytes) traverse successfully, keeping the session alive. But when large BGP Update packets exceeding the path MTU arrive with the DF (Don't Fragment) bit set, intermediate devices drop them. The session resets due to Hold Time expiration.