skip to content

Which EIGRP packet types are sent reliably and which are not, and how does EIGRP carry an acknowledgement?

level: middleimportance: must knowfreq 30%

answer

  1. which packets need a receipt
  2. sequence number zero
  3. a hello with a nonzero ack field
  4. acknowledgements can ride along

basics

~20 s

EIGRP sends UPDATE, QUERY and REPLY packets, with their SIA sub-types, reliably: each carries a nonzero sequence number that must be acknowledged. HELLOs go unreliably with sequence 0, and an ACK is a HELLO with no data and a nonzero acknowledgement number.

solid answer

~40 s

RFC 7868 sends anything that changes routing state reliably: `UPDATE`, `QUERY` and `REPLY`, plus the `SIA-QUERY` and `SIA-REPLY` sub-types used for long-running active routes. Each carries the sender's 32-bit sequence number and sits on a per-neighbour retransmission list until that neighbour acknowledges it. `HELLO` packets are not reliable: they carry sequence number 0, and a lost one is simply replaced by the next. There is no separate ACK opcode in use: an acknowledgement is a `HELLO` with no data and a nonzero acknowledgement number, always unicast, and it can also be piggybacked on another unicast packet, such as a REPLY that acknowledges the QUERY it answers. Acknowledgements are not cumulative: each acknowledges exactly one packet.

go deeper

for a junior

Remember the split: UPDATE, QUERY and REPLY must be acknowledged; HELLOs are not, and an ACK is just a hello with an acknowledgement number.

for a middle

Explain the header mechanics: sequence 0 means unreliable, a nonzero acknowledgement number appears only in unicast packets, acknowledgements acknowledge one packet each and can be piggybacked on a REPLY or UPDATE.

for a senior

Use the split to diagnose: hellos flowing proves only that small multicast gets through, while reliable packets retransmitted without acknowledgement point at unicast delivery or packet size and end in a neighbour reset.

for a principal

Be ready to argue why selective reliability is the right design for a protocol with no periodic refresh, and what that costs in per-neighbour state as neighbour counts grow.

