skip to content

When a RIP neighbour dies silently, when do its routes leave service and the table under RFC 2453, and how does the 180/180/240 set differ?

level: middleimportance: must knowfreq 30%

answer

  1. silence is the only signal
  2. six missed updates
  3. advertised as 16 for a while
  4. timeout plus garbage collection
  5. holddown is not in the RFC

basics

~20 s

Under RFC 2453 a RIP route expires 180 seconds after its last refresh, is advertised at metric 16 while a 120-second garbage-collection timer runs, then is deleted: 300 seconds in all. The invalid/holddown/flush set of 180/180/240 is an implementation's.

solid answer

~50 s

RIP has no hello mechanism, so a router that dies without a word is noticed only by silence. RFC 2453 gives each route a **timeout**, reset by every update for it: after 180 seconds without one (six missed 30-second updates, so a single lost datagram does no harm) the route expires. Its metric becomes `16`, it leaves service, a triggered update tells the neighbours, and a 120-second **garbage-collection** timer starts; until it fires the route is still advertised at 16 so everyone hears it is gone, and a new route can replace it at any moment. Deletion comes 300 seconds after the last update. The `invalid 180 / holddown 180 / flush 240` set many implementations print is not RFC 2453's: invalid matches the timeout, holddown is an implementation mechanism the RFC never defines, and flush is counted from the last update, so the route goes 60 seconds after it turns invalid.

go deeper

for a junior

Recall the RFC 2453 numbers: updates every 30 seconds, a route expires after 180 seconds without one, and it is deleted 120 seconds later.

for a middle

Walk the silent-failure timeline: blackholing until 180 seconds, metric 16 and a triggered update, advertised during garbage collection, deleted at 300 seconds.

for a senior

Separate the RFC's timers from the invalid/holddown/flush set an implementation prints, and explain why routers sharing a segment need compatible values.

for a principal

Judge whether minutes of blackholing after a silent failure is acceptable for a network, and what failure detection outside RIP would have to provide.

## The scenario Three RIP routers sit in a line, R1-R2-R3. R1 owns 192.0.2.0/24; R2 reaches it at metric 2 via R1, and R3 at metric 3 via R2. R1 then loses power. It sends nothing more: no goodbye, no poisoned route, nothing. R2's interface toward R1 may even stay up if a switch sits between them. RIP has **no hello or keepalive packet**. The periodic 30-second update is both the route announcement and the only sign of life, so R2 can detect R1's death only by noticing that the updates have stopped. ## The two per-route timers of RFC 2453 RFC 2453 attaches two timers to every learned route: - the **timeout**, started when the route is installed and reset by every update that mentions it; if **180 seconds** pass without one, the route expires; - the **garbage-collection timer**, started when the route expires (or when its current next hop advertises it at metric 16); after **120 seconds** the route is removed from the table. The RFC explains the 180 seconds directly: a router expects to hear from each neighbour every 30 seconds, but "messages are occasionally lost", so invalidating a route on one missed message would be a mistake. 180 seconds is six update intervals. ## The timeline at R2 1. **t = 0** — R1's last update arrives; R2 resets the timeout for every route via R1. 2. **t = 0 to 180 s** — R2 still believes metric 2 via R1 and forwards packets for 192.0.2.0/24 to a dead router. They are lost. R2 also keeps advertising metric 2 to R3, which resets R3's timeout every 30 seconds. 3. **t = 180 s** — the timeout expires. R2 sets the metric to **16**, removes the route from service, sets its route change flag and sends a **triggered update**. Triggered updates for deleted routes are mandatory in RFC 2453. 4. **t = 180 to 300 s** — garbage collection. The route stays in R2's table at metric 16 and is included in every update, so any neighbour that missed the triggered update still hears it. 5. **t = 300 s** — the garbage-collection timer fires and R2 deletes the route. R3 does **not** time the route out on its own clock: R2 refreshed it until t = 180 s. R3 learns of the loss when R2's metric-16 entry arrives, and because R2 is R3's current next hop, R3 must believe it. R3 then runs its own 120-second garbage collection. If a new route to 192.0.2.0/24 appears during garbage collection, RFC 2453 says it replaces the dying one and the timer is cleared. ## The implementation timer set Many implementations print a different trio. It is an implementation's set, not the protocol's: | Name | Value | Where it comes from | Counted from | |---|---|---|---| | update | 30 s | RFC 2453 | each sending | | invalid | 180 s | matches RFC 2453's timeout | last update | | holddown | 180 s | implementation mechanism, absent from RFC 2453 | route becoming unreachable | | flush | 240 s | implementation value | last update | Two differences matter: - **Flush is not garbage collection.** It runs from the last update, so the route is deleted 240 seconds after the last update, 60 seconds after going invalid. RFC 2453's route is deleted at 300 seconds, 120 seconds after expiring. - **Holddown has no place in RFC 2453.** It is an implementation's loop-prevention mechanism that refuses some news about a destination for a while after it goes unreachable; it buys stability at the cost of convergence and belongs with RIP's loop-prevention rules. Saying "RIP's flush timer is 240 seconds" therefore quotes one implementation's value as the protocol's. ## Why it matters in operation - **Up to 180 seconds of blackholing.** Every packet sent toward the dead neighbour is lost until the timeout fires, unless the router sees the failure some other way, such as an interface going down, which implementations act on directly. - **Timers are not negotiated.** RIP messages carry no timer fields, so routers sharing a segment must be configured with compatible values; a sender slower than a receiver's timeout makes routes flap. - **Deletion is announced, not silent.** The 120 seconds exist so the bad news spreads; a router that simply forgot an expired route would leave its neighbours believing it.

  • In the RIP line R1-R2-R3, why does R3 not time out the route to R1's network on its own after 180 seconds?
    Because R2 keeps advertising the route at metric 2 every 30 seconds until R2's own timeout expires, and each of those updates resets R3's timer. R3 learns of the loss only when R2 advertises the route at metric 16; since R2 is R3's current next hop, R3 must accept the worse metric and starts its own garbage collection.
  • What ends a RIP route's garbage-collection period early?
    A new route to the same destination. RFC 2453 says that if a usable route is learned while the garbage-collection timer runs, it replaces the route being deleted and the timer is cleared, so a neighbour that still has a path restores reachability without waiting the full 120 seconds.
  • Is the holddown timer part of the RIP protocol?
    Not of RFC 2453, which defines only the update timer, the per-route timeout and the garbage-collection timer. Holddown is an implementation mechanism for loop prevention: after a route goes unreachable, some news about it is refused for a while. It trades slower convergence for fewer transient loops.

saying these in an interview costs you the question

  • RFC 2453 defines a 240-second flush timer for RIP.
  • A RIP route is removed as soon as one periodic update is missed.
  • An expired RIP route is deleted at once without being advertised.
  • Holddown is one of RIP's standard per-route timers.
  • RIP neighbours exchange hellos to detect a dead router quickly.