Options

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Cisco Community
- :
- Technology and Support
- :
- Networking
- :
- Routing
- :
- Definition Of Feasible Distance In EIGR...

7077

Views
75

Helpful
10

Replies
Highlighted

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

07-29-2015
01:56 AM

07-29-2015
01:56 AM

hi

i have some problems with understanding the definition of feasible distance in EIGRP Convergence

this book "CCNP Routing and Switching ROUTE 300-101 Official Cert Guide" said:

<<<Feasible Distance (FD): Integer metric for the route, from the local router’s perspective, used

by the local router to choose the best route for that prefix.>>>>

But my teacher said the book definition is not correct for feasible distance

this definition is for computed distance

and he said that there is a difference between these two definitions

for example

there is 2 path for R1 to reach subnet 10.1.0.0./8

from R2 by computed distance 435200 and reported distance 409600

from R3 by computed distance 448512 and reported distance 422912

and feasible distance is 435200

and the second link is feasible successor because Reported Distance is less than Computed Distance of best route

then he changed the delay of the Successor interface from 1000 to 500

now computed distance and feasible distance for successor became 422400

and again he changed the delay of interface to 1000

but this time the computed distance became 435200 But the feasible distance remained the same as before "22400"

And he said the correct definition of Feasible Distance is:

The best or minimum Metric that can be , NOT the best or minimum metric that it is now

Is this definition is correct????????

Solved! Go to Solution.

Labels:

2 ACCEPTED SOLUTIONS

Accepted Solutions

Highlighted

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

07-29-2015
03:59 AM

07-29-2015
03:59 AM

Hello,

Your teacher is correct, and I appreciate him very much for being so precise! If the textbook you referenced claims that the Feasible Distance is the current best metric toward a destination, it is sadly not entirely precise.

Feasible Distance is the lowest distance to the destination experienced since the last time the route went from Active to Passive state. Put differently, the Feasible Distance is the historical record of how closest the router was to the destination since the last diffusing computation for the destination has finished. It is indeed not the current best distance - rather, it is a historical record of the smallest distance known since the last Active->Passive transition. Thus, the value of the Feasible Distance can either be the same as the current best distance, or it can be lower (naturally, it can never be higher).

Your teacher was very wise to show you that the Feasible Distance can truly remain at its current value even if the current best distance rises, as long as this distance increase does not cause the router to go Active. The precise rules for this are not relevant at this point but if you wish, I suggest you start another thread about the precise rules of when a EIGRP route becomes Active - that topic is somewhat more extensive to explain.

You should be aware that the myth of "Feasible Distance is the current best distance" is extremely widespread and appears in many official documents as well. For some reason, it has been the common - and wrong - explanation for more than a decade.

Please tell your teacher my compliments! And of course, feel welcome to ask further!

Best regards,

Peter

Highlighted

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

07-29-2015
07:55 AM

07-29-2015
07:55 AM

Hi,

You are welcome.

I think it will be better to first explain the whole issue from scratch, and then react to your comments.

First, a terminological correction so that we have the individual terms set straight: Terms **Successor** and **Feasible Successor** refer to a neighboring __router__, not to a route. It is incorrect to say "a route is a successor", or "a route is a feasible successor". Correctly, we should say: "this neighboring router is a successor", and "this neighboring router is a feasible successor". Sometimes, terms "successor route" and "feasible successor route" are used instead of more complicated "route through a successor", "route through a feasible successor" statements. However, the one thing holds: successor and feasible successor are neighboring routers, not routes.

Regarding distances in EIGRP, we distinguish between three types of distances EIGRP calculates and keeps track of. Whenever we talk about these distances, we have a particular destination in mind - for every particular destination known to an EIGRP router, an entirely independent calculation of the distances below is performed.

**Reported Distance**, or **RD**, is a distance to a particular destination __learned__ from a particular neighboring router. This distance expresses the current best known distance of that neighbor to the destination, or in other words, how far that neighbor is from the destination. An independent RD is kept for each destination and neighbor. If a router has, say, 3 neighbors then for each known destination learned via EIGRP, it will keep 3 independent RD values, one for each neighbor.

