Re: Behavior of 'bgp best-path as-path ignore'

From: Erich Borchert (erichb80@xxxxxxxxxxx)
Date: Wed Feb 20 2002 - 21:20:55 GMT-3


   
Try enabling bgp always-compare-med on all routers in AS100, when trying to
compare med's between different AS#'s

-Erich
----- Original Message -----
From: "Dennis Dumont" <dfdumont@yahoo.com>
To: <ccielab@groupstudy.com>
Sent: Wednesday, February 20, 2002 11:03 AM
Subject: Behavior of 'bgp best-path as-path ignore'

> I've got an interesting situation while playing around
> with obscure BGP commands. I've got a six router pod
> with three conections to an external AS-254, and
> another connection to an external AS-253. The two
> externals are themselves connected behind the pod.
>
> The two central routers have connections to all of the
> edge routers. All routers in the pod are the same
> AS-100.
> There are no direct connections from the edges to any
> routers other than R3 and R4.
>
> Here's the funny part. With normal behavior, the
> selected paths on R3 (the test box for this) BGP
> chooses the shortest AS-path, like its supposed to. I
> have the three paths to AS-254 each with specific MEDs
> for later fun, but the MED's are ignored unless trying
> to break a tie between equal-length AS-paths.
>
> When I turn on the above command on R3, I don't get
> the best path as determined now by the MED, but rather
> I get the preferrence of the LONGEST AS-path!
>
> Here's R3 BGP block:
> router bgp 100
> no synchronization
> bgp log-neighbor-changes
> bgp bestpath med missing-as-worst
> bgp bestpath as-path ignore
> neighbor local peer-group
> neighbor local remote-as 100
> neighbor local password cisco
> neighbor local update-source Loopback0
> neighbor local soft-reconfiguration inbound
> neighbor 176.14.1.1 peer-group local
> neighbor 176.14.2.2 peer-group local
> neighbor 176.14.4.4 peer-group local
> neighbor 176.14.5.5 peer-group local
> neighbor 176.14.6.6 peer-group local
>
> Here's the BGP table - note the selected paths:
> Network Next Hop Metric LocPrf
> Weight Path
> * i192.14.1.0 176.14.2.2 0 100
> 0 253 i
> * i 176.14.5.5 200 100
> 0 254 253 i
> * i 176.14.6.6 300 100
> 0 254 253 i
> *>i 176.14.1.1 4294967294 100
> 0 254 252 253 i
> * i192.14.2.0 176.14.2.2 0 100
> 0 253 i
> * i 176.14.5.5 200 100
> 0 254 253 i
> * i 176.14.6.6 300 100
> 0 254 253 i
> *>i 176.14.1.1 4294967294 100
> 0 254 252 253 i
> * i192.14.3.0 176.14.2.2 0 100
> 0 253 i
> * i 176.14.5.5 200 100
> 0 254 253 i
> * i 176.14.6.6 300 100
> 0 254 253 i
> *>i 176.14.1.1 4294967294 100
> 0 254 252 253 i
> * i192.14.4.0 176.14.2.2 0 100
> 0 253 i
> * i 176.14.5.5 200 100
> 0 254 253 i
> * i 176.14.6.6 300 100
> 0 254 253 i
> *>i 176.14.1.1 4294967294 100
> 0 254 252 253 i
> * i192.14.5.0 176.14.2.2 0 100
> 0 253 i
> * i 176.14.5.5 200 100
> 0 254 253 i
> Network Next Hop Metric LocPrf
> Weight Path
> * i 176.14.6.6 300 100
> 0 254 253 i
> *>i 176.14.1.1 4294967294 100
> 0 254 252 253 i
> * i192.14.6.0 176.14.2.2 0 100
> 0 253 i
> * i 176.14.5.5 200 100
> 0 254 253 i
> * i 176.14.6.6 300 100
> 0 254 253 i
> *>i 176.14.1.1 4294967294 100
> 0 254 252 253 i
> * i200.200.220.0 176.14.2.2 4294967294 100
> 0 253 254 i
> * i 176.14.5.5 200 100
> 0 254 i
> * i 176.14.6.6 300 100
> 0 254 i
> *>i 176.14.1.1 0 100
> 0 254 252 i
> * i200.200.221.0 176.14.2.2 4294967294 100
> 0 253 254 i
> * i 176.14.5.5 200 100
> 0 254 i
> * i 176.14.6.6 300 100
> 0 254 i
> *>i 176.14.1.1 0 100
> 0 254 252 i
>
> Has anyone else seen this? OR is my code bad [12.1(11)]
>



This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:29 GMT-3