Which events end an EIGRP adjacency, and why can a neighbour that dies behind a switch take far longer to notice than a cut cable?

## Why detection time matters Routes through an EIGRP neighbour stay in use until the router knows the neighbour is gone. Only then does **DUAL**, EIGRP's route computation, switch to a backup path or start asking other routers for one. However fast that computation is, it cannot begin before the failure is detected, so detection is often the largest part of convergence. Knowing which event will end the adjacency, and how long it takes, is the first step in predicting a failover. ## Four ways an adjacency ends | Event | What detects it | How long it takes | |---|---|---| | The local interface goes down | The router's own interface state | Implementations act at once | | The neighbour goes silent | Hold-time expiry (RFC 7868 §5.3.1) | Up to the hold time the neighbour advertised; 15 s by default | | Reliable packets go unacknowledged | Retransmission limit (RFC 7868 §5.2) | After 16 retransmissions without an acknowledgement | | The neighbour announces a reset | Peer-termination TLV in a hello (RFC 7868 §6.7.7) | As soon as the hello arrives | A restart is a fifth, related case: if a neighbour reboots and comes back before its old hold time expires, its first update carries the **INIT** flag, which tells the router to resynchronise from scratch instead of trusting the old state. ## The switch in the middle Compare two topologies: - **A direct cable.** Router A connects straight to Router B. B loses power, A's interface loses its link, and A drops B at once. - **A switch between them.** A connects to a switch, and so does B. B loses power, but A's port to the switch stays up. Nothing tells A that anything happened; B has simply gone quiet. In the second case, on a quiet link, A learns of the failure only when the hold time B last advertised runs out: up to 15 seconds with RFC 7868's defaults. The same applies to a provider Ethernet hand-off, a media converter, or any path where the far end can fail without taking the near link down. There is a mirror-image trap. Hellos and acknowledgements prove that the neighbour's **EIGRP process** is alive, not that it **forwards** traffic. A router whose forwarding has failed while its control plane still sends hellos keeps its adjacencies, and traffic is black-holed until something outside EIGRP notices. ## The other two signals - **Retransmission limit.** Suppose B's multicast hellos still reach A, but unicast packets from A to B are lost. A's hold timer for B keeps being reset, so it never expires; instead, an update A sends to B goes unacknowledged, and after 16 retransmissions RFC 7868 resets the neighbour. The next hello then rediscovers B, and the cycle repeats, which is why a one-way fault shows up as a neighbour that keeps coming back and dropping again. - **An announced reset.** RFC 7868 defines a **peer-termination TLV** that a router puts in a hello to tell the listed neighbours it is resetting or shutting down their adjacency, so they can act at once instead of waiting out the hold time. The RFC notes that older implementations sent the same signal as a Parameters TLV with every K-value set to 255 (K6 excepted). A receiver reads that as a K-value mismatch, so a single mismatch message at the moment a neighbour shuts down is not a configuration fault. ## Making detection faster 1. **Shorten the timers together.** Lower the hello interval and the hold time on the same router, keeping the hold time at about three hellos. The cost is more hellos on every interface, more processing, and a higher chance of false drops when the control plane is busy or hellos queue behind traffic. 2. **Accept the floor.** RFC 7868 carries the hold time in whole seconds, so hellos cannot deliver sub-second detection; one second is the smallest non-zero hold time a router can advertise. 3. **Hand liveness to a dedicated detector.** Bidirectional Forwarding Detection (BFD, RFC 5880) runs fast liveness checks that a routing protocol can subscribe to, and it is the usual answer when failover must beat a second. 4. **Prefer failures that show as link-down.** Where the design allows, a direct routed link turns a silent failure into an immediate one. ## Where answers go wrong - Claiming a dead neighbour is always found within one hello interval. - Assuming the router sees a failure behind a switch as a link going down. - Treating arriving hellos as proof that the neighbour forwards traffic. - Reading every K-value mismatch message as a configuration error.