cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
1831
Views
20
Helpful
10
Replies

EIGRP Feasible Distance

After reading ccie v5 official certification guide i realized that the Feasible distance is an historical value and not a "current" value. But i am trying to understand what is the benefit of keeping this historical value and not update this value with the current "computed distance" value, is there any benefit ?

1 ACCEPTED SOLUTION

Accepted Solutions
Peter Paluch
Hall of Fame Cisco Employee

Hi Ricardo,

Nice to meet you :) I wrote the chapter on EIGRP in that book.

Pages 389 and 390 try to provide the explanation why the Feasible Distance truly is the historical value of the minimum distance to a destination since the last Active->Passive transition. In essence, in EIGRP, each router needs a selection rule that allows it to safely and simply select a next hop that will guaranteedly provide a loop-free path to a destination, without really knowing the topology of the network, just by looking at the data already available. The risk of creating routing loops when a topology changes is based on outdated information about the network. Consider a very simple topology with routers A, B, and a destination network X somewhere far:

A ---> B ---> ... ---> LAN X

Forget about all split horizon rules etc. and assume that each router tells about all known networks to all its neighbors. Assuming that the metric of each link is 10, and B's current distance to LAN X is 100, the distances of the routers to these networks are: B=100, A=110. Furthermore, B knows that A's distance is 110.

Assume now that B's interface toward LAN X suddenly fails. This is represented as having B's distance grow to infinity. Without any selection rule, B would simply look at its stored information and learn that A claims a distance of 110. As 110 is less that infinity, B would be happy to have found a seemingly replacement route and would start pointing toward A - and at this point, a routing loop would be formed, as A still points back to B.

Activating split horizon could remedy this situation but it can not help in more complex topologies where a routing loop can be formed over a longer chain of routers ultimately coming back. Remember, split horizon is just a heuristic - it eliminates some of the ill effects, but it is unable to eliminate all possibilities. EIGRP needs a rule that never makes false positives - if the rule says that a next hop provides a loop-free path then this assesment must be 100% true in all possible network topologies. It must never declare a looped next hop to be okay and usable.

It turns out that keeping the record of the smallest encountered distance to the destination is what this rule can be based on. In a stable network, if a neighbor is closer to the destination than the current router then the neighbor is certainly not forwarding the packets back. Think of the simple topology above again. B's distance is 100, A's distance is 110. Why would B send packets over A with a total distance of 120 (A's 110 plus the cost 10 of link between B and A) when it has a better path with a distance of 100 to the destination network? And now assume that B is keeping a separate historical record of its best distance to the destination - the Feasible Distance - and it's currently set to, say, 90 (just an arbitrary value chosen for this example). Any neighbor whose own distance is less than 90 would not be using B if B's current distance was 90 or arbitrary more, and it does not matter how much more. And exactly this is the trick - at the moment of a topology change when B knows that its distance has risen but its neighbors are not yet guaranteed to know it, B must take care to consider only those neighbors who would not be using it even before the topology change when B's distance was still smaller. This is why you need the Feasible Distance to be a historical record of the minimum distance - to poinpoint those routers that would not be using you even if nothing happened, and even less if they knew that your distance has increased.

Feel welcome to ask further!

Best regards,
Peter

View solution in original post

10 REPLIES 10
Peter Paluch
Hall of Fame Cisco Employee

Hi Ricardo,

Nice to meet you :) I wrote the chapter on EIGRP in that book.

Pages 389 and 390 try to provide the explanation why the Feasible Distance truly is the historical value of the minimum distance to a destination since the last Active->Passive transition. In essence, in EIGRP, each router needs a selection rule that allows it to safely and simply select a next hop that will guaranteedly provide a loop-free path to a destination, without really knowing the topology of the network, just by looking at the data already available. The risk of creating routing loops when a topology changes is based on outdated information about the network. Consider a very simple topology with routers A, B, and a destination network X somewhere far:

A ---> B ---> ... ---> LAN X

Forget about all split horizon rules etc. and assume that each router tells about all known networks to all its neighbors. Assuming that the metric of each link is 10, and B's current distance to LAN X is 100, the distances of the routers to these networks are: B=100, A=110. Furthermore, B knows that A's distance is 110.

