Myth: You have to set ttl to 2 because it is decremented on the way to the loopback.
**This blog is a formatting cleanup and update to a previous blog I posted in 2013 on NetworkWorld.
Years and years ago I was trying to learn more about BGP and I was reading some book with a chapter on the topic. Back then I pretty much believed that if it made it into a book it must be true and my knowledge had to be in error. 🙂 So to say I was confused back then would be an understatement.
Why? Well ya see… they basically said that the reason one must set the TTL to 2 for eBGP peers that are directly connected, but peering with their loopbacks, was cause “the TTL gets decremented on the way to the loopback”
When I try to help someone deprogram this brain washing, I find pictures help. So for those who’d like to get deprogrammed and learn the truth… Let’s go play in the lab!!!
In the picture above we have 3 Routers in 3 different BGP ASes. 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.
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
Actually… you know what? 🙂 Instead of peering R1:R2 loopback to loopback… let’s actually try to eBGP peer R1’s loopback to R3’s loopback.
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 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
As you can see below… all those pings were successful.
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 for 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.
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
- A TTL of 2 would be needed to ping R3 from R1
- A TTL of 2 would be needed to eBGP peer between R1 and R3
So riddle me this. If I need a TTL of 2 for successful eBGP peering between R1 and R3 whether via loopback or physical 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 — the underlying code 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?
This command has really been around for quite some time now.
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!
Hope you had fun playing in the lab! 🙂