BGP with Loopback

[Ganesan Palaniappan]

Hi,

I created a Lab for BGP with 3 routers. R1 and R2 are in same AS and running BGP.Peering with these made by loopback.
Now i added one more Router R3 with different AS Number having connectivity to R1 and again peering made by Loopback.

Now in R1 Router, I am able to see both R2 and R3 Fast ethernet routes.
And in R3 i am able to see both R1 and R2 Fast Ethernet Routes.
But in R2 i am able to see only R1 Fast ethernet routes but not R3 fast ethernet routes.

If i changed the Peering from Loopback to physical interface between R1 and R3 ...then i am able to see R3 fast ethernet routes in R2 Router.

Configured static routes between the Router to reach the Loopback interfaces.

Thanks and Regards,
Gan PL

[Peter Paluch · Accepted solution]

Hello,

It is possible that R2 does not know the route towards R3's loopback address. In default BGP configuration, the R3's loopback address will be the next-hop IP in all routes learned by R1 from R3 and advertised to R2 (the usual BGP next-hop attribute behavior). You may change this using the neighbor next-hop-self command on R1 towards R2. That will make all routes forwarded via IBGP from R1 to R2 contain the next-hop attribute set to R1's loopback which is already reachable from R2.

Best regards,

Peter

[lgijssel]

In addition to the above:

Did you configure the neighbor {ip-address | peer-group-name} ebgp-multihop on R3?

This line of config is required for eBGP when the peer ip is not on a directly connected subnet.

http://www.cisco.com/en/US/docs/ios/11_3/np1/configuration/guide/1cbgp.html

regards,

Leo

[Peter Paluch]

Hi Leo,

I had exactly this written in my original reply, but the OP states that R3 can see the networks on R1 and R2, suggesting that the BGP peering is up, so I eventually removed that comment from my post. In any case, it is a good thing to watch for!

Best regards,

Peter

[lgijssel]

Hi Peter,

Yes, I noticed this as well but decided to post it as it is unclear whether the routes are checked via show ip route or via show ip bgp. (I expect the first one.)

Comparing the output of both would provide a clue.

Your explanation is probably the root cause but still it is important to make the point of correctly configuring the neighbors.

regards,

Leo

[Ganesan Palaniappan]

Hi Peter,

Yes. After configuring neighbor < > next-hop-self in R1 for R2 Router, I am able to all the routes in all the router.

So, It is mandatory that next-self hop should be configured in between IBGP Routers if we are doing a peering with Loopback address in EBGP ?

I gone through so many PDF's and there is a saying that Loopback peering will be used only in the same AS and it is not a good practise to use in EBGP configuration. Also please need much more explaination of next-hop-self command usage.

Really Thanks for your answer . It's a two day discussion in my office for this and i aware of the command but not the usage.

Thanks and Regards

Ganesan PL

[cadet alain]

Hi,

for BGP routes to be selected as best routes in the BGP table and then installed in the Routing table and advertised in BGP updates the next hop of the prefix must be reachable.

EBGP update prepends AS number and change next-hop to the value of the update-source address but IBGP routers don't change the next-hop and don't prepend the AS.

So we you receive an EBGP update and it is advertised as an IBGP you must have a route to the next-hop which is the update-source address of the EBGP peer in the other AS and you can provide this IGP reachability by changing the next-hop value for IBGP neighbours with the neighbour x.x.x.x next-hop-self command.

If you were peering directly with the EBGP neighbour you could get the link network into your IGP by redistributing it or include it in your routing process with a network command.

Concerning peering with loopbacks: IBGP peers don't need to be directly connected and so are always peering with the loopbacks to keep the BGP peering up even if one of the physical links fails.

EBGP neighbours should be directly connected because EBGP TTL is set to one but they can peer over loopbacks in case of redundant physical links between them and if the neighbour x.x.x.x ebgp-multihop command is configured on both sides.

Regards.

Alain.