Assume now that B's interface toward LAN X suddenly fails. This is represented as having B's distance grow to infinity. Without any selection rule, B would simply look at its stored information and learn that A claims a distance of 110. As 110 is less that infinity, B would be happy to have found a seemingly replacement route and would start pointing toward A - and at this point, a routing loop would be formed, as A still points back to B.

Activating split horizon could remedy this situation but it can not help in more complex topologies where a routing loop can be formed over a longer chain of routers ultimately coming back. Remember, split horizon is just a heuristic - it eliminates some of the ill effects, but it is unable to eliminate all possibilities. EIGRP needs a rule that never makes false positives - if the rule says that a next hop provides a loop-free path then this assesment must be 100% true in all possible network topologies. It must never declare a looped next hop to be okay and usable.

It turns out that keeping the record of the smallest encountered distance to the destination is what this rule can be based on. In a stable network, if a neighbor is closer to the destination than the current router then the neighbor is certainly not forwarding the packets back. Think of the simple topology above again. B's distance is 100, A's distance is 110. Why would B send packets over A with a total distance of 120 (A's 110 plus the cost 10 of link between B and A) when it has a better path with a distance of 100 to the destination network? And now assume that B is keeping a separate historical record of its best distance to the destination - the Feasible Distance - and it's currently set to, say, 90 (just an arbitrary value chosen for this example). Any neighbor whose own distance is less than 90 would not be using B if B's current distance was 90 or arbitrary more, and it does not matter how much more. And exactly this is the trick - at the moment of a topology change when B knows that its distance has risen but its neighbors are not yet guaranteed to know it, B must take care to consider only those neighbors who would not be using it even before the topology change when B's distance was still smaller. This is why you need the Feasible Distance to be a historical record of the minimum distance - to poinpoint those routers that would not be using you even if nothing happened, and even less if they knew that your distance has increased.

Feel welcome to ask further!

Best regards,
Peter

View solution in original post

Thanks for your prompt answer. So, i am using a really similar example to the one on the book on my LAB, i also turned off split horizon on R4 interface (ethernet0/0.14)

 

So here is R1 topology table

 

P 11.234.0.0/24, 1 successors, FD is 2560, serno 9
        via 10.12.1.2 (2560/256), Ethernet0/0.12
        via 10.14.1.4 (3584/3072), Ethernet0/0.14
        via 10.13.1.3 (5120/1280), Ethernet0/0.13

If link between R1-R2 fails as you explained on your book and R1 would try to choose a new next hop toward 11.234.0.0/24. It will first try to choose the path with the best metric, which is via R4 (3584) but since R4 Reported distance is not less than the FD for 11.234.0.0/24 (R1 perspective) it will not suffice the feasibility condition and it won't use it right? Now, if FD was not an historical value it will cause a routing loop because the RD from R4 (3072) will be less than the CD via R3 (5120)  and now the FD (supposing that the FD was not an historical value). Is that right?

So, the purpose of keeping the FD as an historical value is to make sure that if we lose our best metric next-hop router to a destination the only way to know if there is no routing loop is to compare the RD from the neighbors against the FD (which is/was the lowest metric to a network at some stable point in time). 

 

 

Peter Paluch
Hall of Fame Cisco Employee

Hi Ricardo,

If link between R1-R2 fails as you explained on your book and R1 would try to choose a new next hop toward 11.234.0.0/24. It will first try to choose the path with the best metric, which is via R4 (3584) but since R4 Reported distance is not less than the FD for 11.234.0.0/24 (R1 perspective) it will not suffice the feasibility condition and it won't use it right?

Exactly right. What would happen is this: Because this path appears to be the best available after the R1-R2 link goes down, but R4 does not meet the Feasibility Condition using R1's current FD, R1 will go Active and send out Queries. It will not start using R3 right away.

The Query sent by R1 will contain the R1's distance through its old successor, R2, after the topology change took place - but because the link has failed, this distance is in fact infinity. The Query will be received by R3 and R4. R3 will not be affected by this Query - it does not use R1 to reach the destination - so it will respond right away with its existing distance of 1280. R4 is, however, affected by this Query. The distance in this Query causes R4 to lose its current successor (from R4's viewpoint, R1 does not meet the Feasibility Condition anymore), and because it has no other feasible successors to promote to a successor role, it will formally go Active - but because it has no other neighbors at all, it will return to Passive immediately, knowing that the path has effectively been lost. R4 will therefore respond with infinity, and remove the network from its routing and topology table.