**Computed Distance**, or **CD**, is a distance to a particular destination __through__ a particular neighboring router. This distance expresses the total distance to the destination through a particular neighbor. Quite logically, CD through a particular neighbor is computed using that neighbor's RD, and the metric of the link between this router and that particular neighbor. If a router has 3 neighbors then for each known destination learned via EIGRP, it will keep 3 independent CD values, one for each neighbor.

**Feasible Distance**, or **FD**, as we have discussed already, is a record of the smallest CD for a particular destination ever encountered since the last time this destination went from Active to Passive state. As opposed to RD and CD that are kept for each neighbor to a destination, FD is kept only for the destination - so regardless how many neighbors you have, a router maintains only a single FD value for a particular destination.

To sum up what we have so far, there are three relevant distances in EIGRP to keep in mind:

- Reported Distance (RD), holding the currently known distance of a particular neighbor to a particular destination
- Computed Distance (CD), holding the distance to a particular destination through a particular neighbor, computed from that neighbor's RD and the metric of the link toward that neighbor
- Feasible Distance (FD), holding the lowest known value of the CD toward a particular destination since the last time the destination went from Active to Passive state

Some sources make a huge mistake in that they confuse the CD with the FD, and they assume that the total distance through a particular neighbor is the FD - but this is wrong. Note that this is the same mistake you have posted yourself:

from R2 with FD 14000 and RD 10000

from R3 with FD 16000 and RD 15000

from R4 with FD 17000 and RD 13000

This is not right. Correctly, the table should be labeled differently:

**FD = 14000** (lowest currently available and assuming no prior history)

from R2 with **CD** 14000 and **RD** 10000

from R3 with **CD** 16000 and **RD** 15000

from R4 with **CD** 17000 and **RD** 13000

So far so good?

Okay, now, the Feasibility Condition states this:

*At any time, any neighbor that, for a particular destination, meets the inequality RD < FD provides a loop-free path to the destination, and will be called the Feasible Successor*.

If we loosen up the vocabulary a little and take into account that the RD tells us how close the neighbor is to the destination, and FD tells us how close we have ever been to that destination (remember, it is a historical minimum), then the Feasibility Condition can be rewritten as follows:

*At any time, any neighbor that, for a particular destination, is closer to that destination than we have ever been since the last time the destination went from Active to Passive state provides a loop-free path to the destination, and will be called the Feasible Successor*.

So, we now know what the Feasibility Condition states - that it is a rule to select paths guaranteed to be loop-free - and we also know that any neighbor that provides such a loop-free path (because it meets the Feasibility Condition) will be called a Feasible Successor.

Now, if that is a Feasible Successor, what is a Successor?

It turns out that the Cisco terminology is a little vague on this point. A Successor is defined as a router that provides the least CD and at the same time meets the Feasibility Condition. Such router could also be called a Feasible Successor because every router meeting the Feasibility Condition is by definition a Feasible Successor, but here, we want to have a special name for a router that not only provides a loop-free path, but also a path that is the cheapest available. So, the name Successor is reserved for those routers that meet the Feasibility Condition and at the same time provide the least CD, while the name Feasible Successor is reserved for those router that meet the Feasibility Condition but whose CD is higher. Feasible Successors always provide a loop-free path, however, they do not provide the least cost path.

For each destination, there always is at least one Successor. There may or may not be any Feasible Successors.

Now, let me requote the example you have posted:

**FD = 14000** (lowest currently available and assuming no prior history)

from R2 with **CD** 14000 and **RD** 10000

from R3 with **CD** 16000 and **RD** 15000

from R4 with **CD** 17000 and **RD** 13000

Here, R2 provides the least CD and meets the Feasibility Condition (10000 < 14000), so it will become the Successor. R4 also meets the Feasibility Condition (13000 < 14000) but its CD isn't the lowest available, so R4 is a Feasible Successor.

R3 does not meet the Feasibility Condition and so is neither Successor nor Feasible Successor - it is just a neighbor, but in this particular example, it happens to be a rather special neighbor: If R2 fails, R3 will be providing the least CD but it still won't meet the Feasibility Condition. Notice the dilemma here: If R1 uses R4, it will be using a guaranteed loop-free path but possibly a one that is not the shortest available. On the other hand, R1 is not allowed to use R3 even though it appears to provide a shorter path than R4 if it does not meet the Feasibility Condition.

