Redistribution and AD on the LOCAL ROUTER

[wintermute000]

We all know about AD fun and games whilst redistributing but I ran into a hilarious niche scenario


Say you are redistributing a static route with an AD of e.g. 200 into something else with an AD below 200


I labbed this just to double check and a routing loop / race condition does NOT develop, the RiB happily accepts the AD200 static route even though it redistributes it correctly into say EIGRP (AD90)


Can anyone find any reference material to back this up/explain this properly? like some kind of 'origin code' in the RiB process?

[srg]

I don't follow, why would it? Did you think the route would turn into an EIGRP route because of the lower AD?

[wintermute000]

Not locally, but I know for a fact that if that same router learns the route from another source but same protocol, the better AD preempts, even if you have redistributed a 'better' metric into the topology table originally

e.g. this concrete example I have encountered - static route with AD 200 redistributed into EIGRP. Due to stupid design, the EIGRP route ends up looping back into itself - whereupon it enters the RiB immediately due to AD (confirmed via debug ip routing) - despite the EIGRP table having (for a split second anyway) a superior metric route that was originally redistributed. TAC confirms this behaviour is legit but even they can't give me a document with 'routing comparison order of operations' or the like in this scenario.

Maybe I have been doing too much BGP lately but it took me by surprise since I was expecting the topology table to duke it out before going down to AD but in this case it doesn't

[Fred]

Not locally, but I know for a fact that if that same router learns the route from another source but same protocol, the better AD preempts, even if you have redistributed a 'better' metric into the topology table originally

If you learn a route from a routing protocol, the AD will determine which route gets entered into the routing table.  I believe this happens first.

e.g. this concrete example I have encountered - static route with AD 200 redistributed into EIGRP. Due to stupid design, the EIGRP route ends up looping back into itself

Are you sure this isn't the issue?  The route that was redistributed should be subject to the same feasibility rule that should prevent it from even being considered back into EIGRP.  In other words, EIGRP should have discarded the route before it considered AD.

whereupon it enters the RiB immediately due to AD (confirmed via debug ip routing) - despite the EIGRP table having (for a split second anyway) a superior metric route that was originally redistributed.

EIGRP should prevent any route it's advertising (whether redistributed or otherwise) from being a feasible successor. 

Can you give any more specifics? EIGRP won't ever learn a route it's advertising from another host. It's mathematically impossible, unless some other redistribution is happening and throwing away some of the metric information.

[wintermute000]

Thats what I thought, but I was online with TAC (not that TAC is the font of all wisdom these days...) and he said it was definitely looking @ AD before it compares the topology table.


Which is opposite of say BGP (e.g. iBGP vs eBGP route)


I sort of reproduced the issue in IOU/GNS3, and have debug ip routing logs that say loud and clear that its installing a new EIGRP route (on the route feedback path) due to superior AD. If I down that interface, the router is happy with a AD 200 static, and EIGRP topology has the redistributed route (as does the next hop).