skip to content

How does a RIP router choose its route to a network, and how does the hop count change as a route travels one router further?

level: juniorimportance: must knowfreq 40%

answer

  1. distances from neighbours, not a map
  2. add the arriving network's cost
  3. usually cost 1, so hops
  4. lowest wins; current next hop always believed
  5. 16 means unreachable

basics

~20 s

A RIP router adds the cost of the network an update arrived on, normally 1, to each metric a neighbour advertises and keeps the lowest result, with that neighbour as next hop; metric 16 means unreachable.

solid answer

~50 s

RIP is a distance-vector protocol built on the Bellman-Ford idea: a router never sees the topology, only each neighbour's claimed distance to every destination. Every 30 seconds each router sends its whole table in Response messages on UDP port `520`. A receiver adds the cost of the network the message arrived on (RFC 2453 says 1 is the usual cost, which turns the metric into a hop count), caps the result at `16` (infinity, unreachable), and installs it if it beats the current route, recording the advertiser as next hop. One exception: news from the router that is already the next hop is always believed, even when the metric got worse. A directly connected network starts at its own cost, so with cost 1 the RFC's counting gives 1 at the owning router, 2 one router away and 3 two routers away.

code

pseudocode · 12 lines
pseudocode
on response from neighbour G over network with cost C:
  for each entry (dest, m) in response:
    if m < 1 or m > 16: ignore entry
    m = min(m + C, 16)
    r = table.lookup(dest)
    if r is none:
      if m < 16: table.add(dest, metric=m, nextHop=G); start timeout
    else if r.nextHop == G:
      reset r.timeout
      if m != r.metric: r.metric = m   # believe G even if worse
    else if m < r.metric:
      r.metric = m; r.nextHop = G; reset r.timeout

go deeper

for a junior

Recall that RIP's metric is a hop count: add one per hop, keep the lowest, and 16 means unreachable.

for a middle

Walk the RFC 2453 input rule: add the arriving network's cost, cap at 16, install if strictly lower, and always believe the current next hop even when its metric rises.

for a senior

Explain what hop count ignores, bandwidth and load, and why raising a network's cost to steer traffic eats into the 15-unit diameter a RIP network can span.

for a principal

Be ready to say when a metric this blunt is still acceptable, a small flat network with uniform links, and what its blindness to capacity costs once link speeds differ.

## What a RIP router actually knows The **Routing Information Protocol (RIP)** is a **distance-vector** protocol. RFC 2453 (RIP version 2, Internet Standard STD 56) describes it as based on the **Bellman-Ford** algorithm: each router keeps, for every destination, only two facts that matter for forwarding: - the **metric** — its current estimate of the total cost to reach that destination; - the **next hop** — the neighbouring router whose advertisement produced that estimate. It never learns the shape of the network. It learns *distance claims* from its neighbours and believes the smallest one. That is the whole idea of distance vector: a router's view of the world is a vector of distances, one per destination, handed to it by the routers next door. ## The metric: cost per network, usually 1 Every network attached to a RIP router has a **cost** between 1 and 15. RFC 2453 leaves the way it is set to the administrator and notes that 1 is the usual value; with every cost at 1, "the RIP metric reduces to a simple hop-count". The value **16** is reserved as **infinity**: a route at metric 16 is unreachable and is not used for forwarding. A **directly connected** network enters the table at its own cost. The RFC's own example shows the owning router at "directly connected, metric 1", the next router at 2 and the one after at 3. In other words the RFC counts the networks a packet crosses, including the destination network. Some implementations display the count of routers crossed instead, one lower at every router; the ordering of routes, and so the choice, is the same either way. ## The update rule, step by step When a Response message arrives from neighbour G, the receiver processes each route entry: 1. **Validate** the entry: a sensible unicast destination and a metric between 1 and 16. 2. **Add the cost** of the network the message arrived on: `metric = MIN(metric + cost, 16)`. 3. **No route yet?** Install it (unless the result is 16), with G as next hop, and start the route's timeout. 4. **Route already via G?** Reset the timeout, and adopt G's new metric *even if it is worse* — G's path is the basis of ours, so if G's distance grew, ours did too. 5. **Route via someone else?** Adopt G's route only if the new metric is **strictly lower**; otherwise ignore the entry. Step 4 is the subtle one. Without it a router could only ever lower a metric, and a path that got longer would keep its stale, too-optimistic value until it timed out. ## A worked example Three routers in a line, every link cost 1, and R1 owning 192.0.2.0/24: | Router | Metric to 192.0.2.0/24 | Next hop | Why | |---|---|---|---| | R1 | 1 | directly connected | the network's own cost | | R2 | 2 | R1 | R1 advertised 1, plus 1 for the R1-R2 link | | R3 | 3 | R2 | R2 advertised 2, plus 1 for the R2-R3 link | R3's next hop is **R2**, the router that told it, not R1, the router that owns the network. A RIP route never names anything beyond the neighbour. ## What hop count ignores - **Bandwidth and delay.** Two hops over slow links beat three hops over fast ones. An administrator can raise a network's cost to steer traffic, but every unit spent comes out of the same budget of 15. - **Load.** The metric is static; RIP does not react to congestion. - **Diameter.** Because 16 means unreachable, a destination more than 15 cost-units away cannot be reached at all; why the ceiling sits so low is a loop-prevention story told separately. ## Where this rule stops How RIP stops routers from counting upward forever after a failure (split horizon, poisoned reverse, holddown) is the loop-prevention part of RIP. Which protocol's route wins when RIP and another source both offer a prefix is decided by route-source preference, not by the hop count. Within RIP, though, the rule above is the entire route computation: add one, keep the lowest, always listen to your current next hop.

  • Why does a RIP router accept a worse metric from its current next hop?
    Because that neighbour's distance is what our route is built on. If its path to the destination got longer, ours did too, so RFC 2453 says to adopt the new metric from the current next hop even when it is higher. Without that rule metrics could only fall, and a lengthened path would keep its stale low value until the route timed out.
  • A RIP router can reach a network over two fast links or one slow serial link; which path does it pick?
    The single slow link, if every network has the usual cost of 1: RIP counts networks crossed and knows nothing about bandwidth. An administrator can raise the slow network's cost so the fast path wins, but every point of cost added comes out of the 15 that RIP allows before a destination becomes unreachable.

Asking strangers for directions where each only says how many streets away the place is from them: you add the street to reach that person, follow whoever gives the smallest total, and never see a map.

saying these in an interview costs you the question

  • RIP picks the path with the most bandwidth.
  • Each RIP router floods link states and computes the whole topology.
  • A RIP router only ever accepts a lower metric, even from its current next hop.
  • Metric 16 is the longest path RIP can still use.
  • A RIP route's next hop is the router that owns the destination network.