skip to content

In RIP, what is count-to-infinity, and how does it unfold when a router's connected network fails while a neighbour still advertises it?

level: middleimportance: must knowfreq 32%

answer

  1. stale news travels in a circle
  2. each router trusts its next hop
  3. metric climbs one per advertisement
  4. ends only at the metric cap

basics

~20 s

Count-to-infinity is RIP's slow failure mode: after a network vanishes, routers keep re-learning it from each other's stale advertisements, raising the metric one hop per exchange until it reaches 16, RIP's infinity, and the route is finally declared unreachable.

solid answer

~50 s

Take `R1`, which has `10.20.30.0/24` directly connected at metric 1, and `R2`, which learned it from `R1` at metric 2. The network fails and `R1` marks it 16, but before that news reaches `R2`, `R2`'s regular update still lists the prefix at 2. `R1` has nothing better than infinity, so it installs the route via `R2` at 3. `R2`'s route points at `R1`, and RIP requires a router to believe its current next hop whether the metric rises or falls, so `R2` moves to 4, then `R1` to 5, and so on. Packets for the prefix bounce between the two until their TTL runs out. The climb stops only when the metric reaches 16, which is why RIP keeps infinity so small. Split horizon would have prevented this two-router case by keeping `R2` from advertising the prefix back to `R1` at all.

code

pseudocode · 13 lines
pseudocode
on response from neighbour G listing prefix P at metric m:
  new = min(m + cost(link to G), 16)
  route = table[P]
  if route is none:
    if new < 16: install P via G at new
  else if route.nextHop == G:
    reset route timeout
    if new != route.metric:
      adopt P via G at new        -- believe the next hop, even if worse
  else if new < route.metric:
    adopt P via G at new          -- strictly better from someone else
  if adopted and new == 16 and old metric < 16:
    start deletion (metric 16, garbage-collection timer, triggered update)

go deeper

for a junior

Recall that RIP counts hops, that 16 means unreachable, and that after a failure routers can keep believing each other's old routes until the metric reaches 16.

for a middle

Trace the two-router case step by step: who advertises what, why the next hop must be believed, and why each advertisement adds exactly one.

for a senior

Show which fix would have stopped this exact trace, why triggered updates only shrink the window, and how slow updates or a larger network make each count more costly.

for a principal

Frame count-to-infinity as the price of trusting neighbours' distances instead of knowing the topology, and weigh the small infinity it forces against the network size you need.

## Why a distance-vector router can be fooled **RIP** (Routing Information Protocol) is a distance-vector protocol. A RIP router never sees the topology; it knows only what each neighbour claims: "I can reach this prefix at this metric." It adds the cost of the link the claim arrived on — by convention 1, so the metric is a hop count — and keeps the best claim. Three rules in RFC 2453 matter here: - A claim from a neighbour that is **not** the current next hop replaces the route only if it is strictly better. - A claim from the **current next hop** is always believed, better or worse, because that neighbour is the only one that knows about the path in use. If it reports 16, RIP's value for **infinity**, the route is unreachable and deletion begins. - Every computed metric is capped: `metric = MIN(advertised + cost, 16)`. The second rule is what lets bad news spread. It is also what lets a stale claim feed on itself. ## The trace: one failure, two routers Take two routers on a point-to-point link. `R1` has `10.20.30.0/24` directly connected at metric 1; `R2` learned it from `R1` at metric 2. Assume, for the moment, that neither uses split horizon. The network behind `R1` fails, and `R1`'s update announcing the loss is lost or crosses `R2`'s regular update on the wire. | Step | What happens | R1's route | R2's route | |---|---|---|---| | 0 | steady state | connected, 1 | via R1, 2 | | 1 | the network fails | unreachable, 16 | via R1, 2 | | 2 | R2's regular update still lists the prefix at 2 | via R2, 3 | via R1, 2 | | 3 | R1 advertises 3; R2 must believe its next hop | via R2, 3 | via R1, 4 | | 4 | R2 advertises 4; R1 must believe its next hop | via R2, 5 | via R1, 4 | | ... | each advertisement adds 1 | 7, 9, 11, 13, 15 | 6, 8, 10, 12, 14 | | last | R1 advertises 15; R2 computes MIN(15 + 1, 16) | via R2, 15 | 16, deletion starts | | after | R2 advertises 16; R1 believes its next hop | 16, deletion starts | 16 | Step 2 is the mistake: `R1` has nothing better than infinity, so a neighbour's offer of 3 looks like an alternative path. It is not — `R2`'s route ran through `R1` all along. From step 3 on, each router points at the other, and every packet for the prefix bounces between them until its TTL runs out. The metrics climb one step per advertisement because each router faithfully believes its next hop. That slow climb is **counting to infinity**. ## Why it is slow, and why it is expensive 1. Each step needs one advertisement to cross the link, so the count from `R1`'s 3 up to 16 takes thirteen of them. 2. If the routers wait for their 30-second regular updates, the loop can last minutes; if they send a triggered update for every change, it ends sooner but costs bandwidth. RFC 2453 names exactly this trade: resolving a large loop takes "either much time" or bandwidth. 3. While it lasts, the link carries the looping traffic as well as the updates. RFC 2453's own example is a four-router topology in which a real backup path exists at metric 11; the routers still count their way up from 3 before one of them switches to it. Counting to infinity is not only about vanished networks — it also delays convergence onto a worse but genuine path. ## What makes it stop Only the cap. RIP defines valid metrics as 1 to 15 and 16 as unreachable, so any count is bounded. RFC 2453 says infinity is chosen "as small as possible" for exactly this reason, and accepts the price: RIP networks are limited to a diameter of 15 hops. ## The fixes layered on top RIP does not remove count-to-infinity; it makes it rare and short: - **Split horizon** — `R2` never advertises the prefix to `R1`, the router it learned it from, so step 2 cannot happen in this two-router case. - **Split horizon with poisoned reverse** — `R2` advertises the prefix to `R1` at 16, which breaks a two-router loop at once even if one forms. - **Route poisoning and triggered updates** — `R1` announces the loss at 16 within seconds rather than at the next regular update, shrinking the window for the race. - **Holddown** — not in RFC 2453, but added by many implementations: for a while after a loss, refuse offers that are no better than the lost route. None of them stops every loop. With three or more routers a stale route can circulate around a ring that split horizon never sees, and then only the metric reaching 16 ends it.

  • Why must a RIP router accept a worse metric from its current next hop instead of keeping the better number it had?
    Because the next hop is the only source of truth for the path in use. If `R2` ignored `R1`'s rising metric, it would keep advertising a cheap route that no longer exists and would never learn of the failure. RFC 2453 makes the rule explicit: an update from the current next hop is adopted whether the metric rises or falls, and a 16 from it starts deletion. The same rule is what lets the count climb.
  • Do packets loop for the whole time the metrics are climbing?
    Yes, for as long as the two routers point at each other for the prefix. Each packet is forwarded back and forth until its TTL is exhausted and it is discarded; new packets keep entering the loop. TTL protects each packet, but only the routing protocol ends the loop itself, when the metric reaches 16 and the route is removed.

saying these in an interview costs you the question

  • RIP cannot form loops because every router computes shortest paths.
  • Count-to-infinity has no upper bound in RIP; the metric can climb forever.
  • A RIP router ignores a worse metric from its current next hop and keeps its old route.
  • The packets' TTL is what ends a RIP routing loop.
  • Count-to-infinity only happens when a router crashes, not when a network behind it fails.