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 <[email protected]> wrote: > From: Brian Tate <[email protected]> > Subject: Re: [c-nsp] BGP/EIGRP Route Determination > To: [email protected] > 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 [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
