skip to content

In EIGRP, what makes routing updates partial and bounded, and how does that differ from RIP's periodic full-table updates?

level: juniorimportance: must knowfreq 42%

answer

  1. triggered, not timer-driven
  2. what one UPDATE actually carries
  3. where the ripple stops
  4. a receipt from each neighbour
  5. RIP's thirty-second habit

basics

~20 s

EIGRP sends an UPDATE only when a route is added or its metric changes, carries only those prefixes, and the change stops spreading where no router's best path changes; RIP resends its whole table every 30 seconds.

solid answer

~40 s

EIGRP has no periodic route refresh. A router sends an `UPDATE` only when a destination is added or its metric changes, and the packet carries only those prefixes: that is the **partial** part. Propagation is **bounded** because a neighbour whose own best distance did not change has nothing to send, and summarisation or filtering hides the change beyond a boundary. Each UPDATE travels over EIGRP's Reliable Transport Protocol and is acknowledged by every neighbour, so it is sent once instead of being repeated; small unreliable hellos are what keep proving the neighbour is alive. RIP (RFC 2453) instead sends its complete table to every neighbour every 30 seconds. Its triggered updates are unacknowledged, so that periodic copy is its only repair for a lost one.

go deeper

for a junior

Recall the contrast in one breath: EIGRP sends only changed routes, only when they change, and stops where nothing changed; RIP sends its full table every 30 seconds.

for a middle

Explain how EIGRP separates liveness (hellos) from routing information (UPDATEs), and why acknowledged delivery is what lets it drop the periodic refresh that RIP depends on.

for a senior

Walk a real flap through the domain: what each router sends, where a summary or an unchanged best path stops it, and what happens if reliable delivery breaks with no periodic copy to fall back on.

for a principal

Frame the trade: near-zero steady-state overhead and change-proportional traffic in exchange for per-neighbour transport state, and failure domains you create deliberately with summarisation.

