skip to content

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%

answer

  1. where network 10 is cut in two
  2. border routers advertise the whole network
  3. two identical 10.0.0.0 entries
  4. one mask per network
  5. masks in updates, summarising switched off

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.

solid answer

~50 s

Network 10.0.0.0 is **discontiguous**: its two parts are separated by 172.16.0.0. RIPv1 must not send subnet routes outside their network, so R1 and R3 each advertise just `10.0.0.0`, both at metric 1. R2, with no interface in network 10, reads both as 10.0.0.0/8 and, under RFC 2453's rule that a different neighbour's route replaces the current one only with a lower metric, keeps whichever arrived first. Traffic for the other site goes to the wrong border router, which has no route for that subnet, so it never arrives; an implementation that installs both equal routes loses a share of flows instead. RIPv1 also assumes one mask per network, so the /24 and /26 conflict anyway. RIPv2 carries a mask per route, but implementations that auto-summarise at network boundaries recreate the fault, so turn that off on R1 and R3 to advertise `10.1.1.0/24` and `10.1.2.0/26`.

go deeper

for a junior

Recall that RIPv1 sends no subnet masks and that a border router advertises only the whole classful network outside it.

for a middle

Walk the topology: what R1 and R3 advertise, how R2 reads 10.0.0.0, which route it keeps, and why the second site's traffic never arrives.

for a senior

Diagnose from R2's table, explain why RIPv2 alone may not fix it because of automatic summarisation, and give the fix plus the alternatives of renumbering or making the network contiguous.

for a principal

Use the failure to argue for addressing plans that do not depend on a protocol's summarisation rules, and for classless protocols with summarisation configured deliberately rather than by default.

## The topology | Router | Interfaces | |---|---| | R1 | LAN `10.1.1.0/24`; link `172.16.12.0/30` to R2 | | R2 | links `172.16.12.0/30` to R1 and `172.16.23.0/30` to R3 | | R3 | LAN `10.1.2.0/26`; link `172.16.23.0/30` to R2 | All three run **RIPv1** (RFC 1058). In classful terms, `10.1.1.0` and `10.1.2.0` both belong to the class A network **`10.0.0.0`**, and the links belong to the class B network **`172.16.0.0`**. Network 10 is therefore **discontiguous**: its two pieces are separated by a different network. ## What each router advertises A RIPv1 route entry has no mask field, so the protocol restricts where subnet routes may go. RFC 1058 says routes to a subnet must not be sent outside the network the subnet belongs to; a **border router** sends only a single entry for the whole network to neighbours in other networks. 1. R1 is a border router between network 10 and network 172.16. On its link to R2 it advertises **`10.0.0.0`, metric 1**, not `10.1.1.0`. 2. R3 does the same on its link to R2: **`10.0.0.0`, metric 1**. 3. R2 has no interface in network 10, so it applies the **natural class A mask** and reads both as `10.0.0.0/8`. ## What R2 does with two identical routes RFC 2453's response processing replaces an existing route with one from a **different** router only when the new metric is **lower**; an update from the **same** router always refreshes it. Both offers have metric 1, so R2 keeps whichever it heard first, say R1's. (An optional heuristic may switch to an equally good route when the current one is at least halfway to timing out, which does not happen while R1 keeps refreshing it.) The result: - Packets from R2 for `10.1.1.x` go to R1 and arrive. - Packets from R2 for `10.1.2.x` also go to R1. R1 holds no route for `10.1.2.0`, since R3 never advertised that subnet across 172.16, and split horizon stops R2 from sending R1's own `10.0.0.0` back to it. The packets never reach R3's site. - Some implementations install **both** equal-metric routes and spread flows between them. That is an implementation choice, not RFC behaviour, and it turns a consistent outage into an intermittent one, which is harder to diagnose. The signature on R2 is a single `10.0.0.0/8` entry where there should be two distinct subnets. ## The second RIPv1 problem: two masks in one network Even if network 10 were contiguous, RIPv1 assumes **one subnet mask per network**. A RIPv1 router with a /24 interface in network 10 that hears `10.1.2.0` applies its own /24, installing a route larger than the real /26. If R3 also had `10.1.2.64/26`, a /24 router would see non-zero bits beyond its mask and read `10.1.2.64` as a **host route**. VLSM is outside what RIPv1 can describe. ## How RIPv2 fixes it **RIPv2** (RFC 2453) puts a **Subnet Mask** in every route entry, so the information R2 needs can travel: `10.1.1.0/24` from R1 and `10.1.2.0/26` from R3, two different routes. One more step is needed. RFC 2453 section 6 notes that some implementations **automatically summarise** groups of routes into single entries at network boundaries, and requires implementations to provide a way to disable it. If R1 and R3 still summarise to `10.0.0.0/8` the fault survives the upgrade. The fix is: 1. Run RIPv2 on R1, R2 and R3 (the send setting that multicasts RIP-2 messages, or broadcasts them for compatibility). 2. **Disable automatic summarisation** on R1 and R3. 3. Check that R2's table now holds `10.1.1.0/24` via R1 and `10.1.2.0/26` via R3. Alternatives exist: renumber so each site sits in its own classful network, or number the transit links from network 10 so it is no longer split (under RIPv1 that also needs one mask everywhere). In a mixed RIPv1 and RIPv2 network, RFC 2453 asks for a single subnet mask throughout and automatic summarisation disabled, because RIPv1 routers still infer masks. ## Why interviewers use this scenario It tests whether a candidate understands that **"classful" is a property of the update, not of the addresses**. Nothing about `10.1.2.0/26` is wrong; RIPv1 simply has no way to say it, and the summarisation rules that keep RIPv1 safe inside one network are exactly what break it when a network is split.

  • After moving to RIPv2, R2 still shows only 10.0.0.0/8. What is the likely cause?
    R1 and R3 are still summarising at the network 10 boundary. RFC 2453 section 6 describes automatic summarisation as something some implementations do and requires that it can be disabled. With it on, RIPv2 carries a mask, but the mask is /8; switch it off on both border routers and the /24 and /26 appear separately.
  • Would changing R3's metric so R2 always prefers one router fix the outage?
    No. R2 still holds a single 10.0.0.0/8 route, so every packet for network 10 leaves through one border router, and the other site stays unreachable from R2's side. A metric only chooses between routes to the same destination; here the problem is that two different destinations collapsed into one.

saying these in an interview costs you the question

  • Switching to RIPv2 fixes discontiguous networks with no further change.
  • R2 load-balances between R1 and R3 because the RFC requires equal-cost paths.
  • R1 advertises 10.1.1.0 to R2, and R2 applies its own /30 mask.
  • The /26 is the problem, so making both sites /24 makes RIPv1 work.
  • Split horizon on R2 is what hides one of the two sites.