Hi Laz,
Can you explain, how is load balancing performing here?
On what basis paths are being prioritized b/c we did not mention anything in static route then how it’s being performed?
Hello Pradyumna
The lesson states that “we would like to use these for load balancing” but the purpose of the lesson is not to configure load balancing, so this is not described here. The point is that if you do want to create such a scenario, where load balancing between two directly connected links between BGP routers is desired, then it would be best practice to use a loopback as your BGP source rather than one of the physical interfaces. And as a result, this will require eBGP multihop.
If you want to learn about load balancing across multiple links in BGP, take a look at these lessons:
I hope this has been helpful!
Laz
Q-May I know the technical reason ,Why disable connected check does not work when the neighbors are not directly connected in our case between (R1 and R3). What exactly happens in packet ?
Q-2(Question Based on the below Diagram)
Can I establish the EBGP peering between R1 & R2 ?
if cant then why ??
what would be issue with the TCP session ??
In regards to the two router setup at the end, I am having trouble understanding the value of establishing the BGP neighbors. Does this actually load balance the two links? The routing table remains the same before and after establishing neighbors between the two loopbacks. Thanks for any feedback!
Hello Ylber
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:
I hope this has been helpful!
Laz
Hello Narad
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 1.1.1.2 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 2.2.2.1 via Fa0/0, which is on a different subnet.
I hope this has been helpful!
Laz
wow I went back and read some of my post. I am the most long winded person I know. It was painful to read my own post… 
Anyway good lesson and much easier to learn this stuff each time you relearn it.
1 Like
Hello YongHun
Take a look at this post:
I hope this has been helpful!
Laz
Hello Erik
Let’s take a look at the network diagram once again:
Assume that there’s a loopback interface on R1 with an address of 1.1.1.1/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 1.1.1.1, 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.
I hope this has been helpful!
Laz
where do u see that r1 refuse the pckt?
Hello Konstantinos
In Rene’s post, he says:
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:
The RST or reset flag is set whenever a segment arrives that doesn’t meet the criteria of a currently active session or connection. In other words, it refuses the connection.
I hope this has been helpful!
Laz
Hi,
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.
Thanks,
Sam
Hello Samir
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!
I hope this has been helpful!
Laz
Hi Laz,
Thanks for that, I read the RFC and there was useful TTL information under sections 4.2.2.9 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?
The only bit that I am unclear on is the explanation here: EBGP Multihop - #119 by lagapidis
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.
Thanks, Sam.
Hello Samir
Yes that is correct…
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.
I hope this has been helpful!
Laz
1 Like
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?
Thank you for a feedback.
Best regards
Aronne
Hello Aronne
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.
I hope this has been helpful!
Laz
Hi Laz,
Thanks a lot for your explanation.
Understand now.
Wish you a great day
Aronne
1 Like
Hello M ; tell me concretely why you configured the static route in this context, you could not directly configure BGP