R1 will collect all Replies, reset its Feasible Distance to infinity, and because the resulting shortest path is now available through R3, R1 will start using R3 as the next hop to the network while also setting FD to R1's new true distance of 5120. Because R1's true distance has changed from the infinity to 5120, R1 will send an Update, at which point R4 will learn about this network again from R1.

Now, if FD was not an historical value it will cause a routing loop because the RD from R4 (3072) will be less than the CD via R3 (5120)  and now the FD (supposing that the FD was not an historical value). Is that right?

Yes - if FD was not a historical but rather a current distance then with regard to loop prevention, it would become entirely lost. EIGRP would effectively degrade to RIP. If the R1-R2 link was lost which would cause the distance to go to infinity then just about any neighboring router would be fit to be chosen. R1 could in that case indeed choose R4 as the next hop, because at the very moment R1-R2 link failed and no one except R1 knows about this, R4 still has no clue, and its distance information at that point in time is outdated. This is exactly what naive routing protocols like RIP do: "Does the neighbor appear to provide a shorter path? If yes, let's use it! And - oh... does that distance information from the neighbor already take the changed topology into account? There's no way to know, so don't bother." - and you end up having transient routing loops.

So, the purpose of keeping the FD as an historical value is to make sure that if we lose our best metric next-hop router to a destination the only way to know if there is no routing loop is to compare the RD from the neighbors against the FD (which is/was the lowest metric to a network at some stable point in time).

Exactly.

Let me try to use a different example. Imagine that you are a reseller of precious goods - paintings, sculptures, art in general. You have your network of peer resellers from which you can purchase these goods, and to which you can resell them afterwards. Each of them offers a particular piece for a different starting price (Reported Distance), and depending on the level of your business relations with that partner, there is a price increase for purchasing that particular piece from this partner (link cost - please note that for the purpose of this example, the profit margins are additive constant costs, not percentages). The starting prices and profit margins may change over time.

What you absolutely want to avoid is purchasing an item you have already purchased and resold at some point in the past, and resell it in such a way it gets back to you again. If you just purchase it and won't be able to resell it again, you will generate a loss, not even a balanced revenue, because now you're buying the same piece possibly for more money than for which you have sold it the last time. And if the commodity goes in circles round and round, its price grows continuously, so that it may happen that it becomes so expensive you cannot afford to buy it at all.

As an example, consider this output: A, B, C, D are four resellers, both have 1000 bucks as their starting capital, and each one of them uses a profit margin of 50 bucks. Reseller A has a commodity that costs 200 bucks in the beginning, and it sells it to B for 250 bucks. B resells it to C for 300 bucks, C resells it to D for 350 bucks, D resells it to A for 400 bucks, and so one. Notice how each of the resellers is continuously poorer than before when the commodity gets back to him after the full round before the reseller can sell it again, and around line 22, some of the resellers go broke as their balance becomes negative:

Price = 200, A:B:C:D = 1000:1000:1000:1000

1: A sells to B for 250, end state: A:B:C:D = 1250:750:1000:1000
2: B sells to C for 300, end state: A:B:C:D = 1250:1050:700:1000
3: C sells to D for 350, end state: A:B:C:D = 1250:1050:1050:650
4: D sells to A for 400, end state: A:B:C:D = 850:1050:1050:1050
5: A sells to B for 450, end state: A:B:C:D = 1300:600:1050:1050
6: B sells to C for 500, end state: A:B:C:D = 1300:1100:550:1050
7: C sells to D for 550, end state: A:B:C:D = 1300:1100:1100:500
8: D sells to A for 600, end state: A:B:C:D = 700:1100:1100:1100
9: A sells to B for 650, end state: A:B:C:D = 1350:450:1100:1100
10: B sells to C for 700, end state: A:B:C:D = 1350:1150:400:1100
11: C sells to D for 750, end state: A:B:C:D = 1350:1150:1150:350
12: D sells to A for 800, end state: A:B:C:D = 550:1150:1150:1150
13: A sells to B for 850, end state: A:B:C:D = 1400:300:1150:1150
14: B sells to C for 900, end state: A:B:C:D = 1400:1200:250:1150
15: C sells to D for 950, end state: A:B:C:D = 1400:1200:1200:200
16: D sells to A for 1000, end state: A:B:C:D = 400:1200:1200:1200
17: A sells to B for 1050, end state: A:B:C:D = 1450:150:1200:1200
18: B sells to C for 1100, end state: A:B:C:D = 1450:1250:100:1200
19: C sells to D for 1150, end state: A:B:C:D = 1450:1250:1250:50
20: D sells to A for 1200, end state: A:B:C:D = 250:1250:1250:1250
21: A sells to B for 1250, end state: A:B:C:D = 1500:0:1250:1250
22: B sells to C for 1300, end state: A:B:C:D = 1500:1300:-50:1250
23: C sells to D for 1350, end state: A:B:C:D = 1500:1300:1300:-100

