05-14-2009 02:07 AM - edited 03-04-2019 04:45 AM
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???
05-14-2009 02:41 AM
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
05-14-2009 05:09 AM
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
05-14-2009 11:12 AM
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
05-16-2009 12:42 PM
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
05-16-2009 01:45 PM
Harold:
The link I provided recommends using route maps with RRs.
Thanks
05-17-2009 06:23 AM
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
05-17-2009 11:14 PM
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.
05-17-2009 11:10 PM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: