EBGP Multihop

[lagapidis (Lazarus Agapidis)]

Hello Samir

@samirkhair

but do you still need to use disable-connected-check? Because even with the TTL increased, the neighbors are still not directly connected.

According to Cisco’s command reference for neighbor disable-connected-check, this command is only required when the neighbor ebgp-multihop command is configured with a TTL value of 1. The address of the single-hop eBGP peer must be reachable, which is what the connectivity check does.

However, when ebgp-multihop is set to a TTL of 2 or more, the disable-connected-check feature is implicitly enabled. (Just to be clear, when the feature is enabled, it means that the connectivity check itself is disabled. )

@samirkhair

but I also added a router in between as another test expecting the peering to fail because the ebgp-multihop was still 2 and needed to be increased to 3, however, it still worked.

It’s important to understand how the TTL decrement takes place, when it takes place, and when a router will discard the packet. For example, you must answer questions like:

• When is the TTL decremented? As soon as the packet is received? Before it is routed? After it is routed? Right before it is sent out the exit interface?
• When will a router drop a packet with a TTL of 1? Does it drop a packet that it decremented the TTL to 0? Does it send a packet that it decremented the TTL to 0? If a router receives a packet with a TTL of zero, does it drop it outright or does it process it without forwarding it?

These questions help us to determine how many hops we actually have. and whether or not the TTL will reach 0 before or after it gets to the loopback address. A post that is helpful to determine this can be found below:

EBGP Multihop

Hello Bala The specific process that is followed in the scenario you describe from the lesson is the following: R1 prepares to send the packet to R3, and sets the TTL to 1. R1 will make its forwarding decision (chooses the egress port) using the destination IP address of R3 and its routing table. Before egress, the TTL is checked to see if it must be dropped or not. TTL is not equal to 0, so it is not dropped. The packet is sent R2 receives the packet. As per RFC1812 a router will not disca…

Ideally, I suggest you look at a Wireshark capture at the various locations of the BGP message’s journey from one router to another and follow along to see the values of the TTL. That way, you can determine how the TTL is being decremented and why the peering is successful. Let us know how you get along!

I hope this has been helpful!

Laz