2

I was playing with an EIGRP Lab in GNS3, and came across a very weird oddity.

Here is the topology:

EIGRP Lab Topology

Here is the oddity:

R2# show ip eigrp topology
<~-~-~ output ommitted ~-~-~>
P 10.4.5.0/24, 1 successors, FD is 309760   <----
        via 10.2.3.3 (332800/307200), FastEthernet0/0
P 10.3.4.0/24, 1 successors, FD is 307200
        via 10.2.3.3 (307200/281600), FastEthernet0/0

Notice for 10.4.5.0/24, I am seeing two different values displayed for Feasible Distance. The line with the arrow reports the FD as 309760. The line just below it reports the FD as 332800.

I included the route for 10.3.4.0/24 as a comparison, In that route (as I expect it to be), the FD in the first line matches the FD in the second line (both 307200).

Looking at the EIGRP route in more detail:

R2# show ip eigrp topology 10.4.5.0/24
IP-EIGRP (AS 99): Topology entry for 10.4.5.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 309760
  Routing Descriptor Blocks:
  10.2.3.3 (FastEthernet0/0), from 10.2.3.3, Send flag is 0x0
      Composite metric is (332800/307200), Route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit     <---- 
        Total delay is 3000 microseconds    <----
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2

We can use the highlighted values to calculate the EIGRP Metric using the default K-values and this formula: 256 * (BW + Delay). Which equates to:

256 * (1000 + 300) = 332800

So the Feasible distance to 10.4.5.0/24 on R2 is 332800. And the show ip route output is indeed showing this:

R2# show ip route 10.4.5.0
Routing entry for 10.4.5.0/24
  Known via "eigrp 99", distance 90, metric 332800, type internal

But for whatever reason, in the EIGRP topology table, I am seeing this other strange value 309760:

R2# show ip eigrp topology
P 10.4.5.0/24, 1 successors, FD is 309760
        via 10.2.3.3 (332800/307200), FastEthernet0/0

What is causing the 309760 value? Why am I seeing two different values in what I thought was always the Feasible Distance? Why is the 10.4.5.0/24 route the only one in my network that is showing two different values?

1

Try "clear ip eigrp neighbors" and then revisit the "show ip eigrp topology" output. Now it should reflect the correct values for the Feasible Distance and the Reported/Advertised Distance.

| improve this answer | |
  • Marking this as the correct answer. I'm chalking this up to a bug. After reboots and restarts, the value was as expected. – Eddie Sep 7 '16 at 15:48
1

332800 = Computed distance

307200 = Reported distance

309760 = Feasible distance

FD is a historical value, it is the closest the router was to the destination before the last Active/Passive change.

| improve this answer | |
0

You interpretation:

Notice for 10.4.5.0/24, I am seeing two different values displayed for Feasible Distance. The line with the arrow reports the FD as 309760. The line just below it reports the FD as 332800.

is incorrect. The FD is 309760. The cost to the destination is 332800. You would not normally see any duplicate information as you seem to think the command shows.

EIGRP Commands:

Feasible distance. The feasible distance is the best metric to reach the destination or the best metric that was known when the route went active. This value is used in the feasibility condition check. If the reported distance of the router (the metric after the slash) is less than the feasible distance, the feasibility condition is met and that path is a feasible successor. Once the software determines it has a feasible successor, it need not send a query for that destination.

and

The first number is the EIGRP metric that represents the cost to the destination. The second number is the EIGRP metric that this peer advertised.

Enhanced Interior Gateway Routing Protocol

Feasible Distance, Reported Distance, and Feasible Successor

Feasible distance is the best metric along a path to a destination network, including the metric to the neighbor advertising that path. Reported distance is the total metric along a path to a destination network as advertised by an upstream neighbor. A feasible successor is a path whose reported distance is less than the feasible distance (current best path). Figure 3 illustrates this process:

eigrp3.gif

Router One sees that it has two routes to Network A: one through Router Three and another through Router Four.

  • The route through Router Four has a cost of 46277376 and a reported distance of 307200.
  • The route through Router Three has a cost of 20307200 and a reported distance of 307200.

