skip to content

RIP

RIP counts hops, advertises its whole table every 30 seconds and treats 16 as unreachable. Interviewers keep it to show why distance-vector routing needs loop prevention and converges slowly.

on this pageshow

explore

questions

16

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.
open as a page

When a RIP neighbour dies silently, when do its routes leave service and the table under RFC 2453, and how does the 180/180/240 set differ?

level: middleimportance: must knowfreq 30%

basics

~20 s

Under RFC 2453 a RIP route expires 180 seconds after its last refresh, is advertised at metric 16 while a 120-second garbage-collection timer runs, then is deleted: 300 seconds in all. The invalid/holddown/flush set of 180/180/240 is an implementation's.

open as a page

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%

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.

open as a page

In RIP, how does simple split horizon differ from split horizon with poisoned reverse, and why is poisoned reverse considered safer?

level: middleimportance: must knowfreq 30%

basics

~20 s

Simple split horizon leaves a route out of updates sent where it was learned; poisoned reverse sends it there with metric 16. That explicit 16 breaks a two-router loop at once rather than after a timeout, but enlarges updates.

open as a page

What does a RIPv2 route entry carry that a RIPv1 entry does not, and why did the missing subnet mask make RIPv1 classful?

level: middleimportance: must knowfreq 32%

basics

~20 s

RIPv1 route entries carry no subnet mask, so a receiver infers each mask from its own interface or the address class, which makes RIPv1 classful. RIPv2 reuses unused fields for a subnet mask, a route tag and a next hop.

open as a page

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

level: juniorimportance: should knowfreq 38%

basics

~20 s

RIP uses 16 as infinity so that counting to infinity after a failure ends quickly. The same choice leaves valid metrics at 1-15, so with each network costing 1 no usable path may be longer than 15 hops.

open as a page

Why does RIPv2 send its periodic updates to the multicast address 224.0.0.9, when RIPv1 broadcast them to every host on the segment?

level: juniorimportance: should knowfreq 22%

basics

~20 s

A RIPv1 broadcast reaches every station on the segment, and each must take it in and discard it. RIPv2 sends to 224.0.0.9, a group only RIP routers join, so other hosts can filter it out; a per-interface switch keeps broadcast for RIPv1 neighbours.

open as a page

Three RIP routers R1, R2, R3 sit in a line; when R1 gains 192.0.2.0/24, how does each table change, and how long can R3 wait?

level: middleimportance: should knowfreq 22%

basics

~20 s

R1 installs 192.0.2.0/24 at metric 1, R2 then learns metric 2 via R1, and R3 metric 3 via R2; without triggered updates each hop waits up to one 30-second update, so R3 can wait about a minute.

open as a page

When a RIP router loses a route, how do route poisoning and triggered updates spread the news, and how does poisoning differ from poison reverse?

level: middleimportance: should knowfreq 22%

basics

~20 s

Route poisoning advertises a lost route at metric 16 rather than dropping it silently; triggered updates send that change within seconds, not at the next regular update. Poison reverse instead sends 16 back toward the neighbour a working route came from.

open as a page

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?

level: seniorimportance: should knowfreq 15%

basics

~20 s

About 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.

open as a page

Why do many RIP implementations add a holddown timer that RFC 2453 never defines, and what does holddown cost when a real backup path exists?

level: seniorimportance: should knowfreq 16%

basics

~20 s

Holddown is an implementation mechanism: after a route fails, the router ignores offers no better than the lost route, so typical stale echoes cannot restart a loop. The cost: a genuine but worse backup path waits too.

open as a page

A RIPv1 network has 10.1.1.0/24 behind router R1 and 10.1.2.0/26 behind R3, joined through R2 over 172.16.0.0 links; why can the two sites not reliably reach each other, and how does RIPv2 fix it?

level: seniorimportance: should knowfreq 18%

basics

~20 s

RIPv1 carries no masks, so border routers R1 and R3 each advertise only 10.0.0.0 across the 172.16 links. R2 cannot tell the halves apart and sends one site's traffic to the wrong router. RIPv2, with automatic summarisation off, advertises each subnet with its mask.

open as a page

How does RIPv2 authenticate an update message, and why did RFC 4822's cryptographic authentication replace the original plain-text password?

level: middleimportance: nice to knowfreq 10%

basics

~20 s

RIPv2 spends the first route entry on authentication, marked by Address Family Identifier 0xFFFF. RFC 2453's only type sends a plain-text password that anyone on the link can capture; RFC 4822 sends a keyed hash with a key ID and a sequence number instead.

open as a page

How does RIPng for IPv6 differ from RIPv2 in its port, multicast group, route entries, next hops and authentication?

level: middleimportance: nice to knowfreq 8%

basics

~20 s

RIPng (RFC 2080) keeps RIP's hop-count distance-vector design but runs on UDP 521 and multicasts to ff02::9. Entries carry a 128-bit prefix and prefix length, next hops are separate link-local entries, and there is no authentication field: it relies on IPsec.

open as a page

Why does RIP resend its whole routing table every 30 seconds instead of only changes, and what does that cost for 1,000 routes?

level: seniorimportance: nice to knowfreq 8%

basics

~20 s

RIP keeps no neighbour state and sends no acknowledgements, so the periodic full table is both the refresh and the liveness signal; 1,000 routes take 40 Response datagrams, about 21 KB per interface every 30 seconds.

open as a page

In RIP with split horizon and poisoned reverse enabled, how can three routers still forward a failed prefix in a loop, and what clears it?

level: seniorimportance: nice to knowfreq 9%

basics

~20 s

Split horizon only stops a route going back to the neighbour it came from; among three routers a stale advertisement can travel around the triangle instead. The loop lasts until the metric reaches 16; triggered updates make it unlikely, not impossible.

open as a page