strange BGP problem...

WillTech105

BGP Attribute Local Preference | BGP

So I am going by this lab right now in BGP. I get up to the point where everyone in al 4 BGP AS' should be able to ping each other. Everyone can ping everyone except ONE route.


RODMAN router cannot ping the loopback of FRANCO.

RODMAN's loopback is 1.1.1.1
FRANCO's loopback is 7.7.7.7

Everyones BGP routing table in AS 1.....

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 192.168.67.6 0 3 2 1 ?
*> 1.1.1.1/32 192.168.47.4 3 0 1 ?
*> 2.2.2.0/24 192.168.47.4 0 1 ?
* 192.168.67.6 0 3 2 1 ?
*> 2.2.2.2/32 192.168.47.4 2 0 1 ?
*> 3.3.3.3/32 192.168.47.4 2 0 1 ?
*> 4.4.4.0/24 192.168.47.4 0 0 1 ?
*> 4.4.4.4/32 192.168.67.6 0 3 2 1 ?
* 5.5.5.0/24 192.168.47.4 0 1 2 i
*> 192.168.67.6 0 3 2 i
*> 6.6.6.0/24 192.168.67.6 0 0 3 i
*> 7.7.7.0/24 0.0.0.0 0 32768 i


Everyone has this in the routing table, but RODMAN never gets the final line
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 0.0.0.0 0 32768 ?
*>i2.2.2.0/24 2.2.2.2 0 100 0 ?
*> 2.2.2.2/32 192.168.13.2 2 32768 ?
*> 3.3.3.3/32 192.168.12.3 2 32768 ?
*> 4.4.4.4/32 192.168.12.3 3 32768 ?
* i 192.168.34.4 2 100 0 ?
*>i5.5.5.0/24 192.168.35.5 0 100 0 2 i
*>i6.6.6.0/24 192.168.35.5 0 100 0 2 3 i
*>i66.66.66.0/24 192.168.35.5 0 100 0 2 3 i
*> 192.168.12.0 0.0.0.0 0 32768 ?



Funny thing is, FRANCO who has 7.7.7.7 can ping RODMAN, but RODMAN can't ping back since its not in the routing table or BGP routing table. He can ping everyone else though. And everyone else in RODMAN's AS 1 is able to ping 7.7.7.7

Why would ONE router out of the whole AS not be able to get one route in his routing table when everyone else does??? Any tips would be appreciated.

EDIT: did a clear ip bgp * but alas nothing. I also made sure FRANCO is adv 7.7.7.7 and it is , since even LANDON can ping it. RODMAN just seems to not want to learn that one route.

Chris_

Hard to say without seeing your configs, could you post them? maybe there is some inbound filtering in place on the Rodman router.

Also, when you say that FRANCO can ping RODMAN - is that ping sourced from the Loopback 7.7.7.7 or the fa0/0 interface?

WillTech105

RODMAN
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname RODMAN
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
no ip domain lookup
!
!
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
ip address 1.1.1.1 255.255.255.0
!
interface FastEthernet0/0
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 192.168.13.1 255.255.255.0
duplex auto
speed auto
!
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
!
router bgp 1
synchronization
bgp log-neighbor-changes
redistribute ospf 1
neighbor 2.2.2.2 remote-as 1
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 1
neighbor 3.3.3.3 update-source Loopback0
no auto-summary
!
no ip http server
no ip http secure-server
!
ip forward-protocol nd
!
!
!
!
!
control-plane
!
!
!
!
mgcp behavior g729-variants static-pt
!
!
!
!
!
!
line con 0
exec-timeout 0 0
logging synchronous
line aux 0
line vty 0 4
login
!
!
end

RODMAN(config-router)#

WillTech105

LANDON
Current configuration : 1143 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname LANDON
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
no ip domain lookup
!
!
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
ip address 3.3.3.3 255.255.255.0
!
interface FastEthernet0/0
ip address 192.168.12.3 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 192.168.24.3 255.255.255.0
duplex auto
speed auto
!
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
!
router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 update-source Loopback0
neighbor 4.4.4.4 remote-as 1
neighbor 4.4.4.4 update-source Loopback0
no auto-summary
!
no ip http server
no ip http secure-server
!
ip forward-protocol nd
!
!
!
!
!
control-plane
!
!
!
!
mgcp behavior g729-variants static-pt
!
!
!
!
!
!
line con 0
exec-timeout 0 0
logging synchronous
line aux 0
line vty 0 4
login
!
!
end

