EIGRP / Static Route Redistribution

mwasserman · ‎10-04-2007

Last week we ran into a nasty situation where we had a routing loop on three of our core routers which prevented us from accessing one of our satellite offices. The circumstances of this event are not too important, but there are a few interesting things we observed.

Consider three routers running EIGRP, R1, R2 and R3. Consider a network, 10.0.0.0/8.

EIGRP AD is 90, EIGRP external AD is 170.

R1 and R2 are configured to redistribute, outbound, static routes based on distribute list EIGRP_OUT.

ip access-list standard EIGRP_OUT

permit 10.0.0.0 0.255.255.255

R1 and R2 are configured with a static route:

ip route 10.0.0.0 255.0.0.0 1.1.1.1 190

Thus, this is a floating static route with AD=190 through some next-hop of 1.1.1.1.

Right off the bat, this route is NOT redistributed into the EIGRP domain; running "show ip eigrp topology 10.0.0.0" returns "% IP-EIGRP (AS 1): Route not in topology table."

This is my first question: is EIGRP programmed not to redistribute any route whose administrative distance is larger than 170, its own AD for externally learned routes?

This sort of makes sense -- if the route exists with a horrible AD, maybe EIGRP shouldn't even be informing other routers about it. I am simply not sure whether this is the case, and I can't seem to find any confirmation from Cisco documentation about this.

The scenario continues.

I remove the static routes from both R1 and R2. I re-add the static route to R1:

ip route 10.0.0.0 255.0.0.0 1.1.1.1 169

Thus, I re-add the static route but this time its AD is less than the AD of an EIGRP external route.

I issue "show ip eigrp topology 10.0.0.0" on R1, R2 and R3 and they all display entries in their topology table: this route is now definitely being redistributed into the EIGRP domain.

The plot thickens; I remove this static route from R1. Again running the "show ip eigrp topology" command on all three routers, the entry has dissapeared from the EIGRP domain (this is expected since there are no sources left to originate this route).

Now, the absolute strangest part -- I re-add the static route on R1:

ip route 10.0.0.0 255.0.0.0 1.1.1.1 190

Thus, I re-add it as I had originally added it -- with an AD of 190.

Issuing "show ip eigrp topology" on all three routers displays entries for this network!!!!!!!!!!!!

There you have it -- once EIGRP "learns" about the existence of this network, it redistributes the route even if the route's AD is higher than that of an EIGRP external route.

This is my second question: what is going on here, exactly? It seems that the EIGRP process is 'caching' something about the 10.0.0.0 network; even after it dissapears from the toplogy/routing tables on routers, it still seems to know about it.

This is incredibly strange and I am curious to find out if anybody can exlpain any part of this ;-)

I'm more than happy to discuss further if anyone is curious.

FYI --

R1 & R2 -- 6509 BXL SUP720, running s72033-advipservicesk9_wan-mz.122-18.SXF8.bin

R3 -- 3750G Stack (multiple switches), running c3750-ipservices-mz.122-35.SE2.bin.

Thanks in advance for your interest, curiosity and for your thoughts!

intelide3 · ‎10-04-2007

hi,

since that was a long explanation & questions,

the only thing that comes to my mind was :

how long have you give the routers to populate their eigrp top?

try to reproduce the problem with clear ip eigrp top -> to clear eigrp top cache, and give it some time to populate its topology.

AFAIK - there is no metric (below 255 of course)limitation for the eigrp to redistribute any routes.

CMIIW.

Cheers.

Richard Burts · ‎10-04-2007

Michael

As far as I know EIGRP does not care about what the AD of any route is in the routing table that it is configured to redistribute (higher than or lower than EIGRP AD should not matter). And this is confirmed by the later part of what you describe.

I am not sure why the first time you checked it did not show it in the topology table. I can only assume that for some reason the static was not in the routing table. The main reason that a floating static would not be in the routing table is that either some route for that prefix with a better AD was in the table or that the next hop for that route was not reachable. Is it possible that either of these conditions existed?

Is there any source of routing information on these routers other than EIGRP and static routes (and is there any possibility that there is an EIGRP process using a different AS number?)

HTH

Rick

HTH

Rick

Kevin Dorrell · ‎10-04-2007

That is indeed a curious story. I cannot explain it off the top of my head, but it does provoke some idea that will have to taken into account when we try and explain it.

1. The route has an AD of 190 or 169, but only on the router that originated it. By the time it gets to the other routers, its AD is 170. I don't know if that is relevant, but should be bourne in mind.

2. Where is the redistribution metric set, in the redistribute command or as a default metric? And perhaps relevantly, was the metric set after you created the static route or before. Did you set the metric after you set the redistribute command?

3. I observed some curious behavior a couple of weeks ago with redistribution into EIGRP, the full transcript of which you might like to look up on the forum. To cut a long story short, I put in the redistribute command referring to a route-map, but without a default metric. I then created the route map, and set the metric within the route map, but my routes did not turn up. Setting a default metric made them turn up, but removing it made them go away again. But, if I added a new static route, it did turn up, even with the metric set in the route map.

At the end of the day, this rather unstable situation was resolved with clear ip route * from the exec. This re-populated the statics, and caused then to pass through the route map, picking up a metric on the way.

The more I'm telling you this story, the closer it seems to what happened in your case. I reckon that when you had the static AD 190, if you had done a clear ip route *, then it would have turned up in the topology table.

Kevin Dorrell

Luxembourg

mwasserman · ‎10-04-2007

I'm going to reply to several questions:

1. I have cleared the EIGRP process and the routing table and it still does not redistribute

2. The static route is in the routing table as a valid route

3. I've left this to sit for the whole day; the route (a different one this time, of course), with AD=190, does not show up in the topology table.

4. I am not concerned with the metric given to the redistributed routes; we have several routes which are being successfully redistributed into EIGRP from static.

5. The issue of having AD 190 for the static will cause a nasty routing loop when it's redistributed into EIGRP with AD=170. This was the cause of our problems in the first place ;-)

Still looking for more.... thanks for the responses guys.