EIGRP

The feasibility condition is RD < FD: a neighbor's reported distance must be smaller than my current feasible distance for that destination. Such a neighbor is a feasible successor.

Loop-freedom without a full topology view: if the neighbor were routing back through me, its own distance would have to include my link and therefore be at least as large as mine — it could never advertise a distance smaller than I have ever had. The invariant "closer than I ever was" is what makes the induction work; no LSDB-style global view is needed.

Losing a feasible successor is a purely local event: the FS is promoted to successor from the topology table, which already holds it as a precomputed loop-free backup. No queries are sent, so the route never goes Active.

A route goes Active only when the successor dies and no feasible successor exists — that is the only case where the router must ask its neighbors (diffusing computation).

The six adjacency breakers, with what to check:

1. Uncommon subnet — primary addresses must share a subnet: compare show run interface on both sides.
2. K-value mismatch — K values ride in the hello: show ip eigrp neighbors detail (or debug) shows the mismatch.
3. AS number mismatch — router eigrp <as> must match: show ip protocols.
4. Passive-interface on the facing interface: show ip protocols lists passive interfaces.
5. Multicast filtered — an ACL blocking 224.0.0.10 (or a unicast-only setup without a static neighbor): check outbound ACLs on the facing interfaces.
6. NBMA mapping — frame-relay map ... broadcast missing: show frame-relay map.

eigrp stub (connected | static | summary | redistributed | receive-only) tells neighbors this router is a leaf: it is never queried. That bounds query scope, so a core-route failure cannot cascade diffusing computations down to branches and SIA across the WAN.

The optional leak-map deliberately re-introduces an exception: specific prefixes the stub will advertise (and be queried for), for example one connected subnet that really does need to be reachable through the branch.

The classic 32-bit composite metric uses 10⁷/bandwidth, so it saturates at 1 Gbps and above: 1G, 10G and 25G links all look equally good and the protocol cannot tell them apart.

Wide metrics (named mode) are 64-bit with separate throughput and latency components, so high-speed links stay distinguishable. They are configured in named mode, under router eigrp <name> → address-family, not in classic router eigrp <as>.

Candidate FD 280 ≤ variance × best FD = 3 × 100 = 300, so the metric condition holds.

But that is not sufficient: the path must also satisfy the feasibility condition (its RD must be < FD 100). If the neighbor's reported distance is 100 or more, the path is not loop-free and is not installed — no matter what variance says. Only then does unequal-cost load sharing apply (traffic-share balanced splits inversely to metric).

EIGRP carries its own RTP directly over IP protocol 88: sequencing and acknowledgment are built in, and hellos/updates normally ride multicast 224.0.0.10 on LANs.

That embeds media assumptions: where multicast is unavailable or untracked (some NBMA media, unicast-only designs), you must configure static neighbors and lose the dynamic model; reliable-transport behavior was tuned with those link types in mind. So "run EIGRP anywhere" needs per-media workarounds that OSPF's interface network types (or IS-IS) handle more systematically — one reason OSPF/IS-IS won the multi-vendor world.

Old behavior: a query unanswered for ~3 minutes meant SIA — the neighbor adjacency was reset, taking down a router that may have been innocent.

Modern IOS: at 90 s the waiting router sends an SIA-Query, and a busy neighbor answers with an SIA-Reply ("still computing"). Only a neighbor that cannot even answer that is reset, and the stuck computation can be traced to the actual bottleneck instead of nuking the adjacency.