Skip to content
Log in Sign up My account

1.9.c and 1.9.d Loop-Free Path Selection, Stuck in Active and Stubs

Blueprint 1.9.c and 1.9.d: Troubleshoot EIGRP (classic and named mode)

  • 1.9.c Loop-free path selections: reported distance (RD), feasible distance (FD), feasibility condition (FC), successor, feasible successor, stuck in active (SIA)
  • 1.9.d Stubs
  • Query scope, and the tools that limit it: stubs, summarization, filtering

DUAL (the Diffusing Update Algorithm) is what makes EIGRP converge quickly without loops. It does that with one simple rule, the feasibility condition, and one fallback, the query process. Exam questions on this objective give you a topology table and ask which path is the successor, which is a feasible successor, what happens when a link fails, or why a router reset a neighbor with "stuck in active". Stubs belong in the same page because their main job is to limit queries.

The vocabulary

Term Definition Where to read it
Reported distance (RD) The neighbor's own metric to the destination, as it advertised it. Also called advertised distance. Second number in brackets: (total/RD)
Computed distance RD plus the cost of the link to that neighbor, that is, the total metric through that neighbor First number in brackets
Feasible distance (FD) The best computed distance to the destination since the route last became passive. In steady state it equals the successor's metric. FD is ... on the prefix line
Successor The neighbor with the lowest computed distance. Its path goes in the routing table. First via line, also the routing table
Feasibility condition (FC) A neighbor's RD must be strictly less than the local FD Compare second number with FD
Feasible successor (FS) A neighbor, other than the successor, that meets the FC. It is a guaranteed loop-free backup. Other via lines in show ip eigrp topology

The reasoning behind the FC: if a neighbor's own distance to the destination is shorter than mine, its path cannot loop back through me. If its distance is equal to or longer than mine, it might be using me to get there, so DUAL refuses to trust it as an instant backup.

Worked example from the module baseline

