62	ROUTING PROTOCOLS

•the advertised distance from each feasible successor;

•the distance via each feasible successor, as calculated locally based on the advertised distance and the cost of the link to the feasible successor;

•the interface via which the feasible successor is reached.

Of all the feasible successors, the one via which the lowest metric has been calculated is declared the successor. The information associated with the successor is used to populate the routing table.

When a current successor advertises the loss of a prefix, the router looks for another feasible successor. If one is found, then the normal process to select the successor from the list of feasible successors is carried out. If no feasible successors are found, then the route is placed in Active mode and queries are sent out to trigger the diffusing computation. The route remains in Active mode until replies are received to all queries.

5.2.12 STUCK-IN-ACTIVE

So what happens if a reply is never received to a particular query? If an adjacent router is unable to reply (maybe it has gone down since the last hello), then the route would remain in Active state forever. However, when a route is placed in Active, an active timer is started and decremented towards zero. If the timer expires before a reply is received, the neighbour is declared dead. All routes associated with that neighbour are removed from the routing table. In addition, all routes from the dead neighbour are assigned an infinite metric so that DUAL is able to correctly deal with the loss of the neighbour.

This situation has led to significant problems in the past. In growing provider networks, particularly those with comparatively low bandwidth links or links into single routers of vastly differing capacities, the problems occurred when there were topology changes within the network resulting in lots of queries. The topology changes resulted in certain links being overwhelmed by traffic and thus the routers were unable to respond to the incoming queries. This, in conjunction with the network instability, caused lots of routes to be stuck in active. This caused EIGRP sessions to be dropped, which in turn caused large numbers of routes to be withdrawn. And so the problems cascaded through the network.

These problems can be mitigated by careful application of route summarization or by the creation of routes to null0 (the discard interface) for the affected prefixes.

5.2.13 WHY USE EIGRP?

This all sounds horribly complex. However, the complexity is mostly hidden from the user. EIGRP, like IGRP, is relatively trivial to implement and operate. This makes it particularly attractive to small network operators who do not necessarily have hordes of highly skilled network engineers to keep the network ticking along. It can be pretty much turned on and left alone to get on with it.