So what R1 will do now is truly to go Active and send out Queries to find out whether the path through R3 would be looped or loop-free.

Notice that this is again different from what many sources say: It is often said that if the current Successor fails, the router will try to look up Feasible Successor if it has any, and if so, promote it to the new Successor role. In reality, this is not what happens because it would potentially cause a router to remain stuck using a suboptimal path and be happy with it. The real sequence of steps in EIGRP is, in general, this:

- After learning about a topology change, update the RD and CD depending on what the topology change is. If a new RD over a neighbor is learned, both the RD and corresponding CD need to be recalculated. If the metric of a link to a neighbor changed, only the CD through that neighbor needs to be recalculated. Loss of a neighbor is represented by setting the RD and CD of all routes through that neighbor to infinity. Adding a neighbor is done by adding that neighbor's RD and resulting CD to each network it advertises.
- After processing the information from the topology change as described in the previous step, look up the neighbor providing the least CD.
- Using the neighbor identified from the previous step, verify whether it meets the Feasibility Condition.

If it does not meet the Feasibility Condition, move the network to the Active state and send Queries.

If it meets the Feasibility Condition, promote it to the new Successor, and if its CD is even lower than the current FD, set the FD to the CD over this new Successor (a new minimum has been found).

So, again, to sum it up, it's simple: Whatever happens in EIGRP, first update the distances and then check whether the neighbor providing the least CD also meets the Feasibility Condition. If it does - hooray! - you've got a Successor! If it does not - oops! - you need to go Active as you cannot be sure whether you can use it but still you absolutely do not want to leave any stone unturned in the search for the least cost path.

This, in general, confirms your teacher's comments. However, definitions are a very sensitive issue as every misquoted word can give the definition a radically different meaning. The definitions you have quoted are not correct, neither one - neither the one from the book, nor the one from your teacher - but I am attributing this to the imprecision in reposting and translating so I am not going to judge based on this one.

You may be also interested in reading the following thread where a similar topic was discussed:

https://supportforums.cisco.com/discussion/11877371/eigrp-successor-and-feasible-successor

Feel welcome to ask further!

Best regards,

Peter

10 REPLIES 10

Highlighted

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

07-29-2015
03:59 AM

07-29-2015
03:59 AM

Hello,

Your teacher is correct, and I appreciate him very much for being so precise! If the textbook you referenced claims that the Feasible Distance is the current best metric toward a destination, it is sadly not entirely precise.

Feasible Distance is the lowest distance to the destination experienced since the last time the route went from Active to Passive state. Put differently, the Feasible Distance is the historical record of how closest the router was to the destination since the last diffusing computation for the destination has finished. It is indeed not the current best distance - rather, it is a historical record of the smallest distance known since the last Active->Passive transition. Thus, the value of the Feasible Distance can either be the same as the current best distance, or it can be lower (naturally, it can never be higher).

Your teacher was very wise to show you that the Feasible Distance can truly remain at its current value even if the current best distance rises, as long as this distance increase does not cause the router to go Active. The precise rules for this are not relevant at this point but if you wish, I suggest you start another thread about the precise rules of when a EIGRP route becomes Active - that topic is somewhat more extensive to explain.

You should be aware that the myth of "Feasible Distance is the current best distance" is extremely widespread and appears in many official documents as well. For some reason, it has been the common - and wrong - explanation for more than a decade.

Please tell your teacher my compliments! And of course, feel welcome to ask further!

Best regards,

Peter

Highlighted
##

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

07-29-2015
05:14 AM

07-29-2015
05:14 AM

thank you so much Mr @Peter

thank you so much Mr @Peter Paluch for your great tips

But one more thing

on this book again : CCNP Routing and Switching ROUTE 300-101 Official Cert Guide By KEVIN WALLACE

About the Feasible Successor ,The book says on page 184:

<<<<<<<<<<<

A router determines whether a route is a feasible successor based on the feasibility condition, defined

as follows:

If a nonsuccessor route’s RD is less than the FD, the route is a feasible successor route.

>>>>>>>>

But My theacher Says:

This definition is wrong.

The correct definition is :

The best route after current successor become Feasible Successor when the reported distance is less than current best successor feasible distance

its mean:

there is 3 path From R1 To network 10.1.0.0/8

