VyOSXXXV · Route SummarisationSummarisation
RIPv2 summarisation — default-metric, automatic classful-boundary summary
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
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 databaseon each site — does the site have the local specifics?show ip routeon 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
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?
Q2. If the operator does not configure `default-metric` for redistribution into RIP, FRR uses metric 0 (the unreachable value).
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.
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.