[c-nsp] BGP/EIGRP Route Determination

[Randy]

Brian,

Given your config, what you are seeing is the *expected behavior*

Wrt <snip>....25% of the time it works:
It does so because EIGRP has taken longer to converge.

Essentially, if you desire failover&failback to work as-You-want, you have two options:

1) lower "weight" to 32767 as opposed to the current-50000 for you inbound bgp updates(whether you do so for all-updates via default-weight OR via an inbound route-map is up to you. I prefer the route-map approach.) 
2) leave 50k in place for in-bound bgp updates and change what you inject into bgp via your eigrp-to-bgp redistribution statement; with a route-map so as to set the weight to 49999 for prefix/s being redistributed to target-protocol - bgp in this case.

What you are seeing is because of the bgp weight-attribute-value not protocol-AD.

Leave protocol-AD's at their defaults:

EIGRP(I) 90
EIGRP(E) 170
EIGRP (summ) 5

BGP - 20(e)200(i)200(loc)

On a separate yet related note:

If I were you, I would take a long hard look at the your-architecture and ask myself the following:

1) IS mutual-redistribution really necessary(bgp-eigrp-bgp)
2) WHY am I redistributing iBGP into eBGP(the redis bgp-internal statement in your rtr-b bgp config)

HTH
./Randy




--- On Fri, 12/23/11, Brian Tate <tatebk at hotmail.com> wrote:

> From: Brian Tate <tatebk at hotmail.com>
> Subject: Re: [c-nsp] BGP/EIGRP Route Determination
> To: cisco-nsp at puck.nether.net
> Date: Friday, December 23, 2011, 5:08 AM
> 
> Thanks for the response, but I'm confused by it - I don't
> think I want to lower the EIGRP AD, as I don't want it to be
> the preferred route.
> Your correct, the external BGP AD is lower [20] than the
> EIGRP learned route [90]... which is why it does install BGP
> as the preferred route, initially.
> But upon failure at Rtr-A, Rtr-B loses the external BGP
> route, and installs the EIGRP learned route... as it
> should.
> But upon restore of Rtr-A, Rtr-B is not always returning to
> the external BGP route - if I reset the EIGRP adjacency on
> Rtr-B, then it will install the BGP route.
> 
> Here are my routing table outputs for the 10.60.0.0/16
> summarized route, on Rtr-B:
> D       10.60.0.0 [90/6436112] via
> X.X.X.X, 00:00:58, Vlan999   (only present in
> the routing table when the issue occurs)
> B       10.60.0.0 [20/0] via
> Y.Y.Y.Y, 00:00:02  (normally present, and re-installed
> after clear eigrp adjacency)
> 
> Here is the EIGRP topology in a normal state:
> sh ip eigr top 10.60.0.0/16
> EIGRP-IPv4 Topology Entry for AS(1)/ID(192.168.0.19) for
> 10.60.0.0/16
>   State is Passive, Query origin flag is 1, 1
> Successor(s), FD is 32000
>   Descriptor Blocks:
>  Y.Y.Y.Y, from Redistributed, Send flag is 0x0
>       Composite metric is (32000/0), route
> is External
>       Vector metric:
>         Minimum bandwidth is 100000
> Kbit
>         Total delay is 250
> microseconds
>         Reliability is 255/255
>         Load is 1/255
>         Minimum MTU is 1500
>         Hop count is 0
>         Originating router is
> 192.168.0.19
>       External data:
>         AS number of route is 68500
>         External protocol is BGP,
> external metric is 0
>         Administrator tag is 13000
>   X.X.X.X (Vlan999), from X.X.X.X, Send flag is 0x0
>       Composite metric is (6436112/6435856),
> route is Internal
>       Vector metric:
>         Minimum bandwidth is 100000
> Kbit
>         Total delay is 250410
> microseconds
>         Reliability is 255/255
>         Load is 1/255
>         Minimum MTU is 1500
>         Hop count is 2
> 
> 
> Also, here is the BGP detail for the same route
> - This is the BGP entry when the issue occurs - before
> clearing EIGRP neighbors
>       Network       
>   Next Hop           
> Metric LocPrf Weight Path
> *> 10.60.0.0/16     X.X.X.X 
>           6436112   
>      32768 ?
> 
> - After clearing EIGRP, and the desired path -
> *> 10.60.0.0/16     Y.Y.Y.Y 
>                
>                
> 50000 13000 68500 ?
> 
> Thanks
> - Tate
> 
> 
> > 
> > I've seen this before and it was due to the bgp routes
> having a lower admin distance (external). Orignally the euro
> adjacency would have been established first so eirgp's
> routes were selected.
> > 
> > You need to modify rtr b so eirgp has a better admin
> distance then external bgp
> > 
> 
>     
>         
>           
>   
> _______________________________________________
> 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/
>