EIGRP “FD is Infinity”

Let’s take a look at EIGRP and the state a route can get into where EIGRP tells you “FD is Infinity”.

First of all, every EIGRP speaker maintains a local database called the EIGRP topology table which holds a copy of every route received from every neighbor and every route being advertised by the local system. EIGRP performs its best-path decision process on the entries in this table in order to determine which routes are the best and then hands those best routes to the Routing Information Base (the RIB). By inspecting the entries in this table, you can see things like:

The next hop (123.1.0.18) is on a locally connected interface and is reachable

Perhaps most confusing, the local composite metric (198000640) is a reasonable value and is far from “infinity”

The RIB value (4294967295) is recognizable as 232 – 1; this is essentially the RIB’s value of “infinity” indicating the route is not going to be present in the RIB

So what’s going on here? Unless I’m missing something, there isn’t a direct way to understand what this means (please post a comment if I’ve overlooked something). Instead we need to get our hands dirty with our good friend debug.

Since we see the route in the EIGRP topology table, we know that the EIGRP update message is being received successfully so we can assume this has nothing to do with EIGRP updates. We could investigate the EIGRP finite state machine (“debug eigrp fsm”) but since I’ve already done that and can tell you that it has nothing to do with this, I won’t go there. Instead, let’s debug the routing table to see what it’s doing when EIGRP sends it the 10.1.14.0/24 route.

Here’s a tip for debugging the routing table: since the output can be quite verbose, create an access-list that matches on the prefix(es) you want to inspect and then use that ACL when turning on debug.

Oh. This makes things much clearer. The same route is being learned via BGP (in this case, eBGP with an admin distance of 20) which is causing the RIB to yank the EIGRP route and install the eBGP route.

Based on this information we can say that:

There’s nothing wrong with the EIGRP topology table entry

EIGRP is sending the route to the RIB just fine (and it actually gets installed in the RIB for a split second)

The “FD is Infinity” message is actually an indicator within EIGRP that the RIB rejected the route due to a lower admin distance route already being present

Of course this would’ve been obvious by doing a “show ip route 10.1.14.0” and seeing the route was learned via BGP but sometimes you can get so deep into troubleshooting one very specific thing that you just can’t see the forest for the trees.

Disclaimer:
The opinions and information expressed in this blog article are my own and not necessarily those of Cisco Systems.

There are two ways to make the EIGRP route the preferred route. One is to either adjust the admin distance of the eBGP route upwards (so it’s less preferred) or adjust the AD of the EIGRP route downwards (more preferred). You can use the “distance” command under the EIGRP process to lower the AD of the EIGRP route. Beware the consequences of doing this. Default AD values are chosen on purpose and changing them should only be done if you really understand what the impact will be.

The other way is to just filter the eBGP route from entering the RIB. You could do this with a route-map/prefix-list on the neighbor(s) where this route is learned or with a table-map to allow the route into the BGP RIB, but prevent it from entering the IP RIB.