Solved: Hi Koh,Sorry, I have been

SJ K · ‎05-26-2015

Hi all,

Please kindly find the exhibit setup using eigrp routing protocol as below ->

R1 config

router eigrp 10
 passive-interface FastEthernet0/0
 network 192.168.1.0
 network 192.168.2.0
 network 192.168.3.0
 auto-summary

R2 config

router eigrp 10
 network 10.0.0.0
 network 192.168.2.0
 auto-summary


R3 config

router eigrp 10
 passive-interface FastEthernet0/1
 network 10.0.0.0
 network 172.16.0.0
 network 192.168.3.0
 auto-summary

==============================================================================

Problem There are 2 routes that can be taken for R1 to reach 172.16.0.0/16 network but it isnt showing in the topology table
via R1 --> R3 or R1 --> R2 -->R3
(see bolded red below)

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(10)/ID(192.168.2.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 10.0.0.0/8, 1 successors, FD is 284160
        via 192.168.3.2 (284160/281600), FastEthernet1/0
        via 192.168.2.2 (307200/281600), FastEthernet0/1  -- going to the 10.0.0.0 network, 2 possible routes are discovered.
P 192.168.1.0/24, 1 successors, FD is 281600
        via Connected, FastEthernet0/0
P 192.168.2.0/24, 1 successors, FD is 281600
        via Connected, FastEthernet0/1
P 192.168.3.0/24, 1 successors, FD is 28160
        via Connected, FastEthernet1/0
P 172.16.0.0/16, 1 successors, FD is 2588160
        via 192.168.3.2 (2588160/2585600), FastEthernet1/0
--- where is via 192.168.2.2 FastEther0/1 ?  -- why isn't 2 routes discovered here also ?

R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 10
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   192.168.2.2             Fa0/1             13 00:13:06  236  1416  0  107
1   192.168.3.2             Fa1/0             10 00:15:28  106   636  0  44

On shut down and no shut on R2 fa0/0 and having debug ip eigrp on R1, following was observed.

1) R2 fa0/0 did advertise 172.16.0.0/16 out through fa0/0 interface

R2
*Mar  1 08:38:53.917: IP-EIGRP(Default-IP-Routing-Table:10): 172.16.0.0/16 - do advertise out FastEthernet0/0
*Mar  1 08:38:53.921: IP-EIGRP(Default-IP-Routing-Table:10): Int 172.16.0.0/16 metric 2611200 - 2560000 51200

2) R1 did receive but doesn't want to install into the routing table (which routing table, eigrp topology or show ip route routing table)

*Mar  1 00:55:36.391: IP-EIGRP(Default-IP-Routing-Table:10): Processing incoming UPDATE packet
*Mar  1 00:55:36.391: IP-EIGRP(Default-IP-Routing-Table:10): Int 172.16.0.0/16 M 2636800 - 2560000 76800 SM 2611200 - 2560000 51200
*Mar  1 00:55:36.395: IP-EIGRP(Default-IP-Routing-Table:10): route installed for 172.16.0.0  ()
*Mar  1 00:55:36.395: IP-EIGRP(Default-IP-Routing-Table:10): 172.16.0.0/16 routing table not updated thru 192.168.2.2

q1) Why is it so ? :(

Regards,
Confused Noob

Peter Paluch · ‎05-27-2015

Hi Koh,

Hey, don't spoil your lunch just because of me :)

1) I have got the respective documentation from
http://www.ciscopress.com/articles/article.asp?p=1171169&seqNum=2 ; under Figure 5.6

Understood. Unfortunately, that document is not correct with respect to the Feasible Distance definition and use.

Q1) How does the sentence implies that the link between the current router to the next router, is more costly than the cost of the entire route of the next router to the destination ?

Simply read the statement carefully. The relevant part of it says: "if the next router in the path is closer to the destination than to the current router [... cut ...]". Now, the next router and the current router are connected via a direct link (otherwise the "next" router would not be the "next" one, right?). So the distance of the next router to the current router is simply the cost of the link that connects them together. As a result, saying that the next router is closer to the destination than to the current router means that the cost of the path from the next router to the destination is lower than the cost of the link that connects the current and the next router together. Voilà.

Isn't it correct if the next router's RD is lesser then the current router's FD, it means that it is actually closer to the destination then compared to the current router's distance to the destination- was it wrong ?

In the previous paragraph, I have intentionally underlined and emphasized the word "to" because it dramatically changes the meaning of the statement we are analyzing.

Notice that the statement says: "if the next router is closer to the destination than to the current router", and that is what I object against in the first place. It would be slightly more correct, but still not entirely correct, if it was rephrased as follows: "if the next router is closer to the destination than the current router", having the second "to" removed.

You could ask - what's wrong with the rephrased statement? Surely, any neighboring router that is closer to the destination than the current router is not on a routing loop, otherwise its distance would need to include the current router's distance as well and would be larger which is a contradiction with the starting assumption, right?

Well, this would be true if the network was stable and no topology changes took place. However, in the moment of a topology change, the router that detects it obviously knows about it, but its neighbors may not yet have been informed. For example, assume that a directly connected network to a router goes down. In routing protocols, this is represented as a topology change in which the distance to the network increases to infinity. At this very moment when the router just detects the directly connected interface going down, it already knows the route is dead. However, its own neighbors do not know about it yet. Using any of them just because each one of them has reported a lower-than-infinity distance in their last update would be grossly premature.

So relying on the current distances as known in the moment of a topology change is not going to prevent you from routing loops. Remember: You know about the topology change but do your neighbors know about it as well? Does their last reported distance already take the topology change into account? See, there's no guarantee of that.

That is why EIGRP uses another distance to do these loop-freedom checks, the Feasible Distance, defined as the historical minimum of the distance toward the destination since the last time the route became Passive. You may be interested in reading this entire thread very carefully:

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

It is lengthy but if we want to talk about what's really up with EIGRP and its operations, it is a mandatory stuff to master.

Q2) For the sentence "Every neighbor whose Reported Distance is smaller than this router's Feasible Distance provides a loop-free (that is, feasible) path to the destination" - does it means that for any neighbor whose Reported distance is larger then the current router's feasible distance will cause a loop if the current router go through that neighbor to reach the destination ?

No, that is not a correct extrapolation. The Feasible Condition you are quoting in your question is what we call a sufficient condition in mathematical logic. Every route that meets the Feasibility Condition is loop-free. However, the Feasibility Condition does not say anything about routes that fail the Feasibility Condition check. They might be loop-free or not. You cannot be certain, and that's the point. Routes that meet the Feasibility Condition are guaranteed to be loop-free. Routes that fail the Feasibility Condition can be either loop-free or looped - EIGRP can't tell just by looking at the distances.

This is why EIGRP also has the mechanism of diffusing computations. If a path meets the Feasibility Condition, you're perfectly safe to use it. If, however, a path does not meet the Feasibility Condition and you want to use it, you must start a diffusing computation to make an explicit verification whether that path can be used, or some other needs to be used instead.

Does that means that best local metric = FD = best historical path ever used ?

Yes, you're getting the point of FD quite right. More properly worded, FD is the best metric seen to a particular destination since the last Active->Passive transition. That is when one history ends and another history starts.

Does that even means that for a route to be a feasible successor, not only it must comply to the feasible condition; the feasible condition must be match against the best metric ever toward that particular destination before (highlighted in red above) and not just the current route metric in used (in green above) - am i right ?

Be careful about the wording. A route is never a feasible successor. The terms successor and feasible successor refer to neighboring routers, that is, potential next hops. You can have a "successor route" or a "feasible successor route" which is a shorthand for saying that the route uses the successor or the feasible successor as its next hop, but whenever we talk about successors and feasible successors, we're talking about routers, not routes.

Also, I would not say that for a route to be a feasible successor route, it must comply with several criteria (you have used the wording "not only" suggesting that there are several things for it to match). Let's break it down once again:

Feasible Distance (FD): The lowest seen (or experienced) metric to the destination since the last time the destination transitioned from Active to Passive state (that is, since the last diffusing computation for that destination has finished).
Feasible Condition: Any neighbor whose RD is strictly smaller than the current router's FD for that destination provides a loop-free path to that destination. In other words, taking the historical nature of the FD into account, any neighbor that is closer to the destination than the current router has been since the last diffusing computation for that destination provides a loop-free path.
Successor: A neighbor that meets the Feasibility Condition and provides the least total distance to the destination.
Feasible Successor: A neighbor that meets the Feasibility Condition but provides a higher-than-least total distance to the destination

That's it.

How do i reset the FD ?

As an administrator, you cannot. The FD is an internal variable maintained by EIGRP for every known route. However, by its definition, the FD is always lowered whenever the current router learns about a better (understand - shorter) path than currently known. Increasing the FD can only be done during a diffusing computation. A router must not increase the FD on its own accord without coordinating with its neighbors.

I am sure this is a difficult topic and it elicits lots of questions so please feel welcome to ask further!

Best regards,
Peter

View solution in original post

Peter Paluch · ‎06-01-2015

Dear friends,

I am struggling to find an appropriate response to all your compliments but I am utterly at a loss. I do not want this to appear as posturing of any kind, neither do I want to be irritating, but I feel at this point that it is the best to remain silent - apart from telling you in all my sincerity that I am deeply and profoundly touched.

Koh - absolutely no need to apologize. I needed time to respond, too. By the way, is it proper to call you Koh? Is that your first name? If not, how should I properly call you? I apologize but obviously, different languages have different ways of addressing a person. I refuse to use the word "noob" to address you. With its usual meaning, using it to refer to you is an insult and could not be farther from the truth.

a) for every events that cause an update to the topology table - even if there is currently-in-use successor route, the router will still check for routes that has the least cost metric, if there is such a (newer) route, and if it matches the feasibility condition, then it will replace the existing successor route.

Q1) right ? -- what happen to the "current" successor route, that is going to be "replaced" ?

That is correct. Regarding the replaced route, it will be removed from the routing table but it will still remain in the topology table.

b) The FD for the scenario above, might stay the same (even if the newer route has a higher cost metric/FD) or will go lower. This is because the operation above is still within the scope of a local computation.

Correct. While the route remains Passive, the FD can not increase. It may stay at its current value (if the new route is of the same or higher metric) or it may decrease (if the new route has a lower metric than the previous one). However, increasing the FD during Passive state is not allowed under any circumstances. Period. It's that simple.

c) In the event that the newer route does not meet the feasibility condition but however is still / has the least cost metric, then it is put into active mode and queries are send out to neighbors to confirm on their RD to the destination network.

Absolutely correct. Just to make sure we keep the terminology correct: It is not a route that meets the Feasibility Condition, rather it is the next hop (that is, the router) that meets the Feasibility Condition. This may be daunting but it is important to always keep in mind that the checks are performed on neighbors for a particular route, not just on the route itself.

Q2) why is it that when/if a newer route does not meet the feasibility condition, then the route must be put into active mode and queries must be send out to neighbors to confirm on the their RD to the destination network ? In the situation above, can't the router use back the original successor route ? (without going to active mode/sending updates)

Let's make sure we're talking about the same scenario: A route will be put into the Active state if both following conditions are true:

It provides the least total metric (that is, the lowest Computed Distance among all available routes toward the same destination in the topology table)
Its advertising neighbor does not meet the Feasibility Condition

So under these circumstances, why does not the router simply stay with its current route it has been using so far? The answer is simple: You want your router to be always using the shortest path that is available. In my scenario with the two routers, after the link to Router1 went from 10 to 50, the path through Router1 became more expensive (100) than through Router2 (80). The path through Router1 is still guaranteed to be loop-free because Router1 meets the Feasibility Condition - but there is a chance that there is a shorter route available right through Router2. If you stayed with Router1, you would be using a workable route but possibly not the shortest one that is available, and that is not how routing protocols work - to be happy with just about any loop-free route, short or long. But with Router2, you cannot be sure whether it's loop-free or on, as Router2 fails the Feasibility Condition check. That is why you go Active - to make sure.

Note that if the new route did not provide the least cost metric, the fact that its neighbor meets or fails the Feasibility Condition would be irrelevant. You would not go Active with that route because you do not need to: You already have a better path that is loop-free. There would be nothing new to learn by going Active.

What are the actual checks in place (send via the queries) with/to the neighbors to make sure R2 is a usable route and to have it install as the successor route eventually leading to the increment in the FD ?

Okay, this may be a little hairy. When the current router finds out that the route through Router1 (100) is more costly than through Router2 (80) but Router2 fails the Feasibility Condition, it will go over the following (simplified) sequence of steps:

First, it will update the entry in the routing table, keeping it pointing through Router1 but updating the total metric to 100. In EIGRP, you must not change the next hop until you have a guarantee that it is loop-free by meeting the Feasibility Condition. As you have had this guarantee for Router1 up to this point, you are going to keep routing packets through Router1 until the diffusing computation is finished. The packets may thus travel a longer route, perhaps even get blackholed, but they're not going to be stuck in a routing loop. As to why the metric value in the routing table gets increased to 100, this is the very same logic we've used when we talked about the routing loops in RIP: If I am using a particular next hop to reach a destination, and the total cost through that next hop increases (computed as the sum of the link cost to that next hop plus its RD) then until I change to a different next hop, I am objectively farther from the destination, and this fact has to be recorded in the routing table.

Second, the router will put the route into the Active state and send out Queries to all its neighbors. A Query simply contains the new increased distance over the current successor, in this case, 100. The current router effectively tells its neighbors: "Guys, my current distance to this destination has changed to 100. Tell me your own distances to that destination after you take this changed distance of mine into account!"

What happens on the neighbors, now? First of all, the neighbors will treat the metric in the Query as the sending router's new RD, meaning they will update their own topology tables, recalculate their own Computed Distances and determine whose of their own neighbors provides the new least cost path. Now, for each neighbor individually, there are two possibilities:

Either its own next hop for the new least cost path satisfies the Feasibility Condition as seen by that neighbor (using that neighbor's FD), in which case the neighbor is happy because it could identify its own new successor in a local computation. In this case, the neighbor will send a Reply right away, indicating its new distance through its own new successor. Notice that it could have safely happened that the neighbor did not need to change its own next hop and metric at all. I have described the situation in this thread you have already visited.
Or its own next hop for the new least cost path does not satisfy the Feasibility Condition. In this case, the neighbor performs the very same steps as this router: It will keep the route through its current successor - most probably, it's you - in its routing table but will update the metric through its current successor, reflecting the changed distance, and will send its own Queries indicating its own changed distance over its current successor.

So in other words, the Query is nothing else than an indication that a router's current distance through its current successor has changed to a different value which is indicated in the Query, along with a request for the routers receiving the Query to update their own topology tables, re-evaluate their own choices of least cost paths, subject to their own Feasibility Condition checks, and report back their possibly changed distances. Either they will be able to find the least cost loop-free path using their own local computation, in which case they will simply send a Reply with their re-evaluated distance right away, or they will be unable to find such a path and will need to become Active themselves. A single router going Active may therefore cause a cascade of all routers that formerly relied on the same affected path to go Active, looking for a replacement path. Routers unaffected by this topology change (unaffected in the terms of "Even after processing the distance in the Query, I still could find a neighbor in my topology table that provides the least cost path and based on my current FD, it passes the FC check") will not propagate the Query further, they will simply respond by sending a Reply with their current best metric.

At this point, let's recap: You are a router. You have noticed after processing an event that the neighbor providing the current least-cost path does not meet the FC check. You lock the current routing table entry to make sure it still points to the unchanged old next hop (the old successor), just update its metric to reflect the current (possibly increased) metric through the old next hop, and send out Queries indicating this metric to your neighbors. After doing this, you must not change the routing table until you receive Replies from all neighbors that have been sent a Query. When a Reply is received from a neighbor, it is certain that it was either unaffected, or that it has also engaged into a diffusing computation but has got all necessary Replies and made its own best path selection, in both cases taking your changed distance into account. So after all your neighbors send you a Reply you can be sure they have updated their own knowledge based on what you told them in your Query, and that their own Feasibility Condition check prevents them from choosing you as their next hop if there is a chance you would be using them as your next hop.

Third, with all Replies received - taking the indicated distance from each Reply and recording it into the topology table as they are received - the router now can set the FD to infinity (that, increase it to the maximum value possible) and re-evaluate the least cost path in the topology table. Whichever neighbor provides it, it is going to become the new successor, and because its metric is certainly lower than infinity (which is currently stored in FD), the metric over this neighbor also becomes the new FD. After this, the router can unlock the routing table entry, update it to the newly chosen successor, and put the route back into the Passive state.

Finally, if the current router went active because it received a Query itself then this would be a time to start sending Replies. While in the Active state, you cannot start sending Replies if you haven't received all Replies to your own Query - because you haven't made your mind yet. Otherwise, if you became Active because of any other event, you simply send an unrequested Update if your distance changed from what it was before the Active state.

This will require quite some pondering but in principle, it's relatively simple. It is a recursive process: your Active state may cause other neighbors to go Active as well, but this all depends on how their own Feasibility Checks turn out after processing your Query. So in terms of the behavior of a single router, it's simple, really. You get a Query, process the distance in it, re-evaluate the Computed Distances, choose the neighbor providing the least Computed Distance and now check whether it meets the Feasibility Condition. If it does, you're fine, just start using it and send back a Reply with the new distance. If it does not, go Active yourself advertising your current (possibly changed) distance over your current successor, and wait for all Replies before making a new selection, only then start using it and send Replies. Visualizing it over a larger network may make your head spin, though :)

I will respond to your question about doing the studying in a separate post as this one has got insanely large.

Best regards,
Peter

View solution in original post

Peter Paluch · ‎06-02-2015

Hi,

Yeap, you can call me Koh; that's my surname

Understood. Pardon my ignorance - what is your first name? Sze or Jie? It's uncommon for me in an informal setting like this one to address a person by his/her surname.

1) Can i say that the update/query is actually not to confirm on the router's (newly found successor) but to inform the others/neighbors of the updated metric.to the currently (in-use) successor;

Very correct. You do not send out Queries because you want to "confirm" something. Rather, you send out Queries to inform your neighbors about your updated metric toward the destination network through your current successor, request them to update their own choice of best paths and respond with their own updated best distances. All this is done so that you can choose your new successor based on guaranteedly up-to-date information, knowing that your neighbors have been briefed on the update that has affected you and have considered that before sending a Reply back to you.

2) through the above, neighbors will reply with their updated/confirmed RD to the destination nework; and this is when the current Router itself, can confirm on and use its (newly found successor) ; changing its current FD to infinity and updating it to the new FD for the newly found successor; then going in to passive again.

... "changing its current FD to infinity and updating it to the new CD for the newly found successor". Yes, correct.

so i am going to believe that whoever come up with EIGRP is a maths or some path-finding genius.

There are many smart people behind the fundamental principle but its principial author is Prof. Jose Joaquin Garcia-Luna-Aceves, currently at University of California, Santa Cruz, the author of the Feasibility Condition and of the DUAL itself. He also reused the diffusing computation mechanism from E. W. Dijkstra and C. Scholten and has adapted all of this to the basic shortest path search algorithm by Bellman and Ford.

But you see, to prove that EIGRP works correctly, you do not try to prove it for an entire network at once. Instead, the general mechanism is consider the processes on a single node and their interaction with neighboring routes. By recursively applying this over an entire network, you get the actual proof.

q1) as mentioned, the update of 1's metrics can create a series of chain effect and 1 must wait for all the replies before 1 can confirm on its own successor and change from active to passive.

Very good! This chained dependence in EIGRP is in fact its Achilles heel, and if some router for whatever reason fails to deliver its Reply to the neighbor that has asked for it, you'll end up with so-called Stuck-In-Active (SIA) states. EIGRP developers had to implement a specific mechanism to recover from these occurrences, and there are lots of things in best practices that should be done to make sure that SIA states never happen. That would require a separate thread.

-- assuming we are talking about a super large network; (i don't know if eigrp is use across WAN/Internet as well); and assuming that the destination network is quite some distance away in a extremely meshed up network. -- how can we be sure if we will get all the replies we need ?

EIGRP is an enterprise interior gateway protocol and is not usually used in service provider environment. Still, even enterprise networks, especially when compounded with high redundancy, lots of VLANs, and VPNs, can get exceedingly complex. How we can be sure we'll get a Reply eventually?

With respect to the reliability of delivering EIGRP messages, EIGRP uses its own reliable transport protocol that allows reliability both when unicasting and multicasting and preserves message ordering. From this viewpoint, EIGRP has the means to make sure that once a Reply has been sent, it will eventually come through if you have infinite time for possible retries.

Of course, this is a theoretical assumption. You need to have the Reply as soon as possible, otherwise the convergence speed of your network suffers. However, the links may be so overloaded or faulty that the Replies cannot make it in reasonable time. You may also have some other specific problems - losing packets of specific type or length, software issues, etc. that may cause that the Reply is simply unable to make it back to the neighbor that needs it.

For this situations, EIGRP imposes a time limit on each diffusing computation. If the diffusing computation is not finished in this time (3 minutes by default), the routers will give up on it and just move on with the remaining replies they have received, if any. This is an extremely simplified description of handling a SIA but as I indicated earlier, this topic would be more suitable in a standalone thread.

I am just thinking A -> B -> C -> Network E

-> D -> Network E

Okay, so what happens here if you raise the cost of the link between B and C, causing D that nonetheless fails the Feasibility Condition to provide the least cost path?

B will go Active and send a Query to all its neighbors. C and D are totally unaffected - they have not been using B to reach network E before and are even less eager to use it after they found out it is even farther than before. So while C and D process B's indicated RD into their topology tables, their best paths do not change and they just send back a Reply indicating their (unchanged) distance to E.

What happens on A is somewhat more surprising. For A, there is a very big chance that B's RD (as learned from its Query) has grown beyond A's FD. That would mean that A has lost its own successor and the router providing the least cost path (in this case, it's still B) does not meet the Feasibility Condition. For A, this means it has to go Active as well.

So A will send out a Query to its only neighbor, B, indicating A's own increased distance. Now, B has to send a Reply but hey, B is still Active so how can it send a Reply? Isn't this a deadlock?

Fortunately, it isn't. If B is in Active state and receives a Query itself, it sends a Reply right away, indicating the same distance it already indicated in its own Query - because that's the truth: At the moment B is Active, its current distance is the increased distance through C. B has indicated this in its Query already but should B receive a Query from any of its neighbors while still Active, B is going to send a Reply right away indicating the same distance again.

So in this network, after A sends a Query to B, B will respond with a Reply, indicating the same distance it has already indicated in its Query. As A got all Replies it expected, it sets the FD to infinity, then chooses the neighbor providing the best path (B), updates the metric in the routing table, then goes Passive and - remember that A still has a Reply to send - sends B a Reply, indicating its momentary distance from the network E.

Only now, at this point, B has all Replies it expects, so it sets its own FD to infinity, chooses the neighbor providing the least cost path (D), updates its own metric in its routing table, and because now B's distance has changed from what it was before the topology change, B sends an Update to all its neighbors including A. To A, this will appear as a metric decrease.

I would not call Updates as "gratuituous". They are simply event-driven and uncoordinated. Every time a router in a Passive state detects a topology change such that its distance to the destination changes but no diffusing computation is required, it will advertise its updated distance in an Update packet.

Best regards,
Peter

View solution in original post

Jon Marshall · ‎05-26-2015

The reason is because the AD (Advertised Distance) of the route via R2 is greater than the FD (Feasible Distance) of the route via R3 so you won't see it in the "sh ip eigrp topology" output which only shows successor and feasible successor routes ie.

from your IP routing table -

P 172.16.0.0/16, 1 successors, FD is 2588160 via 192.168.3.2 (2588160/2585600), FastEthernet1/0

and the route update from R2 -

*Mar 1 00:55:36.391: IP-EIGRP(Default-IP-Routing-Table:10): Int 172.16.0.0/16 M 2636800 - 2560000 76800 SM 2611200 - 2560000 51200

the SM is the AD of the route from R2 and you can can see that the AD > FD of the route.

So you won't see it when you run the "sh ip eigrp topology" command because as stated above that command only lists the best route(s) and any other routes that are not currently being used but can be considered as feasible successor routes.

If you run the command "sh ip eigrp topology all-links" you will see the full EIGRP topology database and it should be in there.

Jon

SJ K · ‎05-26-2015

Hi Jon, Bilal,

Thanks for replying.

I think I have known the reason why. As per Jon said, the AD of the route is higher then the FD current route, that is the reason why it is not consider as a feasible route and will not show when "show ip eigrp topology".

In the documentation, it says ->

A route is feasible if the next router in the path is closer to the destination than to the current router and if the metric of the alternate path is within the variance. Load balancing can use only feasible paths, and the routing table includes only these paths. The two feasibility conditions are as follows:

The local best metric, which is the current feasible distance, must be greater than the best metric (the advertised distance) that is learned from the next router. In other words, the next router in the path must be closer to the destination than to the current router; this criterion prevents routing loops.

The metric of the alternate path must be less than the variance multiplied by the local best metric (the current feasible distance)

=============================================================

To prove my theory is right, I have to make the AD lower then the current FD, after playing around with the delay (shortening the delay) , i finally got what i want ;)

- not load balancing though, but added in as a feasible successor route

R1(config-if)#do show ip eigrp topology
IP-EIGRP Topology Table for AS(10)/ID(192.168.2.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 10.0.0.0/8, 1 successors, FD is 28160
        via 192.168.2.2 (29696/27648), FastEthernet0/1
        via 192.168.3.2 (30208/27648), FastEthernet1/0
P 192.168.1.0/24, 1 successors, FD is 281600
        via Connected, FastEthernet0/0
P 192.168.2.0/24, 1 successors, FD is 27648
        via Connected, FastEthernet0/1
P 192.168.3.0/24, 1 successors, FD is 28160
        via Connected, FastEthernet1/0
P 172.16.0.0/16, 1 successors, FD is 2588160
        via 192.168.3.2 (2588160/2585600), FastEthernet1/0
        via 192.168.2.2 (2589696/2587648), FastEthernet0/1

Just 2 quick questions though

q1) when manually adjusting bandwidth and delay parameters, do we need to do it across adjacent interfaces ( meaning setting the parameters on each interfaces of the connecting routers)

q2) Does the output of "show ip eigrp topology" in "p" mode, means only successor and feasible successor routes/paths that are being elected by EIGRP ?

if we add a /all behind, it means all available paths ? - but some will not be consider as feasible at all.

Am i right ?

Regards,
Noob

Peter Paluch · ‎05-26-2015

Hi Koh,

There are some inaccuracies in the information you have quoted. What documentation was that? If it is a Cisco documentation, it needs to be corrected.

I will be using the term Reported Distance instead of Advertised Distance because the acronym AD is easily confused with Administrative Distance which is a different unrelated concept.

A route is feasible if the next router in the path is closer to the destination than to the current router and if the metric of the alternate path is within the variance.

This is wrong. First, the variance has absolutely no relevance in determining whether the route is feasible. Feasible routes are identified exclusively based on the Feasibility Condition that says: Every neighbor whose Reported Distance is smaller than this router's Feasible Distance provides a loop-free (that is, feasible) path to the destination. Second, the formulation "next router should be closer to the destination than to the current router" is a misrepresentation of the Feasible Condition as it implies that the link between this router and the next router should be more costly than the cost of the entire path from the next router down to the destination.

The local best metric, which is the current feasible distance, must be greater than the best metric (the advertised distance) that is learned from the next router.

This is wrong. This router's Feasible Distance is not the local best metric. The Feasible Distance is defined as the lowest metric to the destination this router has experienced since the route last transitioned from Active to Passive state. In other words, it is a historical record of the smallest distance to the destination since the last Active->Passive transition. The current best distance can be equal to the Feasible Distance, or it can be greater; there is no strict equality between them.

In other words, the next router in the path must be closer to the destination than to the current router; this criterion prevents routing loops.

This is wrong as explained earlier.

The metric of the alternate path must be less than the variance multiplied by the local best metric (the current feasible distance)

This is partially wrong and partially unrelated. This rule talks about selecting worse feasible routes for unequal-cost load balancing and not about identifying feasible routes in the first place. To identify feasible routes, only the Feasibility Condition is used as explained above. In addition, this formulation again makes the mistake of confusing the current best metric with the Feasible Distance and assuming they are the same - which they most certainly aren't.

P 172.16.0.0/16, 1 successors, FD is 2588160
        via 192.168.3.2 (2588160/2585600), FastEthernet1/0
        via 192.168.2.2 (2589696/2587648), FastEthernet0/1

When comparing the FD and the RD, don't make the mistake of using the local best metric as you have done in your previous example. The FD is clearly indicated for the route in its heading, here in green. It has only worked for you because in your network, the FD happened to be the same as the current best metric but this does not always need to be the case.

q1) when manually adjusting bandwidth and delay parameters, do we need to do it across adjacent interfaces ( meaning setting the parameters on each interfaces of the connecting routers)

Ideally, yes, although there are situations where the bandwidth setting on both routers on a common link can be different, most often in multipoint Frame Relay scenarios with different speeds of individual virtual circuits. Note, however, that you should not use the bandwidth to influence EIGRP's choice of paths. The bandwidth setting has more consequences than just impacting the EIGRP metric (it also affects the QoS tools operation on the interface if configured; it translates into how much bandwidth EIGRP will actually use when sending its updates over the interface) and so it should be set to a realistic value. If you need to influence the path EIGRP will use, modify the delay setting. The delay parameter is used only in EIGRP metric calculation and does not affect any other router operation.

q2) Does the output of "show ip eigrp topology" in "p" mode, means only successor and feasible successor routes/paths that are being elected by EIGRP ?

Can you rephrase this please? I am not entirely sure I understand what you mean.

Best regards,
Peter

SJ K · ‎05-27-2015

Hi Peter,

Good to hear from you. I rushed back from lunch just to be able to reply to your response. Hope you will be able to see them here.

1) I have got the respective documentation from
http://www.ciscopress.com/articles/article.asp?p=1171169&seqNum=2 under Figure 5.6

With regards to the variance, I agreed with you on what you have said and it should have no impact on feasible routes selection.

However with regards to the below

Second, the formulation "next router should be closer to the destination than to the current router" is a misrepresentation of the Feasible Condition as it implies that the link between this router and the next router should be more costly than the cost of the entire path from the next router down to the destination.

Q1) How does the sentence implies that the link between the current router to the next router, is more costly than the cost of the entire route of the next router to the destination ?

Isn't it correct if the next router's RD is lesser then the current router's FD, it means that it is actually closer to the destination then compared to the current router's distance to the destination- was it wrong ?

It would be good if you can illustrate with a diagram (if possible)

Q2) For the sentence "Every neighbor whose Reported Distance is smaller than this router's Feasible Distance provides a loop-free (that is, feasible) path to the destination" - does it means that for any neighbor whose Reported distance is larger then the current router's feasible distance will cause a loop if the current router go through that neighbor to reach the destination ?

Consider this below (courtesy of packetlife.net)

R4 to R5 - FD = 1280+512= 1792

R3 to R5 - FD and RD = 2560+512 = 3072

If R4 to R5 is down, R3 to R5 is not consider as a feasible route because its RD (3072) is more then the FD (1792) of the current router, but how will/does going from R4-R3-R5 consider or cause a loop ?

Q3)

The current best distance can be equal to the Feasible Distance, or it can be greater; there is no strict equality between them

When comparing the FD and the RD, don't make the mistake of using the local best metric as you have done in your previous example. The FD is clearly indicated for the route in its heading, here in green. It has only worked for you because in your network, the FD happened to be the same as the current best metric but this does not always need to be the case.

I have done a test

P 172.16.0.0/16, 1 successors, FD is 2588160 -- current FD
via 192.168.3.2 (2588160/2585600), FastEthernet1/0
via 192.168.2.2 (2589696/2587648), FastEthernet0/1

172.16.0.0/16, 1 successors, FD is 2587904 -- lowest FD after adjusting shorter delay
via 192.168.3.2 (2587904/2585600), FastEthernet1/0
via 192.168.2.2 (2589696/2587648), FastEthernet0/1

P 172.16.0.0/16, 1 successors, FD is 2587904 -- lowest FD remains after returning the delay to original
via 192.168.3.2 (2588160/2585600), FastEthernet1/0
via 192.168.2.2 (2589696/2587648), FastEthernet0/1

Does that means that best local metric = FD = best historical path ever used ?

Does that even means that for a route to be a feasible successor, not only it must comply to the feasible condition; the feasible condition must be match against the best metric ever toward that particular destination before (highlighted in red above) and not just the current route metric in used (in green above) - am i right ?

How do i reset the FD ?

Regards,
Noob

Peter Paluch · ‎05-27-2015