In the baseline, R1 reaches 10.4.40.0/24 (R4's Loopback40) through R2 and through R3. The R1 to R3 link has delay 100 on R1, so that path is slower. The numbers are 64-bit wide metrics, worked out step by step on the metrics page.

graph LR
  R1["R1<br/>FD 329646080"] -- "Gi0/1 delay 10 us" --- R2["R2<br/>RD 328990720"]
  R1 -- "Gi0/2 delay 1000 us" --- R3["R3<br/>RD 328990720"]
  R2 -- "Gi0/2" --- R4["R4<br/>Lo40 10.4.40.0/24<br/>delay 5000 us"]
  R3 -- "Gi0/2" --- R4
R1# show ip eigrp topology 10.4.40.0/24
EIGRP-IPv4 VR(CORP) Topology Entry for AS(100)/ID(10.255.255.1) for 10.4.40.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 329646080, RIB is 2575360
  Descriptor Blocks:
  10.1.2.2 (GigabitEthernet0/1), from 10.1.2.2, Send flag is 0x0
      Composite metric is (329646080/328990720), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 5020000000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
        Originating router is 10.255.255.4
  10.1.3.3 (GigabitEthernet0/2), from 10.1.3.3, Send flag is 0x0
      Composite metric is (394526720/328990720), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 6010000000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
        Originating router is 10.255.255.4
  1. Successor: 10.1.2.2, computed distance 329,646,080, which becomes the FD.
  2. FC for 10.1.3.3: RD 328,990,720 is less than FD 329,646,080, so R3 is a feasible successor.
  3. If R1 Gi0/1 fails, R1 promotes R3 immediately, without sending a single query. The route stays passive.

Now a variation that the lab reproduces. Someone sets delay 2 (20 microseconds) on R3's link to R4. R3's own metric rises to 65,536 x (10 + 5,000 + 20) = 329,646,080, which is exactly R1's FD. Equal is not less, so R3 fails the FC even though its path still works and is still under any variance multiplier. R1 now has no feasible successor, and losing R2 forces a query.

Exam trap

The FC is a strict "less than". An RD equal to the FD fails. Also, the FC compares the neighbor's RD with the local FD. The total metric through the backup neighbor is irrelevant to feasibility, so a path with the second-best total metric can fail the FC while a worse one passes.

Reading the default topology view

show ip eigrp topology lists only successors and feasible successors. A working path that fails the FC is hidden. Use show ip eigrp topology all-links to see every neighbor that advertised the prefix, or show ip eigrp topology <prefix> for the full detail.

Command Shows
show ip eigrp topology Successors and feasible successors only
show ip eigrp topology all-links Every path learned, including non-feasible ones
show ip eigrp topology <prefix>/<len> Vector metric detail for every path to one prefix
show ip eigrp topology active Routes currently active and which neighbors have not replied
show ip eigrp topology zero-successors Routes in the table with no successor (not installed)

When the successor is lost

graph TB
  F["Successor lost<br/>(link down or worse metric)"] --> Q{"Feasible successor<br/>in topology table?"}
  Q -- Yes --> P["Local computation:<br/>promote FS, stay Passive,<br/>send update, no queries"]
  Q -- No --> A["Go Active:<br/>query every non-stub neighbor,<br/>start 3 minute active timer"]
  A --> R{"All replies<br/>received?"}
  R -- Yes --> B["Pick best reply as new successor<br/>or remove route, back to Passive"]
  R -- "No reply at 90 s" --> S["Send SIA-Query to the silent neighbor"]
  S --> T{"SIA-Reply<br/>received?"}
  T -- Yes --> R
  T -- "No, timer expires" --> X["Neighbor reset:<br/>stuck in active"]

The query process

A router that goes active sends a query for the prefix to every neighbor except stubs, and must hear a reply from every one before it can finish. A neighbor that receives a query does one of three things:

  1. If it has another path that does not use the querying router, it replies with its metric.
  2. If it does not know the prefix at all (it was filtered or summarized away), it replies immediately with "unreachable". This is why summarization and filtering stop queries.
  3. If the querying router was its successor and it has no FS of its own, it goes active itself and queries its own neighbors. The reply to the original query waits until its own computation finishes.

Step 3 is how queries spread through a large network. The furthest router determines how long the first router stays active.

Stuck in active

The default active timer is 3 minutes (timers active-time under the address family, or under router eigrp in classic mode). Halfway through, at 90 seconds, the active router sends an SIA-Query to any neighbor that has not replied. If the neighbor answers with an SIA-Reply ("still working on it"), the timer is restarted for that neighbor. A router sends up to three SIA-Queries. If a neighbor stops answering SIA-Queries as well, the active router resets that adjacency and logs it:

%DUAL-3-SIA: Route 10.4.40.0/24 stuck-in-active state in IP-EIGRP(0) 100.  Cleaning up
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.3.3 (GigabitEthernet0/2) is down: stuck in active

The neighbor that was reset is usually not the problem. It is the next link in a chain of routers waiting for replies. To find the real cause, run show ip eigrp topology active on the router that logged SIA and follow the neighbors that still owe a reply:

R1# show ip eigrp topology active
EIGRP-IPv4 VR(CORP) Topology Table for AS(100)/ID(10.255.255.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

A 10.4.40.0/24, 0 successors, FD is 329646080, RIB is 2575360
    1 replies, active 00:01:52, query-origin: Local origin
         via 10.1.2.2 (Infinity/Infinity), GigabitEthernet0/1
    Remaining replies:
         via 10.1.3.3, r, GigabitEthernet0/2

R1 has been active for 1 minute 52 seconds and is still waiting for R3 (the lowercase r). Log in to R3 and run the same command. Repeat until you find a router that is not waiting on anyone but still has not replied, or a link where replies are lost. Typical root causes are a congested or lossy link, a one-way link, a router with high CPU, or simply a query domain so large that three minutes is not enough.

Exam trap

The cure for SIA is rarely to raise the active timer. Fix the link or the slow router, then reduce the query scope with stubs, summarization or filtering. In an answer list, "configure the remote sites as stub routers" or "summarize toward the core" usually beats "increase the active timer".

Limiting query scope

Tool Why queries stop there
Stub routers Neighbors do not send queries to a stub at all
Summarization A router that has only the summary replies "unreachable" for a component prefix right away, without asking its own neighbors
Route filtering (distribute-list) A router that never learned the prefix replies immediately
Separate EIGRP AS with redistribution Queries do not cross the AS boundary. The redistributing router answers for its own AS.

Stub routers

A stub tells its neighbors in its hellos that it is a stub and which route types it will advertise. Neighbors then stop sending it queries. Configure it on the remote router only, never on the hub.

router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  eigrp stub connected summary          ! the default when no keyword is given

Classic mode: eigrp stub connected summary directly under router eigrp 100. For IPv6, configure it again under the IPv6 address family or ipv6 router eigrp.

Keyword Advertises
(none) Same as connected summary
connected Connected routes
summary Summary routes configured on the stub
static Redistributed static routes
redistributed Other redistributed routes
receive-only Nothing. Cannot be combined with other keywords
leak-map NAME Additionally, the EIGRP-learned routes that the route map permits

Two behaviors cause most stub tickets:

  1. A stub never re-advertises routes it learned from one EIGRP neighbor to another, unless a leak map allows it. That is the point of a stub: it must not become a transit path.
  2. Stub is a promise about the router, not the link. If you put eigrp stub on a hub or distribution router by mistake, it stops passing routes between its neighbors and the network partitions.
graph LR
  HQ["Core"] --- B1["Branch R6<br/>eigrp stub"]
  HQ --- B2["Branch R7<br/>eigrp stub"]
  B1 -- "branch link" --- B2
  B2 --- LAN["LAN 10.7.70.0/24"]

In the dual-homed branch above, if R7's link to the core fails, the core loses 10.7.70.0/24 completely. R6 learns it from R7 but, as a stub, will not advertise it to the core. The fix is a leak map on R6 that permits the branch prefixes:

ip prefix-list BRANCH-LANS seq 5 permit 10.7.70.0/24
route-map LEAK-BRANCH permit 10
 match ip address prefix-list BRANCH-LANS
!
router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  eigrp stub connected summary leak-map LEAK-BRANCH

On the hub, show ip eigrp neighbors detail tells you which neighbors are stubs and what they advertise:

R1# show ip eigrp neighbors detail GigabitEthernet0/3
EIGRP-IPv4 VR(CORP) Address-Family Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
2   10.1.5.5                Gi0/3                    12 01:10:44    4   100  0  31
   Version 23.0/2.0, Retrans: 0, Retries: 0, Prefixes: 2
   Topology-ids from peer - 0
   Topologies advertised to peer:   base

  Stub Peer Advertising (CONNECTED SUMMARY ) Routes
  Suppressing queries
  Max Nbrs: 0, Current Nbrs: 0

On the stub itself, show ip protocols includes a line such as EIGRP stub, connected, summary.

Exam trap

The stub flag does not stop the stub from receiving routes. A receive-only stub still learns everything. When a ticket says "the branch can reach the data centre but the data centre cannot reach the branch", look at the stub keywords on the branch router.

Lab: two DUAL and stub tickets

Use the module baseline from the address-family lab and reload it before each ticket.

Ticket 6: "The branch lost the data centre, and the data centre lost the branch, after a change on R1."

Inject on R1:

router eigrp CORP
 address-family ipv4 unicast autonomous-system 100
  eigrp stub connected summary
  1. On R5, show ip route eigrp lists only R1's connected subnets (10.1.2.0/30, 10.1.3.0/30 and 10.255.255.1/32). Every route that R1 learned from R2 and R3 is gone.
  2. On R4, 10.5.50.0/24 is missing. R1 learned it from R5 and, as a stub, will not pass it on.
  3. On R2, show ip eigrp neighbors detail shows Stub Peer Advertising (CONNECTED SUMMARY ) Routes for 10.1.2.1. That is the hub, which should never be a stub.
  4. Fix with no eigrp stub on R1. Verify that R5 learns 10.4.40.0/24 and R4 learns 10.5.50.0/24.

Ticket 7: "R1 used to fail over to R3 instantly. Now a failure of the R2 link causes an outage of several seconds."

Inject on R3:

interface GigabitEthernet0/2
 delay 2
  1. On R1, show ip route 10.4.40.0 shows only the path through R2, although variance 2 is configured.
  2. show ip eigrp topology 10.4.40.0/24 lists only 10.1.2.2. show ip eigrp topology all-links adds via 10.1.3.3 (395182080/329646080).
  3. Compare: R3's RD 329,646,080 equals R1's FD 329,646,080. It is not less, so the FC fails and R3 is neither a feasible successor nor eligible for variance.
  4. Shut R1 Gi0/1 while running debug eigrp fsm (or watch show ip eigrp topology active) to see R1 go active and query R3 and R5. Bring the interface back up.
  5. The ticket says the documented delays must stay, so the fix is to remove the undocumented delay 2 from R3 Gi0/2. Verify that R3 is back as a feasible successor and both paths are in the routing table.

Reading exercise (SIA). Without injecting anything, answer from the show ip eigrp topology active output in this page: which router should you log in to next, and what three commands do you run there? (Answer: R3, then show ip eigrp topology active, show ip eigrp neighbors to check Q Cnt and RTO toward its own neighbors, and show interfaces on the links that still owe replies.)

Quick check

R1's FD to a prefix is 3072. Neighbor A reports RD 2816 with total 3328. Neighbor B reports RD 3072 with total 5632. Which are feasible successors?

Only A. Its RD 2816 is less than 3072. B's RD equals the FD, which fails the strict "less than" condition, even though B's path might work.

A route goes active on R1. R1 logs SIA and resets neighbor R3. Is R3 the router to fix?

Not necessarily. R3 is the neighbor that did not reply, but it may itself be waiting for a reply from further away. Follow show ip eigrp topology active hop by hop to the router or link that is really stuck.

Name two ways to stop queries from reaching 200 branch routers.

Configure the branches as stub routers, and summarize the core address space toward the branches (and the branch space toward the core), so routers with only a summary reply immediately.

References