Hello Ryan,

I may be wrong but I think what you see comes from having tried to use next-hop self on a RR server towards a client the workaround is that of using a route-map.

normally, RRS are not on the data path

Edit:

next-hop-self works towards a normal iBGP neighbor and I used it. It is the RRS that makes the command non effective.

Hope to help

Giuseppe

Ryan:

You inadvertently -- and intelligently, I might add -- figured out the correct way of doing things with an RR.

It is a standard methodology for influencing the next-hop advertisement to use route maps with RRs and not the next-hop self command. In fact, there is a specific directive not to use the command.

http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fs_bgpnh.html#wp1027195

HTH

Victor

Giuseppe,

You are correct. On a RR, the nexthop-self keyword only applies if the RR also have bgp session to external peers (eBGP). Paths received via iBGP will not get their next-hop modified unless you use a route-map, which is generally not recommended either.

Regards

Harold:

The link I provided recommends using route maps with RRs.

Thanks

Victor,

Except for rare cases, it is not a good idea to change the next hop attribute on the RR. RFC4456, Section 10 states that it should not be allowed:

"10. 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."

http://www.ietf.org/rfc/rfc4456.txt?number=4456

Also note that the documentation you are referring to has a warning message that reads as follow:

"Caution Incorrectly setting BGP attributes for a route reflector can cause inconsistent routing, routing loops, or a loss of connectivity. Setting BGP attributes for a route reflector should be attempted only by an experienced network operator."

Regards

Correct, unfortunately this is in fact one of those "rare" cases because one of the RR clients does not participate in the IGP process. We have a very unique setup, so it was required.

Guiseppe,

You are correct, sorry. The statement "iBGP routes are not affected by this command on an iBGP neighbor" implies either a RR or confederation setup, since this is the only way to advertise iBGP learned routes to iBGP neighbors. I could have stated that explicitly, but it is implied.

Thanks,

Ryan