It is well known that eBGP packets default to having a Time to Live (TTL) value of 1. This has caused confusion for many network practitioners who wish to run eBGP between loopback addresses of directly connected routers. This misunderstanding sometimes leads to ebgp-multihop being configured when it is not necessary. This also gave me a chance to experiment with the eBGP “connected check” feature.

To demonstrate this, I configured two of my lab routers for eBGP between Loopbacks. R1 has Gi0/0 addressed as 172.16.0.1/30 and Lo1 as 10.0.0.1/32. R2 has Gi0/0 with 172.16.0.2/30 and Lo1 as 10.0.0.2/32. An Ethernet switch is sitting between the routers with SPAN configured for packet analysis. Below is the initial, working BGP configuration. Static routes are configured for reachability between loopbacks.

RoutingLoop_R1#show run | section bgp
router bgp 65001
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.0.0.2 remote-as 65002
neighbor 10.0.0.2 disable-connected-check
neighbor 10.0.0.2 update-source Loopback1
!
address-family ipv4
neighbor 10.0.0.2 activate
exit-address-family

RoutingLoop_R2#show run | section bgp
router bgp 65002
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.0.0.1 remote-as 65001
neighbor 10.0.0.1 disable-connected-check
neighbor 10.0.0.1 update-source Loopback1
!
address-family ipv4
neighbor 10.0.0.1 activate
exit-address-family

Notice the neighbor “disable-connected-check” statement applied to each router. This allows the eBGP session to establish with a peer that is not considered directly connected. With this configuration the TTL of BGP packets is still 1. The receiving router does not decrement the TTL when switching the packet to the Loopback interface. The TTL is only decremented if the packet must be forwarded to another host. Below is a snippet of the packet capture from this configuration.

With everything working, I decided to remove the “disable-connected-check” statement on R2 and run a debug. The CEF output confirms that R2 does not consider R1’s Loopback to be directly attached.

RoutingLoop_R2#show ip cef 10.0.0.1/32
10.0.0.1/32
nexthop 172.16.0.1 GigabitEthernet0/0

RoutingLoop_R2(config-router)#no neighbor 10.0.0.1 disable-connected-check
RoutingLoop_R2(config-router)#end
RoutingLoop_R2#debug ip bgp

*Mar 4 21:24:10.019: BGP: nbr global 10.0.0.1 Active open failed – open timer running
*Mar 4 21:24:10.463: BGP: 10.0.0.1 Active open failed – no route to peer, open active delayed 8192ms (35000ms max, 60% jitter)

Active open failed, no route to peer. Unless the connected check feature is used the local router will not attempt to establish the session. I decided to try a “non-standard” configuration to verify a suspicion. I left the R1 configuration unmodified. On R2 I deleted the Lo1 interface, removed the “disable-connected-check” statement and changed the IP configuration on R2’s Gi0/0 interface. R2 Gi0/0 is now configured with 10.0.0.2/24. This configuration makes R2 think that R1’s Lo1 address (10.0.0.1) is directly attached as confirmed by the CEF entry. Within seconds of R2’s Ethernet interface address being changed, the BGP session established

RoutingLoop_R2(config-if)#ip address 10.0.0.2 255.255.255.0
RoutingLoop_R2(config-if)#end
RoutingLoop_R2#
*Mar 4 21:47:43.415: %SYS-5-CONFIG_I: Configured from console by console
RoutingLoop_R2#
*Mar 4 21:47:46.831: %BGP-5-ADJCHANGE: neighbor 10.0.0.1 Up

RoutingLoop_R2#show ip cef 10.0.0.1
10.0.0.1/32
attached to GigabitEthernet0/0

RoutingLoop_R2#show run | sec bgp
router bgp 65002
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.0.0.1 remote-as 65001
!
address-family ipv4
neighbor 10.0.0.1 activate
exit-address-family

This Ethernet to Loopback peering is also working fine with TTL 1.