EIGRP has Active and passive states:- A destination in the topology table can be marked
either as passive or active. A passive state is a state when the router has identified the
successor(s) for the destination
the route state is Passive which is the ideal output. Remember that Passive in EIGRP means
that DUAL already computed the path and no more computations are going to be executed; the
route is ready to be installed in the global RIB
A topology table entry for a destination can have one of two states. A route is considered in
the Passive state when a router is not performing a route recomputation. The route is
in Active state when a router is undergoing a route recomputation
Query messages use reliable transmission via RTP and are multicasts; Reply messages are
reliable and are unicasts. Both are acknowledged using Ack messages.
EIGRP includes a timer called the Active timer, which limits the amount of time in which a route
can stay active. If the Active timer expires before a router receives all of its Reply messages, the
router places the route in a stuck-in-active state.
The router also brings down any neighbors from which no corresponding Reply was received, thinking
that any neighbors that did not send a Reply are having problems.
Routes that stay in active state too long are considered to be stuck-in-active routes.
Queries are subject to the split horizon rule just like advertisements are. If you get a query for a network from
an interface, you never send out a query for that same network from that interface.
A destination in the topology table can be marked either as passive or active.
A passive state is a state when the router has identified the successor(s) for the destination.
The destination changes to active state when the current successor no longer satisfies the
feasibility condition and there are no feasible successors identified for that destination (i.e. no
backup routes are available).
The destination changes back from active to passive when the router received replies to all
queries it has sent to its neighbors.
Notice that if a successor stops satisfying the feasibility condition but there is at least one
feasible successor available, the router will promote a feasible successor with the lowest total
distance (the distance as reported by the feasible successor plus the cost of the link to this
neighbor) to a new successor and the destination will remains in the passive state


