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 30.30.30.30

!

router bgp 20

bgp router-id 30.30.30.30

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

neighbor 10.10.10.10 peer-group REMOTE

Routes being learned from 10.10.10.10 are then advertised to 20.20.20.20. However, when I log into 20.20.20.20, I see the next hop as 10.10.10.10 instead of 30.30.30.30, 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

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

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

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

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

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

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

Harold:

The link I provided recommends using route maps with RRs.

Thanks

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

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

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

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

Actions

Login or Register to take actions

This Discussion

Posted May 14, 2009 at 2:07 AM
Stats:
Replies:8 Overall Rating:
Views:458 Votes:0
Shares:0
Tags: No tags.