Scribd
Upload
142 views6 pages

EIGRP Feasible Distance Proof of Concept

This document describes a lab experiment to demonstrate the true operation of the Feasible Distance parameter in EIGRP. The lab shows that Feasible Distance is not the current metric to reach a route, but rather the lowest metric the router recorded at any time since the route last transitioned to an active state. By modifying link metrics and delays, the lab illustrates that Feasible Distance only changes when a route becomes active, not when intermediate link metrics change. This helps routers avoid potential routing loops by disregarding routes with higher metrics than what was once feasible.

Uploaded by

Saptarshi Bhattacharjee
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
142 views6 pages

EIGRP Feasible Distance Proof of Concept

This document describes a lab experiment to demonstrate the true operation of the Feasible Distance parameter in EIGRP. The lab shows that Feasible Distance is not the current metric to reach a route, but rather the lowest metric the router recorded at any time since the route last transitioned to an active state. By modifying link metrics and delays, the lab illustrates that Feasible Distance only changes when a route becomes active, not when intermediate link metrics change. This helps routers avoid potential routing loops by disregarding routes with higher metrics than what was once feasible.

Uploaded by

Saptarshi Bhattacharjee
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

EIGRP Feasible Distance Proof of Concept

This is a lab that observes the true operation of the Feasible Distance parameter in EIGRP. This was
sparked after reading about the description of Feasible Distance from the CCIEv5 R&S Official
Certification Guide, Volume 1.

Basically, we will redefine some terms that have been commonly used to describe the different metrics
EIGRP assigns to routes.

Reported Distance This is the distance sent to the local router by its neighbor. This is
sometimes called the Advertised Distance but because confusion can arise with the acronym
AD most books seem to be navigating towards calling it Reported Distance.

Calculated Distance This is the distance computed by the local router. Basically, the router
takes the Reported Distance from its neighbor and adds its metric to reach that neighbor to it.
This has been called Feasible Distance in many texts (and in Cisco Documentation).

Feasible Distance This is the best metric to reach a destination a router had at some point in
time since the last time that route went active. (Wow! Thats a lot of words). Basically, this is the
routers way of saying Hey, I remember my best metric to reach that network was XXX last time
I had to check it. This is what makes the Feasibility Condition work.

All of those definitions are probably what you are used to studying in CCNA and CCNP level texts. The
only difference is the new definition of Feasible Distance. This can be kind of hard to grasp at first.

The important thing to remember is this does NOT change how the Feasibility Condition works. The
router will still not use any route that has a Reported Distance larger than the current Feasible Distance.

The difference is how the Feasible Distance is calculated and when it is updated.

To illustrate this I have set up a simple three router lab.


R3 will be our focal point of this lab.

All routers have been configured for EIGRP AS 100. To make the metric numbers more predictable all
interfaces have their delay set to 1 and the EIGRP metric weights have been modified to only include
delay in their calculations. This is done using the metric weights 0 0 0 1 0 0 command in router
configuration mode for EIGRP.

This makes it so that every routers link has a metric of 256. Recall that the EIGRP metric calculation
(simply) is 256(Bandwidth + Delay). Since we have set bandwidth to 0 the result is 256 x Delay.
Lets first look at the topology table for R3 before we make any additional changes. Take special note to
the current Feasible Distance to 192.168.1.0/24.

The current Feasible Distance is 512. This is expected because R1 and R2 are both reporting their
distance to 192.168.1.0/24 as 256.

R3 has a metric of 256 to reach both R1 and R2. 256 + 256 = 512. According to our new understanding of
Feasible Distance R3 will hold that value as its lowest metric to reach that subnet no matter what its
Calculated Distance to the route becomes.

Lets change R3s metric on its Serial0/1 and Serial0/2 interfaces to double what is configured currently.
When we run the show ip eigrp topology command we should see a Calculated Distance of 768 and a
Reported Distance of 256 from both R1 and R2. However, the Feasible Distance should remain 256
because changing the metric on an interface does not cause the route to go into active state.

As we can see the Feasible Distance is still 512 because changing the interface metric does not cause a
route to go into active state. Our Reported Distance from our neighbors is 256 and the Calculated
Distance has increased to 768. Remember, as long as the Reported Distance is less than the current
Feasible Distance each router will be considered a Feasible Successor.
Now we will change the delay setting on R1 FastEthernet0/0 interface to 3. This will increase its
Reported Distance to 768. This should remove it from the show ip eigrp topology table.

In order to view it we need to add the all-links option to the show ip eigrp topology command.

From the output we see that the Reported Distance has been changed to 768. This also affected R3s
Calculated Distance to reach that network. However, remember the reason this path is not a Feasible
Successor is because the Reported Distance is more than the current Feasible Distance R3 has saved for
that route.

In other words R3 is saying I know my current best Calculated Distance for this route is 768, however,
at one point, my best Calculated Distance to 192.168.1.0/24 was 512. Knowing this, I can logically
assume that any router that reports a distance lower than this cannot create a loop back to me.

R3 will not change its Feasible Distance unless that route goes into an active state again. (and runs
DUAL).

To test this I will shut down the Serial0/1 link.


The previously looped connection becomes the Feasible Successor. Also note that the Feasible
Distance has changed to 1280. This is because the route went into active and accepted the new
Calculated Distance of 1280.

Now lets enable that interface again. We should see the Feasible Distance change and 10.1.1.1 should
no longer be a successor for that route.
Now lets set the delays on R1 and R2 back to 1 and see what the effect will be.

The route to 10.1.1.1 meets the Feasibility Condition and is now added to the list of Feasible Successors.

Now, we will set R3s delay values back to 1. The result should be returning things to the way they were
at the beginning of the lab.

There you have it. So lets hit the high points

Conclusion
Feasible Distance in EIGRP is not the current metric to the route. It merely represents the lowest metric
to reach that route since the local router ran the EIGRP DUAL process.

In other words, Feasible Distance is the router remembering the last best metric it had back in the day.

You might also like