eBGP TTL Issue — Multihop Neighbor Not Connecting
Presenting Symptom
An eBGP neighbor configured with a multihop connection remains in the Idle state and never transitions to Established.
Network Context
Two routers, R1 (AS 65001) and R2 (AS 65002), are connected via a Layer 3 switch. R1's loopback0 (1.1.1.1) is used as the BGP update source, and R2's loopback0 (2.2.2.2) is the neighbor. The routers are not directly connected; they are two hops apart. Both run IOS 15.x. This is a small enterprise branch office scenario.
Diagnostic Steps
Check BGP neighbor status
show ip bgp summaryNeighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2.2.2.2 4 65002 0 0 1 0 0 never Idle
The neighbor is in Idle state, indicating that BGP has not started the connection process. This could be due to a missing route, TTL issue, or misconfiguration.
Verify IP connectivity between loopback addresses
ping 2.2.2.2 source 1.1.1.1Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Ping succeeds, so Layer 3 connectivity exists. The issue is not a missing route or ACL blocking ICMP.
Check BGP configuration for ebgp-multihop
show running-config | section router bgprouter bgp 65001 bgp log-neighbor-changes neighbor 2.2.2.2 remote-as 65002 neighbor 2.2.2.2 update-source Loopback0
The ebgp-multihop command is missing. By default, eBGP peers must be directly connected (TTL=1). Since the peers are two hops apart, the TTL must be increased.
Confirm TTL value using debug
debug ip bgp updatesBGP: 2.2.2.2 open active, local address 1.1.1.1 BGP: 2.2.2.2 went from Active to Idle BGP: 2.2.2.2 open failed: Connection refused by remote
The debug shows that BGP attempts to open a TCP connection but fails. The remote router is not responding because the incoming TTL is 1 (default) and the packet is dropped after the first hop.
Root Cause
The eBGP multihop neighbor is not directly connected, but the ebgp-multihop command is missing on both routers. By default, eBGP sets the IP TTL to 1, so packets are dropped by the intermediate Layer 3 switch. The neighbor remains Idle because the TCP connection cannot be established.
Resolution
Verification
Run 'show ip bgp summary' on R1: Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2.2.2.2 4 65002 10 12 5 0 0 00:02:34 3 The neighbor state should be Established (indicated by the number of prefixes received). Also verify with 'show ip bgp neighbors 2.2.2.2' to see BGP state = Established.
Prevention
1. Always use the ebgp-multihop command when eBGP peers are not directly connected. 2. Use loopback interfaces for BGP peering to provide stability, but remember to configure ebgp-multihop. 3. Verify TTL requirements during network design; a common best practice is to set the TTL to the number of hops plus 1.
CCNA Exam Relevance
On the CCNA 200-301 exam, this scenario appears in troubleshooting questions where an eBGP neighbor is not forming. The exam may present a multiple-choice question asking why a multihop eBGP neighbor is stuck in Idle, with options including missing ebgp-multihop, incorrect update-source, or AS number mismatch. The key fact is that eBGP requires direct connectivity by default (TTL=1) unless ebgp-multihop is configured.
Exam Tips
Remember: eBGP default TTL is 1; use ebgp-multihop for non-directly connected peers.
The command 'ebgp-multihop' is configured under the BGP router configuration mode, per neighbor.
In exam simulations, if you see an eBGP neighbor in Idle and ping works, suspect TTL or missing ebgp-multihop.
Commands Used in This Scenario
Test Your CCNA Knowledge
Practice with scenario-based questions to prepare for the CCNA 200-301 exam.
Practice CCNA Questions