So how can you make sure this does not happen? Imagine that the least historical starting selling cost for which you have been able to sell a particular piece by Picasso was 10K bucks (the Feasible Distance). The claimed prices can change, of course, and at the present time, your two neighbor resellers X and Y state that a similar Picasso can be purchased from them for a starting price of, say, 8K bucks and 12K bucks, respectively, while the profit margin is 10K for X and 1K for Y, so the total prices would be 18K for X and 13K for Y. These total prices would become the starting selling costs for you should you decide to purchase that piece from any of those neighbors.

The reseller Y with the total price of 13K seems to be perfectly nice, but its own price of 12K seems suspicious. There's a real possibility - though not a guarantee! - that at some point in the past, it may have bought the piece from you when you offered it for 10K starting cost (you never offered it for less) and with a profit margin of 2K, then he waited speculatively, and now he's making a seemingly perfect offer to you. Are going to you like this? I don't think so.

The reseller X, on the other hand, could never have purchased the piece from you, as its current cost is 8K and you have never, ever, offered it for less than 10K. Wherever he got that piece, one thing is for certain - it's not from you.

And that's how the Feasible Distance works ;)

As always, feel welcome to ask further!

Best regards,
Peter

Thank you so much for taking time to answer my question I really appreciate that, by the way your example was awesome and it definitely helped me to better understand the point of keeping an historical value on the topology table.

Hello Peter,

Long time ago I have analyzed the EIGRP behavior related to FD and I found something which at the first glance I cannot explain. Please see bellow my test with a very simple topology.

On R1 we have the following output:

R1#sh ip ei top

P 11.234.0.0/24, 1 successors, FD is 307200
        via 10.0.0.2 (307200/281600), FastEthernet0/0
        via 10.0.0.6 (5401600/281600), FastEthernet0/1


This command is showing only the feasible paths to 11.234.0.0 (successor and feasible successor).

R1#sh ip ei top all

P 11.234.0.0/24, 1 successors, FD is 307200, serno 19
        via 10.0.0.2 (307200/281600), FastEthernet0/0
        via 10.0.0.10 (2681856/768000), Serial0/0
        via 10.0.0.6 (5401600/281600), FastEthernet0/1


Now we have also R4 in the output but because it has not satisfied the FC (Feasabilty Condition) it is not shown in the command without the "all" keyword.

Now I'm starting a debug on R1 (debug eigrp fsm) and put in shutdown the interface connecting R1-R2:

After this I'm expecting to see R3 to be the next-hop for prefix 11.234.0.0/24.