LANDON#

WillTech105

FRANCO
Current configuration : 1070 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname FRANCO
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
no ip domain lookup
!
!
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
ip address 7.7.7.7 255.255.255.0
!
interface FastEthernet0/0
ip address 192.168.47.7 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 192.168.67.7 255.255.255.0
duplex auto
speed auto
!
router bgp 4
no synchronization
bgp log-neighbor-changes
network 7.7.7.0 mask 255.255.255.0
network 192.168.47.0
network 192.168.67.0
neighbor 192.168.47.4 remote-as 1
neighbor 192.168.67.6 remote-as 3
no auto-summary
!
no ip http server
no ip http secure-server
!
ip forward-protocol nd
!
!
!
!
!
control-plane
!
!
!
!
mgcp behavior g729-variants static-pt
!
!
!
!
!
!
line con 0
exec-timeout 0 0
logging synchronous
line aux 0
line vty 0 4
login
!
!
end

FRANCO#

WillTech105

Thought it'd be easier to read per post versus one huge ****.

I posted up LANDONs sh run as well for comparison. He can ping them all fine. Doing some google searches but it keeps telling me that "check router adv if he doesnt learn it" which obv isnt the case since everyone else has it.

Its pretty bare bones, no route maps or access lists or anything.

Chris_

I've only had a quick glance at the lab but the only way I can see that RODMAN would get the 7.7.7.7 route is from franklin who would have it as an EBGP route from Jacobs and that would need to be franklin's best route in order for it to be advertised to Rodman; this won't be the case due to the local pref of 700 that the ;ab asks for on hunnisjer AS4 routes. RODMAN wouldn't get the route that hunnisker receives from franco due to bgp split-horizon. So either make rodman a route reflector client or have an ibgp peering between rodman and hunnisker.

It's late and I'm tired so sorry if that makes no sense!!

WillTech105

Hmmm -- KINDA makes sense. The more I play around with it the more I am getting it but my thing is, if HUNIKSER learned it, and passed it onto LANDO, why isnt the same happening with FRANKLIN > RODMAN.

Its the same links, cost, and topology so it doesnt make sense.

WillTech105

EBGP External BGP - YouTube

I think this might be a solution....lol gotta head to bed though will try it tomm and update everyone


EDIT: well, bad news is the stupid GNS3 didnt save my show runs so i lost it all.

But I think I know what was off. According to this lab, pings may not go through because the link is missing on RODMAN's routing table so it doesnt know how to get there. I may have had to add or I was missing a network statement and that would of taken care of it all.

I'll have to re-create this one again and see if thats the case or not.

Chris_

Right I'm awake now and on my laptop as opposed to my iPhone so I can be a bit more clear.

These are the 2 potential paths that i can see for the 7.7.7.0 route to get to RODMAN

The 7.7.7.0 route is injected into BGP on FRANCO. FRANCO will add the route to it's BGP table and share with it's neighbors (HUNNISKER IN AS1 and PINTO in AS3)

HUNNISKER will receive the route as an EBGP update, change the local preference attribute to 700 (as per the lab instructions) and install it in the bgp table. Because this is an EBGP update HUNNISKER will also propogate the route to it's IBGP neighbors (LANDON and FRANKLIN)

So, in AS1 now Hunnisker, Franklin and Landon have the 7.7.7.0 route in their BGP tables. HUNNISKER learnt it as an EBGP update, FRANKLIN an LANDON learnt it as an IBGP update.

This is where the IBGP full mesh rules kick in; neither FRANKLIN or LANDON will share this route with their IBGP neighbor RODMAN. The BGP Split Horizon rule states that any route received from an internal BGP peer will not be shared with any other internal BGP peer.
This rule has an impact on transit AS in that it effectively dicatates that the area must have a full mesh of BGP peerings in order for routes to be shared around the AS.

So for RODMAN to receive this path it must have an IBGP peering directly with HUNNISKER, the router that received the EBGP update into the AS.