When EIGRP loses a route and there is no feasible successor the route will go
from passive to active and the router starts sending queries to its neighbors.
EIGRP sends queries on all interfaces except the interface of the successor.
What this means is that the Query message has two objectives:
One which is purely informational, meaning, to inform the neighbors about he is not longer a valid path
for the prefix.
2. To ask the network about an path for the 1.1.1.1/32 prefix.
1.
1.5 minutes has elapsed, R1 needs to send a SIA-Query to R2 since it has not hear back from
him from a while.
Limiting Query Scope
Although disabling the Active timer can prevent stuck-in-active routes, a better solution
to the prolonged wait for Reply messages is to limit the scope of Query messages. By
reducing the number of neighbors that receive the messages, and by limiting the
number of hops away the queries flow, you can greatly reduce the time required to
receive all Reply messages.
Two methods can be used to limit query scope. The first is route summarization. When
a Query reaches a router that has a summarized route, but not the specific route in the
query, the router immediately replies that it does not have that route. For instance, a
router with the route 172.31.0.0/16 in its topology table, upon receiving a query for
172.31.151.0/24, immediately sends a Reply, stating it does not have a route to
172.31.151.0/24. With well-designed route summarization, EIGRP queries can be
limited to a few hops. (Chapter 11, "IGP Redistribution, Route Summarization, and
Default Routing," covers route summarization details.)
The use of EIGRP stub routers also limits the query scope. Stub routers, by definition,
should not be used as transit routers for traffic. In Figure 9-4, R5 would be a classic
candidate to be a stub router. Also, if R4 should not be used to forward traffic from R1
over to R2, or vice versa, R4 could be a stub as well. In either case, non-stub routers do
not send Query messages to the stub routers, knowing that the stub routers should not
be transit routers. (Stub router configuration is covered in the next section.)
split-horizon causes a path to be excluded from the topology table which not satisfy fesibility
condision
for a destination in topology table
successor
RD to destinatioin from a neighborv< FD of this destination from
EIGRP DUAL FSM (Finite State Machine)
EIGRP has a mechanism called DUAL FSM (Diffusing Update Algorithm) that takes care of
multiple changes that occur during a topology change. In this lesson, I’ll explain what the
finite state machine is and how it works.
When the network is stable and there are no changes in the topology, each route will
be passive. EIGRP will act whenever an input event occurs. The source of an input
event can be:



When the metric of a directly connected interface changes.
A directly connected interface that goes up or down.
When you receive an update, query, or reply packet.
When any of these input events occurs, the router will first do a local computation where it
recalculates the distance for all feasible successors in the topology table. The possible
results from this local computation are:



If a feasible successor has a lower distance than the current successor, the feasible
successor becomes the new successor.
If the new distance is lower than the current feasible distance, we update the
feasible distance.
If the new distance is different than the current distance, we send an update with the
new distance to all neighbors.
During this local computation, the route remains passive. If there is no feasible successor
in the topology table, the router will start a diffusing computation and the route will
go active. During this diffusing computation, the router is unable to:




Change the successor of this route.
Change the distance it is advertising for this route.
Change the feasible distance for this route.
Start another diffusing computation for this route.
The router will start the diffusing computation by sending a query to each of its neighbors. In
this query, we will find the new distance that was calculated on our router.
When a neighbor router receives the query, it will start with its own local computation. If it
has a feasible successor in its topology table, it will send a reply to the neighbor that sent
the query which includes the distance to the destination. If the neighbor doesn’t have a
feasible successor, it will start a diffusing computation on its own.
EIGRP keeps track of all neighbors that it has sent a query to, it does so with a reply status
flag. The diffusing computation is finished when we receive a reply from all our
neighbors.
It is possible that some replies never make it to an EIGRP neighbor which is called stuck-inactive.
When the diffusing computation is finished, the router will change the metric of the feasible
distance to infinity to make sure that the route that its neighbors advertise in the reply is
accepted and meet the “feasibility condition” (advertised distance of the feasible successor
has to be lower than the feasible distance of the successor).
Once the router has received all outstanding replies, it will select a new successor based on
the shortest distance to the destination and sets the new feasible distance. Any feasible
successors that don’t meet the feasibility condition of this new successor are removed from
the topology table.
There are multiple input events that can cause a route to change its state and some of
these input events can occur while the route is already active.
Because of this, EIGRP doesn’t have just one “active” state but there are four active
states. We can move from one state to another. Here is an overview of the EIGRP finite
state machine, with all its different states and how we get there:
The diagram above needs some explanation. First of all, here are the acronyms:



R: query reply status flag
O: query origin flag
IE: input event
Here are the input events that you see above:












IE1: feasibility condition satisfied.
IE2: received query from successor and feasibility condition is not satisfied.
IE3: input event other than query from the successor where feasibility condition is
not satisfied.
IE4: input event other than last reply or query from the successor.
IE5: input event other than the last reply, query from the successor, or distance to
destination increased.
IE6: input event other than the last reply.
IE7: input event other than last reply or distance to destination increased.
IE8: distance to destination increased.
IE9: received all replies, feasibility condition not satisfied for current feasible
distance.
IE10: received query from the successor.
IE11: received all replies, feasibility condition satisfied with current feasible distance.
IE12: received all replies, feasible distance set to infinite metric.
The arrows in the diagram explain to which input events DUAL reacts to and to what state it
changes. EIGRP uses the query origin flag to keep track of which state it is in.
3.4.
DUAL Message Types
DUAL operates with three basic message types: QUERY, UPDATE, and
REPLY.
o
UPDATE - sent to indicate a change in metric or an addition of a
destination.
o
QUERY - sent when the Feasibility Condition fails, which can
happen for reasons like a destination becoming unreachable or the
metric increasing to a value greater than its current FD.
o REPLY - sent in response to a QUERY or SIA-QUERY
In addition to these three basic types, two additional sub-types have
been added to EIGRP:
o
SIA-QUERY - sent when a REPLY has not been received within onehalf of the SIA interval (90 seconds as implemented by Cisco).
o
SIA-REPLY - sent in response to
is still in ACTIVE state. This
original QUERY; it is only used
neighbor is still in the ACTIVE
4.2.
an SIA-QUERY indicating the route
response does not stratify the
to indicate that the sending
state for the given destination.
QUERY Packets
A QUERY packet carries the DUAL QUERY message type and is sent by a
router to advertise that a route is in ACTIVE state and the
originator is requesting alternate path information from its
neighbors. An infinite metric is encoded by setting the delay part
of the metric to its maximum value.
If there is a topology change that causes multiple destinations to be
marked ACTIVE, EIGRP will build one or more QUERY packets for all
destinations present. The state of each route is recorded
individually, so a responding QUERY or REPLY need not contain all the
same destinations in a single packet. Since EIGRP uses a reliable
transport mechanism, route QUERY packets are also guaranteed be
reliably delivered.
Savage, et al.
Informational
[Page 21]
RFC 7868
Cisco's EIGRP
May 2016
When a QUERY packet is received, each destination will trigger a DUAL
event, and the state machine will run individually for each route.
Once the entire original QUERY packet is processed, then a REPLY or
SIA-REPLY will be sent with the latest information.
3.1.
Algorithm Description
DUAL is used by EIGRP to achieve fast loop-free convergence with
little overhead, allowing EIGRP to provide convergence rates
comparable, and in some cases better than, most common link state
protocols [10]. Only nodes that are affected by a topology change
need to propagate and act on information about the topology change,
allowing EIGRP to have good scaling properties, reduced overhead, and
lower complexity than many other interior gateway protocols.
Distributed routing algorithms are required to propagate information
as well as coordinate information among all nodes in the network.
Unlike basic Bellman-Ford distance vector protocols that rely on
uncoordinated updates when a topology change occurs, DUAL uses a
coordinated procedure to involve the affected part of the network
into computing a new least-cost path, known as a "diffusing
computation". A diffusing computation grows by querying additional
routers for their current RD to the affected destination, and it
shrinks by receiving replies from them. Unaffected routers send
replies immediately, terminating the growth of the diffusing
computation over them. These intrinsic properties cause the
diffusing computation to self-adjust in scope and terminate as soon
as possible.