EBGP Multihop

in the other word what is the benefit of disabling connected check, since when we increase the TTL the routers will know that they are not direct contacted ?

Hi Hussein,

Disabling the connected-check is only useful when you have two routers and you want to connect through eBGP using their loopback interfaces. This is the only scenario where it will work. If the routers are not directly connected then you always have to increase the TTL, there’s no point disabling the connected check then.

There’s not really any benefit “over” increasing the TTL, both will work.

Rene

Hi Rene,

What do you think to create a GRE tunnel between R1 and R3 so that BGP neighbors can reach the other one? Is that possible? I think in this way R2 doesn’t have to know anything about the BGP routes.

Thanks

Hi Diana,

Configuring a GRE tunnel between R1/R3 is a valid solution yes. When you configure BGP, you have two options:

  1. Establish the BGP neighbor adjacency using the tunnel addresses.
  2. Establish the BGP neighbor adjacency using the physical interfaces and then use a route-map to change the next-hop to the tunnel addresses.

Rene

In your example R1:

R1(config)#router bgp 1
R1(config-router)#neighbor 2.2.2.2 remote-as 2
R1(config-router)#neighbor 2.2.2.2 update source loopback 0
R1(config-router)#neighbor 2.2.2.2 ebgp-multihop 2

You said “we also have to use the update-source command to tell the routers to use the IP address on their loopback interface as the source IP address for the eBGP neighbor adjacency”

The 2nd command “neighbor 2.2.2.2 remote-as 2” – what does that do? That doesn’t establish R2 as the source?

Hi Jason,

R1(config-router)# neighbor 2.2.2.2 remote-as 2

That command instructs R1 to establish a neighbor relationship with 2.2.2.2. It does not, however, tell R1 to use any specific interface as source or “from” address when establishing the relationship. By default, BGP will try to use the closest interface to the neighbor to establish the relationship. Knowing this, what do you suppose would happen if we just used the command above to try to establish a BGP neighbor relationship with R2?

From R2’s perspective it would be receiving packets from R1, but the source address would be R1’s closest inteface–in this case either 192.168.12.1 or 192.168.21.1. Now, assuming that the administrator correctly setup R2 ahead of time, R2 is expecting a relationship with R1, but only from the source address of 1.1.1.1 (R1’s loopback). The reason for this is because the R2 administrator has already typed in “neighbor 1.1.1.1 remote-as 1” on his side.

When the BGP Open packet arrives from R1, but not from 1.1.1.1, R2 will ignore it, so a relationship will never be formed! This is why the additional command of: “neighbor 2.2.2.2 update source loopback0” is necessary. R1 is being told, “Whenever you talk to R2 at 2.2.2.2, be sure to use the loopback interface as the packet source.”

--Andrew

3 Likes

Hi Rene,

I guess there is a typo in this line after the first image:

“First I will create some static routes so that R1 and R2 are able to reach each other”

I think it should be

“First I will create some static routes so that R1 and R3 are able to reach each other”

Thanks,

Tooryalai

1 Like

Hi Tooryalai,

For sure, I just fixed this error. Thanks for letting me know!

Rene

1 Like

Hi Rene,

Will the load balancing between 2 ebgp peers be per packet or per flow ?

Hi Vikas,

The default on Cisco IOS is per-destination load balancing so that also applies to BGP.

Rene

Nice tutorial, one design question:

imagine instead of using loopback interfaces for configuring the 1 BGP session, instead we just configure multiple sessions (one per link), R1 will then install the prefix on the RIB and show as possible next hops the 2 ips configured on the interfaces of R2… besides adding more configuration and load on the BGP process (2 sessions instead of 1) and removing the need of care about loopback interfaces, do you see any criterias to prefer one solution or the other?

Edward,
What you describe will work. The answer as to whether you should do this comes down scenario-specific criteria. Since the example in this lesson is external BGP, there really isn’t an an advantage of using loopbacks or multiple connections over different links.

You will most often see loopback based peering in an iBGP scenario where the traffic is traversing a network under your own control. In this case, it is much better to use loopbacks because internal routing protocols can achieve sub-second convergence in the event of a path failure.

By the way, there are some scenarios, like MPLS Layer 3 VPNs, where you must use loopbacks or the network will fail.

Hi Rene, What if you don’t know the number of hops of your neighbor router. What is going to be the configuration or is there any replacement for ebgp-multihop command ? Thanks

Hi Rene, What if you don’t know the number of hops of your neighbor router. What is going to be the configuration or is there any replacement for ebgp-multihop command ? Thanks

Venus,
In this situation, you can do two things:

  1. (config-router)#neighbor 10.10.10.10 ebgp-multihop 255

  2. Run a trace route from your router to the neighbor. Take the hop count from that. I usually pad it out by about three.

Method #2 is the more desirable one, fyi.

2 Likes

Hi Rene

I have a question about load balancing with respect to routing. Here we have this static routes doing the load balancing for BGP messages. What kind of load balancing this is, is it per packet basis or something else?
Also does this load balancing concept same for all routing protocols?

R1(config)#ip route 2.2.2.0 255.255.255.0 192.168.12.2
R1(config)#ip route 2.2.2.0 255.255.255.0 192.168.21.2

Thanks
Palani

Hi Palani,

Cisco IOS routers use CEF (Cisco Express Forwarding) for the forwarding of packets.

The default is “per destination” load balancing but you can change it per interface. For example:

R1(config)#interface GigabitEthernet 0/1
R1(config-if)#ip load-sharing per-packet 

Routing protocols are used to learn different routes, CEF is used for the forwarding of traffic. If you change the load sharing type then it will apply to all traffic.

Rene

Great, Thanks Rene.

Hi Rene ,

I think no more option to use load sharing per packet at Cisco at least .
the only way to use real load sharing is Pfr .

Regards ,
Shady

Hi Rene,

Just a quick question to ask about BGP:

Something is not clear for me in BGP which I need to ask you:
Sometimes in BGP we use network command to advertise our routes to BGP but sometimes we just use neighbor command and we don’t advertise any network.

I am aware we use neighbor to build adjacencies and I am also aware that we use network command to advertise routes in to BGP. Can you please tell me why in some senarios we don’t use network command which makes neighbor command both for adjacencies and also advertisement…

Thanks.