cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
856
Views
0
Helpful
10
Replies

iBGP route reflector question

rm2017
Level 1
Level 1

I have a situation with the following scenario:

RTRC(AS5)---RTRA(AS5)---RTRB(AS5)---RTRD(AS5)

RTRA and RTRB have eBGP peers with other routers not shown in the diagram. RTRC is configured as a route-reflector-client of RTRA and RTRD is configured as a route-reflector-client of RTRB.

In order for RTRB to have the correct next hop information in the BGP table for RTRC prefixes, does RTRB also have to be configured as a route-reflector-client of RTRA and vice versa?

10 Replies 10

Harold Ritter
Cisco Employee
Cisco Employee

It should work just fine, assuming RTRA and RTRB are iBGP neighbors and that RTRB is not a client of RTRA. RTRC would pass its updates to its RR and RTRA would reflect it to RTRB, which in turn would reflect it to its RRC (RTRD).

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Just as a clarification, it would work fine even if RTRB was a RR client of RTRA.

Sorry for the confusion,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Thanks for your response. As is, RTRA and RTRB are iBGP neighbors and are NOT configured as route-reflector-clients for each other. Problem is, that in the bgp table of RTRB, RTRC routes show up with a next hop of RTRC vs. RTRA - which is where things are breaking.

Michael,

This is normal behavior dor RTRB to have RTRC as the next-hop for updates coming from RTRC as the router-reflector (RTRA) should leave the next-hop unchanged as it reflects routes. Why is it breaking? Aren't you running a common IGP between all of these routers.

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

next-hop-self is a widely used feature on Route Reflector's. Or as said previously you could have a common IGP...

Michael, why not just configure

Next-hop-self on your route-reflectors?

Joseph,

the next-hop-self feature on the route-reflector will only affect paths learnt via eBGP. It will not change the BGP NH for iBGP learnt paths.

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Joseph,

I should have added that the reason for this behavior is section 8 of RFC1966, which states the following:

8. Implementation and Configuration Considerations

Care should be taken to make sure that none of the BGP path

attributes defined above can be modified through configuration when

exchanging internal routing information between RRs and Clients and

Non-Clients. This could result is looping of routes.

In some implementations, modification of the BGP path attribute,

NEXT_HOP is possible. For example, there could be a need for a RR to

modify NEXT_HOP for EBGP learned routes sent to its internal peers.

However, it must not be possible for an RR to set on reflected IBGP

routes as this breaks the basic principle of Route Reflection and

will result in potential black holeing of traffic.

An RR should not modify any AS-PATH attributes (i.e. LOCAL_PREF, MED,

DPA)that could change consistent route selection. This could result

in potential loops.

The BGP protocol provides no way for a Client to identify itself

dynamically as a Client to an RR configured BGP speaker and the

simplest way to achieve this is by manual configuration.

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

"However, it must not be possible for an RR to set on reflected IBGP

routes as this breaks the basic principle of Route Reflection and

will result in potential black holeing of traffic"

This appears to be the actual/default behavior on Cisco devices. I quickly tested this in the lab and the RR wouldn't effect next-hop-self on IBGP learned routes and that's consistent with the RFC. I don't know if there's a way to get around this by making the RR change the NH on IBGP learned routes.

While traffic getting potentially blackholed is a possibility when RR changes the NH for IBGP learned routes but I can see changing the NH mayn't create any issue in a simple topology (assuming this is a complete topology) as the one posted by the original poster. Harold, do you have any thoughts on this?

HTH

Sundar

My recommendation would definitely be to stick to what is dictated by the RFC and deploy a common IGP so that NH set by RRC is known by all internal BGP speakers.

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Just as a clarification, RFC1966 has actually been superseded by RFC2976 but the restriction remains the same.

"In addition, when a RR reflects a route, it should not modify the

following path attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED.

Their modification could potential result in routing loops."

http://tools.ietf.org/html/rfc2796

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco