Why does RIP treat a metric of 16 as unreachable, and how does that cap a RIP network at 15 hops?

## The metric is a hop count RIP's metric is the sum of the costs of the networks on a path. RFC 2453 notes that each network normally costs 1 — "this is the way RIP is normally configured" — so the metric is effectively the number of hops. When a router receives a route, it adds the cost of the link it arrived on and caps the result: ``` metric = MIN(advertised_metric + link_cost, 16) ``` Valid metrics run from **1 to 15**. The value **16 is infinity**: the destination is unreachable. A route at 16 is never installed as a new route, and if it comes from the router's current next hop, the existing route is taken out of service and deleted. ## Why infinity is so small RFC 2453 says 16 is chosen to be "as small as possible". The reason is counting to infinity: after a network disappears, distance-vector routers can keep re-learning it from each other's stale advertisements, each adding a hop, and the only guaranteed stop is the metric reaching infinity. The smaller infinity is, the sooner that happens: - Infinity must be **larger** than any real metric, or reachable networks would look unreachable. - It should be **no larger** than needed, or each count takes longer and carries more looping traffic. - The RFC calls it "a tradeoff between network size and speed of convergence in case counting to infinity happens". ## 16 as a loop guard Because every computed metric is capped at 16, every count-to-infinity is bounded. However a stale route circulates — between two routers or around a ring of three — each pass adds at least one, and the route is declared unreachable when it reaches 16. Split horizon, poisoned reverse and triggered updates make such loops rare; the cap guarantees that the ones that happen end. ## 16 as a diameter cap The same number limits size. RFC 2453 lists it as the protocol's first limitation: RIP is "limited to networks whose longest path (the network's diameter) is 15 hops". That assumes cost 1 everywhere: | Cost per network | Longest reachable path | |---|---| | 1 | 15 networks | | 3 | 5 networks (5 x 3 = 15) | | 5 | 3 networks (3 x 5 = 15) | Raising link costs to steer traffic therefore shrinks reach: "If the system administrator chooses to use larger costs, the upper bound of 15 can easily become a problem." A destination beyond the limit is not slow or degraded; it is simply unreachable. ## Why it was never raised The metric field in a RIP route entry is **four octets** wide, so 16 is not a field-width limit; it is a protocol constant. RFC 2453 records that people asked for a larger infinity and explains why it was not done: 1. Older RIP routers would be confused; at best they would ignore larger metrics as they ignore 16. 2. Reusing the high octets of the field would break implementations that treat the metric as a 4-octet number. 3. A larger infinity would also make every count to infinity longer, giving back the reason it is small. RIPng (RFC 2080) keeps the same range: 1 to 15 valid, 16 unreachable. ## What it means in practice - A RIP domain is small by design; RFC 2453 describes RIP as an interior gateway protocol for networks of moderate size. - A network wider than 15 hops needs a different interior routing protocol, or several routing domains joined by other means. - A metric of 15 is still reachable; 16 is not. Calling 16 "the longest usable route" has the boundary backwards.