Note that in each case EIGRP calculates the reported distance from the router advertising the route to the network. In other words, the reported distance from Router Four is the metric to get to Network A from Router Four, and the reported distance from Router Three is the metric to get to Network A from Router Three. EIGRP chooses the route through Router Three as the best path, and uses the metric through Router Three as the feasible distance. Since the reported distance to this network through Router Four is less than the feasible distance, Router One considers the path through Router Four a feasible successor.

When the link between Routers One and Three goes down, Router One examines each path it knows to Network A and finds that it has a feasible successor through Router Four. Router One uses this route, using the metric through Router Four as the new feasible distance. The network converges instantly, and updates to downstream neighbors are the only traffic from the routing protocol.

Let us look at a more complex scenario, shown in Figure 4.

eigrp4.gif

There are two routes to Network A from Router One: one through Router Two with a metric of 46789376 and another through Router Four with a metric of 20307200. Router One chooses the lower of these two metrics as its route to Network A, and this metric becomes the feasible distance. Next, let us look at the path through Router Two to see if it qualifies as a feasible successor. The reported distance from Router Two is 46277376, which is higher than the feasible distance - so this path is not a feasible successor. If you were to look in the topology table of Router One at this point (using show ip eigrp topology), you would only see one entry for Network A - through Router Four. (In reality there are two entries in the topology table at Router One, but only one will be a feasible successor, so the other will not be displayed in show ip eigrp topology; you can see the routes that are not feasible successors using show ip eigrp topology all-links).

Let us suppose that the link between Router One and Router Four goes down. Router One sees that it has lost its only route to Network A, and queries each of its neighbors (in this case, only Router Two) to see if they have a route to Network A. Since Router Two does have a route to Network A, it responds to the query. Since Router One no longer has the better route through Router Four, it accepts this route through Router Two to Network A.

  • The Feasible Distance is the best metric (at least as reported when the router became active) to the destination.
  • The Metric to the Destination is the sum of all the metrics between the router on which you are reporting and the destination.
  • The Advertised Distance is distance another router tells you is its metric to the destination.

Among the other routers reporting an Advertised Distance, your router will compare all the Advertised Distances to the Feasible Distance. Any routers with an Advertised Distance less than the Feasible Distance will become Feasible Successors, and the router with the best Advertised Distance will be the Successor. If there are no routers reporting an Advertised Distance less than the Feasible Distance, there will be no Successors or Feasible Successors.

Your problem with the two different values is that they are two different things. The first is the Feasible Distance, which may be the best metric for the route reported at the time when the route became active, but it may no longer be the metric to the destination (the original best path may be down, or something may have changed on the path, e.g. using the bandwidth or delay interface commands). The second number is the metric to the destination.

| improve this answer | |
  • I don't think you understood the question. There are three numbers in question: 309760, 332800, and 307200... If one is the Feasible Distance and another is the Reported (Advertised) Distance, than what is the third? – Eddie Mar 23 '16 at 20:30
  • Right there in the quote in my answer are the definitions for the two numbers (332800/307200) in the second line. The FD number (309760) in the first line is the feasible distance. So, in order, you have feasible distance, destination metric, and advertised distance. Your original understanding of the output is incorrect. – Ron Maupin Mar 23 '16 at 20:33
  • The route immediately after to 10.3.4.0/24 uses these 3 for the 3 numbers: 307200,307200,281600. How (in that case, per your definitions) is the feasible distance the same as the destination metric. Also, how did the metric formula used to calculate the feasible distance result in 332800, despite you claiming the FD is 309760. How was this number calculated. – Eddie Mar 23 '16 at 21:09
  • The explanation in the Table 23 of the above link is: "Feasible distance. The feasible distance is the best metric to reach the destination or the best metric that was known when the route went active. This value is used in the feasibility condition check. If the reported distance of the router (the metric after the slash) is less than the feasible distance, the feasibility condition is met and that path is a feasible successor. Once the software determines it has a feasible successor, it need not send a query for that destination." – Ron Maupin Mar 23 '16 at 21:15
  • Here is a link with a longer explanation about those three values: cisco.com/c/en/us/support/docs/ip/… – Ron Maupin Mar 23 '16 at 21:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.