iBGP route reflector question

Unanswered Question
Apr 13th, 2007

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?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Harold Ritter Fri, 04/13/2007 - 10:36

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 Fri, 04/13/2007 - 10:42

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

Sorry for the confusion,

robertsmichael Fri, 04/13/2007 - 11:14

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.

Harold Ritter Fri, 04/13/2007 - 11:24

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,

jbrunner007 Mon, 04/16/2007 - 10:01

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?

Harold Ritter Mon, 04/16/2007 - 10:15

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 Mon, 04/16/2007 - 10:23

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,

sundar.palaniappan Mon, 04/16/2007 - 11:20

"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

Harold Ritter Mon, 04/16/2007 - 11:33

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 Tue, 04/17/2007 - 04:41

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,

Actions

This Discussion