the count-to-infinity problem

Two children stand facing each other; you tell one that recess is over. Instead of one telling the other plainly, each keeps echoing a slightly-changed version of what they just heard from the other, and the message takes ages to actually mean 'it is over'. Distance-vector routers can fall into a similar trap when bad news (a link broke) needs to spread: the news creeps up one cost-step at a time instead of arriving cleanly. This slow, looping spread of bad news is the count-to-infinity problem.

Here is the mechanism. Suppose A reaches destination Z through B at cost 1. The A-Z direct link (or B-Z link) breaks. Before B learns the truth, A still advertises 'I can reach Z at cost 1'. B, having lost its own route, believes A and now says 'I reach Z via A at cost 2'. A then hears B's new claim and updates to 'Z via B at cost 3', B replies with 4, and so on — each round adding one, the two routers bouncing the unreachable destination back and forth, their estimates climbing toward infinity. Good news (a link came up) spreads fast in distance-vector; bad news propagates painfully slowly.

It matters because it makes naive distance-vector routing converge slowly and form transient loops exactly when you most need correctness — during failures. To bound the damage, protocols define a small finite 'infinity': RIP uses 16, so as soon as a count reaches 16 the route is simply declared unreachable, stopping the climb after at most a handful of rounds.

An honest caveat: the partial cures — split horizon and poison reverse — prevent the simplest two-router loop but not all of them; loops involving three or more routers can still count to infinity. This fundamental fragility, not mere taste, is a core reason large networks adopt link-state routing (where every router holds the full map) instead.