I am having an issue with the next-hop-self command in BGP. I have an iBGP Route Reflector that is learning a route from one client and advertising it to another. However, the second client doesn't see the next hop as being the route-reflector, but rather sees it as the first client.
Here is a sample config...
ip address 22.214.171.124
router bgp 20
bgp router-id 126.96.36.199
neighbor WHATEVER peer-group
neighbor WHATEVER remote-as 20
neighbor WHATEVER password <blah blah>
neighbor WHATEVER update-source Loopback0
neighbor WHATEVER route-reflector-client
neighbor WHATEVER next-hop-self
neighbor WHATEVER send-community
neighbor WHATEVER prefix-list DENY_QUADZERO out
neighbor REMOTE peer-group
neighbor REMOTE remote-as 20
neighbor REMOTE password <blah blah>
neighbor REMOTE route-reflector-client
neighbor REMOTE next-hop-self
neighbor REMOTE prefix-list DEFAULTNET out
neighbor 188.8.131.52 peer-group WHATEVER
neighbor 10.10.10.10 peer-group REMOTE
Routes being learned from 10.10.10.10 are then advertised to 184.108.40.206. However, when I log into 220.127.116.11, I see the next hop as 10.10.10.10 instead of 18.104.22.168, despite the next-hop-self command being configured on the WHATEVER peer group.
Found the solution.
Next-hop-self only sets the next hop to the router for routes learned from eBGP. iBGP routes are not affected by this command on an iBGP neighbor.
To resolve, I am using a route-map applied outbound...
route-map NEXT-HOP-SELF permit 10
set ip next-hop peer-address
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
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
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.
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.
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."
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."
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.
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.