Other options that act as exceptions to the full-mesh requirement are route reflectors or confederations - but these aren't really covered in the CCNP route apart from a courtesy mention.

The second potential path for RODMAN to get the 7.7.7.0 route is from FRANKLIN. FRANKLIN will have received it as an EBGP update from JACOBS who in turn will have received it as an EBGP update from PINTO.

The problem here is that BGP speakers will determine their own best path to a route and this is the only path that they will share with their neighbors. As FRANKLIN already has the path through HUNNISKER with a Local preference of 700 (vs 500 on the route coming from JACOBS) then the path through JACOBS will not be shared with RODMAN.

I hope this helps. I'm only in the process of studying BGP myself, so I hope the opinion above is correct. Anyone else out there feel free to correct me if necessary. I will have a go at this LAB myself later to see how my theory pans out

lrb

A few things to note are:

1. If your iBGP peering all your routers in AS1, turn off BGP synchronization (RODMAN has sync turned on for example). If you are keen to see if this is the problem, do a show ip bgp 7.7.7.7 on any one of the routers in AS1 and look for the line 'not synchronised'. In the case of BGP sync, you would need to have a route to 7.7.7.7/32 learned via an IGP for this iBGP route to be considered valid. If you turn BGP sync off, this requirement is not needed. Also, you should full mesh the iBGP relationships insode AS 1.
2. Do the the edge routers have the neighbor ip next-hop-self command on for the iBGP neighbours? Remember that the BGP NEXT_HOP attribute is not updated by default when advertising through iBGP, so the BGP next hop for 7.7.7.7 (if this command is not turned on) would actually be the IP address of FRANCO or JACOBS - and the IP address would be the one that the eBGP relationship to AS1 is setup on. 7.7.7.7 would actually get advertiesd to RODMAN OK but would not pass the valid next-hop requirement in the BGP path selection process.

Crap just re-read the post and you said that LANDON could ping FRANCO so I'm guessing you do have the next-hop-self command on the edge routers (and i noticed LANDON has BGP sync turned off too) or LANDON knows some way to reach the 192.168.47.0/24 network (i.e. OSPF is enabled on the external interface on HUNISKER)?

unclerico

As part of the decision making process, if the Local Pref was left at the default of 100 then AS_PATH will be used. The AS_PATH is better going through Hunisker (4 i) as opposed to through Franklin (2 3 4 i)...don't you just love BGP??

WillTech105

:O wow dont i feel like an idiot. After recreating this lab without being sleep-deprived, RODMAN can now ping 7.7.7.7 -- I was probably missing a network statement somewhere. Unfortuantly my show runs never were saved so thats my only assumption.

Regardless I really appreciate everyone trying to help me on this one. The best way to learn something is to have it broken and then try "banging ur head against the wall" researching it and tryinging diff methods out. Thanks a bunch guys!

Forsaken_GA

Chris_ wrote: »

This is where the IBGP full mesh rules kick in; neither FRANKLIN or LANDON will share this route with their IBGP neighbor RODMAN. The BGP Split Horizon rule states that any route received from an internal BGP peer will not be shared with any other internal BGP peer.
This rule has an impact on transit AS in that it effectively dicatates that the area must have a full mesh of BGP peerings in order for routes to be shared around the AS.

Rodman could learn the route from Franklin, just not via iBGP. If Franco eBGP's the route to Pinto, who sends it to Jacobs, who sends it to Franklin, then Rodman could learn it from Franklin via the eBGP route.

Forsaken_GA

lrb wrote: »

post and you said that LANDON could ping FRANCO so I'm guessing you do have the next-hop-self command on the edge routers (and i noticed LANDON has BGP sync turned off too) or LANDON knows some way to reach the 192.168.47.0/24 network (i.e. OSPF is enabled on the external interface on HUNISKER)?

It doesn't look he's got next-hop self enabled. If you look at the next hop values from the bgp table he posted from Rodman, you'll see some of them are for 192.168.35.0/24, which is the transit link between Franklin and Jacobs.

I'd be willing to bet the entirety of this problem is because Rodman was missing a route to a next hop value, and that your initial suggestion of having the border routers set next-hop-self would have solved it.