BGP Next-Hop-Self

Unanswered Question
May 14th, 2009

Hello all,

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

int lo0

ip address


router bgp 20

bgp router-id

no synchronization

bgp log-neighbor-changes

bgp redistribute-internal

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 peer-group WHATEVER

neighbor peer-group REMOTE

Routes being learned from are then advertised to However, when I log into, I see the next hop as instead of, despite the next-hop-self command being configured on the WHATEVER peer group.

Any help???

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
rpfinneran Thu, 05/14/2009 - 02:41

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

Giuseppe Larosa Thu, 05/14/2009 - 05:09

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


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


lamav Thu, 05/14/2009 - 11:12


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.



Harold Ritter Sat, 05/16/2009 - 12:42


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.


lamav Sat, 05/16/2009 - 13:45


The link I provided recommends using route maps with RRs.


Harold Ritter Sun, 05/17/2009 - 06:23


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


rpfinneran Sun, 05/17/2009 - 23:14

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.

rpfinneran Sun, 05/17/2009 - 23:10


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.




This Discussion