Changing the interfaces on R2 and R5 on which EBGP peering has been established.
Preconfiguration :
Please check the BGP case study 1.2 EBGP peering as the configuration follows from there.
What are we actually doing here???
You have seen from the previous case studies that the BGP peering was done on directly connected physical interfaces. Now, peering on directly connected physical interfaces is definitely the one of the most important criteria for most IGP (Interior Gateway protocols like OSPF). However, this is not the case with BGP. On the contrary, most real world scenarios have BGP running on the loopback interfaces.
Running BGP on the loopback interfaces has the following advantages :
1. A loopback interface is always in UP/UP state (So long as you are not explicitly shutting the interface DOWN. (Now why would you do that?????)). This means that even if the physical interface goes down, so long as there is an alternate path to the loopback (on which the BGP peering has been established), the peering will remain intact.
2. If there are multiple links to the peer (loopback on the remote router on which the BGP peering actually exists), you can load balance the traffic.
Moral of the Story : Here we are establishing the EBGP peering between R2 and R5 using their Loopback 0 interace (and not the physical interface).
R2 configuration :
R5 configuration :
Explanation :
1. Firstly, we are creating static routes on both R2 and R5 since there is no other way for these routers to find out the path to the remote loopback address on which they are forming the EBGP peering.
2. Secondly, we are removing the previous EBGP configuration that had created the BGP peering on the physical interface.
UPDATE-SOURCE :
Now let us understand the basic behaviour of the BGP :
As soon as you enter the "neighbor <IP> remote-as <AS-NO>", the router will use its local interface which is closest to the above configured IP. In our case, since the remote IP address was on the directly connected link, the local IP that the router chose, for the BGP peering was the directly connected interface.
To override this, we will specify the interface on which we desire to establish the BGP peering.
We do this using the command "neighbor <IP> update-source <interface>" under the BGP configuration.
EBGP MULTIHOP :
Now adding the command "neighbor <IP> update-source <interface>" after "neighbor <IP> remote-as <AS-NO>" will suffice in case of the IBGP neighborship.
However, for EBGP peering you need to include an extra command "neighbor <IP> ebgp-multihop <1-255>"
Significance of the command is that although you can create IBGP across multiple router hops, EBGP neighbors by default must be directly connected. This is because by default, when BGP hello packets are sent over EBGP link, the TTL is set to 1. But in our scenario, the hello packets need to travel 2 hops. (When the R5's BGP hello reaches the R2's physical interface, the TTL gets reduced by 1, which means the TTL becomes zero and hence the hello is dropped.)
By incorporating the command "neighbor <IP> ebgp-multihop <1-255>" we are actually increasing the TTL of the hello packet. In our case, our hello has to travel 2 hops. Hence, we have given the "ebgp-multihop" value of 2. If no value is entered, the Cisco IOS by default, takes the value of 255.
Preconfiguration :
Please check the BGP case study 1.2 EBGP peering as the configuration follows from there.
What are we actually doing here???
You have seen from the previous case studies that the BGP peering was done on directly connected physical interfaces. Now, peering on directly connected physical interfaces is definitely the one of the most important criteria for most IGP (Interior Gateway protocols like OSPF). However, this is not the case with BGP. On the contrary, most real world scenarios have BGP running on the loopback interfaces.
Running BGP on the loopback interfaces has the following advantages :
1. A loopback interface is always in UP/UP state (So long as you are not explicitly shutting the interface DOWN. (Now why would you do that?????)). This means that even if the physical interface goes down, so long as there is an alternate path to the loopback (on which the BGP peering has been established), the peering will remain intact.
2. If there are multiple links to the peer (loopback on the remote router on which the BGP peering actually exists), you can load balance the traffic.
Moral of the Story : Here we are establishing the EBGP peering between R2 and R5 using their Loopback 0 interace (and not the physical interface).
R2 configuration :
 |
| Fig 1.3.1 |
R5 configuration :
 |
