Must EIGRP neighbours use the same hello and hold timers, and what breaks when a router's hello interval exceeds its advertised hold time?
answer
- who sets the deadline
- carried in the sender's own hello
- each router's own pair
- OSPF is stricter here
basics
~20 sNo. Each EIGRP router advertises its own hold time in its hellos, and neighbours time it out on that value, so timers may differ. But if a router's hello interval exceeds the hold time it advertises, neighbours drop it between hellos.
solid answer
~40 sThey need not match. The hold time travels in each hello's Parameters TLV, and the receiver times the sender out on the value the sender advertised, so Router A can send hellos every 5 seconds with a 15-second hold time while Router B uses 10 and 30. What must be consistent is **each router's own pair**: its hello interval has to sit well inside the hold time it advertises, three intervals by default in RFC 7868. If one router's hello interval is raised to 20 seconds while it still advertises 15, its neighbours expire it 15 seconds after each hello and rediscover it at the next: a flap every 20 seconds, with the neighbourship and its routes rebuilt each time. OSPF is the contrast: RFC 2328 requires matching Hello and Dead intervals.
go deeper
Remember that EIGRP neighbours may run different hello and hold timers, unlike OSPF neighbours, and that the default hold time is three hello intervals.
Explain that the receiver applies the hold time the sender advertised, and walk the timeline of a router whose hello interval is longer than the hold time it advertises.
Diagnose a periodic flap from its rhythm, find which router's own timer pair is wrong, and check whether the implementation recalculates the hold time when only the hello interval changes.
Set timer standards per link type, weighing detection speed against control-plane load and the risk of one-sided timer changes during maintenance.
## Two timers, two jobs Every EIGRP router has two liveness timers on each interface, and they belong to it, not to the link: - **Hello interval**: how often this router sends hellos. RFC 7868's default is 5 seconds. - **Hold time**: how long neighbours should consider this router valid after hearing from it. The router puts this value, in whole seconds, in the **Parameters TLV** of its own hellos. RFC 7868's default is three hello intervals, 15 seconds. A receiving router keeps one hold timer per neighbour and sets it to **the value that neighbour advertised**. RFC 7868 restarts it whenever any packet arrives from the neighbour; if it expires, the neighbour is removed and DUAL is told about the change. ## Why mismatched timers are fine Because each router is timed out on its own advertised value, two neighbours can run different timers with no problem: | Router | Sends hellos every | Advertises hold time | Its neighbour declares it down after | |---|---|---|---| | A | 5 s | 15 s | 15 s of silence from A | | B | 10 s | 30 s | 30 s of silence from B | Nothing in the adjacency checks compares these numbers between routers; RFC 7868 requires the AS number, the K-values and the authentication to agree, not the timers. **OSPF works differently**: RFC 2328 has routers on a network agree on their Hello and Dead intervals, and a mismatch prevents the neighbour relationship. Engineers who learned OSPF first often expect the same rule here. ## The pair that must be consistent What does matter is the relationship between **one router's own** hello interval and **its own** advertised hold time. The hold time must cover several hellos, so that an occasional lost hello (hellos are sent unreliably and never retransmitted) does not end the neighbourship. RFC 7868's default ratio of three is the usual rule of thumb. The trap is that the two values may be set separately. RFC 7868 describes the default hold time as three hello intervals, but whether an implementation recalculates the hold time when only the hello interval is changed is an implementation choice, and in some it does not. Raise the hello interval alone and the router may go on advertising the old hold time. ## A timeline of the fault Router A sends hellos every 20 seconds but still advertises a 15-second hold time; Router B is its neighbour on a quiet link. | Time | What happens | |---|---| | 0 s | A's hello arrives; B sets A's hold timer to 15 s | | 15 s | The timer expires; B removes A, DUAL withdraws the routes through A | | 20 s | A's next hello arrives; B treats A as a new neighbour and starts initialisation | | 20 s onward | A receives an initialisation update from a router it thought was up, so it resynchronises too; both resend their routes | | 35 s | The timer expires again, and the cycle repeats | In each 20-second cycle A is up for about 15 seconds and gone for about 5, and every return costs a full route exchange. Three details help when diagnosing it: 1. **The rhythm gives it away.** A flap whose period equals one router's hello interval points at that router's timer pair, not at the cable. 2. **The neighbour notices first.** B drops A because B applies the too-short hold time A advertised; A usually notices only when B restarts the relationship. 3. **Traffic can hide it.** Any packet resets the hold time, so while A is sending updates or acknowledgements often enough the flap pauses, and it returns when the link goes quiet. ## Fixing it and setting timers well - Change the hello interval and the hold time **together, on the same router**, keeping the hold time at about three hello intervals. - After a change, check what the router actually **advertises**, not only what was configured. - Shorter timers detect failures sooner but cost more packets and processing and raise the risk of false drops when the control plane is busy; sub-second detection is better handed to a dedicated detection protocol than squeezed out of hellos. ## Where answers go wrong - Insisting that both routers must use the same timers, which is OSPF's rule. - Assuming each router times its neighbours out on its own hold time. - Treating the hold time as negotiated to the smaller of two values, which is how BGP sets its session hold time.
- Which router logs the neighbour going down first in this fault, the misconfigured one or its neighbour?The neighbour. It applies the too-short hold time the misconfigured router advertised, so it expires that router between hellos. The misconfigured router usually notices only when the neighbour restarts the relationship and sends an initialisation update, which forces it to resynchronise too, so both logs fill, but the cause sits in the router whose own timer pair is wrong.
- Why might this flap stop for minutes at a time on a busy network?RFC 7868 resets the hold time on any packet from the neighbour, not only on hellos. While the misconfigured router sends updates, queries or acknowledgements more often than its hold time, its neighbours keep refreshing it. The flap comes back when the link goes quiet and hellos are the only traffic left.
saying these in an interview costs you the question
- EIGRP neighbours must use identical hello and hold timers or they will not peer.
- Each EIGRP router uses its own hold time to decide when its neighbours have died.
- The EIGRP hold time is negotiated down to the smaller of the two routers' values.
- Raising the hello interval alone always raises the advertised hold time too.
- A neighbour that flaps every few seconds must have a bad cable or interface errors.