Skip to main content
RunBook Academy

VyOSXXXV · Route SummarisationSummarisation

RIPv2 summarisation — default-metric, automatic classful-boundary summary

Intermediate⏱ ~18 minshow ip ripshow ip route ripshow ip protocolsshow ip rip databaseconfigurecomparecommitsaverollbackvtysh

What you'll learn

  • Configure automatic summarisation on RIPv2 classful boundaries
  • Use `default-metric` to set the metric for redistributed routes
  • Recognise the discontiguous-subnet failure mode caused by classful summarisation
  • Diagnose missing summaries, traffic blackholes, and metric issues

Prerequisites

Verified against VyOS 1.5.x LTS (circinus) · VyOS 1.4.x (sagitta) — legacy · FRRouting 10.x (VyOS 1.5) · Linux kernel 6.6 LTS (VyOS 1.5 base) · strongSwan 5.9.x (IPsec) · WireGuard 1.0.x (kernel module + userspace tooling) · 2026-08-15

Not yet marked complete on this device.

RIP version 2 is a distance-vector protocol with classful summarisation baked in. RIPv2 summarises routes on the classful network boundary by default — every subnet of 192.168.1.0/24 is summarised to 192.168.1.0/24 when crossing the boundary to a router whose outgoing interface is in a different major network.

This lesson is the operator’s reference for RIPv2 summarisation: the classful-boundary rule, when it helps and when it backfires, the default-metric for redistributed routes, and the production failure modes — especially the discontiguous- subnet problem that classful summarisation can create.

The classful-boundary rule

RIPv2 inherits its summarisation rule from RIPv1: routes are summarised to the classful network when crossing the boundary between major networks. A “classful network” is the natural mask of an IP address class:

  • Class A: /8 (e.g., 10.0.0.0/8)
  • Class B: /16 (e.g., 172.16.0.0/16)
  • Class C: /24 (e.g., 192.168.1.0/24)
flowchart LR
  subgraph "Inside 192.168.1.0/24 (intra-classful)"
    N1["192.168.1.0/26<br/>(subnet 1)"]
    N2["192.168.1.64/26<br/>(subnet 2)"]
    N3["192.168.1.128/26<br/>(subnet 3)"]
    N4["192.168.1.192/26<br/>(subnet 4)"]
  end
  R["R1 (interface 192.168.1.1/24<br/>and 10.0.0.1/8)"]
  R2["R2 (interface 10.0.0.2/8)"]
  N1 --> R
  N2 --> R
  N3 --> R
  N4 --> R
  R -- "summary: 192.168.1.0/24<br/>(classful boundary)" --> R2

The classful boundary triggers when the outgoing interface is in a different major network than the route. In the diagram, R1’s outgoing interface to R2 is 10.0.0.1/8 (Class A), and the routes are inside 192.168.1.0/24 (Class C). Different major networks — the boundary triggers, and the summary 192.168.1.0/24 is sent instead of the four /26 subnets.

Why classful summarisation works (and when it does not)

The classful summarisation is a feature, not a bug. It collapses subnet routes at the natural class boundary, reducing the size of the routing table and the number of RIP updates. The catch: the summarisation happens unconditionally on the classful boundary, even when the operator has engineered subnets with longer prefix lengths.

The production failure mode: discontiguous subnets.

flowchart LR
  subgraph "Site A"
    A1["192.168.1.0/24<br/>(subnetted /26s)"]
  end
  subgraph "Backbone (Class A: 10.0.0.0/8)"
    BB["R2 (interface 10.0.0.2/8)"]
  end
  subgraph "Site B"
    B1["192.168.1.0/24<br/>(different subnetted /26s)"]
  end
  A1 --> BB
  BB -- "summary: 192.168.1.0/24" --> B1
  BB -- "summary: 192.168.1.0/24" --> A1

If site A has 192.168.1.0/26 and site B has 192.168.1.64/26, both sites announce a summary of 192.168.1.0/24 across the backbone. Each site sees the summary but cannot tell whether the destination subnet is local or remote. The result: asymmetric routing or blackhole.

The fix is to disable classful summarisation on the backbone-facing interface:

set protocols rip interface eth0 no-summary

With no-summary, the router sends the specific subnets (/26s) instead of the classful summary. The discontiguous- subnet problem disappears because the specific subnet routes have full prefix information.

default-metric for redistribution

The default-metric configuration sets the metric that redistributed routes receive when entering RIP:

set protocols rip default-metric 3

A route redistributed from another protocol (OSPF, BGP, static, connected) gets metric 3 in the RIP database. The default is 1 if not configured.

flowchart LR
  OSPF["OSPF route<br/>192.168.1.0/24<br/>metric 20"]
  REDIST["Redistribute ospf<br/>into RIP"]
  METRIC["default-metric 3"]
  RIP["RIP database<br/>192.168.1.0/24<br/>metric 3<br/>hop count 1"]
  OSPF --> REDIST
  REDIST --> METRIC
  METRIC --> RIP

The operator who redistributes OSPF into RIP must set default-metric explicitly. RIP’s metric is hop count (1-16, with 16 meaning “unreachable”). An OSPF route with metric 20 (say) is not directly comparable to a RIP hop count; the operator must translate.

Common production defaults:

  • default-metric 1 — treat the route as if it is one hop away. Used when the operator wants the redistribution to look like a directly-connected RIP route.
  • default-metric 3 — small “imported” cost; the route becomes less preferred than local RIP routes but still reachable.
  • default-metric 5 — larger cost; the route is the longest-resort fallback.

Suppressing summarisation on specific interfaces

The classful summarisation can be disabled per-interface:

set protocols rip interface eth0 no-summary

This is the configuration for the discontiguous-subnet fix. The router sends the full /26 (or whatever the actual subnet mask is) to the peer on eth0 instead of summarising to the classful boundary.

Common practice:

  • Inside a site — Summarisation is usually on (the default). The site has contiguous subnets; the classful boundary is outside the site.
  • Backbone-facing interfaces — Summarisation is usually off (with no-summary) if the operator has discontiguous subnets across the backbone.
  • Stub networks with one prefix — Summarisation is on; the single prefix is the summary.

Distribute-list and route-map for filtering

The operator who wants finer-grained control over what RIP advertises uses a distribute-list or a route-map:

set policy access-list ALLOW-SUMMARY rule 10 permit 192.168.0.0/16
set policy access-list ALLOW-SUMMARY rule 20 deny any

set protocols rip distribute-list ALLOW-SUMMARY out

This advertises only 192.168.0.0/16 (the summary) and denies everything else. The out keyword applies the filter to outgoing updates.

The same effect with a route-map:

set policy route-map RIP-OUT rule 10 action permit
set policy route-map RIP-OUT rule 10 match ip address prefix-list SUMMARY
set protocols rip route-map RIP-OUT

Validation

# 1. The RIP database (Loc-RIB)
show ip rip database
# Shows every route in the RIP database, with metric and
# summarisation status

# 2. The interfaces with summarisation
show ip rip interface
# Shows the interface-level configuration including
# no-summary if configured

# 3. The route as advertised
show ip protocols
# Shows the redistribution configuration, default-metric,
# and the interfaces

# 4. The downstream router's view
# (On the downstream router:)
show ip route rip
# Shows the routes received via RIP

# 5. The trace from a downstream router to a specific subnet
traceroute 192.168.1.50
# Should show the path to the specific subnet; if the trace
# shows only the summary's next-hop, the summary is in effect

A clean validation: the RIP database has the specific routes (or the summary, depending on the configuration); the downstream router has the routes it should have; the traceroute shows the expected path.

Production failure modes

Discontiguous subnets

The classic RIPv2 failure. Two sites with subnets inside the same major network (e.g., 192.168.1.0/24) advertise their classful summary across the backbone; each site cannot tell whether the destination is local or remote. Traffic for 192.168.1.50 may be routed to the wrong site.

Diagnostic:

  • show ip rip database on each site — does the site have the local specifics?
  • show ip route on the backbone-facing router — does the router see only the summary or the specifics?

The fix is no-summary on the backbone-facing interface.

Subnet advertised but not reachable

A specific subnet is in the RIP database on the local router but unreachable from a downstream router. The most likely cause: the downstream router’s outgoing interface is in a different classful network, and the classful summarisation collapsed the specific to the summary. The downstream router sees the summary but the local router’s specifics are not visible.

The fix is no-summary on the local router’s outgoing interface to the downstream router.

Metric accumulation beyond 16

RIP’s hop count is bounded at 16 (16 = unreachable). A route that accumulates 16 hops is dropped. With summarisation, the operator may redistribute a route from OSPF (which has metric 20) into RIP with default-metric 1. The route is announced with hop count 1, but the path through the RIP network adds hops. If the path is 15 hops long, the route becomes unreachable.

The fix is to either keep the RIP network small (so hops do not accumulate) or use a higher default-metric to make the route look less attractive.

default-metric not set on redistribution

The operator redistributes OSPF into RIP without setting default-metric. RIP assigns the default metric 1, which makes the OSPF route look attractive — possibly more attractive than the local RIP routes. The result: suboptimal path selection (traffic prefers the OSPF-redistributed route even when a local RIP route is shorter).

The fix: set default-metric to a value that makes the redistributed route less attractive than local RIP routes.

Rollback

# Capture the running configuration
show configuration commands | save /tmp/rip-summary-$(date +%s).txt

# Compare
compare

# Remove the redistribution
delete protocols rip redistribute ospf
commit

# Or remove default-metric (revert to default 1)
delete protocols rip default-metric
commit

The rollback reverts the metric assignments. Routes already in the RIP database retain their old metric until the next update cycle (typically 30 seconds for RIP).

Production discipline

Cross-course references

  • Part XVII-04 (XVII-VyOS-RoutingFund / IGP vs EGP) covers the distance-vector vs link-state distinction.
  • Part XXXIV (XXXIV-VyOS-Redistribution) covers the redistribution primitives (route-map, distribute-list, prefix-list) used with RIP.
  • Part XXXV-01 (XXXV-VyOS-Summarisation / concept) covers the summary vs specific distinction that applies across RIP, OSPF, and BGP.
  • Part XXXV-05 (XXXV-VyOS-Summarisation / null0) covers the blackhole route that protects against missing components.

Quiz

Knowledge check · 4 questions

  1. Q1. Site A has 192.168.1.0/26 and Site B has 192.168.1.64/26, connected by a RIPv2 backbone. Site A's router sends `192.168.1.0/24` to Site B (and vice versa). What is the failure mode?

  2. Q2. If the operator does not configure `default-metric` for redistribution into RIP, FRR uses metric 0 (the unreachable value).

  3. Q3. Site A has 192.168.1.0/26 and Site B has 192.168.1.64/26, connected by a RIPv2 backbone. Traffic from Site A to 192.168.1.65 (Site B's subnet) is routed back into Site A instead of going to Site B. What is the fix?

    R-A has interface 192.168.1.1/26 (Site A's subnet) and 10.0.0.1/8 (backbone). R-B has interface 192.168.1.65/26 (Site B's subnet) and 10.0.0.2/8 (backbone). RIPv2 is running on both interfaces. R-A sends 192.168.1.0/24 to R-B (classful summary). R-B sends 192.168.1.0/24 to R-A. R-A has 192.168.1.0/24 in its routing table with next-hop via the backbone. Traffic from R-A to 192.168.1.65 is forwarded to the backbone (10.0.0.2 = R-B). R-B has 192.168.1.0/24 with next-hop via the backbone (10.0.0.1 = R-A). R-B has 192.168.1.65/26 as connected. R-B's longest-prefix-match for 192.168.1.65 uses the /26 (R-B's own interface). The return path uses 192.168.1.65 directly. Forward and reverse paths disagree.

  4. Q4. An operator redistributes OSPF routes into RIP without setting `default-metric`. Local RIP routes have hop count 3; the OSPF-redistributed routes have hop count 1 (the default). The OSPF-redistributed route is preferred even when the local RIP path is shorter. What is the fix?

    R1 has OSPF and RIP configured. R1 redistributes OSPF routes into RIP without setting `default-metric`. The OSPF routes have OSPF cost 20; when redistributed into RIP, they have hop count 1 (the FRR default). Local RIP routes have hop count 3 (the path is 3 hops). Traffic from a downstream RIP router to the OSPF route prefers the OSPF-redistributed route (hop count 1) over the local RIP path (hop count 3) — even though the OSPF-redistributed route goes through the OSPF network first, then RIP.

Passing score: 75%. Answers are checked in this browser.