## Why periodic full tables were the default A **distance-vector** routing protocol tells each neighbour its distance to every destination it knows. The oldest way to keep neighbours in sync is brute force: send everything, on a timer, forever. **RIP** (RFC 2453, section 3.8) does exactly this. Every 30 seconds each router sends an unsolicited Response containing its **complete routing table** to every neighbouring router, over UDP port 520. A route that is not refreshed for 180 seconds times out. The periodic copy is doing two jobs at once: it carries routing information, and it is the only proof that the neighbour is still there. The cost scales with the size of the table, not with the rate of change. A domain whose routes have not moved for a week still sends every route, from every router, every 30 seconds. ## What "partial" means in EIGRP **EIGRP** is also a distance-vector protocol, described in RFC 7868, an **Informational** RFC published in 2016 for what had been one vendor's protocol. It separates the two jobs RIP's timer does: - **Liveness** belongs to small `HELLO` packets, multicast to `224.0.0.10` every 5 seconds by default (an implementation value that can be configured). They carry no routes. - **Routing information** travels in `UPDATE` packets, which RFC 7868 section 3.4 says are sent "to indicate a change in metric or an addition of a destination". There is no timer that resends routes. So an UPDATE is **partial**: it carries one TLV per destination that changed, not the table. Each TLV is processed individually by the receiver's route computation. ## What "bounded" means **Bounded** describes how far a change travels. A receiving router runs the changed destination through its own computation. If its own best distance to that destination did not change, it has nothing new to say and sends no UPDATE of its own, so the ripple stops there. RFC 7868 section 3.1 describes the deliberate version of the same effect: hiding reachability information through **summarisation** or **filtering** controls how far a change spreads and creates failure domains inside one autonomous system. Split horizon adds a local bound: a router does not advertise a route back out of the interface toward the neighbour it uses to reach that destination. ## One stub network flapping in a 50-router domain Take a 50-router EIGRP domain. Router R17 has a stub LAN, `10.50.7.0/24`, that goes down and comes back. A distribution router upstream advertises only a summary, `10.50.0.0/16`, toward the core. 1. The LAN goes down. R17 has no other path, so the loss is handled by the algorithm's query-and-reply exchange (a separate subject); those QUERY packets carry the one prefix and are delivered reliably. 2. The LAN comes back. R17 builds one UPDATE with a single TLV for `10.50.7.0/24` and multicasts it on each interface that has neighbours. 3. Each neighbour unicasts an acknowledgement; R17 retransmits by unicast only to a neighbour that has not acknowledged. 4. A neighbour whose best distance to the prefix changed sends its own UPDATE onward, again carrying one prefix. 5. At the distribution router the summary is still reachable with an unchanged metric, so there is typically nothing new to report beyond it. The core never hears about the flap. 6. Thirty seconds later, nothing is sent. The next routing packet appears only at the next change. ## Side by side | | RIP (RFC 2453) | EIGRP (RFC 7868) | |---|---|---| | When routes are sent | every 30 s, plus triggered updates | only when a route is added or its metric changes | | What is sent | the complete table | only the changed destinations | | Delivery | UDP, unacknowledged | IP protocol 88, acknowledged and retransmitted | | Liveness | the periodic update itself; routes time out after 180 s | separate hellos and a hold time | | How far a change spreads | every router re-advertises its table anyway | stops where no best path changes, or at a summary | RIP does have **triggered updates** (RFC 2453 section 3.4.4): implementations must send them for deleted routes and may for changed ones, at a limited rate. The difference is not that RIP is blind to changes; it is that RIP's triggered updates are unacknowledged, so the periodic full table remains the safety net. EIGRP removes the safety net and replaces it with reliable delivery. ## What this buys and what it costs - **Buys:** steady-state routing traffic close to zero, change traffic proportional to the change, and convergence that does not wait for a timer. - **Costs:** per-neighbour transport state (sequence numbers, acknowledgement numbers, retransmission queues), and a dependency on that transport working. If reliable delivery fails, nothing periodic will quietly repair the table; RFC 7868 resets the neighbour relationship instead. - **Pacing:** RFC 7868 section 5.2.1 describes a default cap of 50% of the interface's configured bandwidth for EIGRP's own packets, so a burst of updates cannot starve user traffic.

  • If EIGRP never resends routes on a timer, how does a router notice that a neighbour's routes have gone stale?
    Liveness is separate from routing. Hellos arrive every 5 seconds by default and advertise a hold time, by default three times the hello interval; any packet from the neighbour resets it. When the hold time expires, the router tells its route computation the neighbour is gone and its routes are withdrawn. A reliable packet left unacknowledged after the RFC's 16 retransmissions also resets the neighbour.
  • Why does RIP still need its periodic full table when it also sends triggered updates?
    RIP's triggered updates are unacknowledged UDP datagrams and must be rate-limited, so one can be lost or delayed. Nothing tells the sender, and the next periodic Response is what repairs the neighbour's table. The periodic update is also RIP's liveness signal: a route not refreshed for 180 seconds times out.
  • Does bounded mean an EIGRP UPDATE reaches only the routers on the changed path?
    Not literally. An UPDATE is multicast to every neighbour on an interface, so all of them receive and acknowledge it. The bound comes next: each receiver re-advertises only if its own best distance changed, split horizon keeps it off the interface toward the successor, and a summary or filter stops it at a boundary.

saying these in an interview costs you the question

  • EIGRP refreshes its whole table on a slow timer, like a gentler RIP.
  • Partial means EIGRP sends a portion of its table in each update cycle.
  • Bounded means EIGRP updates expire after a fixed hop limit, like RIP's 15 hops.
  • RIP has no triggered updates, so it always waits for the next 30-second cycle.
  • A lost EIGRP UPDATE stays lost until the next hello repairs it.
  • EIGRP hellos carry routes so that neighbours stay in sync.