It’s important to note that the focus of this lesson is on creating BGP peers. In a topology such as the one shown at the end of the lesson, you have two links. Regardless of how user traffic traverses these links, your BGP peering must take place over those links. If you use physical interfaces on the routers as the source of the BGP peering, then the BGP peering will go down too, even though there is a second redundant link. So in essence, you lose the redundancy that a second link could provide to your BGP peerings.
By using loopbacks, and the multihop feature, you are sourcing the BGP peerings from loopbacks. If any single physical link fails, the BGP peering will still remain up. So the redundancy delivered in this case is to the BGP peering itself. It is a redundancy on the control plane.
Now once you establish this redundancy, you can then take care of using both links for user traffic, on the data plane. In order to do that with BGP, you can use features such as BGP Multipath and BGP Additional Paths, which appear in the following lessons:
There are two different mechanisms taking place. One is the connected check, the other is the TTL setting. The connected check will check to see if the IP address of the neighbor is on the same subnet as one of the interfaces of the local router. If it is, then everything is OK. If it is not, it will not even try to establish connectivity. Once you disable this check, it no longer examines the subnet of the IP address of the neighbor, so it starts to send BGP update packets normally.
But we still have the TTL check. So these packets will be sent, but will never reach the neighbor since the TTL check is set, and the neighbor is more than one hop away. The TTL will reach zero so the update will never reach the intended neighbor.
This is why we must disable the connectivity check AND enable multihop in such a scenario.
Concerning your second question, I tried labbing this up and found that this will not work. Remember that BGP peerings depend upon proper IGP routing set up between the peers. In order for a peering to take place, the neighbor IP addresses must be reachable between peers.
Now in your scenario, R1 is trying to peer with 22.214.171.124 via the Fa0/1 interface. However, there is no route to this destination via that interface. The same is true on R2, where it is trying to reach 126.96.36.199 via Fa0/0, which is on a different subnet.
Assume that there’s a loopback interface on R1 with an address of 188.8.131.52/32.
Now when a router has an IP packet that it wants to send (whether that packet is generated by the router itself or it is a packet that has entered from another interface), it must decide out of which interface it must send it. To do so, it takes the destination address of the packet and compares it to the entires in its local routing table. If an entry is found, it sends it out of the appropriate interface. If an entry is not found, it drops the packet.
Now if R3 is trying to ping 184.108.40.206, it will look in its own routing table. Since there is no such entry, and since there is no configured default route, the packet will be dropped.
Keep in mind that the next hop is not contained within the packet itself, but is derived from the local routing table. Note that this whole process is independent of any BGP or multi-hop configurations.
For more information about this routing table lookup process, take a look at the following lesson.
In the cloudshark capture that he shared, you can see in packet number 7 the Reset flag is set to 1. This is also indicated with the “RST” flag shown in the info column of the capture, as indicated below:
I just want to clarify the usage of ebgp-multihop and disable-connected-check:
I understand that increasing ebgp-multihop is necessary when there is a situation where the TTL could be reduced to 0 before the packet reaches its neighbor (as per your example), but do you still need to use disable-connected-check? Because even with the TTL increased, the neighbors are still not directly connected. I tested above and came across some strange behavior. I can see that increasing the multihop to 2 works on its own for reaching routers’ loopbacks (without disable-connected-check), which makes sense, 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. I know there wont be a TTL issue because its still enough for the routers to reach each other, but I expected it to fail because you still need to increment to 3 as I am trying to peer using loopbacks.
Also, in the situation where the neighbors are directly connected but using Loopbacks to peer, is it better to increase the multihop to 2 or use disable-connected-check?
And if you use the neighbor ebgp-multihop command without specifying a value, which I have seen done, what does it change the TTL to? I can seem to find an answer online, only that the default is 1.
Update: I just checked above and it seems if you exclude a value it defaults to 255.
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. )
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:
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!
Thanks for that, I read the RFC and there was useful TTL information under sections 220.127.116.11 and 5.3.1 (5.3 Specific Issues), and they made sense. So the TTL is only deducted if it is being forwarded. This explains why the connected check works on its own without modifying the TTL, and, if the routers are not directly connected but you are using ebgp-multihop, it still works because the disable connected-check is implicitly enabled
So, I’m correct in assuming that because the loopback IP is an interface on the router, it is not being forwarded and the TTL is not decremented to 0 then dropped?
I understand that the TTL is decremented and then checked when being forwarded, but does this still occur if the router is the source of the packet? Step 4 seems to imply this as I have run captures on my lab and the TTL is still 1 after leaving the router.
I looked into it more, did some labbing, and confirmed what you are saying. Indeed, even though the packet originated on the loopback interface when it is forwarded out of the Gi0/1 interface, the TTL is not decremented. I have since modified the post to correct it.
What I have found is that when a router along the path receives a packet with a TTL of 1, it will not forward it, but it will consider it as “destination unreachable” and will send an ICMP message to that effect. Now, if that router is not the final destination, it will send the destination unreachable message to the originating host. If that router is, however, the destination, the packet has arrived and must be processed by the local device.
TTL can be confusing to get your head around, but hopefully, this has shed some light on the subject.
Hi Rene, Hi Laz,
I’m missing something about the next hop…
What Is the difference between configuring ebgp-multihop 2 in case of loopback neighborship and next-hop self ?
Does the second command not accomplish the same thing as the first?
As best practice should i configure always next-hop self or should i let It work in specific cases?
Both next-hop-self and ebgp-multihop are features that can be used in the context of eBGP to enable communication between peers that are not directly connected. However, each one serves a different purpose.
The next-hop self feature is used to modify the next hop attribute of the prefixes that you advertise to your eBGP neighbor, so that the next hop IP address is changed to your own IP address. This ensures that the packets are sent to you, and then you can forward them to the correct destination. This feature is used when the eBGP neighbor is only one hop away from your router, but the next hop attribute of the prefixes advertised by your neighbor needs to be modified to ensure correct routing.
On the other hand, the ebgp-multihop feature is used when the eBGP neighbor is more than one hop away from your router, and the TTL (Time To Live) value of the packets sent to the neighbor needs to be increased to allow the packets to reach the neighbor. By default, eBGP neighbors are expected to be directly connected, and packets sent to them will have a TTL value of 1. The ebgp-multihop feature allows you to increase the TTL value, so that the packets can traverse multiple hops to reach the neighbor.
So next-hop self feature is used to modify the next-hop attribute of the prefixes advertised by your directly connected neighbor, while the ebgp-multihop feature is used to increase the TTL value of packets sent to an eBGP neighbor that is more than one hop away.
The static routes were configured in this case in order to achieve connectivity between the BGP peers. Remember, in order for BGP to operate, BGP peers must be able to find each other. That means that routing between those BGP peers must already be established, either by using IGPs or by using static routes.
This might sound a little bit strange because BGP is a routing protocol. Why do you need other routing protocols to enable communication between BGP peers, in order to exchange routes? Take a look at this NetworkLessons note on why we need an IGP for BGP to work, and if you have any further questions, please let us know.