skip to content

On a LAN with several EIGRP neighbours, how does the Reliable Transport Protocol deliver one UPDATE reliably to all of them?

level: middleimportance: should knowfreq 18%

answer

  1. send once, collect many receipts
  2. a retransmit list per neighbour
  3. the second copy is addressed differently
  4. one slow listener must not stall the rest
  5. SEQUENCE TLV and the CR flag

basics

~20 s

The router multicasts the UPDATE once with a new sequence number and records it on every neighbour's retransmit list; each neighbour unicasts an acknowledgement of that number, and only neighbours that stay silent get unicast retransmissions.

solid answer

~50 s

EIGRP's Reliable Transport Protocol keeps a sequence number, an acknowledgement number and a retransmission queue **per neighbour**. To send an `UPDATE` on a LAN, the router increments its sequence number, multicasts the packet once to `224.0.0.10` and marks it as needing acknowledgement from every neighbour on that interface. Each neighbour unicasts back an acknowledgement equal to that sequence number, which clears the packet from that neighbour's list only. A neighbour that does not acknowledge gets **unicast** retransmissions; RFC 7868 tries 16 times and then resets that neighbour. If one neighbour is still behind when the next multicast is due, the router sends a `HELLO` with a `SEQUENCE` TLV listing that neighbour and sets the **CR flag** on the next multicast: the listed neighbour ignores it, the others accept it, and the laggard later receives both packets by unicast, in order.

go deeper

for a junior

Remember the shape: one multicast out, one unicast acknowledgement back from each neighbour, and a unicast resend only to whoever stayed silent.

for a middle

Explain the per-neighbour state (sequence number, acknowledgement number, retransmission queue), why multicasts carry acknowledgement 0, and why acknowledgements are individual rather than cumulative.

for a senior

Explain conditional receive and read the signs: growing per-neighbour retransmission queues, unicast retransmissions to one router, then a reset after 16 tries while hellos still flow.

for a principal

Weigh the design: one multicast for many receivers saves bandwidth on dense segments, at the price of per-neighbour queues and an ordering mechanism that a slow neighbour can still drag on.

## The problem a LAN creates On a point-to-point link, reliable delivery is simple: send, wait for the acknowledgement, retransmit if it does not come. A multi-access LAN with several EIGRP routers is harder. Sending a separate unicast copy of every routing packet to each neighbour wastes bandwidth, but a single multicast reaches neighbours that may not all receive it. EIGRP's **Reliable Transport Protocol (RTP)**, described in RFC 7868 section 5.2, is designed for exactly this mix: it "supports intermixed transmission of multicast and unicast packets" and guarantees ordered delivery to every neighbour. ## The state RTP keeps RFC 7868 requires these to be kept **per neighbour**: - the **received sequence number** from that neighbour; - the **acknowledgement number** to send back to it; - a **transmission queue**, the list of packets that neighbour has not yet acknowledged. The sender also has one **global sequence number** that it increments for every reliable packet. Sequence number 0 is reserved for packets that need no acknowledgement, such as hellos. ## One UPDATE to three neighbours RFC 7868's example puts routers A, B, C and D on one Ethernet. 1. A increments its sequence number to 100 and **multicasts** the UPDATE with sequence 100 and acknowledgement 0. Multicast packets must carry acknowledgement 0. 2. A adds the packet to B's, C's and D's retransmit lists. 3. Each neighbour **unicasts** an ACK back: sequence 0, acknowledgement 100. 4. Each ACK removes the packet from that neighbour's list only. 5. If B's ACK does not arrive, A **retransmits by unicast** to B alone. RFC 7868 says the initial packet "is always multicast and subsequent retransmissions are unicast addressed". 6. If the acknowledgement still does not come after 16 tries, A resets its neighbour relationship with B. Acknowledgements are not cumulative and there is no window: each acknowledgement confirms exactly one packet, and a receiver drops anything out of order. ## When one neighbour falls behind: conditional receive Suppose B is still missing packet 100 when a new change requires A to multicast packet 101. If B accepted 101 now, it would hold 101 without 100, out of order. Waiting for B would hold up C and D. RTP solves this with **conditional receive**: 1. A sends a multicast `HELLO`, unreliably, carrying a `SEQUENCE` TLV. The TLV lists the neighbours that still have unacknowledged packets queued, here only B. 2. Each receiver looks for its own address. A neighbour that is **not** listed (C and D) enters **Conditionally Received mode** (CR-mode). A neighbour that **is** listed (B) does not. 3. A multicasts packet 101 with the **CR-Flag** (`0x02`) set in the header. 4. C and D, in CR-mode, accept and acknowledge 101. B, not in CR-mode, must discard it without acknowledging. 5. A later unicasts 100 and then 101 to B. B acknowledges each, and A clears both from B's list. If every neighbour on the interface has a full queue, RFC 7868 says to reschedule the multicast until the queues drain. (One sentence in RFC 7868's walk-through of this example says B "enters CR-Mode"; the SEQUENCE TLV definition in section 6.7.3 and the figure itself both say the listed neighbour does not, and the behaviour above follows those.) ## How the pieces fit | Situation | Addressing | Acknowledged? | |---|---|---| | First transmission of an UPDATE or QUERY on a LAN | multicast | yes, by each neighbour | | Retransmission to a neighbour that missed it | unicast | yes | | Acknowledgement | unicast | no | | HELLO carrying a SEQUENCE TLV | multicast | no | ## Pacing RTP also controls how fast it sends. RFC 7868 section 5.2.1 describes a default limit of **50% of the bandwidth an interface reports** for EIGRP's packet pacing. If an operator has configured an interface bandwidth that does not match the physical link, the pacing is computed from the wrong number: the RFC warns that EIGRP may then generate more traffic than the interface can handle, causing drops of its own packets, or leave little bandwidth for user data. An **interface-pacing timer** governs when the next packet may go out. ## Why this matters operationally - A neighbour with a growing retransmission queue is the early sign of a delivery problem, long before the 16-try reset. - Hellos flowing normally say nothing about reliable delivery: they are unacknowledged multicasts. - Because there is no periodic route refresh, a neighbour that cannot complete reliable delivery is reset rather than left with a silently stale table.

  • What exactly does the SEQUENCE TLV in an EIGRP HELLO list?
    It lists the neighbours that should not enter Conditionally Received mode: the ones that still have unacknowledged packets queued. Every other neighbour that receives the hello enters CR-mode and accepts the next multicast with the CR flag set. The listed neighbours discard that packet without acknowledging it and receive it later by unicast, after the packets they are missing.
  • What happens when an EIGRP neighbour never acknowledges a reliable packet?
    The sender keeps the packet on that neighbour's retransmission list and retransmits it by unicast. RFC 7868 says each packet is tried 16 times; if there is still no acknowledgement, the neighbour relationship is reset, and the routes learned through that neighbour are withdrawn.
  • Why does EIGRP drop an out-of-order packet instead of buffering it?
    RTP has no windowing: each acknowledgement confirms one packet, and the sender delivers strictly in order to each neighbour. Dropping an out-of-order packet keeps the receiver simple; the sender still has it queued and retransmits it after the missing earlier one, so order is restored.

A teacher hands one printed notice to the whole class and ticks each student's name as they sign for it, then walks over to the few who did not sign and hands each a personal copy. The notice is announced once to everyone; only the follow-up is individual.

saying these in an interview costs you the question

  • EIGRP unicasts a separate copy of every UPDATE to each neighbour on the LAN.
  • EIGRP retransmissions are multicast again so every neighbour gets a second copy.
  • One slow EIGRP neighbour stalls all multicasts until it acknowledges.
  • EIGRP acknowledgements are multicast so every router sees who received what.
  • An EIGRP neighbour that never acknowledges is retried indefinitely.