cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3861
Views
0
Helpful
9
Replies

iBGP next-hop-self problem

John Blakley
VIP Alumni
VIP Alumni

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

HTH, John *** Please rate all useful posts ***
2 Accepted Solutions

Accepted Solutions

Edison Ortiz
Hall of Fame
Hall of Fame

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.

View solution in original post

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.

View solution in original post

9 Replies 9

Edison Ortiz
Hall of Fame
Hall of Fame

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.

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

HTH, John *** Please rate all useful posts ***

Yes, that should work.

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

HTH, John *** Please rate all useful posts ***

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

HTH, John *** Please rate all useful posts ***

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.

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

HTH, John *** Please rate all useful posts ***

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!

HTH, John *** Please rate all useful posts ***

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

Getting Started

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: