Clearing Up Some Misinformation RE: eBGP Multihop and TTL

Last week I was at Cisco Live in Orlando and met, yet again, some people that had been taught one must set the TTL to 2 for two directly connected routers to be able to eBGP peer between their loopbacks because the TTL “gets decremented on the way to the loopback.” The web, ya gotta love it. When I try to help someone deprogram this brain washing, I find pictures help. So for those who’d like to get deprogrammed, it’s time to play!

In the picture above we have 3 Routers in 3 different BGP AS.  We all probably know that if we peer R1 and R2 together configured, to use our directly connected subnet (10.1.2.0), the eBGP (which has a default TTL of 1) will come up with no playing or tweaking of the TTL.  But let’s try to peer with the loopbacks.  In fact, let’s actually try to eBGP peer R1’s loopback to R3’s lookback

Through the use of some quick static routes, they have full connectivity to each other’s loopback addresses

• R1 is in BGP AS #1
• R2 is in BGP AS #2
• R3 is in BGP AS #3

R1 and R3 eBGP Peer with a TTL of 2

What if I told you that I can eBGP peer between R1 and R3 with a TTL of 2?  

Don’t take my word for it.  Let’s check R1 and see if it actually has an established BGP session and let’s look at those configs.

So as we can see, R1 and R3 can indeed eBGP peer loopback to loopback with a ttl of 2 and with R2 in the middle!

Taking a Step Back

Let’s take one giant step backwards and look at this not from a BGP perspective.  Let’s just say we had 3 routers and a PC connected to Router 1 as in the diagram below.

Let’s have the PC ping all 3 of the Loopbacks while setting TTL.  Wanna take bets?  I’m betting

• TTL of 1 is sufficient to reach R1’s loopback address
• TTL of 2 is sufficient to reach R2’s loopback address
• TTL of 3 is sufficient to reach R3’s loopback address

Any takers?

So Then Why?

Since R1 and R2 only need a TTL of 1 to get between their respective loopbacks,  why do we “need” to set eBGP multihop to 2 if R1 and R2 for eBGP to work?

The truth is we actually don’t “need” to.

Off to Read Documentation

Let’s do a quick google search for neighbor ebgp-multihop.

 —

(http://www.cisco.com/en/US/docs/ios/iproute_bgp/command/reference/irg_bgp3.html#wp1106590)

So this command says that it will help connect eBGP peers “residing on networks that are not directly connected.”  So, is R1’s loopback directly connected to R2’s loopback?  Nope!

By default, the above says, that without this command (ebgp-multihop) that for eBGP “only directly connected neighbors are allowed.”  If the default behavior is that only directly connected neighbors are “allowed,” this would mean that some type of check happens that realizes that R1’s loopback and R2’s loopback are not directly connected to each other and the attempted eBGP connection must, then, by default fail.  

So if it isn’t TTL that “fails,” then what?  

Well it basically seems to indicate in the above documentation that the default behavior is to check to see if the neighbors are directly connected.  For our eBGP peering between R1 and R3 back in beginning we knew two things

1. The loopbacks are not directly connected with each other
2. A TTL of 2 was going to be needed for the 2 loopbacks to get to each other

So riddle me this.  If I need a TTL of 2 (as in eBGP peering between R1 and R3) then can it even be in the realm of possibility that they are directly connected?  No.  If I literally need to change the TTL from the eBGP default of 1 to a TTL of 2 for the two IP addresses to even reach each other, then they must not be directly connected.

Therefore — when I configure ebgp-multihop to 2 — I must disable the code that does the checking to see if they are directly connected.  Right?  Of course right!

We don’t “need” a TTL of 2 to eBGP peer between R1’s loopback and R2’s loopback, we just need to disable the directly connected little test that it does by default when the TTL is set to 1.  

What if I could just do that?  Leave the TTL to 2 but disable that code that, by default, checks if the eBGP peers are directly connected?

“neighbor disable-connected-check”

This command has really been around for quite some time now.    

http://www.cisco.com/en/US/docs/ios/iproute_bgp/command/reference/irg_bgp3.html#wp1106122

Disable-connected-Check Into Action

And now we peer R1’s loopback with R2’s loopback with “disable-connected-check” on both routers and – VOILA!