In this example, Rene is showing how two routers can become BGP neighbors while taking advantage of the redundancy provided by two links between those routers.
Now there are two separate concepts being described here. One is the choice of the loopback interface as the update source for BGP (and thus the need for multihop), and the other is the redundancy/load balancing between the two routers achieved via multiple physical links and static routes.
The primary idea of the lesson is how to achieve a BGP peering without compromising the redundancy provided by the two links. If Fa0/0 or Fa0/1 were used for the peering on both routers, and if that link fails, the BGP peering fails even though there is a second link between the routers. By creating the loopback, using that as the update source, and using multihop, the BGP peering will be maintained even if one of the physical links fail.
The redundancy provided in this case, is a redundancy for the BGP peering (as well as any other traffic that may be traversing the links).
If we look simply at the redundancy/load balancing nature of this topology, independent of BGP peerings, then we can see that the two static routes in both routers are both placed within the routing tables. Whenever there are two routes to the same destination within the routing table, load balancing is automatically performed. The algorithm used to load depends on the forwarding mechanism configured on the device. You can find out more about such load balancing at the following Cisco documentation.
The network topology as it is in the lesson truly doesnât show how load balancing can be effective. But remember, that this example is simply being used to show how to use EBGP Multihop in order to achieve BGP neighbor adjacency when using loopbacks as the BGP update source.
Imagine you have a huge Network behind each of the routers like so:
Imagine that Network A and Network B communicate with each other with a lot of traffic. In order to accommodate this traffic, you have created redundant links. You arrange routing (or will arrange routing) such that the links are used equally. This can be done in several ways one of which is BGP Multipath load sharing.
Regardless of the load balancing being implemented, you want to create an eBGP peering. You could use one of the interfaces (Fa0/0 or 0/1) as the BGP source for either router, but then you defeat the purpose of load balancing, because if that interface goes down, BGP peering is lost, and the redundant link is useless, even if it still remains up.
For this reason, using a loopback as the BGP source, and eBGP multihop, the problem is solved. So even if an interface goes down, the BGP peering remains up and traffic is still served over the remaining link.
Hi
I am stuck on the first step. When I create static routes R1 and R3 cannot ping each other. I think its because R1 does not know about F1/0 interface of R2. Should they ping each other?
Thank you
Make sure that you are correctly configuring the static routes in the routing table. Notice that in R1, the route is to 192.168.23.3 which is the IP address of the Fa0/0 interface of R3, and the next hop is the IP address of Fa0/0 on R2.
For the static routing configuration of R3, we have a similar situation where the route is to 192.168.12.1 which is the Fa0/0 interface of R1, with a next hop IP address of 192.168.23.2 , which is the Fa1/0 interface of R2.
This should be enough for R1 to communicate with R3, since R2 has both the 192.168.12.0/24 and 192.168.23.0/24 networks directly connected.
Make sure that your config matches that of the lesson exactly, and you should find that the routing works. I just labbed it up to try it out too, and everything seems to be in order.
I still failed to understand why do we need to configure eBGP Multi-hop to form neighbourship between R1âs loopback to R2âs loopback interface.
I have created a similar topology in GNS with only one link in between R1 and R2 and I have not configured eBGP mult-hop command still I could see I am able to ping from R1-R2 and from R2-R1, please clarify on thisâŚ
By default, eBGP peerings can take place only between directly connected neighbors. More accurately, they can only take place between directly connected interfaces on directly connected neighbors.
For example, take a look at the following diagram from the lesson:
If you were to create a peering between the Fa0/0 interfaces of R1 and R2, then you would have no problem in creating your eBGP neighbors. But what happens if you want to use the loopbacks as the peering interfaces? They are not directly connected interfaces.
Actually, the two loopbacks are two hops away from each other. If you were to ping from 1.1.1.1 to 2.2.2.2, then the first hop is from R1 to R2, and the second hop is from R2 to the loopback. Because of these two hops, an eBGP peering will never form between the loopbacks. Remember, BGP uses a TTL of 1, so the TTL will decrement to 0 before reaching the other loopback. So you need to increase that TTL by using the multihop feature.
You must remember that the purpose of the multihop feature is not to enable routing between the loopbacks, or between the routers, but to enable a BGP peering between interfaces with a hop count of more than 1 between them. In order for the peering to take place, network connectivity between the routers must be established, so the fact that you can ping is not relevant in this case.
Hi Rene,
Are you able to provide a little more information as to why peering with neighbour through a transit router is a bad idea? Would it not still have the source and destination in the packet header as it does to bring up the peering?
hostname R1
!
interface gi0/0
ip address 192.168.12.1 255.255.255.0
no shut
des Link to R2
exit
!
ip route 192.168.23.3 255.255.255.255 192.168.12.2
!
router bgp 1
neighbor 192.168.23.3 remote-as 3
neighbor 192.168.23.3 ebgp-multihop 2
and:
*Nov 30 15:29:14.337: %BGP-5-ADJCHANGE: neighbor 192.168.23.3 Up
but:
R1#show ip bgp neighbors | include External
External BGP neighbor may be up to 2 hops away.
External BGP neighbor NOT configured for connected checks (multi-hop no-disable-connected-check)
Yes, your output is ok as well. It seems that you are using IOS-XE on your device whereas Rene is using an older version of IOS for this particular lesson, so the output is different.
The messages in your output simply state that the BGP neighbor is not directly connected and that the BGP neighbor verification is disabled on this router. You can enable it if you like, using the commands described in the following CIsco CLI reference.
Iâve done the configurations for the scenario with 2 links using loopbacks to connect to each other, and when I shut down one of the physical links I canât ping anymore. I prefers one link over the other and doesnât fail over to the second link.
I think youâre missing some configs here.
I have a successful neighborship, I can advertise and receive routes, but when I shut down one link I canât ping the loopback anymore. Whatâs going on?
Itâs important to note that in this topology, BGP is not playing any role in the connectivity between the two loopbacks. Routing between the two loopbacks must first be established before eBGP peerings can take place. So we can examine the connectivity between the two loopbacks independently from BGP. Here is the topology once again:
In the lab, R1 is configured with two static routes to the 2.2.2.0/24 network, and similarly, R2 is also configured with two static routes to 1.1.1.0/24. Because these static routes are equal-cost routes, they will automatically perform load balancing. This configuration is enough to ensure that the two loopbacks can indeed ping each other, even if one link goes down.
Now I labbed this up and checked this connectivity. I was able to ping from L0 of R1 to L0 of R2 while shutting down one of the two links between the routers. I did lose a couple of pings but connectivity was quickly restored.
Now once this connectivity is established, you can then create the BGP peering between the devices. Once again, this lab demonstrates the best practice for BGP peering, that is, to use loopbacks and ensure multiple redundant links between the routers so that BGP peerings will not be lost in the event that an interface goes down.
Thank you for the explanation.
I figured out what the issue wasâŚIâm using GNS and when I shut the interface down on the other end it still showed up on the switch I was pinging from. When I shut down the interface on the switch I was initiating the ping from it used the other link to reach the Loopback as itâs supposed to.
Hello Rene,
What can be the practical use of âdisable-connected-checkâ ? Because, we just needed only ebgp-multhop command to make routers which are mult-hopes away to be neighbors.
Thanks
The multihop feature and the disable connected check do two different things.
When an eBGP peering is attempted, based on the neighbor commands under the BGP configuration mode, the first thing the router does is determine if the neighbor is directly connected. How does it do that? It checks to see if the IP address of the neighbor belongs to a subnet that is connected to any of its interfaces. It does this by comparing the neighborâs IP address with the directly connected routes in the routing table. If the neighborâs IP address is not in one of those subnets, the router doesnât even attempt to send out any BGP messages. If it is, it will create the BGP peering using the directly connected interface as the BGP source.
By issuing the disable connected check command, this check is skipped. It doesnât affect the TTL used or any other parameter.
Now if eBGP peerings are taking place using loopback interfaces, then the requirement is that the neighborâs IP address will indeed not be directly connected to the loopbackâs subnet. So, if you have the situation where two directly connected routers use a loopback as the BGP source, you can use the disable connected check feature to allow them to become BGP peers, but only for directly connected routers.
Alternatively, you can use the multihop feature to do so. But for routers with multiple hops between them, only the multihop feature will suffice since the TTL must be increased.