| Fig 1.3.2 |
Explanation :
1. Firstly, we are creating static routes on both R2 and R5 since there is no other way for these routers to find out the path to the remote loopback address on which they are forming the EBGP peering.
2. Secondly, we are removing the previous EBGP configuration that had created the BGP peering on the physical interface.
UPDATE-SOURCE :
Now let us understand the basic behaviour of the BGP :
As soon as you enter the "neighbor <IP> remote-as <AS-NO>", the router will use its local interface which is closest to the above configured IP. In our case, since the remote IP address was on the directly connected link, the local IP that the router chose, for the BGP peering was the directly connected interface.
To override this, we will specify the interface on which we desire to establish the BGP peering.
We do this using the command "neighbor <IP> update-source <interface>" under the BGP configuration.
EBGP MULTIHOP :
Now adding the command "neighbor <IP> update-source <interface>" after "neighbor <IP> remote-as <AS-NO>" will suffice in case of the IBGP neighborship.
However, for EBGP peering you need to include an extra command "neighbor <IP> ebgp-multihop <1-255>"
Significance of the command is that although you can create IBGP across multiple router hops, EBGP neighbors by default must be directly connected. This is because by default, when BGP hello packets are sent over EBGP link, the TTL is set to 1. But in our scenario, the hello packets need to travel 2 hops. (When the R5's BGP hello reaches the R2's physical interface, the TTL gets reduced by 1, which means the TTL becomes zero and hence the hello is dropped.)
By incorporating the command "neighbor <IP> ebgp-multihop <1-255>" we are actually increasing the TTL of the hello packet. In our case, our hello has to travel 2 hops. Hence, we have given the "ebgp-multihop" value of 2. If no value is entered, the Cisco IOS by default, takes the value of 255.
Hi Mate,
ReplyDeleteThis is not correct.I also had this wrong assumption.
When you try to configure BGP neighborship between 2 peers using their loopback interfaces, it does not make the hop count 2 to reach from 1 router to the loopback interface of the other router.
They are still just 2 hops away. You must count routers, not links. When sending packets to a distant router, with respect to the hop count, it is irrelevant which of the destination router's IP addresses you are talking to.
I believe that a part of this confusion stems from the fact that when we have two routers connected back to back and run eBGP between them, you are told to use ebgp-multihop 2 if you are peering them using their loopbacks. This creates a notion as if talking to the opposite router's loopback involved decrementing the TTL. However, there is a totally different and slightly hidden agenda inside: Cisco's BGP implementation makes two precautions when establishing eBGP neighborships:
It checks whether the client is on a directly connected network. If it is not, it does not even try to establish the relationship(loopback IP of the peer router can't be the connected route for the local router ). This check can be deactivated on a per-neighbor basis using the neighbor disable-connected-check.
Now, the BGP connection also comes up when we configure ebgp-multihop 2 in place of disable-connected-check.
This is because by default (for ebgp neighborships) router considers the peer to be just 1 hop away, but when we put ebgp-multi-hop 2 it considers that the peer may be 2 hops away and thus does not perform direct connected check (also called samecable check in cisco terms), thus the BGP comes up.
so in brief if the ebgp-multihop is configured(in the above case study), the router automatically and implicitly behaves to the neighbor as if the disable-connected-check was configured. In other words, using ebgp-multihop automatically implies disable-connected-check
In fact, the disable-connected-check was created precisely for the purpose of peering two back-to-back routers on their loopbacks without using the ebgp-multihop. So in other words, if you're talking to a directly connected eBGP neighbor by its loopback address, you are perfectly fine with TTL=1 (i.e. don't use the ebgp-multihop), just use the disable-connected-check and the peering will come up.
Regards
Jaideep CHoudhary
Hi Jaideep,
ReplyDeleteThanks a lot for this excellent point.. Can you please share a Cisco / RFC link, so that we can add some credence to the fantastic explanation above?
Regards,
Tejas Jain