From: Joseph Rothstein (ziutek@mac.com)
Date: Wed Sep 15 2004 - 19:01:00 GMT-3
Hi Guys,
I know what the problem is, but I am not sure how I get the results that I do compared to the author's.
As far as BGP path selection goes, I believe that the path selection comes down to number, 10, and does not go to 12.
"10. Prefer the route that can be reached through the closest IGP neighbor...." Although I am not sure if this applies to external routes as wella sinternal.
In this case, since the IGP section asks you to manipulate the bandwidth of the links between R1-R4 and R6-R4, 256 ans 512 respectively, the preferred path is to 10.6.6.6 like the bgp table shows since it has the lower OSPF metric.
Before:
R4#sipb
BGP table version is 20, local router ID is 10.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.0/29 10.6.6.6 0 61555 62555 i
* 10.1.1.1 0 61555 62555 i
*> 4.4.4.0/24 0.0.0.0 0 32768 i
* 5.5.5.0/27 10.1.1.1 0 61555 64555 i
*> 10.6.6.6 0 61555 64555 i
*> 8.8.8.0/28 10.6.6.6 0 61555 63555 i
* 10.1.1.1 0 61555 63555 i
In this case, R4 prefers R6 to 2.2.2.2 and R6 prefers R4 to 2.2.2.2, hence the loop.
I solved the problem by using the next-hop-unchanged on R6.
After:
R4#sipb
BGP table version is 12, local router ID is 10.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 2.2.2.0/29 10.90.90.1 0 61555 62555 i
*> 10.1.1.1 0 61555 62555 i
*> 4.4.4.0/24 0.0.0.0 0 32768 i
* 5.5.5.0/27 10.1.1.1 0 61555 64555 i
*> 10.6.6.6 0 61555 64555 i
*> 8.8.8.0/28 10.6.6.6 0 61555 63555 i
* 10.1.1.1 0 61555 63555 i
I'm not sure how the authors can come up with their BGP table if unless they did not change the bandwidth of the links. In that case, path selection criteria 12 would be in effect I believe, and then the prefered path would be to 10.1.1.1. The problem with this, is then, 8.8.8.8 is not reachable, and loops in the same manner that the 2.2.2.2 looped. R4 prefers the path to R1 for 8.8.8.8, and R1 prefers the path to R4.
Configs below for clarification and info.
R4#srb router bgp
router bgp 60555
no synchronization
bgp log-neighbor-changes
network 4.4.4.0 mask 255.255.255.0
neighbor PEER peer-group
neighbor PEER remote-as 61555
neighbor PEER ebgp-multihop 255
neighbor PEER update-source Loopback0
neighbor 10.1.1.1 peer-group PEER
neighbor 10.6.6.6 peer-group PEER
no auto-summary
R1#srb router bgp
router bgp 61555
no synchronization
bgp log-neighbor-changes
neighbor 10.4.4.4 remote-as 60555
neighbor 10.4.4.4 ebgp-multihop 255
neighbor 10.4.4.4 update-source Loopback0
neighbor 10.6.6.6 remote-as 61555
neighbor 10.6.6.6 update-source Loopback0
neighbor 10.8.8.8 remote-as 63555
neighbor 10.8.8.8 ebgp-multihop 255
neighbor 10.8.8.8 update-source Loopback0
neighbor 10.90.90.1 remote-as 62555
neighbor 10.90.90.1 update-source Loopback0
no auto-summary
R6#srb router bgp
router bgp 61555
no synchronization
bgp router-id 10.6.6.6
bgp log-neighbor-changes
neighbor 10.1.1.1 remote-as 61555
neighbor 10.1.1.1 update-source Loopback0
neighbor 10.4.4.4 remote-as 60555
neighbor 10.4.4.4 ebgp-multihop 255
neighbor 10.4.4.4 update-source Loopback0
neighbor 10.5.5.5 remote-as 64555
neighbor 10.5.5.5 ebgp-multihop 255
neighbor 10.5.5.5 update-source Loopback0
neighbor 10.8.8.8 remote-as 63555
neighbor 10.8.8.8 ebgp-multihop 255
neighbor 10.8.8.8 update-source Loopback0
no auto-summary
Thanks for your input,
Joe
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:44 GMT-3