## Why EIGRP needs to know which packets are reliable EIGRP's route computation assumes, in the words of RFC 7868 section 5.2, "lossless communication between devices". It never resends routes on a timer, so a lost routing message would leave a neighbour wrong indefinitely. The **Reliable Transport Protocol (RTP)** inside EIGRP closes that gap by guaranteeing ordered delivery of the packets that matter. EIGRP runs directly over IP as **protocol 88**, not over TCP or UDP, so this reliability is EIGRP's own. RFC 7868 is an **Informational** RFC describing what was one vendor's protocol. RTP is selective: reliability costs per-neighbour state and an acknowledgement for every packet, so it is provided "only when necessary". ## The packet types and their opcodes Every EIGRP packet starts with a fixed header: version (currently 2), **opcode**, checksum, flags, a 32-bit **sequence number**, a 32-bit **acknowledgement number**, a virtual router ID and the autonomous system number. | Packet | Opcode | Purpose | Reliable? | Usually addressed | |---|---|---|---|---| | `UPDATE` | 1 | new or changed destinations; the full table to a new neighbour | yes | multicast; unicast to a new neighbour and for retransmissions | | `QUERY` | 3 | a route has gone active; asking neighbours for alternatives | yes | multicast or unicast | | `REPLY` | 4 | answer to a QUERY or SIA-QUERY | yes | unicast to the querier | | `HELLO` | 5 | neighbour discovery and liveness | no (sequence 0) | multicast to `224.0.0.10` or `FF02::A` | | ACK | 5 (a HELLO) | acknowledges one packet | no (sequence 0) | unicast | | `SIA-QUERY` | 10 | checks on a neighbour still owing a REPLY | yes | to the neighbour concerned | | `SIA-REPLY` | 11 | "still active for this destination" | yes, as a REPLY sub-type | to the querier | The header also defines `REQUEST` (opcode 2), which RFC 7868 lists but does not elaborate. Opcode 8 is marked **reserved**, with the old name `EIGRP_OPC_ACK` in parentheses: the ACK is not a packet type of its own any more. ## How a packet is marked reliable or not The rules in RFC 7868 section 5.2 are short: 1. A sender puts its own **global sequence number** in every packet that needs acknowledging. The number wraps to 1, because **sequence number 0 is reserved for unreliable transmission**. 2. Any packet that does not need acknowledging is sent with sequence number 0. That is why every HELLO has sequence 0. 3. The **acknowledgement number** carries the receiver's sequence number being acknowledged. A value of 0 means "nothing acknowledged here". 4. A nonzero acknowledgement number may appear **only in unicast packets**; network-layer multicast packets must carry 0. 5. A `HELLO` whose acknowledgement number is nonzero is decoded as an **ACK**, not as a hello. ## Piggybacking and individual acknowledgement An acknowledgement does not always need its own packet. When a router has a unicast packet to send anyway, it writes the acknowledgement into that packet's header. RFC 7868's example: router B multicasts a QUERY with sequence 101; router A answers with a unicast REPLY carrying sequence 201 and acknowledgement 101. That one packet both delivers the reply and acknowledges the query. B then sends a bare ACK (sequence 0, acknowledgement 201) for the REPLY. Two properties distinguish RTP from TCP: - **No cumulative acknowledgement.** An acknowledgement number acknowledges exactly one packet, the one whose sequence number it equals. - **No windowing.** A receiver acknowledges each packet individually and drops packets that arrive out of order; duplicates are discarded and acknowledged, so the sender stops retransmitting. ## Why hellos are left unreliable Hellos are periodic, small and self-replacing: if one is lost, the next one, by default 5 seconds later, carries the same information. Acknowledging them would add one unicast packet per neighbour per hello for no gain. On a LAN the saving is the point: one multicast hello serves every neighbour, with an indication in the packet that it need not be acknowledged. The routing packets are the opposite case: each carries a change that will never be repeated, so each must be confirmed. ## What goes wrong when reliability fails If an acknowledgement does not arrive, the packet is retransmitted by unicast to the neighbour that is missing it. RFC 7868 says each packet is tried 16 times; if there is still no acknowledgement, the neighbour relationship is reset. A neighbour can therefore be exchanging hellos normally while its reliable packets fail, a symptom worth recognising in the field.

  • Why must an EIGRP multicast packet carry an acknowledgement number of 0?
    An acknowledgement number names one specific packet from one specific neighbour, using that neighbour's sequence numbering. A multicast reaches many neighbours whose sequence numbers differ, so no single value could acknowledge for all of them. RFC 7868 therefore allows a nonzero acknowledgement only in unicast packets, and every acknowledgement is unicast back to its sender.
  • Why does EIGRP build its own reliable transport instead of running over TCP?
    EIGRP runs directly over IP as protocol 88 and needs something TCP cannot give: one multicast transmission on a LAN, acknowledged individually by every neighbour, with unicast retransmission only to those that missed it. TCP is a point-to-point byte stream. RTP keeps the sequence number, acknowledgement number and retransmission queue per neighbour instead.
  • What does an EIGRP router do with a reliable packet that arrives out of order or twice?
    RTP has no windowing, so the receiver drops an out-of-order packet and waits for the sender to retransmit in order. A duplicate is discarded but still acknowledged, because a duplicate usually means the sender never saw the first acknowledgement; acknowledging it again stops the retransmissions.

saying these in an interview costs you the question

  • EIGRP has a dedicated ACK packet type with its own opcode.
  • EIGRP hellos are acknowledged so each router knows its hellos arrived.
  • QUERY packets are best-effort because the router can always query again.
  • EIGRP gets reliable delivery by running its packets over TCP.
  • One EIGRP acknowledgement number confirms every packet up to that number, as in TCP.