IOS-XR Route Reflection with next-hop-self

[steven.crutchley]

My understanding is that using next-hop-self on a Cisco IOS route-reflectors follows this rule:

Using the 'neighbor next-hop-self' command on the route reflector will modify next hop attributes only for routes that are learned from eBGP peers and not the intended routes that are being reflected from the route reflector clients.

This makes sense. You don't want the reflector reseting the next hop for internal routes received from clients. However is this the same behaviour for IOS-XR? I have a router, XR1, that has an eBGP peer but is also an RR for several iBGP peers. A peering to an iBGP neighbor looks like this:

router bgp 1
 bgp cluster-id 255.255.255.2
 address-family ipv4 unicast
  network 11.11.11.11/32
 !
 af-group IPV4_IBGP_RR_CLIENTS address-family ipv4 unicast
  route-reflector-client
  next-hop-self
 !
 session-group IBGP_PEERS
  remote-as 1
  update-source Loopback0
 !
 neighbor 2.2.2.2
  use session-group IBGP_PEERS
 address-family ipv4 unicast
  use af-group IPV4_IBGP_RR_CLIENTS
 !

I'm finding that if I don't remove next-hop-self, XR1 is setting itself as the next hop when reflecting routes from one iBGP client to another iBGP client. This seems to be the opposite of what Cisco IOS does. 

Can anyone advise if this is normal behaviour? I'm happy to provide additional output if needed.

[tkarnani]

i am not sure of your exact issue, however if you receive multiple paths/ecmp for example from a peer on ios-xr it will do a next-hop-self type change when advertising to peers.

it can be turned off with "next-hop-unchanged multipath" under the address-family.

[Michalis Milaitis]

Hello Steven,

In the most cases you should not change the next-hop on the Route Reflector.

The best practice is to change the next-hop on the route reflector client (for both ibgp and ebgp).

If you use next-hop-self on the RR then all the traffic will be forwarded through the RR and I think that it's not what you want.

Best Regards,

Michalis Milaitis

[steven.crutchley]

Hi Michalis,

Thanks for the response. I know that have a route reflector set itself to the next hop is not best practice. My situation is for a lab environment and I am trying to understand Cisco's IOS-XR default behaviour. 

in my lab the route reflector, despite not being best practice, has an eBGP peer and several iBGP clients (which essentially make this both a Route Reflector and an MSE/BR which, I agree, is not best practice). 

Under the address-family group towards the iBGP route reflector clients the next-hop-self command has been used. My understanding was that the router would do the following:

When reflecting routes to an iBGP neighbor who is a client (e.g. route-reflector-client is configured), and I have next-hop-self configured, then I will only set the next hop to myself if the route I'm reflecting is learning via an iBGP peer (most likely another client). If I learn a route from an eBGP peer then I will reflect the route and set the next hop to myself. 

This is what I believe should be happen but it is not what I observe in my lab (running GNS3 XRv routers with version 6.1.1). In my lab, the iBGP reflected routes are being given the reflector as the next hop. I'm trying to determine if I have misunderstood the default behaviour or if I might have something configured that is causing this default behaviour not too apply.

Does that clarify my query?

[Michalis Milaitis]

The default behaviour of ios xr is that you can't use next-hop self for ibgp reflected routes. If you want to change attributes for an ibgp session you should use the command "ibgp policy out enforce-modifications" in combination with a route policy. 

If you want to change the next-hop for some specific prefixes you need to apply a route policy that match your criteria. For example you can mark the routes from the ebgp session with a bgp community. On the ibgp session with the RR clients you can apply a route policy that match this community and set next-hop-self. 

[smilstea]

Are the eBGP peers connected to the RR/PE in a VRF?

Are they using the same or different AS numbers than the local AS?

Is it only on these eBGP peers where you see the next-hop changed or also on iBGP RR client connections?

Thanks,

Sam

[decode.chr13]

I understand your requirement and your “not recommended” setup in the lab. 

I don’t know if this works as you want, but even if it would work I would not recommend in a production environment, because if the code will change in the future, you will either move all iBGP traffic thru RR, either you’ll loose eBGP connectivity. 

Why don’t you just simply “redistribute connected” on your RR, so all iBGP peers would know about your external peerings interconnect?

HTH

[Adam Vitkovsky · Accepted solution]

Hi,

I had a similar setup in production (but it was an MPLS PE acting as a RR too).

However in my case the problem of setting next-hop-self only on paths received from eBGP peers and reflecting paths received from iBGP peers/clients untouched solved itself through the use of L3VPNs (when path is received via eBGP in a VRF the PE sets next-hop-self automatically when advertising it via iBGP) -hence the reason I did not need to use next-hop-self on client sessions.

So in your case you might need to get more creative than the broad brush of setting the next-hop-self on all client sessions.

Maybe instead try to use a policy with simple logic matching if the path was received via iBGP or eBGP and setting the next-hop-self accordingly.

Couple of examples:

if community matches-any CS_EBGP_PEERS then set next-hop self else pass

Or:

if source in PS_EBGP_PEERS then set next-hop self else pass

Or:

if next-hop in PS_EBGP_PEERS then set next-hop self else pass

-not sure which one of the above examples can be actually attached in OUT direction on client sessions.

Note:  In order to change attributes in OUT direction towards iBGP sessions you need to enable the “ibgp policy out enforce-modifications” command.

adam

[smilstea]

Yep, that is what I was getting to with my questions!

In L3VPN scenario where router is acting as PE next-hop-self is automatically applied.

Sam

[steven.crutchley]

Hi Adam, 

Thanks for the response and sorry for the delay in replying. 

Yes I believe you're correct. I have removed next-hop-self and applied an outbound route policy to iBGP peers and forced next-hop-self for any prefixes I know to have been received from an eBGP peer. 

I think it should only change the next-hop for eBGP routes, but the image I'm using (6.1.1) appears to be suffering from some kind of bug (possibly this one: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvd16351 ).

Thanks again.

[smilstea]

Some details as to your exact topology would help, including AS numbers if they are the same or not and what is in a VRF etc.

In the scenario where it acts like L3VPN whether it is eBGP or even if its iBGP technically it will do next-hop-self. Anytime it is in a VRF regardless of BGP type we will treat it like a CE and like aL3VPN and perform next-hop-self.

I have seen this before and there are a few solutions.

Possible solutions:
ibgp policy out enforce-modifications and using an RPL
Next-hop-unchanged is for eBGP only, but changing to eBGP or some private-AS could work
Remove the VPNv4 neighborship and only use the IPv4 AF

Sam

[steven.crutchley]

Hi Sam, 

See above for a quick diagram I drew on my tablet. I have confirmed this issue is to do with the software version I'm running. 

In the above topology L3VPN and MPLS are not involved. It is straight IPv4. "ibgp policy out enforce-modifications" is not configured anywhere.

The XR router reflector (R1), when running 6.1.1 demo software, will reset the next hop to itself on an iBGP reflected route. This shouldn't happen. Even with next-hop-self in the af-group, iBGP reflected routes should not have the next hop changed (unless"ibgp policy out enforce-modifications" is on, which it isn't).

If I run 6.5.3 software on the XR, this issue does not occur and the next-hop for prefix 4.4.4.4/32 isn't reset. This leads me to believe 6.1.1 is subject to bug https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvd16351 or similar. Thanks for the help.