from R2 with FD 14000 and RD 10000

from R3 with FD 16000 and RD 15000

from R4 with FD 17000 and RD 13000

the book specifically says:

route Frome R2 become Successor because it has lowest FD that is 14000

and route from R4 become Feasible Successor because it's RD that is 13000 is less than best route's FD that is 14000

My Teacher says

this definition is completely wrong

becuase as in the previous example

route from R4 never become Feasible Distance

becuse its not the best route after current Successor

in the previous example , if the current successor route has faild , the router certainly sends the Query and waiting for reply to ensure that the

other route is loop-free routes

Highlighted

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

07-29-2015
07:55 AM

07-29-2015
07:55 AM

Hi,

You are welcome.

I think it will be better to first explain the whole issue from scratch, and then react to your comments.

First, a terminological correction so that we have the individual terms set straight: Terms **Successor** and **Feasible Successor** refer to a neighboring __router__, not to a route. It is incorrect to say "a route is a successor", or "a route is a feasible successor". Correctly, we should say: "this neighboring router is a successor", and "this neighboring router is a feasible successor". Sometimes, terms "successor route" and "feasible successor route" are used instead of more complicated "route through a successor", "route through a feasible successor" statements. However, the one thing holds: successor and feasible successor are neighboring routers, not routes.

Regarding distances in EIGRP, we distinguish between three types of distances EIGRP calculates and keeps track of. Whenever we talk about these distances, we have a particular destination in mind - for every particular destination known to an EIGRP router, an entirely independent calculation of the distances below is performed.

**Reported Distance**, or **RD**, is a distance to a particular destination __learned__ from a particular neighboring router. This distance expresses the current best known distance of that neighbor to the destination, or in other words, how far that neighbor is from the destination. An independent RD is kept for each destination and neighbor. If a router has, say, 3 neighbors then for each known destination learned via EIGRP, it will keep 3 independent RD values, one for each neighbor.

**Computed Distance**, or **CD**, is a distance to a particular destination __through__ a particular neighboring router. This distance expresses the total distance to the destination through a particular neighbor. Quite logically, CD through a particular neighbor is computed using that neighbor's RD, and the metric of the link between this router and that particular neighbor. If a router has 3 neighbors then for each known destination learned via EIGRP, it will keep 3 independent CD values, one for each neighbor.

**Feasible Distance**, or **FD**, as we have discussed already, is a record of the smallest CD for a particular destination ever encountered since the last time this destination went from Active to Passive state. As opposed to RD and CD that are kept for each neighbor to a destination, FD is kept only for the destination - so regardless how many neighbors you have, a router maintains only a single FD value for a particular destination.

To sum up what we have so far, there are three relevant distances in EIGRP to keep in mind:

- Reported Distance (RD), holding the currently known distance of a particular neighbor to a particular destination
- Computed Distance (CD), holding the distance to a particular destination through a particular neighbor, computed from that neighbor's RD and the metric of the link toward that neighbor
- Feasible Distance (FD), holding the lowest known value of the CD toward a particular destination since the last time the destination went from Active to Passive state

Some sources make a huge mistake in that they confuse the CD with the FD, and they assume that the total distance through a particular neighbor is the FD - but this is wrong. Note that this is the same mistake you have posted yourself:

from R2 with FD 14000 and RD 10000

from R3 with FD 16000 and RD 15000

from R4 with FD 17000 and RD 13000

This is not right. Correctly, the table should be labeled differently:

**FD = 14000** (lowest currently available and assuming no prior history)

from R2 with **CD** 14000 and **RD** 10000

from R3 with **CD** 16000 and **RD** 15000

from R4 with **CD** 17000 and **RD** 13000

So far so good?

Okay, now, the Feasibility Condition states this:

*At any time, any neighbor that, for a particular destination, meets the inequality RD < FD provides a loop-free path to the destination, and will be called the Feasible Successor*.

If we loosen up the vocabulary a little and take into account that the RD tells us how close the neighbor is to the destination, and FD tells us how close we have ever been to that destination (remember, it is a historical minimum), then the Feasibility Condition can be rewritten as follows:

*At any time, any neighbor that, for a particular destination, is closer to that destination than we have ever been since the last time the destination went from Active to Passive state provides a loop-free path to the destination, and will be called the Feasible Successor*.

