Pages

Tuesday, May 14, 2013

1.3 UPDATE-SOURCE AND EBGP MULTIHOP

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 :

EBGP update source and ebgp multihop
Fig 1.3.1













R5 configuration :

EBGP update source and ebgp multihop
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.

No comments:

Post a Comment