[c-nsp] Believing iBGP over eBGP?

[Dry, Cameron]

The AD for BGP is only used to compare BGP to
other routing protocols, not between iBGP and eBGP.

eBGP paths will only take precedence over iBGP paths
if the higher priority attributes in the path selection algorithm
are the same (weight, local pref, AS path etc).

The "received-only" indicator for the AS7132 prefix indicates
that you are filtering the advertisement; therefore, BGP
has selected the path with the lowesr AS_PATH value.

So the solution is to either

a. Modify you ingress route-map to permit 0/0 from AS7132
    (if this is desired behaviour),or,
b. Apply an inbound route-map to modify the weight of
    the eBGP prefix so it is preferred (note that you can't
    use local pref as this will also make the route favourable
    to router A).

> -----Original Message-----
> From:	Patrick Bohannon [SMTP:pbohanno at kiva.net]
> Sent:	Wednesday, 11 August 2004 4:14 pm
> To:	cisco-nsp at puck.nether.net
> Subject:	[c-nsp] Believing iBGP over eBGP?
> 
> I'm having an interesting problem with eBGP and iBGP:
> 
> I am multihomed and accepting only default route from my eBGP peers.  Both
> peers are sending the default route just fine:
> 
> BorderA and BorderB do iBGP with each other, and each do eBGP with one of
> our upstream providers.  I've indicated in the appropriate places below the
> relationship each has to its peer(s).
> 
> Total number of prefixes 1 
> borderB#sh ip bgp neigh x.x.x.x routes          
> BGP table version is 128, local router ID is x.x.x.x
> Status codes: s suppressed, d damped, h history, * valid, > best, i -
> internal
> Origin codes: i - IGP, e - EGP, ? - incomplete
> 
>    Network          Next Hop            Metric LocPrf Weight Path
> *  0.0.0.0          x.x.x.x (eBGP peer)                    0 4279 4279 4279
> 7132 i
> 
> 
> Total number of prefixes 1 
> borderB#
> 
> My problem is that on the edge, I am believing the default route from my
> other edge router (we'll call it borderA) which is being delivered via iBGP
> instead of the eBGP delivered route.
> 
> borderB#sh ip route 0.0.0.0
> Routing entry for 0.0.0.0/0, supernet
>   Known via "bgp 4279", distance 200, metric 0, candidate default path
>   Tag 4323, type internal
>   Last update from x.x.x.x (borderA's eBGP peer) 00:27:42 ago
>   Routing Descriptor Blocks:
>   * x.x.x.x (borderA's eBGP peer), from x.x.x.x (borderA), 00:27:42 ago
>       Route metric is 0, traffic share count is 1
>       AS Hops 1
> 
> BorderA is also getting just a default route from its eBGP peer, which is
> probably implied here already.  Shouldn't the administrative distance of 20
> associated with eBGP-learned routes supercede the administrative distance of
> 200 associated with iBGP-learned routes?
> 
> Here's more:
> 
> borderB#sh ip bgp 0.0.0.0 
> BGP routing table entry for 0.0.0.0/0, version 128
> Paths: (3 available, best #3, table Default-IP-Routing-Table)
>   Not advertised to any peer
>   4279 4279 4279 7132
>     x.x.x.x (borderB's eBGP peer) from x.x.x.x (borderB's eBGP peer)
> (x.x.x.x)
>       Origin IGP, localpref 100, valid, external
>   7132, (received-only)
>     x.x.x.x (borderB's eBGP peer) from x.x.x.x (borderB's eBGP peer)
> (x.x.x.x)
>       Origin IGP, localpref 100, valid, external
>   4323
>     x.x.x.x (borderA's eBGP peer) (metric 20) from x.x.x.x (borderA)
> (x.x.x.x)
>       Origin IGP, localpref 100, valid, internal, best
> borderB#
> 
> Thanks!
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/