So, we now know what the Feasibility Condition states - that it is a rule to select paths guaranteed to be loop-free - and we also know that any neighbor that provides such a loop-free path (because it meets the Feasibility Condition) will be called a Feasible Successor.

Now, if that is a Feasible Successor, what is a Successor?

It turns out that the Cisco terminology is a little vague on this point. A Successor is defined as a router that provides the least CD and at the same time meets the Feasibility Condition. Such router could also be called a Feasible Successor because every router meeting the Feasibility Condition is by definition a Feasible Successor, but here, we want to have a special name for a router that not only provides a loop-free path, but also a path that is the cheapest available. So, the name Successor is reserved for those routers that meet the Feasibility Condition and at the same time provide the least CD, while the name Feasible Successor is reserved for those router that meet the Feasibility Condition but whose CD is higher. Feasible Successors always provide a loop-free path, however, they do not provide the least cost path.

For each destination, there always is at least one Successor. There may or may not be any Feasible Successors.

Now, let me requote the example you have posted:

**FD = 14000** (lowest currently available and assuming no prior history)

from R2 with **CD** 14000 and **RD** 10000

from R3 with **CD** 16000 and **RD** 15000

from R4 with **CD** 17000 and **RD** 13000

Here, R2 provides the least CD and meets the Feasibility Condition (10000 < 14000), so it will become the Successor. R4 also meets the Feasibility Condition (13000 < 14000) but its CD isn't the lowest available, so R4 is a Feasible Successor.

R3 does not meet the Feasibility Condition and so is neither Successor nor Feasible Successor - it is just a neighbor, but in this particular example, it happens to be a rather special neighbor: If R2 fails, R3 will be providing the least CD but it still won't meet the Feasibility Condition. Notice the dilemma here: If R1 uses R4, it will be using a guaranteed loop-free path but possibly a one that is not the shortest available. On the other hand, R1 is not allowed to use R3 even though it appears to provide a shorter path than R4 if it does not meet the Feasibility Condition.

So what R1 will do now is truly to go Active and send out Queries to find out whether the path through R3 would be looped or loop-free.

Notice that this is again different from what many sources say: It is often said that if the current Successor fails, the router will try to look up Feasible Successor if it has any, and if so, promote it to the new Successor role. In reality, this is not what happens because it would potentially cause a router to remain stuck using a suboptimal path and be happy with it. The real sequence of steps in EIGRP is, in general, this:

- After learning about a topology change, update the RD and CD depending on what the topology change is. If a new RD over a neighbor is learned, both the RD and corresponding CD need to be recalculated. If the metric of a link to a neighbor changed, only the CD through that neighbor needs to be recalculated. Loss of a neighbor is represented by setting the RD and CD of all routes through that neighbor to infinity. Adding a neighbor is done by adding that neighbor's RD and resulting CD to each network it advertises.
- After processing the information from the topology change as described in the previous step, look up the neighbor providing the least CD.
- Using the neighbor identified from the previous step, verify whether it meets the Feasibility Condition.

If it does not meet the Feasibility Condition, move the network to the Active state and send Queries.

If it meets the Feasibility Condition, promote it to the new Successor, and if its CD is even lower than the current FD, set the FD to the CD over this new Successor (a new minimum has been found).

So, again, to sum it up, it's simple: Whatever happens in EIGRP, first update the distances and then check whether the neighbor providing the least CD also meets the Feasibility Condition. If it does - hooray! - you've got a Successor! If it does not - oops! - you need to go Active as you cannot be sure whether you can use it but still you absolutely do not want to leave any stone unturned in the search for the least cost path.

This, in general, confirms your teacher's comments. However, definitions are a very sensitive issue as every misquoted word can give the definition a radically different meaning. The definitions you have quoted are not correct, neither one - neither the one from the book, nor the one from your teacher - but I am attributing this to the imprecision in reposting and translating so I am not going to judge based on this one.

You may be also interested in reading the following thread where a similar topic was discussed:

https://supportforums.cisco.com/discussion/11877371/eigrp-successor-and-feasible-successor

Feel welcome to ask further!

Best regards,

Peter

Highlighted
##

kind regards

Paul

Please rate and mark posts accordingly if you have found any of the information provided useful.

