A RIP router reaches 198.51.100.0/24 at metric 2 via neighbour B and hears neighbour C offer metric 3; if B dies silently, how long until traffic uses C, and why?
answer
- only the best route is kept
- worse offers from others are ignored
- wait for the timeout
- then C's next periodic update
- equal metric changes the answer
basics
~20 sAbout three to three and a half minutes: RIP keeps only B's route and ignores C's worse offer until B's route times out at 180 seconds, then adopts C on C's next update, up to 30 seconds later.
solid answer
~50 sA RIP router remembers only its best route, and RFC 2453 accepts an offer from a neighbour other than the current next hop only if it is strictly better. So C's metric-3 offer, which becomes 4 on receipt, is ignored every 30 seconds while B's metric-2 route is valid, and packets are forwarded to dead B. At 180 seconds without an update B's route expires: metric `16`, out of service, garbage collection started. C's next periodic update, up to about 30 seconds later (35 with the random offset), is now better than 16, so it replaces the dying route and clears the garbage-collection timer. Outage: roughly 180 to 210 seconds. If C offered an equal metric, the RFC's optional but highly recommended heuristic switches once the timeout is halfway gone, cutting the outage to about 90 to 120 seconds; an implementation's holddown can stretch it instead.
go deeper
Recall that a RIP router keeps a single best route and notices a dead neighbour only when its updates stop for 180 seconds.
Explain why C's worse offer is ignored while B's route is valid and adopted once B's route sits at metric 16.
Build the full timeline, about 180 to 210 seconds, and show how an equal metric, a visible link failure or an implementation's holddown each change it.
Decide when minutes of failover rule RIP out for a network, and what failure detection or protocol change would earn its operational cost.
## The setup Router R reaches 198.51.100.0/24 through two neighbours: - **B** advertises it at metric 1, so R installs metric **2** via B; - **C** advertises it at metric 3, which R would hold as metric **4**. Neighbour B then fails silently: it stops sending, and R's interface toward it stays up. The question is how long R keeps sending packets into the void. ## Why the alternative sits unused RFC 2453's input rule decides everything here. When an update arrives from a neighbour that is **not** the current next hop, R adopts it only if the new metric is **strictly lower** than the one it has. C's 4 is worse than B's 2, so each of C's 30-second updates is examined and thrown away. The RFC is explicit that real implementations keep "only the best route to any given destination". There is no stored backup, no precomputed alternative and no second-best list. C's route exists in R's table only after B's has been removed from consideration. ## The timeline | Time after B's last update | What R does | Traffic | |---|---|---| | 0 to 180 s | keeps metric 2 via B; ignores C's offers | sent to B and lost | | 180 s | timeout expires: metric 16, out of service, garbage collection starts, triggered update | dropped as unreachable | | 180 s plus up to about 30 s | C's next periodic update arrives; 4 is lower than 16, so the route is replaced and the garbage-collection timer cleared | flows via C | So the outage is about **180 to 210 seconds**. The RFC's random offset of up to 5 seconds can stretch C's interval to 35 seconds, so the worst case is roughly 215 seconds. The best case is just over 180, when C's update lands right after the expiry. ## Three variants an interviewer will probe - **C offers an equal metric.** If C also offered metric 1, RFC 2453 describes an optional but "highly recommended" heuristic: when an equal-metric route arrives and the current route is at least halfway to its timeout, switch to it. The switch then happens at C's first update after 90 seconds of silence, an outage of about 90 to 120 seconds. - **The failure is visible locally.** If R's interface to B goes down, an implementation can mark the routes through it unreachable at once. The wait then shrinks to C's next update, up to about 30 seconds. - **An implementation's holddown is configured.** RFC 2453 defines no holddown, but implementations that add one refuse some news about a destination for a while after it becomes unreachable. That can keep C's route out for longer still; the trade between holddown and convergence is part of RIP's loop-prevention story. ## Why RIP is slow by design Several properties stack up: 1. **Failure is inferred from silence.** There is no hello or keepalive separate from the 30-second update, and the timeout is set at six missed updates so that lost datagrams do no harm. 2. **One route per destination.** With no stored alternative, recovery waits for an alternative to be advertised again. 3. **Propagation is one interval per hop.** Downstream routers learn of R's new path on R's own updates, or faster only through triggered updates. 4. **Timers are not negotiated.** RIP messages carry no timer fields, so shortening them means configuring every router on a segment to compatible values. ## What actually shortens it - **Equal-metric alternatives** let the halfway heuristic help. - **Faster failure detection** outside RIP, where an implementation ties route removal to it, removes the 180-second wait for silent failures. - **Shorter update and timeout values** cut the wait proportionally, at the price of more full-table traffic and processing, and only when every router on the segment agrees. - **A protocol that keeps alternatives or detects neighbours explicitly** removes the cause rather than the symptom; comparing protocol classes is a separate discussion. The honest summary for an interview: RIP converges correctly but slowly, and the slowness comes from its timers before any routing loop gets involved.
- Why can't you fix RIP's slow failover by lowering the update timer on one router?RIP timers are not negotiated: messages carry no timer fields, so each router uses its own values. Faster updates from one router do not shorten its neighbours' 180-second timeouts, and a router whose timeout is shorter than its neighbour's update interval will expire good routes and flap. Timers have to be changed consistently on every router sharing the segment.
- If neighbour C offered the RIP route at the same metric as B, how would the outage change?RFC 2453's recommended heuristic would switch to C when C's update arrives and B's route is at least halfway to its 180-second timeout. With C updating every 30 seconds, that is C's first update after 90 seconds of silence, so traffic recovers after about 90 to 120 seconds instead of 180 to 210.
saying these in an interview costs you the question
- A RIP router switches to C the moment B stops sending.
- RIP keeps C's route as a ready backup in the table.
- RIP's slow convergence comes only from count-to-infinity.
- Lowering the update timer on one RIP router speeds up the whole network.
- C's route is accepted only after B's route is deleted from the table.