05-29-2009 05:54 AM - edited 03-04-2019 04:56 AM
All,
I've attached a lab diagram that I was playing with this morning, and I can't get it to work.
RTRB is getting a route for RTRD (3.3.3.3) from RTRC. The next hop is showing as RTRD's ip address since iBGP doesn't change the next hop address. I enabled next-hop-self on RTRC:
neighbor 192.168.4.1 next-hop-self
It's not working. To get the RTRD route to RTRB, I had to set up a RR client like:
neighbor 192.168.5.1 route-reflector-client
That brought my route into RTRB, but with the wrong next hop. I know I'm missing something. :-)
Thanks!
John
Solved! Go to Solution.
05-29-2009 06:22 AM
John,
When configuring iBGP on multiple BGP speaking routers, one of the rules is to have an iBGP mesh, route-reflector or confederation.
This practice is done to avoid any loops within the BGP environment.
As for the wrong next-hop, the BGP next-hop self does not modify the next-hop on route-reflectors. You can modify the next-hop with a route-map.
http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fs_bgpnh.html
Do not use the neighbor next-hop-self command to modify the next hop attribute for a route reflector when this feature is enabled for a route reflector client. Using the neighbor next-hop-self command on the route reflector will modify next hop attributes only for routes that are learned from eBGP peers and not the intended routes that are being reflected from the route reflector clients. To modify the next hop attribute when reflecting a route, use an outbound route map.
HTH,
__
Edison.
05-29-2009 08:06 PM
John,
If you want to ping from an interface and the interface isn't known by the destination device, you need some kind of advertisement either via BGP or IGP.
I see you are advertising the loopbacks, did you try pinging by sourcing from the loopbacks?
I'm a little confused since our conversation has been around the iBGP mesh yet you bring up RouterA into the picture - an eBGP peer.
__
Edison.
05-29-2009 06:22 AM
John,
When configuring iBGP on multiple BGP speaking routers, one of the rules is to have an iBGP mesh, route-reflector or confederation.
This practice is done to avoid any loops within the BGP environment.
As for the wrong next-hop, the BGP next-hop self does not modify the next-hop on route-reflectors. You can modify the next-hop with a route-map.
http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fs_bgpnh.html
Do not use the neighbor next-hop-self command to modify the next hop attribute for a route reflector when this feature is enabled for a route reflector client. Using the neighbor next-hop-self command on the route reflector will modify next hop attributes only for routes that are learned from eBGP peers and not the intended routes that are being reflected from the route reflector clients. To modify the next hop attribute when reflecting a route, use an outbound route map.
HTH,
__
Edison.
05-29-2009 06:29 AM
Ah. So because I used the RR client, I can't use next-hop-self?
Would I do something like the following on the RR client (RTRC):
access-list 10 permit host 3.3.3.3
route-map SETHOP permit 5
match ip address 10
set ip next-hop 192.168.4.2
router bgp 100
neighbor 192.168.4.1 route-map SETHOP out
This was in GNS, and I don't have it handy at the moment, but does the above look like it would work?
Thanks Edison!
John
05-29-2009 06:34 AM
Yes, that should work.
05-29-2009 06:25 PM
Edison,
I was able to get a "valid/best" route in my bgp table on the router that I was having the problem with, but I still can't ping anything. I have a route-map that changes the hop incoming on the "problem" router. I can ping my neighbor, and the neighbor can ping the advertised networks on both routers, but I can't ping through my route-reflector.
RTRA:
* i1.1.1.1/32 192.168.1.1 0 100 0 200 i
*> 192.168.3.1 0 0 200 i
*>i2.2.2.2/32 192.168.5.1 0 100 0 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
*>i4.4.4.4/32 192.168.5.1 0 100 0 i
*> 192.168.5.0 0.0.0.0 0 32768 i
RTRA#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
RTRB:
* i1.1.1.1/32 192.168.1.1 0 100 0 200 i
*> 192.168.2.1 0 0 200 i
*> 2.2.2.2/32 0.0.0.0 0 32768 i
*>i3.3.3.3/32 192.168.4.2 0 100 0 i
*>i4.4.4.4/32 192.168.4.2 0 100 0 i
* i192.168.5.0 192.168.5.2 0 100 0 i
RTRB# #ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
4.2 is the router that has route-reflector-client configured, and 5.1 is the other interface on the same router. I thought a valid/best route was a "guaranteed" route that bgp could get to.
Thanks,
John
05-29-2009 07:12 PM
Edison,
I got this to work, but only by advertising my neighboring interfaces too. So, for the 2.2.2.2 loopback interface, I had to advertise the 192.168.5.0 network. But I feel that defeated the purpose of the next hop "need" because in my routing table, I, of course, show that the next hop was the 192.168.5.2 interface.
When using a route reflector client, shouldn't the client have the next hop of the route reflector itself?
Thanks,
John
05-29-2009 08:06 PM
John,
If you want to ping from an interface and the interface isn't known by the destination device, you need some kind of advertisement either via BGP or IGP.
I see you are advertising the loopbacks, did you try pinging by sourcing from the loopbacks?
I'm a little confused since our conversation has been around the iBGP mesh yet you bring up RouterA into the picture - an eBGP peer.
__
Edison.
05-30-2009 03:59 AM
Edison,
You rock :) There's no ebgp peer in this scenario. All three routers were ibgp, but I was only advertising one loopback on each "end router." The router in the middle, RouterA, was configured as a RR for the end routers. I used the RR option when I wasn't getting the routes for the other end router.
I could ping from the end router to the other end when sourcing from the loopback. So that tells me that when I added my egress interfaces, 192.168.4.0 and 192.168.5.0, it knew how to get back because ping the loopback without sourcing made my source my 192.168.5.x address, which the other router didn't know how to get to. Makes sense.
Okay, so I removed the RR option on the middle router and I still see my routes on the end routers, so I may have not waited long enough before. Are RR used generally for routers that get routes from an ebgp and then have one ibgp peer, and then that ibgp peer is configured for a RR? I'm going to play some more with that, but now I know why my other didn't work. :)
Thanks!
John
05-30-2009 05:09 AM
Scratch that. Since I took the RR client off, I cleared my bgp sessions, and I can't see the routes from the other end. I believe that ibgp won't advertise a route to an ibgp peer that was learned from another ibgp peer, and that's what the RR is for. Once I put the RR on, I was able to get the other route, manipulate the next hop with an inbound policy map, and voila, everything worked :)
Thanks!
05-30-2009 07:57 AM
"I believe that ibgp won't advertise a route to an ibgp peer that was learned from another ibgp peer, and that's what the RR is for."
Correct :)
__
Edison.
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: