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
