Summarisation troubleshooting — missing summaries, more-specific leaks, attribute loss

A summarisation failure is not a request to remove the aggregate or to expand the summary. It is a request to identify which contract failed: the aggregate is missing (no components), the more-specifics are leaking (summary-only is wrong), the attributes are wrong (route-map missing), the ICMP unreachables are flooding (blackhole is wrong), or the discontiguous-subnet problem is back (RIP classful summarisation).

This lesson is the operator’s troubleshooting reference for Part XXXV: the five-layer diagnostic method, the failure modes specific to summarisation, and the rollback discipline that prevents the troubleshooting from making the outage worse.

The five-layer diagnostic method

A summarisation failure can be in any of five layers:

1. Configuration — Is the aggregate statement committed? Is summary-only configured? Is the route-map applied?
2. Components — Do the more-specific components exist in the relevant RIB (BGP table, OSPF LSDB, RIP database)?
3. Aggregation logic — Does the aggregate generation fire? Are the components inside the summary prefix?
4. Outbound policy — Is the aggregate being sent to the peer? Are the more-specifics being filtered?
5. Forwarding — Does the receiving peer install the aggregate? Is the next-hop reachable? Is the blackhole in place if needed?

flowchart TB
  S["Symptom<br/>(missing aggregate, leak, etc.)"]
  C["Configuration check"]
  COMP["Components check"]
  AGG["Aggregation logic check"]
  OUT["Outbound policy check"]
  FWD["Forwarding check"]
  D["Diagnosis"]
  S --> C
  C --> COMP
  COMP --> AGG
  AGG --> OUT
  OUT --> FWD
  FWD --> D

The operator starts with the configuration (the cheapest check) and walks through the layers. The first layer where the evidence diverges from the expected state is the failure boundary.

The first three commands

For a BGP summarisation failure:

show ip bgp 192.0.2.0/22
show ip bgp neighbors 10.0.0.2 advertised-routes
show configuration commands | match aggregate

For an OSPF summarisation failure:

show ip ospf database summary
show ip route 10.1.0.0/16
show configuration commands | match "area.*range"

For a RIP summarisation failure:

show ip rip
show ip rip status
show configuration commands | match 'protocols rip'

show ip rip is the route table RIP itself holds; show ip rip status prints the timers and the per-interface send and receive versions. Note that neither is show ip protocols, which is a Cisco command, and neither is show ip rip database, which FRR does not have.

The pattern: the protocol-specific show command, the forwarding-state command, and the configuration command. The three together identify the layer where the failure is.

Missing aggregate

The aggregate is configured but does not appear in the BGP table (or OSPF LSDB, or RIP database).

Diagnostic sequence:

# 1. Confirm the aggregate is configured
show configuration commands | match aggregate
# Expected on 1.4 and 1.5:
#   set protocols bgp address-family ipv4-unicast aggregate-address 192.0.2.0/22
# If you see the 1.3 form instead:
#   set protocols bgp 64512 aggregate-address 192.0.2.0/22
# then you are reading a runbook, not a router - that path does not
# commit on 1.5.

# 2. Check the components
show ip bgp 192.0.2.0/24
show ip bgp 192.0.3.0/24
show ip bgp 192.0.4.0/24
show ip bgp 192.0.5.0/24

# 3. Check the aggregate
show ip bgp 192.0.2.0/22

# 4. Check the BGP table for the summary
show ip bgp | match 192.0.2

The most common cause: the components are not in the BGP table. The BGP aggregate-address is generated only when at least one more-specific component exists.

Diagnostic: if show ip bgp 192.0.2.0/24 returns nothing, the /24 is not in the BGP table. The aggregate has nothing to summarise.

The fix: bring the components into the BGP table (network statement, redistribution, peer session) or remove the aggregate if it is not needed.

Missing more-specifics (more-specific leaks)

The aggregate is configured with summary-only but the more-specifics are still advertised to the peer.

Diagnostic:

# 1. Confirm summary-only is configured
show configuration commands | match aggregate
# Expected:
#   set protocols bgp address-family ipv4-unicast aggregate-address 192.0.2.0/22 summary-only

# 2. Check the advertised routes
show ip bgp neighbors 10.0.0.2 advertised-routes | match 192.0.2
# Should show only the /22, not the /24s

# 3. Check the BGP table for suppressed status
show ip bgp | match 192.0.2
# The /24s should have the `s` (suppressed) status code

The most common cause: the summary-only keyword is missing or was mistyped.

The fix: add the summary-only keyword and re-commit.

A secondary cause: the outbound route-map on the peer permits the more-specifics despite the summary-only flag. The summary-only flag suppresses the more-specifics at the BGP table level; the outbound route-map is a separate filter.

Attribute loss on the aggregate

The aggregate is advertised but the expected attributes (community, MED, AS-path prepend) are missing.

Diagnostic:

# 1. Check the aggregate's attributes
show ip bgp 192.0.2.0/22

# 2. Check the route-map exists, and then check FRR compiled it.
show configuration commands | match "route-map AGG"

# FRR prints the route-map with its match and set clauses and a
# per-clause hit counter. A clause with a zero counter never fired.
vtysh -c "show route-map AGG-OUT"

# 3. Check what the peer is actually being sent
show ip bgp neighbors 10.0.0.2 advertised-routes 192.0.2.0/22

The most common cause: the route-map is configured but not applied to the aggregate. The aggregate-address statement must end with route-map <name> for the route-map to apply.

The fix: add the route-map keyword to the aggregate-address statement:

set protocols bgp address-family ipv4-unicast aggregate-address 192.0.2.0/22 route-map 'AGG-OUT'
commit

The whole aggregate-address family moved under address-family in 1.4 and stayed there in 1.5, which is worth knowing during a diagnosis specifically because of how it fails: the 1.3 path set protocols bgp 64512 aggregate-address ... is not accepted, so a stale runbook produces a commit error rather than a wrong aggregate. That is the merciful outcome. What is not merciful is a generated configuration that silently drops the line during a template migration and leaves you diagnosing a missing aggregate whose statement was never applied — which is exactly why step 1 of this ladder reads the router rather than the template.

A secondary cause: the route-map is applied but the rule does not match. Verify the route-map’s match conditions.

ICMP unreachable flood

A blackhole for a summary is generating a high rate of ICMP unreachables. The downstream router or upstream peer is sending traffic for unknown specifics inside the summary; the blackhole is discarding; the ICMP rate is hitting the kernel’s rate limit and possibly saturating the source’s ICMP processing.

Diagnostic:

SUSPECT=203.0.113.40

# 1. Confirm the blackhole is what is actually installed.
vtysh -c "show ip route 192.0.2.0/22"

# 2. Read the ICMP counters, including how many the kernel
#    suppressed rather than sent.
nstat -az | grep -i icmp

# 3. Find who is sending the traffic being discarded.
sudo tcpdump -ni eth0 "icmp and host $SUSPECT"

From VyOS operational mode the capture is monitor traffic interface eth0 filter 'icmp', which is the same tcpdump without needing a shell.

The most common cause: a misconfigured upstream peer or local source is sending traffic for the summary without knowing the specifics. The blackhole catches the traffic; the ICMP rate limit absorbs the feedback.

The fix:

• Identify the source and stop the traffic.
• If the source is a downstream router with a stale route, refresh its routing table (clear ip bgp, restart OSPF, etc.).
• If the source is a misconfigured application, fix the application.
• If the source is unavoidable (the upstream peer is legitimate), consider whether the blackhole is the right design or whether the summary should be narrower.

Discontiguous subnets, and what RIP on VyOS actually does

The real diagnostic on VyOS is therefore “who built this summary”, and there are only a few candidates:

# 1. What does RIP actually hold, and at what prefix length?
show ip rip

# 2. What version is running, and on which interfaces?
show ip rip status

# 3. Is something filtering or rewriting the advertisements?
show configuration commands | match 'protocols rip'

# 4. Is the aggregate arriving from somewhere else entirely -
#    a static summary that was redistributed, or a route
#    learned from another protocol that is winning on distance?
show ip route 192.168.1.65

Read step 1 first. If show ip rip holds 192.168.1.0/26 and 192.168.1.64/26 as separate entries, RIP is behaving classlessly and the collapse is happening somewhere else — most often a static summary route that was redistributed into RIP, or a distribute-list trimming the specifics on the way out.

Step 2 matters because RIPv1 interoperability is the one way to get the classful behaviour back on purpose. show ip rip status prints the send and receive versions per interface; an interface sending version 1 is sending updates with no mask, and everything downstream of it is inferring. If that is what you find, the fix is to put the interface back on version 2:

set protocols rip version '2'

Step 4 is the one that closes most of these. A /24 in the routing table that RIP never advertised is coming from somewhere else, and show ip route 192.168.1.65 names the protocol that installed it.

Routing loops with summaries

A summary is advertised but no blackhole is in place. Traffic for an unknown specific is forwarded via the summary’s next-hop; the upstream forwards back; loop.

Diagnostic:

# 1. Check the routing table
show ip route 192.0.2.99
# Should NOT show the /22 summary with a real next-hop
# (the /22 should have a blackhole, not a forwarding next-hop)

# 2. Trace the loop
traceroute 192.0.2.99
# The trace bounces between the local router and the upstream

# 3. Confirm the missing blackhole
show ip route 192.0.2.0/22
# The /22 is a forwarding route (next-hop via the upstream),
# not a blackhole

The fix: install the blackhole.

set protocols static route 192.0.2.0/22 blackhole
commit

Production failure modes summary

The summarisation-specific failure modes:

• Missing aggregate (no components) — components not in the RIB; bring them in or remove the aggregate.
• Missing aggregate (wrong ABR) — area range on the wrong router; configure on the ABR for the area.
• More-specific leaks — summary-only missing or outbound route-map permits the specifics.
• Attribute loss — route-map configured but not applied; route-map rule does not match.
• ICMP unreachable flood — misconfigured source; fix the source, do not raise the rate limit.
• “RIP is summarising by itself” — it is not. FRR’s ripd speaks RIPv2, which carries the mask, and has no auto-summary to switch off. Find what actually built the summary: a redistributed static, a distribute-list, or an interface still sending version 1.
• Routing loop — blackhole missing for a summary that covers blocks the local router does not own.
• Orphaned blackhole — blackhole outlived the summary; remove the blackhole.

Rollback discipline

The summarisation changes are typically small, but the impact is global. The rollback discipline:

• For BGP — delete protocols bgp address-family ipv4-unicast aggregate-address 192.0.2.0/22 and commit. The more-specifics stop being suppressed and reappear immediately; the peer’s table grows by however many components you were hiding, which on a large aggregate is the part to think about before you type it.
• For OSPF — delete protocols ospf area 1 range 10.1.0.0/16 and commit. The ABR resumes generating per-prefix Type-3 LSAs and every router in the backbone re-runs SPF. On a large area that is a real event, not a no-op.
• For a redistributed static summary — delete protocols static route 192.168.1.0/24 and commit, which removes it from every protocol it was being redistributed into at once. That breadth is the point and also the risk: confirm with show ip route on a downstream router rather than on the one you changed.
• For a blackhole — delete protocols static route 192.0.2.0/22 blackhole and commit. Do this only knowing that the loop the blackhole was preventing comes back with it.
• Not rollback N — the VyOS documentation states that it applies the stored revision by rebooting the router. On a box carrying BGP and OSPF adjacencies that converts a summarisation problem into a convergence event across the estate. For a whole-configuration revert, load from /config/archive/, run compare, and commit that.

For all changes, use commit-confirm:

configure
# ... make the change ...
commit-confirm 5
# If the change has unintended consequences, the auto-rollback
# fires after 5 minutes and the previous configuration is restored.

Production discipline

Cross-course references

• Part XXXV-01 through XXXV-05 cover the conceptual, BGP, OSPF, RIP, and blackhole primitives that this lesson assumes.
• Part XXXI-01 (XXXI-VyOS-BGPTroubleshoot / session states) covers the BGP-specific troubleshooting primitives.
• Part XXII-06 (XXII-VyOS-OSPFTroubleshoot / missing route) covers the OSPF-specific troubleshooting primitives.
• Part LII (LII-VyOS-Troubleshoot) covers the general troubleshooting methodology that applies across all subsystems.

Quiz