R1#debug eigrp fsm
EIGRP FSM Events/Actions debugging is on
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int fa0/0
R1(config-if)#shut
R1(config-if)#
*Mar  1 01:49:02.915: DUAL: rcvupdate: 10.0.0.0/30 via Connected metric 4294967295/4294967295
*Mar  1 01:49:02.919: DUAL: Find FS for dest 10.0.0.0/30. FD is 281600, RD is 281600
*Mar  1 01:49:02.919: DUAL:     0.0.0.0 metric 4294967295/4294967295 not found Dmin is 4294967295
*Mar  1 01:49:02.919: DUAL: Peer total 3 stub 0 template 3
*Mar  1 01:49:02.919: DUAL: Dest 10.0.0.0/30 entering active state.
*Mar  1 01:49:02.919: DUAL: Set reply-status table. Count is 3.
*Mar  1 01:49:02.919: DUAL: Not doing split horizon
*Mar  1 01:49:02.919: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.0.2 (FastEthernet0/0) is down: interface                                                down
*Mar  1 01:49:02.919: DUAL: linkdown: start - 10.0.0.2 via FastEthernet0/0
*Mar  1 01:49:02.919: DUAL: Destination 10.0.0.8/30
*Mar  1 01:49:02.919: DUAL: Destination 10.0.0.0/30
*Mar  1 01:49:02.919: DUAL: Clearing handle 1, count now 2
*Mar  1 01:49:02.919: DUAL: Destination 10.0.0.4/30
*Mar  1 01:49:02.919: DUAL: Destination 11.234.0.0/24
*Mar  1 01:49:02.919: DUAL: Find FS for dest 11.234.0.0/24. FD is 307200, RD is 307200
*Mar  1 01:49:02.919: DUAL:     10.0.0.2 metric 4294967295/4294967295
*Mar  1 01:49:02.919: DUAL:     10.0.0.10 metric 2681856/768000
*Mar  1 01:49:02.919: DUAL:     10.0.0.6 metric 5401600/281600 not found Dmin is 2681856
*Mar  1 01:49:02.919: DUAL: Peer total 2 stub 0 template 2
*Mar  1 01:49:02.919: DUAL: Dest 11.234.0.0/24 entering active state.
*Mar  1 01:49:02.919: DUAL: Set reply-status table. Count is 2.
*Mar  1 01:49:02.919: DUAL: Not doing split horizon
*Mar  1 01:49:02.919: DUAL: linkdown: finish
*Mar  1 01:49:02.987: DUAL: dest(10.0.0.0/30) active
*Mar  1 01:49:02.987: DUAL: rcvreply: 10.0.0.0/30 via 10.0.0.6 metric 4294967295/4294967295
*Mar  1 01:49:02.991: DUAL: reply count is 2
*Mar  1 01:49:02.991: DUAL: Clearing handle 2, count now 1
*Mar  1 01:49:02.991: DUAL: Removing dest 10.0.0.0/30, nexthop 10.0.0.6, infosource 10.0.0.6
*Mar  1 01:49:02.991: DUAL: rcvreply: 11.234.0.0/24 via 10.0.0.6 metric 5401600/281600
*Mar  1 01:49:02.991: DUAL: reply count is 2
*Mar  1 01:49:02.991: DUAL: Clearing handle 2, count now 1
*Mar  1 01:49:02.991: DUAL: dest(10.0.0.0/30) active
*Mar  1 01:49:02.991: DUAL: rcvreply: 10.0.0.0/30 via 10.0.0.10 metric 4294967295/4294967295
*Mar  1 01:49:02.991: DUAL: reply count is 1
*Mar  1 01:49:02.991: DUAL: Clearing handle 0, count now 0
*Mar  1 01:49:02.991: DUAL: Freeing reply status table
*Mar  1 01:49:02.991: DUAL: Find FS for dest 10.0.0.0/30. FD is 4294967295, RD is 4294967295 found
*Mar  1 01:49:02.991: DUAL: Removing dest 10.0.0.0/30, nexthop 0.0.0.0, infosource 0.0.0.0
*Mar  1 01:49:02.991: DUAL: Removing dest 10.0.0.0/30, nexthop 10.0.0.10, infosource 10.0.0.10
*Mar  1 01:49:02.991: DUAL: No routes.  Flushing dest 10.0.0.0/30
*Mar  1 01:49:02.991: DUAL: rcvreply: 11.234.0.0/24 via 10.0.0.10 metric 2681856/768000
*Mar  1 01:49:02.991: DUAL: reply count is 1
*Mar  1 01:49:02.991: DUAL: Clearing handle 0, count now 0
*Mar  1 01:49:02.991: DUAL: Freeing reply status table
*Mar  1 01:49:02.991: DUAL: Find FS for dest 11.234.0.0/24. FD is 4294967295, RD is 4294967295 found
*Mar  1 01:49:02.991: DUAL: Removing dest 11.234.0.0/24, nexthop 10.0.0.2, infosource 10.0.0.2
*Mar  1 01:49:02.991: DUAL: RT installed 11.234.0.0/24 via 10.0.0.10
*Mar  1 01:49:02.991: DUAL: Send update about 11.234.0.0/24.  Reason: metric chg
*Mar  1 01:49:02.991: DUAL: Send update about 11.234.0.0/24.  Reason: new if
*Mar  1 01:49:04.835: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar  1 01:49:05.835: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down

