An EIGRP adjacency forms, then resets repeatedly while routes are being exchanged, although hellos flow normally both ways; what does that point to, and how do you confirm it?

## The symptom, stated precisely Two EIGRP routers see each other's hellos. The neighbour comes up, the routers start exchanging routes, and some time later the neighbour is reset. It forms again almost at once, because hellos are still arriving, and the cycle repeats. The routing table never settles. A hold-time expiry would look different: hellos would have to stop first. ## What hellos do and do not prove EIGRP's **Reliable Transport Protocol (RTP)** treats packets differently (RFC 7868 section 5.2): - `HELLO` packets are **multicast**, small, and sent **unreliably** with sequence number 0. Losing one costs nothing, because the next one replaces it. - `UPDATE`, `QUERY` and `REPLY` packets are **reliable**: each carries a sequence number and stays on a per-neighbour retransmission list until that neighbour acknowledges it. - Acknowledgements are always **unicast**, and retransmissions on a LAN are unicast too. So hellos arriving prove one narrow thing: small multicast packets get through. They do not prove that unicast works in either direction, that large packets survive, or that acknowledgements return. ## Why the neighbour is reset RFC 7868 requires that a packet that is not acknowledged be retransmitted, and says each packet is tried **16 times**; if there is still no acknowledgement, "the neighbor relationship is reset with the peer that didn't send the ACK". EIGRP has no periodic route refresh to fall back on, so it cannot simply carry on with a neighbour whose state may be wrong. Then hellos rediscover the neighbour, the startup exchange begins again, the same packet fails the same way, and the reset repeats. ## The usual causes | Cause | Why hellos still work | What the exchange shows | |---|---|---| | Unicast blocked or broken in one direction | hellos are multicast | the empty INIT-flagged first UPDATE or its acknowledgement never arrives; the neighbour may never leave pending | | MTU mismatch, or a path that drops large packets | hellos are small | the first full-sized UPDATE of the table exchange is retransmitted unanswered | | Heavy loss or congestion on the link | an occasional lost hello is replaced by the next one | many retransmissions; some packets eventually exhaust their tries | | A neighbour too slow to keep up | hellos need little work | a growing retransmission queue for that one neighbour | The MTU case deserves a note. RFC 7868 says EIGRP does not use network-layer fragmentation; it sends packets no larger than the interface MTU. If the two ends disagree about the MTU, or something in the middle carries less, the largest UPDATEs are dropped every time, while hellos and small packets pass. The startup exchange is where the largest packets appear, which is why the failure shows up "while routes are being exchanged". ## How to confirm it 1. **Read the per-neighbour transport state.** Most implementations show each neighbour's retransmission queue length and the last sequence number. A queue that grows and never drains for one neighbour points at reliable delivery to that neighbour. 2. **Capture IP protocol 88 on both routers.** Look for the same sequence number sent again and again by unicast, and check whether a packet with a matching acknowledgement number ever comes back. Seeing it leave one router and never arrive at the other localises the loss. 3. **Test unicast reachability** between the two interface addresses in both directions, separately from multicast. 4. **Test packet size.** Send the largest packet the interface MTU allows, with fragmentation disallowed, across the link. If it fails while smaller ones pass, align the MTU on both ends or fix the device in the path. 5. **Check the link itself** for errors and drops, and check the implementation's pacing setting: EIGRP paces from the interface's configured bandwidth (RFC 7868 section 5.2.1 describes a default of 50% of it), and a figure far above the real link can make EIGRP drop its own packets. ## What it is not - **Not a hold-time problem.** Raising hold or hello timers does not help, because the reset comes from the retry limit, not from missing hellos. - **Not stuck-in-active.** A stuck-in-active reset comes from the route computation waiting too long for a REPLY to a QUERY, on an active timer that common implementations set in minutes; a retry-limit reset comes from transport, from any reliable packet of any type that never gets acknowledged. - **Not an adjacency mismatch.** Mismatched autonomous system numbers or metric weights stop the neighbour forming at all; here it forms and then fails. ## Why this is a senior question The diagnosis rests on knowing that EIGRP sends different packet types with different delivery guarantees, and that a healthy-looking signal (hellos) can coexist with a broken one (reliable unicast). Candidates who know only "neighbours use hellos" will chase timers; candidates who know the transport will go straight to unicast and packet size.