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\u00a0eBGP peer between their loopbacks because the TTL "gets decremented on the way to the loopback." The web,\u00a0ya 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. \u00a0We 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. \u00a0But let's try to peer with the loopbacks. \u00a0In fact, let's actually try to eBGP peer R1's loopback to R3's lookbackThrough\u00a0the use of some quick static routes, they have full connectivity to each other's loopback addressesR1 is in BGP AS #1R2 is in BGP AS #2R3 is in BGP AS #3R1 and R3 eBGP Peer with a TTL of 2What if I told you that I can eBGP peer between R1 and R3 with a TTL of 2? \u00a0Don't take my word for it. \u00a0Let'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 BackLet's take one giant step backwards and look at this not from a BGP perspective. \u00a0Let'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. \u00a0Wanna take bets? \u00a0I'm bettingTTL of 1 is sufficient to reach R1's loopback addressTTL of 2 is sufficient to reach R2's loopback addressTTL of 3 is sufficient to reach R3's loopback addressAny takers?So Then Why?Since R1 and R2 only need a TTL of 1 to get between their respective loopbacks,\u00a0\u00a0why do we "need" to\u00a0set eBGP multihop to 2 if R1 and R2 for eBGP to work?The truth is we actually don't "need" to.Off to Read DocumentationLet's do a quick google search for neighbor ebgp-multihop.\u00a0---(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." \u00a0So, is R1's loopback directly connected to R2's loopback? \u00a0Nope!By default, the above says, that without this command (ebgp-multihop) that for eBGP "only directly connected neighbors are allowed." \u00a0If the default behavior is that only directly connected neighbors are "allowed,"\u00a0this 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. \u00a0So if it isn't TTL that "fails," then what? \u00a0Well it basically seems to indicate in the above documentation that the default behavior is to check to see if the neighbors are directly connected. \u00a0For our eBGP peering between R1 and R3 back in beginning we knew two thingsThe loopbacks are not directly connected with each otherA TTL of 2 was going to be needed for the 2 loopbacks to get to each otherSo riddle me this. \u00a0If I need\u00a0a 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? \u00a0No. \u00a0If 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. \u00a0Right? \u00a0Of 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. \u00a0What if I could just do that? \u00a0Leave 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. \u00a0 \u00a0http:\/\/www.cisco.com\/en\/US\/docs\/ios\/iproute_bgp\/command\/reference\/irg_bgp3.html#wp1106122Disable-connected-Check Into ActionAnd now we peer R1's loopback with R2's loopback with "disable-connected-check" on both routers and - VOILA!