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:
- Bandwidth, Load, Delay, Reliability - the values to go into computing the composite metric
- The actual composite metric that the local system has calculated
- The composite metric that the neighbor calculated
- Whether the route is internal or external
- A list of all neighbors that advertised the route (neighbor's router ID)
- The feasible distance (FD) for the route
- The metric for the route as seen in the RIB
I've highlighted the lines in the output below where this information can be found.
R12#show ip eigrp topology 10.1.11.0/24
EIGRP-IPv4 VR(HQ) Topology Entry for AS(65201)/ID(10.1.12.12) for 10.1.11.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 131809280, RIB is 1029760
Descriptor Blocks:
123.1.0.18 (Ethernet0/0), from 123.1.0.18, Send flag is 0x0
Composite metric is (131809280/1392640), route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 1011250000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
123.1.1.14 (Ethernet0/1), from 123.1.1.14, Send flag is 0x0
Composite metric is (197345280/131809280), route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 2011250000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3
The output above is what I'll call a "healthy" topology table entry. We don't see "FD is Infinity" anywhere and if we check the RIB, the route is there too:
R12#show ip route 10.1.11.0
Routing entry for 10.1.11.0/24
Known via "eigrp 65201", distance 90, metric 1029760, type internal
[...]
Here's an example of a topology table entry where FD is Infinity:
R12#show ip eigrp topology 10.1.14.0/24
EIGRP-IPv4 VR(HQ) Topology Entry for AS(65201)/ID(10.1.12.12) for 10.1.14.0/24
State is Passive, Query origin flag is 1, 0 Successor(s), FD is Infinity, RIB is 4294967295
Descriptor Blocks:
123.1.0.18 (Ethernet0/0), from 123.1.0.18, Send flag is 0x0
Composite metric is (198000640/132464640), route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 2021250000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 4
Let's analyze this entry.
- Bandwidth, Delay, Reliability and Load all seem normal. None of the values are extreme.
- Side note: MTU and hop count are carried in EIGRP updates but they are not used in the metric calculation (draft-savage-eigrp-02, sec 5.5.1)
- 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 2^32 - 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.
R12(config)#access-list 99 permit 10.1.14.0 0.0.0.0
R12#debug ip routing 99
IP routing debugging is on for access list 99
R12#show debug
IP routing:
IP routing debugging is on for access list 99
Now, hit the thing with a hammer (you are doing this in the lab, right?) and let's see what happens.
R12#clear ip route *
R12#
*Mar 28 22:01:26.416: RT: updating eigrp 10.1.14.0/24 (0x0) :
via 123.1.0.18 Et0/0 0
*Mar 28 22:01:26.416: RT: add 10.1.14.0/24 via 123.1.0.18, eigrp metric [90/1546880]
Ok, cool. EIGRP has sent 10.1.14.0/24 to the RIB and the RIB is actually installing it. That's exactly what we thought should happen.
*Mar 28 22:01:26.417: RT: updating bgp 10.1.14.0/24 (0x0) :
via 10.1.11.11 0
*Mar 28 22:01:26.417: RT: closer admin distance for 10.1.14.0, flushing 1 routes
*Mar 28 22:01:26.417: RT:
R12#add 10.1.14.0/24 via 10.1.11.11, bgp metric [20/1029760]
*Mar 28 22:01:26.464: RT: updating eigrp 10.1.14.0/24 (0x0) :
via 123.1.0.18 Et0/0 0
*Mar 28 22:01:26.464: RT: rib update return code: 17
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.