And the result is:

R1(config-if)#do sh ip route ei
     11.0.0.0/24 is subnetted, 1 subnets
D       11.234.0.0 [90/2681856] via 10.0.0.10, 00:03:05, Serial0/0

It prefers R4 as next hop even if it was not satisfied the FC.

This line "*Mar  1 01:49:02.919: DUAL:     10.0.0.6 metric 5401600/281600 not found Dmin is 2681856" with "not found" means that no FS has been found for destination 11.234.0.0/24 and shortly it will enter in Active confirmed by this line "*Mar  1 01:49:02.919: DUAL: Dest 11.234.0.0/24 entering active state." The router is receiving the Reply from R3 and R4 but even if R4 (768000) has not satisfied the FC using the historical FD (307200) it is now the next-hop.

I want to ask you if in this particular scenario is a correct behavior? I think not but maybe is related to a software version or something.

 

Thank you very much for your time!

 

 

Peter Paluch
Hall of Fame Cisco Employee

Hi Bogdan,

I want to ask you if in this particular scenario is a correct behavior?

It is perfectly correct and valid.

Let's start with the debug output. The relevant output are somewhat poorly formatted by IOS but this is what they say:

*Mar  1 01:49:02.919: DUAL: Find FS for dest 11.234.0.0/24. FD is 307200, RD is 307200
*Mar  1 01:49:02.919: DUAL:     10.0.0.2 metric 4294967295/4294967295
*Mar  1 01:49:02.919: DUAL:     10.0.0.10 metric 2681856/768000
*Mar  1 01:49:02.919: DUAL:     10.0.0.6 metric 5401600/281600 
                            not found
                            Dmin is 2681856
*Mar  1 01:49:02.919: DUAL: Peer total 2 stub 0 template 2
*Mar  1 01:49:02.919: DUAL: Dest 11.234.0.0/24 entering active state.

When you deactivated the Fa0/0 interface, EIGRP noticed a topology change. A loss of a neighbor or an interface to a neighbor is represented by setting the Reported Distance (RD) and Computed Distance (CD, it's the Cisco's name for the total distance through that neighbor including the cost of the link to that neighbor) to infinity. This is nicely seen in the green-highlighted text.

After each topology change, EIGRP records the changed distances into the topology table and afterwards, it first triest to find a router offering the least CD and only then it verifies whether it meets the Feasibility Condition (FC).

