skip to content

When two EIGRP routers first become neighbours, why do they exchange full tables by unicast when later updates are partial multicasts?

level: middleimportance: should knowfreq 15%

answer

  1. a new neighbour knows nothing yet
  2. an empty first packet with a flag
  3. pending before up
  4. proving unicast works both ways
  5. a flag that ends the table

basics

~20 s

A new EIGRP neighbour has no topology to apply changes to, so each router sends it the full table by reliable unicast, after an empty INIT-flagged UPDATE proves unicast works both ways. Once synchronised, only changes are multicast.

solid answer

~50 s

Partial updates only work against a shared starting point, and a new neighbour has none. RFC 7868 therefore starts every adjacency with a full exchange. When a router hears a `HELLO` from an unknown neighbour, it puts that neighbour in a **pending** state and unicasts a **NULL UPDATE**: no routes, `INIT` flag set. Hellos have proved only that multicast arrives; the NULL UPDATE and its unicast acknowledgement prove unicast works in both directions, and only then does the neighbour move to **up**. Each router then sends its whole topology table in reliable unicast `UPDATE` packets addressed to the new neighbour alone, so neighbours already in sync on the same LAN are not disturbed. The `EOT` flag can mark the end of that table. From then on, the two routers exchange only changes, multicast and acknowledged.

go deeper

for a junior

Recall that a new EIGRP neighbour gets the full table once, by unicast, and only changes after that.

for a middle

Walk the handshake: hello, pending state, empty INIT-flagged UPDATE, acknowledgement, up, then reliable unicast UPDATEs with the full table and the startup poison back.

for a senior

Connect it to operations: every adjacency flap costs a full-table transfer, and a neighbour stuck before up with healthy hellos points at unicast delivery, not routing.

for a principal

Judge how adjacency stability and table size interact: in a large domain an unstable link costs repeated full exchanges, which is an argument for summarisation and for damping link instability.

## Why partial updates need a starting point EIGRP's **partial updates** say "this destination changed". That only makes sense to a router that already holds everything else. A router that has just discovered a neighbour knows none of that neighbour's routes, and EIGRP has no periodic refresh that would eventually fill them in. So every new adjacency begins with a **full exchange of topology tables**, and only then switches to incremental updates. RFC 7868 section 4.1: "When a new neighbor is discovered, unicast UPDATE packets are used to transmit a full table to the new neighbor." Neighbour discovery itself, the hello and hold timers and the checks two routers must pass before they become neighbours, are a separate subject; this question starts at the moment a hello from an unknown router is accepted. ## The handshake before any routes move RFC 7868 sections 5.3.3 and 5.3.5 describe a three-way handshake: 1. Router A receives the first multicast `HELLO` from router B. Multicast delivery from B to A is now proven. 2. A places B in the **pending** state and unicasts a **NULL UPDATE**: an UPDATE that contains no topology information, with the **INIT-Flag** (`0x01`) set. It is sent reliably, with a sequence number. 3. While B is pending, A sends it neither a QUERY nor an UPDATE beyond that first one. If A's own routes go active meanwhile, B is left out of the query process and is not expected to reply. 4. B acknowledges by unicast. A moves B from **pending** to **up**. Unicast now works in both directions. The INIT-Flag also instructs the receiver to advertise its own routes, so B answers with an INIT-flagged UPDATE of its own. The flag earns its keep in one awkward case: a neighbour that reboots and returns before its hold time expires. The surviving router never noticed the outage, but the INIT-Flag tells it the neighbour has lost its state and needs the full table again. ## The full exchange Once the neighbour is up, each router sends its **entire topology table** in **reliable unicast** UPDATE packets, as many as needed, each sized not to exceed the interface MTU because EIGRP does not rely on fragmentation. Each packet is acknowledged individually. RFC 7868's figure 9 shows the sequence: | Step | Packet | Sequence / Ack | Note | |---|---|---|---| | 1-2 | HELLO, both ways | 0 / 0 | multicast, unreliable | | 3 | B to A: UPDATE, INIT | 10 / 0 | unicast; B queues its next UPDATE | | 4 | A to B: UPDATE, INIT | 100 / 10 | acknowledges B's packet 10 | | 5 | B to A: UPDATE | 11 / 100 | B's routes; acknowledges A's packet 100 | | 6 | A to B: ACK | 0 / 11 | lost in the example | | 7 | B to A: UPDATE, retransmitted | 11 / 100 | A discards the duplicate | | 8 | A to B: ACK | 0 / 11 | both routers synchronised | Two details from the same RFC: - **Startup poison.** For each destination a router receives during startup, it advertises the same destination back to the new neighbour with a **maximum metric** (section 5.4.2.1), so neither side can use the other as a path back to a route it supplied. - **End of table.** The **EOT-Flag** (`0x08`) marks the end of the startup exchange: it tells the neighbour that all UPDATEs have been sent. During a restart, that is the moment to remove stale routes that the neighbour did not refresh. ## Why unicast, not multicast The full table is addressed to **one** neighbour. On a LAN where three other routers are already synchronised, multicasting thousands of routes would make every one of them receive, process and acknowledge information they already have. Unicast keeps the cost on the pair that needs it. ## After the exchange Once both tables have been delivered and acknowledged, the adjacency behaves like every other: - changes go out as **partial** UPDATEs, normally **multicast** on the interface and acknowledged by each neighbour; - retransmissions to any neighbour that missed one are unicast; - nothing is resent on a timer; hellos alone keep the neighbour alive. ## What this means in practice - The cost of a new or flapping adjacency is a **full-table transfer** each time it forms. A link that flaps every minute generates a full exchange every minute, which is far more traffic than the partial updates it was designed around. - A router stuck between pending and up, exchanging hellos but never completing the NULL UPDATE handshake, points at unicast delivery between the two interfaces rather than at routing.

  • Why does the first UPDATE to a new EIGRP neighbour carry no routes at all?
    Its job is to test the path, not to carry routing. Hellos have shown only that multicast arrives. The NULL UPDATE is unicast and reliable, and so is its acknowledgement, so a returned acknowledgement proves unicast works both ways. RFC 7868 allows no further UPDATE to be sent until that first one is acknowledged, and only then does the neighbour leave the pending state.
  • What does the INIT flag achieve when an EIGRP neighbour reboots faster than its hold time?
    The surviving router never saw the neighbour go away, so it would carry on sending only incremental changes. The rebooted router's INIT-flagged UPDATE tells it the neighbour has lost its state and must be sent the full table again. RFC 7868 also notes that, unless the restart flag is set, a router receiving an INIT UPDATE must answer with its own.

saying these in an interview costs you the question

  • A new EIGRP neighbour learns routes gradually from later periodic updates.
  • The startup full table is multicast so every router on the LAN refreshes together.
  • The INIT-flagged first UPDATE carries the sender's whole routing table.
  • An EIGRP neighbour joins the query process as soon as its first hello arrives.
  • During startup an EIGRP router never advertises back a route its new neighbour sent.