eBGP Loopback Session Stuck in Active Across a Transit Router
R1 (Nokia SR OS, AS 65010) and R2 (AS 65020) need an eBGP session between loopbacks 10.0.0.1/32 and 10.0.0.2/32, not over a directly connected link. The loopbacks are separated by transit router R3: R1 connects to R3 on 192.0.2.0/30 and R3 connects to R2 on 198.51.100.0/30. Static routes on R1 and R2 point to each other's loopback via R3. R1 has neighbor 10.0.0.2, peer-as 65020, local-address 10.0.0.1, no multihop, and no TTL security. R2 has neighbor 10.0.0.1, peer-as 65010, local-address 10.0.0.2, multihop 2, and ttl-security hops 2. R1's BGP summary shows the neighbor in Active with connect-retry 120. R2 shows no established session to 10.0.0.1. ICMP ping from R1 to 10.0.0.2 succeeds, and the static route is active. R1's interface counters show TCP SYN packets leaving toward R3, but R2 never sees a SYN. No firewall is between R1 and R3.
1. What is the most likely reason the session never leaves Active, and what evidence distinguishes this from a routing or authentication failure?
Read the worked answer
The static route and successful ICMP ping rule out a missing route. The failure is at TCP establishment: R1 is Active, not OpenSent or OpenConfirm, and R2 never receives a SYN. Default eBGP uses TTL 1. R1's SYN to the off-link loopback must cross R3, so its TTL expires before R2. R2's multihop setting affects R2's outgoing packets but cannot repair R1's ingress TTL. Confirm with show router bgp neighbor 10.0.0.2, which should show connect-retry with no TCP session, and with a traceroute to 10.0.0.2. A TCP authentication failure would show TCP established and a BGP notification, not silent SYN loss.
2. What configuration change makes the session work while preserving TTL security, and how would you verify it?
Read the worked answer
On both neighbors, set multihop to match the two-router path and enable GTSM. Under the SR OS BGP neighbor context for 10.0.0.2 on R1, add multihop 2 and ttl-security hops 2; mirror the change on R2 for 10.0.0.1. GTSM must be on both ends: each side sends BGP TCP with TTL 255 and accepts only TTL greater than or equal to 254 for a two-hop peer. If only R2 has GTSM, R2 will drop R1's normal-TTL SYN. After the change, check show router bgp summary for Established, then show router bgp neighbor 10.0.0.2 for negotiated capabilities and show router bgp routes for exchanged prefixes.
3. Why not simply set multihop to 255?
Read the worked answer
Setting multihop to 255 would allow TCP from an attacker many hops away and defeats the purpose of GTSM. The hop count should match the actual path, which is two. If the path later changes to three hops, update both neighbors or change the design rather than opening the TTL check. Also verify that local-address uses the loopback and that return static routes exist.