The debug says it nicely: EIGRP was able to find out who is providing the current minimal CD (obviously, it's 10.0.0.10, and the Dmin, or the minimal CD, is 2681856) but this neighbor is not a Feasible Successor at this point because its RD of 768000 is not strictly less than the current FD of 307200. It is not certain whether it truly provides the best loop-free path to the destination, unaffected by the recent topology change, or whether it is pointing back. Both options are possible - R1 simply does not have a guarantee based on the distance alone.

Most of the trainings and text books on EIGRP would now state that if the current successor fails, the feasible successor (10.0.0.6) will be promoted to the new successor. As you have seen yourself, this is not true. If EIGRP decided to be happy with 10.0.0.6, it would indeed be using a loop-free route but possibly not the shortest one that is available. EIGRP's dilemma is clear here: Do I want to stay with 10.0.0.6 and go over a potentially suboptimal loop-free path, or do I risk using 10.0.0.10 and possibly create a routing loop?

EIGRP tries to have the cake and eat it, too. Being a routing protocol, it always has to converge on the shortest paths - that is its utmost purpose. But also by its intended design, it must never, ever, even dare to use a path that is not guaranteed to be loop-free.

So what EIGRP does is this: Because the shortest path after the topology change appears to go through 10.0.0.10 but the 10.0.0.10 is not guaranteed to provide a loop-free path, R1 will put the route into Active state and start querying the neighboring routers for their own updated distances to that destination. Because neither 10.0.0.6 nor 10.0.0.10 are affected by R1's distance increase - they have not been using R1 as their next hop even before - they will respond with the same distances as before, but now, R1 can be sure that these replies are up-to-date and taking R1's condition into account. Therefore, after the diffusing computation terminates and R1 returns to Passive state, it resets FD to infinity and afterwards chooses any neighbor that currently provides the least CD, which is 10.0.0.10, as the new successor. The CD through 10.0.0.10 also becomes the new FD, as this is the best encountered CD since the last Active->Passive transition.

So while many sources state that EIGRP's path decision process is roughly this:

  • After a topology change, check whether you have a feasible successor.
    • If yes, use it right away
    • If not, go Active

it is incorrect, and the true sequence of steps is:

  • After a topology change and updating RD and CD, find the neighbor providing the least CD
  • Check whether the neighbor providing the least CD is a Feasible Successor
    • If yes, use it right away
    • If not, go Active, even if some other neighbors are Feasible Successors

This line "*Mar  1 01:49:02.919: DUAL:     10.0.0.6 metric 5401600/281600 not found Dmin is 2681856" with "not found" means that no FS has been found for destination

Correct. It says that the least CD is 2681856 but the neighbor providing it is not a Feasible Successor, so in fact, EIGRP has not found a suitable next hop. That is why EIGRP needs to go Active - because on one hand, it must not use a possibly looped path, on the other, it must not ignore the possibility that a shorter path may truly exist.

The router is receiving the Reply from R3 and R4 but even if R4 (768000) has not satisfied the FC using the historical FD (307200) it is now the next-hop.

Yes, it is, because even after the diffusing computation has ended, it still provides the least CD, and whenever a diffusing computation is terminated and the route returns to Passive state, FD is explicitly reset to infinity because now, it can be reinitialized by any router providing the least CD.

Does this make sense? Please feel welcome to ask further!

Best regards,
Peter

Thank you very much!

This was my assumption too but I did not find in any docs or writings where this statement to be clearly exposed, even worse it is not touched at all!

 

Thank you Peter! Everything is perfect now!

Hi Peter,

thank you for the brilliant explanation. Just want to point out one thing. FD=infinity. When can this be observed? When EIGRP route is not valid (other routing protocol is preferred as per better AD) and when the best new CD is NOT provided by a feasible successor but rather after diffusing computation? So when the next time a change on the network happens, what will be an FD for that route? Will it be a "reinitialized" CD it acquired after diffusing computations? I don't think it will be still infinity, right?

Thanks!

Dima

Peter Paluch
Hall of Fame Cisco Employee

Hi Dima,

Thank you for your kind words!

FD=infinity. When can this be observed?

Great question! FD of infinity can be observed in two major scenarios.

First, an infinite FD for a network can be observed during the diffusing computation if the path through the current successor became entirely unreachable, and at the time of processing this topology change, any neighbor providing the least CD was not a Feasible Successor. This can happen if the current successor is lost entirely (it timed out, or the interface to that neighbor went down), or if the successor itself sends an Update or a Query for this network advertising an infinite distance. Also, if the network is a directly connected network, an infinite FD would be seen during the diffusing computation if the interface for the directly connected network went down.

Second, as you have correctly mentioned, an infinite FD is indicated for a network learned by EIGRP that could not, however, be installed into the routing table because there already was an identical network installed by a protocol with a lower administrative distance. Note that such a network in EIGRP still has a finite CD (otherwise it would not be learned at all), but EIGRP internally needs to reflect on the fact that the EIGRP-learned route is unusable because it didn't make it into the routing table. Therefore, EIGRP artificially sets the FD on such routes to infinity. Such networks can be seen using the show ip eigrp topology zero-successors command.

Please note that these two scenarios are independent.

When EIGRP route is not valid (other routing protocol is preferred as per better AD) and when the best new CD is NOT provided by a feasible successor but rather after diffusing computation?

I am afraid I do not entirely understand. Could you perhaps try asking again, or give us an example that would help us understand your scenario?

Thank you!

Best regards,
Peter

Peter, thank you very much again. Your responses really encourage for further learning!

In my sentence your were confused by I have actually combined the two scenarios you have described above:

1. Another routing protocol takes precedence (FD=infinity then)

2. Diffusing computations are triggered as no best CD found from feasible successors and route had to go Active (FD=infinity). However, I have mistakenly mentioned "after computation" instead of "during", again, as you have described.

Cheers

Dima