Route Reflector

[saishreevj]

Do we need to consider both Route Reflectors and Next Hop self while Planning for IBGP Peerings?

[balaji.bandi]

Not sure what is the use case here.

Both do different jobs.  next-hop  not going to change on route reflectors in iBGP routes, it does only for eBGP learned routes ( as per i know)

[saishreevj]

@balaji.bandi I mean configuring Next Hop Self inside IBGP network.

[paul driver]

Hello

Yes it is applicable to apply it on the RR only not on any RRC

[saishreevj]

@paul driver thanks, If route learned from RR client will be propagated to EBGP via RR and need to configure  Next Hop Self on non RR I believe

[paul driver]

Hello

@MHM Cisco World @saishreevj 
No you do not require to add next-hop-self on any RRC, This feature ONLY needs to appended on the RR towards the RRC.

RRC are internal ibgp rtrs and have no direct connection to ebgp peers. any ebgp prefix being advertised into the ASN will have its next-hop change to be the RR so any ibgp rtrs will see the next-hop NLRI for ebgp prefixes as the RR and not the advertising ebgp rtr.

The same applies to any internal prefix being advertised externally by the RR the next-hop advertised will be the RR itself.

[Harold Ritter · Accepted solution]

Hi @paul driver ,

> No you do not require to add next-hop-self on any RRC, This feature ONLY needs to appended on the RR towards the RRC.

I disagree with this statement. Generally, "next-hop-self" is applied to the route reflector client, which normally peers with the other ASNs. It is also generally not recommended to change the next hop on the route reflector itself. In fact IOS and IOS-XR by default only allow the modification of the next hop for paths learnt via eBGP (if any eBGP peer are directly connected to the RR). This default behavior can be changed, but is only required if the RR needs to be inline, such as in an MPLS BGP LU scenario for example.

Here's with RFC4456 says about changing the next hop on the RR:

.  Implementation 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.  Their modification could potentially result in routing
   loops.

   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 potentially result in routing loops.

https://datatracker.ietf.org/doc/html/rfc4456

Regards,

[paul driver]

Hello Harold 

Thank for your feedback it’s very much appreciated.

Generally, "next-hop-self" is applied to the route reflector client,

Just to confirm when you state “to” you mean towards the rrc not on the rrc towards the rr correct?

also

In fact IOS and IOS-XR by default only allow the modification of the next hop for paths learnt via eBGP (if any eBGP peer are directly connected

isnt this what i am saying which is that if the RR have ebgp peers or infact come to think of it if the rrc also,  that the next-hop-self is valid .

However then you provide this little nugget 

In addition, when a RR reflects a route, it SHOULD NOT modify the
   following path attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED

which is now stating the opposite from above unless i have missed something…which is very possible 

[Harold Ritter]

Hi @paul driver ,

> Just to confirm when you state “to” you mean towards the rrc not on the rrc towards the rr correct?

No, I mean on the RRC towards the RR.

> isnt this what i am saying which is that if the RR have ebgp peers or infact come to think of it if the rrc also,  that the

> next-hop-self is valid .

The case where RR has ebgp sessions is more of a corner case. The RR is normally dedicated to being a RR and doesn't handle the eBGP sessions.

> which is now stating the opposite from above unless i have missed something…which is very possible 

I meant next-hop-self should be applied on the RRC towards the RR. 

Regards,

[paul driver]

Hello Harold

---

@Harold Ritter wrote:

The case where RR has ebgp sessions is more of a corner case. The RR is normally dedicated to being a RR and doesn't handle the eBGP sessions.

---

Okay if the RR or RRC did have ebgp sessions then the NHS would be applicable however as you state normally it would be either a RR client or non-client within the same ASN that would have the ebgp peering as such they would implement the NHS feature, And as both RR are basically non clients to each other they will reflect each other IGBP routes with the NHS already set from the RRC/non client rtr.

[Harold Ritter]

Hi @paul driver ,

> Okay if the RR or RRC did have ebgp sessions then the NHS would be applicable however as you state normally it would be

> either a RR client or non-client within the same ASN that would have the ebgp peering as such they would implement the

> NHS feature, And as both RR are basically non clients to each other they will reflect each other IGBP routes with the NHS

> already set from the RRC/non client rtr.

That is correct Paul.

Regards,

[paul driver]

Hello Harold

Cheers mate for that clarification,
By the way  barcleona 2019 cisco live, I coulndt get into the ipv6 adv lab I believe now you were presenting, I wasnt a happy bunny at the time but all good in the end due to the on demend sessions!

Was you booked for 2022 Amsterdam?  

[Harold Ritter]

Hi Paul,

> By the way  barcleona 2019 cisco live, I coulndt get into the ipv6 adv lab I believe now you were presenting, I wasnt a happy

> bunny at the time but all good in the end due to the on demend sessions!

Barcelona was my last in-person CiscoLive. Sorry to hear you couldn't get in the IPv6 session. It would have been nice to meet you in person.  We always try to get at least two slots, but even that isn't enough. I always fight to get a 3rd slot, but it is not easy due to the number of overall sessions. We did have 3 sessions this year in the virtual event.

> Was you booked for 2022 Amsterdam?

Yes, I was. It was very sad to hear that it got cancelled last week. I was so looking forward to going back to an in-person CiscoLive. Hope to get a chance to meet you at CiscoLive Amsterdam 2023.

Regards, 

[saishreevj]

@Harold Ritter Thanks for the explanation, much appreciated. 

[Harold Ritter]

You are very welcome @saishreevj