BGP Route-Reflector and Confederations

[tsalt]

Is it possible to have a multiple RR inside a Confederated AS.

I have configured a BGP network with a Confederated AS that has 2 sub AS's. I then put a RR in each Sub AS. I could not then get the 2 RR to establish a connection without the eBGP Multihop command.

The issue I have is that the RR then advertise them selves as the next-hop. I thought that the next hop shoudl not change within a confederation on on a real eBGP session.

Enclosed are my RR configs.

Plesae could somebody advise?

[royalblues]

Are your RR's directly connected?

If not then i think EBGP multihop will be needed as a confederation inherits most of the characteristics of a true EBGP connection.

eBGP sessions between confederation sub-ASes does not modify the next hop attribute.

I will try to simulate a similar scenario and check

Narayan

[tsalt]

Dear Narayan,

Many thanks. No they are not directly connected. I did have eBGP multihop configured as this was the only way to bring up the BGP session.

But all routes learn't from the other sub-AS has the next-hop changed to be the RR. As this is an IP-VPN network I do not want the Next-Hop changing.

[tsalt]

Many thanks.

I have been doing more testing and from teh debugs can see that the LDB-RR-LB1 was sending out the prefixes with the wrong next-hop.

*Mar 3 17:59:36.979: BGP(1): 212.137.1.253 send UPDATE (format) 5551:46001:63.130.56.8/32, next 212.137.1.14, metric 0, path 64810, extended community RT:5551:11 RT:5551:46001

*Mar 3 17:59:36.987: BGP(1): 212.137.1.253 send UPDATE (format) 5551:46001:63.130.56.10/32, next 212.137.1.14, metric 3, path 64810, extended community RT:5551:11 RT:5551:46001

I therefore obtained a new router and a different IOS. Using the same BGP configuration this router did send the routes out to the ebgp peer with out altering the next hop, and therefore obeyed the confed eBGP rules.

The only thing I think that might have been causing it was the following entry in the debug:-

*Mar 3 17:59:21.083: BGP(1): 212.137.1.13 rcvd 5551:46000:63.130.56.8/32 -- DENIED due to: extended community not supported;

But a later update was not denied.

Many thanks for your help I now have a working solution.

[Harold Ritter]

You need the ebgp-multihop between 64550 and 64551 since the eBGP session is configured to use the loopback addresses instead of the physical interfaces. This is normal behavior for an eBGP session even between two sub-ASes.

As far as the RRs changing the BGP nh for the routes learnt from the RR clients, this is definitely not normal.

Could you please attach a "show ip bgp v a x.x.x.x" on ldn-rr.lb2 for one of the prefixes originated from one of the RR clients connected to the other RR.

Hope this helps,

[tsalt]

Thanks.

I did have BGP Multi-Hop configured as this was the only way to get the neighborship established.

Will get you the output tomorrow when I am in the office.

[Harold Ritter]

I know you have it in your configuration. The comment I made was aimed at the fact that you said that you couldn't get the session up and running without it, which is completely normal as you are using the loopback interface to establish the session.

Hope this helps,

[tsalt]

Many thanks, sorry I misunderstood.

I have been doing more testing and from teh debugs can see that the LDB-RR-LB1 was sending out the prefixes with the wrong next-hop.

*Mar 3 17:59:36.979: BGP(1): 212.137.1.253 send UPDATE (format) 5551:46001:63.130.56.8/32, next 212.137.1.14, metric 0, path 64810, extended community RT:5551:11 RT:5551:46001

*Mar 3 17:59:36.987: BGP(1): 212.137.1.253 send UPDATE (format) 5551:46001:63.130.56.10/32, next 212.137.1.14, metric 3, path 64810, extended community RT:5551:11 RT:5551:46001

I therefore obtained a new router and a different IOS. Using the same BGP configuration this router did send the routes out to the ebgp peer with out altering the next hop, and therefore obeyed the confed eBGP rules.

The only thing I think that might have been causing it was the following entry in the debug:-

*Mar 3 17:59:21.083: BGP(1): 212.137.1.13 rcvd 5551:46000:63.130.56.8/32 -- DENIED due to: extended community not supported;

But a later update was not denied.

Many thanks for your help I now have a working solution.

[Harold Ritter]

Thomas,

This is interesting. Thanks for keeping us posted. I'm glad the upgrade fixed it.

The "DENIED due to: extended community not supported;" message was probably unrelated since it is for a different VPNv4 prefix:

5551:46000:63.130.56.8/32 in the error message and 5551:46001:63.130.56.8/32 is sent with the wrong bgp nh.

Hope this helps,