Lesson
RIP: Routing Information Protocol
Learning objective
Explain how RIP exchanges routes by hop count, prevents loops with split horizon and triggered updates, and where its RFC 2453 packet format and limits show up in practice.
Learning objective
Explain how RIP exchanges routes by hop count, prevents loops with split horizon and triggered updates, and where its RFC 2453 packet format and limits show up in practice.
What RIP is
RIP (Routing Information Protocol) is the oldest interior gateway protocol still seen in production and lab networks. RIPv1 was standardized in RFC 1058 (1988); the classless version in wide use today, RIPv2, is standardized in RFC 2453 (1998). RIP is a distance-vector protocol: each router tells its neighbors only "here is my distance to each network I know," using a single metric — hop count — the number of routers between here and the destination. RIP runs over UDP port 520, and RIPv2 sends its periodic updates to the multicast address 224.0.0.9 (RIPv1 used broadcast).
RIP packet format
An RFC 2453 RIPv2 message starts with a command field (1 = Request, 2 = Response), a version field, and then up to 25 route entries. Each route entry carries an address family identifier, the destination IP address, a subnet mask (the field RIPv1 lacked, forcing it to assume classful boundaries), a next hop address, and the metric itself — a single byte, since RIP's whole distance space only needs to represent 0 through 16.
How RIP updates work
RIP routers send their full routing table as a periodic Response roughly every 30 seconds. If a route hasn't been reheard within 180 seconds, it is marked invalid and advertised with a poisoned metric of 16; if it stays unreachable, it is flushed from the table entirely around 240 seconds after it was last valid. Beyond the periodic cycle, RIP also sends triggered updates: the instant a route changes — a link fails, or a better route appears — the affected router advertises the change immediately, without waiting for its next 30-second cycle.
Preventing routing loops
A pure distance-vector protocol is naturally vulnerable to routing loops: if two routers each believe the other has a valid path to a now-dead network, they can bounce updates back and forth, each incrementing the hop count, until they "count to infinity." RIP caps this at hop count 16 (defined as unreachable), and adds two loop-prevention rules to stop it happening in the first place:
- Split horizon: never advertise a route back out the same interface it was learned on.
- Split horizon with poisoned reverse: go further — advertise that route back out the same interface, but with a metric of 16, explicitly telling the neighbor "don't route through me for this."
Interactive RIP exchange
Step through three RIP routers connected in a triangle: one router advertises its network to both neighbors at once, a neighbor that hears about that same network twice keeps whichever path has the lower hop count, split horizon with poisoned reverse closes the loop back to the source, and a link failure triggers an immediate update instead of waiting for the next scheduled one.
RIP's limits and RIPng
Hop count treats every link as equal, so a 15-hop path of gigabit Ethernet loses to a 2-hop path of dial-up — RIP has no concept of bandwidth. A maximum usable hop count of 15 also puts a hard ceiling on how large a RIP network can grow. RIPv1's lack of a subnet mask in its route entries meant it could not support Variable Length Subnet Masking (VLSM) or discontiguous subnets; RIPv2 fixed this by carrying a mask with every route. For IPv6, RIPng (RFC 2080) adapts the same distance-vector, hop-count design to 128-bit addresses, sent over UDP port 521 to the multicast group FF02::9.
Inspect RIP evidence
On a representative network device, show ip protocols confirms RIP is running, which interfaces are participating, and the configured timers. show ip rip database (or the equivalent RIP topology command) lists every route RIP has learned, including ones a lower-administrative-distance source has kept out of the actual routing table.
Basic Wireshark check
Display filter: rip
Capture on a RIP-enabled interface for at least one full 30-second cycle. Confirm the destination is UDP port 520 to 224.0.0.9, identify the command field (Request vs. Response), and read each route entry's address, mask, and metric.
Guided RIP convergence practice
Work through "counting to infinity" by hand: three routers in a line, A–B–C, all know about a network attached to A with metrics 1 (at B) and 2 (at C). A's link to that network fails. Without split horizon, B might momentarily still hear C's old, now-stale route (metric 2) and re-advertise it as metric 3, C then re-advertises 4, and so on — climbing toward infinity instead of converging immediately.
Interview scenario
Show answer and reasoning
Troubleshoot RIP
- Confirm RIP is enabled on the correct interfaces with
show ip protocols, and that the network statements cover the intended subnets. - Verify RIPv2 is in use, not RIPv1, if VLSM or discontiguous subnets are in play — RIPv1 cannot carry a subnet mask.
- Check for a mismatched RIP version or missing multicast/broadcast reachability between neighbors (RIPv1 broadcasts, RIPv2 multicasts to 224.0.0.9 by default).
- Inspect the RIP database for routes stuck at metric 16 — that is a poisoned, not a missing, route, and points at a real reachability change.
- Confirm passive-interface configuration is not silently suppressing updates on an interface that should be participating.
- If routes flap, check whether split horizon has been disabled on a hub-and-spoke or NBMA-style topology, which is one of the few cases where doing so is intentional — and risky.