It will hopefully assist others with similar issues in the future

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

07-29-2015
09:40 AM

07-29-2015
09:40 AM

Excellent peter!

Excellent peter!

kind regards

Paul

Please rate and mark posts accordingly if you have found any of the information provided useful.

It will hopefully assist others with similar issues in the future

Highlighted
##

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

07-29-2015
11:17 PM

07-29-2015
11:17 PM

thank you thank you Peterthat

thank you

thank you Peter

that was perfect Mr @Peter Paluch

Indeed this requires further study

However About quote me

from R3 with FD 16000 and RD 15000

from R4 with FD 17000 and RD 13000

I mean CD

It was just a mistake

but I Read more

thank you so much

Highlighted
##

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

11-27-2017
10:16 PM

11-27-2017
10:16 PM

Re: Hi,You are welcome.I think it

Flawless and Invaluable Explanation :)

Highlighted
##

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

05-16-2020
10:18 PM

05-16-2020
10:18 PM

Re: Hi,You are welcome.I think it

Highlighted
##

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

11-27-2017
09:41 PM

11-27-2017
09:41 PM

Re: Hello,Your teacher is correct

I am little confused.

My understanding:

1. Feasible Distance only changes when EIGRP goes to Active to Passive.

2. Feasible Distance cannot increase. It can only stay or decrease.

3. It is just a historical record how closest the router was to the destination.

Am I right?

My understanding:

1. Feasible Distance only changes when EIGRP goes to Active to Passive.

2. Feasible Distance cannot increase. It can only stay or decrease.

3. It is just a historical record how closest the router was to the destination.

Am I right?

Highlighted
##

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-16-2019
10:50 PM

12-16-2019
10:50 PM

Re: Hello,Your teacher is correct

Since the FD won't increase until the state toggles to active and back; is that why Cisco does not recommend using the K values for (2) Load and (4) Reliability in the metric calculation?

Highlighted
##

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-17-2019
07:14 AM

12-17-2019
07:14 AM

Re: Hello,Your teacher is correct

Hello @btk_1,

Cisco's recommendation not to use load and reliability related K-values in EIGRP boils down to the fact that when they change on an interface, they do not generate an event to EIGRP, and so they do not immediately impact the best path selection. If they did, EIGRP might get unstable - a traffic could be moved to a formerly underutilized link, causing its load (and consequently the metric) to rise and eventually fall back to the original link, starting the whole cycle again.

So even if you enable the K2, K4 and K5, EIGRP will not trigger an update *just because* the load and/or reliability change. EIGRP only takes a "snapshot" of the momentary reliability and load values when it sends an update (or a query, or a reply) triggered by other events. Hence, the load and reliability metric components are, in practical terms, useless as far as EIGRP is concerned.

Please feel welcome to ask further!

Best regards,

Peter

Latest Contents

Created by EasonY
on 08-13-2020
08:06 PM

0

0

0

0

Hi,I've had below topology: So from RT1's perspective, if link RT1 - RT5 is the link to be protected, the P-space (RT1, Redlink) will be RT2? I can see the definition of P space of RT1 is the set of nodes that RT1 can reach as per pre-convergenc...
view more

Created by ChhunCam
on 08-13-2020
03:46 AM

9

0

9

0

Dear all, please kindly advise how to can configure on Rommon on switch 3650please kindly see in the attach file. Best regards,

Created by Zurattos
on 08-11-2020
02:44 PM

0

0

0

0

Hello , I really need your help , how can I configure a management vlan for the switch while using GRE tunnel between two routers ? Best Regards

Created by aalesna
on 08-11-2020
10:22 AM

0

0

0

0

Cisco Champion Radio · S7|E30 Taming Your AI/ ML Workloads with Kubeflow
As organizations increasingly introduce machine learning (ML) capabilities to their existing products, their artificial intelligence (AI) projects and operations complexity g...
view more

Created by dhristov
on 08-10-2020
11:56 AM

0

5

0

5

Cisco IOS-XE 17.3.1 – Catalyst Switching Updates
Table of Contents
IOS-XE 17.3.1
Hardware Additions since IOS-XE 17.2.1
Key Summary Features
Platform and Infra Features
High Availability Features
Routing / MPLS / VPN Features
Security Features
&nbs...
view more

Related Content