How does an EIGRP router discover its neighbours on a link, and how does it notice that one has disappeared?
answer
- a small periodic packet
- a multicast group of its own
- the sender decides how long it counts
- any packet restarts the clock
basics
~20 sAn EIGRP router multicasts hello packets to 224.0.0.10, by default every 5 seconds, and lists each sender in its neighbour table. Each hello advertises a hold time, 15 seconds by default; a neighbour silent for that long is declared down.
solid answer
~40 sAn EIGRP router sends **hello** packets out of every interface it runs EIGRP on, directly in IP as protocol `88` and multicast to `224.0.0.10` (`FF02::A` over IPv6). RFC 7868's default is one hello every 5 seconds. A router that hears a hello from an unknown address adds the sender to its **neighbour table**, holds it as pending until unicast delivery is proven in both directions, then brings it up. Each hello also advertises a **hold time**, three hello intervals or 15 seconds by default. The receiver times the neighbour out on that advertised value, and any packet from the neighbour restarts the clock; if it runs out, the neighbour is removed and DUAL recomputes the routes that used it.
go deeper
Recall the core facts: hellos over IP protocol 88 to 224.0.0.10, every 5 seconds by default, and a hold time of three hello intervals. Say what the neighbour table records.
Explain that the hold time is advertised by the sender and applied by the receiver, and that any packet from the neighbour resets it. Mention the pending state a new neighbour passes through before it is up.
Connect discovery to failover: a dead neighbour behind a switch is found only when its hold time expires, so detection time is a design input, and the timers that matter are the ones the neighbour advertises.
Treat hello-based liveness as one option among several: weigh tighter timers against control-plane load and false drops, and decide where an external failure detector earns its place.
## What EIGRP needs neighbours for EIGRP (Enhanced Interior Gateway Routing Protocol) is an advanced distance-vector routing protocol: a router learns routes only from routers directly attached to it. Before it can exchange a single route it has to know **who its neighbours are**, and afterwards it has to know **whether they are still alive**. RFC 7868, an Informational RFC published in 2016 when the protocol's originator documented what had until then been one vendor's protocol, calls this **neighbor discovery/recovery**. One small packet does both jobs: the **hello**. ## How hellos find neighbours When EIGRP is enabled on an interface, the router starts sending hellos out of it straight away. - **Transport.** EIGRP runs directly over IP as **IP protocol 88**, with no TCP or UDP in between. IPv6 uses the same protocol number. - **Destination.** On a multicast-capable link a hello goes to the IPv4 group **224.0.0.10** ("EIGRP Routers"), or to **FF02::A** over IPv6, so every EIGRP router on the segment hears it without any per-neighbour configuration. Where multicast is not available, hellos can be sent unicast to a neighbour configured by address. - **Interval.** RFC 7868 gives a default of **one hello every 5 seconds** and notes that an implementation may let the interval be configured. - **Contents.** Each hello carries a **Parameters TLV** holding the sender's metric weights (the **K-values**) and its **hold time**. When a router receives a hello from an address it does not yet know, it creates an entry in its **neighbour table**: the neighbour's address, the interface it was heard on and the hold time it advertised. The new neighbour first sits in a **pending** state while the two routers prove that unicast as well as multicast delivery works between them; only then does it move to **up** and begin exchanging routes. That route exchange belongs to EIGRP's reliable update machinery, not to discovery. ## The hold time: how a neighbour is declared gone The **hold time** is the number of seconds a receiving router should keep treating the sender as reachable and operational. Two details make it different from what many people expect: 1. **The sender chooses it.** Router A's entry for Router B times out on the hold time **B advertised**, not on a value configured on A. By default it is **three times the hello interval**: 15 seconds with 5-second hellos. 2. **Any packet resets it.** RFC 7868 says that if any packet, not only a hello, arrives from the neighbour within the hold time, the hold time starts again. If the hold time runs out with nothing received, the neighbour is removed and **DUAL**, EIGRP's route computation, is told about the topology change; it then recomputes the routes that went through that neighbour. ## Defaults and whose they are | Item | Value | Where it is stated | |---|---|---| | IP protocol number | 88 | RFC 7868 §6.1 and its IANA section | | IPv4 hello destination | 224.0.0.10 | RFC 7868 §4 | | IPv6 hello destination | FF02::A | RFC 7868 §4 | | Hello interval | 5 s by default | RFC 7868 §5.3.2 | | Hold time | 3 x hello interval by default (15 s) | RFC 7868 §5.3.2 | Implementations may choose other defaults on particular link types, such as a longer interval on slow multipoint links; those are implementation choices, not RFC 7868 values. ## What a hello is not - **Not reliable.** Hellos are sent unacknowledged with a sequence number of 0. Losing an occasional hello costs nothing, because the default hold time spans three hello intervals. - **Not OSPF's or RIP's.** OSPF hellos go to 224.0.0.5 over IP protocol 89; RIPv2 uses the group 224.0.0.9 over UDP port 520. Mixing these up is a classic slip. - **Not a routing update.** A hello carries no routes; it only establishes that a neighbour exists, which parameters it uses and how long to believe it. ## Why this matters in practice Hellos and the hold time are EIGRP's main built-in liveness check. If a neighbour loses power while the link to it stays up, for example because a switch sits between the two routers, then on a quiet link it is the hold time running out that notices, and that takes up to 15 seconds with defaults. When the router's own interface goes down, implementations act on that at once instead of waiting. Knowing which of the two cases you are in tells you how long a failover takes before EIGRP even starts recomputing routes.
- Does an EIGRP neighbour have to keep sending hellos to stay up while it is busy sending updates?No. RFC 7868 resets the hold time on any packet received from the neighbour, not only on hellos, so updates, queries and acknowledgements also keep it alive. Hellos matter on a quiet link, where they are the only traffic; with default timers a neighbour that sends nothing at all for 15 seconds is removed.
- How do EIGRP routers find each other on a link that cannot carry multicast?RFC 7868 allows hellos to be sent to a neighbour's unicast address instead of 224.0.0.10. The neighbour has to be configured by address, because nothing is discovered automatically. Once hellos flow, the neighbour table, the advertised hold time and the adjacency checks work exactly as they do on a multicast link.
The hold time works like a parking meter the neighbour feeds itself: every hello, or any other packet it sends, tops the meter back up to the amount the neighbour chose, and when the meter runs out the router removes the neighbour's entry. The router never sets the meter; it only reads what the neighbour paid for.
saying these in an interview costs you the question
- EIGRP hellos ride in UDP or TCP, the way RIP and BGP packets do.
- EIGRP hellos go to 224.0.0.5, the same group OSPF uses.
- An EIGRP neighbour is dropped as soon as a single hello is missed.
- Each router times out its neighbours using its own configured hold time.
- EIGRP hellos are acknowledged, so a lost hello gets retransmitted.