04-13-2007 10:17 AM - edited 03-03-2019 04:32 PM
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?
04-13-2007 10:36 AM
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,
04-13-2007 10:42 AM
Just as a clarification, it would work fine even if RTRB was a RR client of RTRA.
Sorry for the confusion,
04-13-2007 11:14 AM
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.
04-13-2007 11:24 AM
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,
04-16-2007 10:01 AM
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?
04-16-2007 10:15 AM
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,
04-16-2007 10:23 AM
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,
04-16-2007 11:20 AM
"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
04-16-2007 11:33 AM
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,
04-17-2007 04:41 AM
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,
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: