Blackhole routes for summary prefixes — null0, discard, loop prevention

A summary prefix that covers blocks the local router does not own is a routing loop waiting to happen. The fix is a blackhole route for the summary: the local router’s longest- prefix-match uses the summary for forwarding to unknown specifics, and the discard prevents the packet from being forwarded to a wrong next-hop.

This lesson is the operator’s reference for the blackhole route in the context of summarisation: the configuration, the loop prevention model, the ICMP unreachable behaviour, and the production failure modes that arise when the blackhole outlives the summary or captures traffic the operator intended to forward.

What the blackhole does

The blackhole route installs a static entry in the kernel’s FIB (Forwarding Information Base) with the action “discard”. The router’s longest-prefix-match uses the blackhole for forwarding when no more-specific is available; the packet is silently dropped (with an optional ICMP unreachable reply).

flowchart LR
  P["Packet for 192.0.2.99"]
  LPM["Longest-prefix-match<br/>192.0.2.0/22"]
  BH["blackhole route<br/>(discard)"]
  SPEC["192.0.2.0/24<br/>(specific, if present)"]
  DROP["Discard"]
  P --> LPM
  LPM -- "192.0.2.0/24 exists" --> SPEC
  SPEC --> FWD["Forward via specific"]
  LPM -- "no specific" --> BH
  BH --> DROP

The blackhole is not a forwarding route — it does not have an outgoing interface or a next-hop. It is a discard route; the packet is dropped at the routing decision.

The VyOS configuration

set protocols static route 192.0.2.0/22 blackhole
commit
save

The configuration installs a static route in the kernel’s routing table with the action “blackhole”. The router’s longest-prefix-match uses this route for forwarding any destination inside 192.0.2.0/22 that does not have a more- specific.

The validation:

vyos@r1:~$ show ip route 192.0.2.0/22

Routing entry for 192.0.2.0/22
  Known via "static", distance 1, metric 0
  * directly attached, blackhole

The “directly attached, blackhole” line indicates the discard action. The route is installed in the kernel’s FIB.

The operator can also verify via ip route show:

vyos@r1:~$ ip route show 192.0.2.0/22
blackhole 192.0.2.0/22

The blackhole keyword in the ip route show output is the kernel’s way of indicating the discard action.

The loop prevention model

The blackhole’s role is loop prevention. Consider the topology:

flowchart LR
  R1["R1<br/>192.0.2.0/22 summary<br/>192.0.2.0/24 specific"]
  R2["R2<br/>192.0.2.0/22 summary<br/>(no specific)"]
  R3["R3<br/>192.0.2.0/22 summary<br/>192.0.3.0/24 specific"]
  R1 -- "eBGP peer" --> R2
  R2 -- "eBGP peer" --> R3

R2 does not own any prefix inside 192.0.2.0/22; it has only the summary (learned from R1). Traffic for 192.0.2.99 arrives at R2:

• Without blackhole on R2: R2’s longest-prefix-match uses the /22 summary. The /22’s next-hop is R1 (the upstream). R2 forwards the packet to R1. R1 has the /24 specific 192.0.2.0/24, but 192.0.2.99 is outside 192.0.2.0/24 (it is inside 192.0.2.0/22 but not inside 192.0.2.0/24). R1’s longest-prefix-match for 192.0.2.99 uses… the /22 summary on R1. R1’s /22 has next-hop… R2 (the upstream). Loop.
• With blackhole on R2: R2’s longest-prefix-match uses the /22 summary, but the /22 is a blackhole. R2 discards the packet. No loop.

The discipline: every router that advertises a summary but does not own every component of the summary must have a blackhole for the summary. The blackhole is the loop prevention.

ICMP unreachable behaviour

By default, the Linux kernel generates an ICMP unreachable (Type 3, Code 0: “Network Unreachable”) when it discards a packet via a blackhole route. The ICMP is sent back to the source, which can use the feedback to diagnose the routing issue.

The operator can disable ICMP unreachables:

# (No VyOS-level toggle; use Linux netfilter or sysctl)
sysctl net.ipv4.icmp_ratemask
# Or set per-route via:
set protocols static route 192.0.2.0/22 blackhole
set system sysctl net.ipv4.icmp_ratemask 6168

The blackhole and BGP aggregate interaction

When the operator combines a BGP aggregate-address with a blackhole for the summary, the local router’s RIB has:

1. The BGP aggregate (192.0.2.0/22) — locally originated, advertised to peers.
2. The blackhole (192.0.2.0/22) — static, in the kernel’s FIB.
3. The specific components (192.0.2.0/24, 192.0.3.0/24, …) — from various sources (network statement, redistribution, learned).

The longest-prefix-match for 192.0.2.99:

• The /24 specific (192.0.2.0/24) does not match (192.0.99 is not inside 192.0.2.0/24).
• The /22 summary matches.
• The /22 has two entries: the BGP aggregate (with next-hop 0.0.0.0) and the blackhole. The kernel uses the more specific action; the blackhole wins for forwarding because it is a static, in-kernel action.

The packet is discarded. The BGP aggregate is still advertised to peers; the peers see the /22 and route traffic for 192.0.2.99 to the local router. The local router discards.

flowchart TB
  PEER["Peer sends<br/>packet for 192.0.2.99"]
  RIB["Local RIB"]
  AGG["BGP aggregate 192.0.2.0/22<br/>(next-hop 0.0.0.0)"]
  BH["Static blackhole 192.0.2.0/22<br/>(discard)"]
  DROP["Discard"]
  PEER --> RIB
  RIB --> AGG
  RIB --> BH
  AGG --> DROP
  BH --> DROP

The blackhole and OSPF area range interaction

The same logic applies to OSPF: an ABR with area 1 range 10.1.0.0/16 and a blackhole for the /16 discards traffic for unknown specifics inside area 1.

set protocols ospf area 1 range 10.1.0.0/16
set protocols static route 10.1.0.0/16 blackhole

The ABR generates a Type-3 LSA for 10.1.0.0/16 (the summary). The blackhole is in the kernel’s FIB. Traffic for an unknown specific (e.g., 10.1.99.0/24, which is inside 10.1.0.0/16 but not actually inside area 1) is forwarded to the ABR (via the Type-3 LSA), and the ABR discards via the blackhole.

The discipline: OSPF summarisation without a blackhole at the ABR is the same failure mode as BGP aggregation without a blackhole at the aggregating router.

Validation

# 1. The blackhole is in the routing table
show ip route 192.0.2.0/22

# 2. The blackhole is in the kernel's FIB
ip route show 192.0.2.0/22
# Should show "blackhole 192.0.2.0/22"

# 3. The blackhole is reachable (via the kernel's perspective)
ping 192.0.2.99
# Should fail with "Network is unreachable" (the ICMP unreachable
# is generated by the kernel)

# 4. The blackhole is the only entry for the prefix
show ip route 192.0.2.0/22
# Should show only the static blackhole; the BGP aggregate should
# not appear as a route (it's in the BGP RIB but not installed
# as a kernel route if the blackhole is present)

A clean validation: the blackhole is in place, the ICMP unreachable is generated for unknown specifics, the BGP aggregate is advertised to peers, and the specific components are reachable via their own routes.

Production failure modes

Long-lived blackhole captures new components

The operator advertises the summary, configures the blackhole, and a year later adds a new specific (e.g., 192.0.2.16/28). The new specific has its own route in the RIB; the longest- prefix-match for 192.0.2.17 uses the /28, not the /22. The blackhole does not affect the new specific.

This is not actually a failure mode — the new specific is forwarded correctly. The operator who worries about the blackhole capturing new components can verify: the /28 specific is reachable, the /22 blackhole only catches unknown specifics.

Blackhole outlives the summary

The operator removes the BGP aggregate but forgets to remove the blackhole. The blackhole remains in the kernel’s FIB for months. Traffic for 192.0.2.99 is silently discarded; the operator does not realise the summary is gone and the blackhole is the only thing catching the traffic.

Diagnostic:

• show ip bgp 192.0.2.0/22 — does the aggregate exist? If not, the blackhole is orphaned.
• show ip route 192.0.2.0/22 — does the blackhole exist? If yes, it is the only entry for the prefix.

The fix: remove the blackhole when removing the summary, or audit the blackholes periodically to confirm they are still tied to a live summary.

Unwanted discard captures production traffic

The operator configures a blackhole for the summary but did not realise one of the “unknown” specifics inside the summary is actually a legitimate production destination. The discard silently drops traffic for that destination; the production traffic fails.

Diagnostic:

• show ip route — does any specific inside the summary have a route via a non-discard action?
• traceroute from a downstream router — does the trace hit the local router and disappear?

The fix: remove the blackhole, add a more-specific route for the legitimate destination, or expand the summary to exclude the legitimate destination.

Rollback

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

# Compare
compare

# Remove the blackhole
delete protocols static route 192.0.2.0/22 blackhole
commit

The rollback removes the blackhole. Traffic for unknown specifics inside the summary is now forwarded via the summary’s next-hop (which may be a loop waiting to happen — the operator who added the blackhole in the first place usually had a reason).

The disciplined rollback uses commit-confirm:

commit-confirm 5
# If the rollback causes unintended forwarding (loop), the
# auto-rollback fires and the blackhole is restored.

Production discipline

Cross-course references

• Part XII-04 (XII-VyOS-StaticRouting / blackhole routes) covers the static-route blackhole primitive.
• Part XXXV-01 (XXXV-VyOS-Summarisation / concept) covers the summary vs specific distinction.
• Part XXXV-02 (XXXV-VyOS-Summarisation / BGP aggregation) covers the BGP aggregate-address interaction.
• Part XXXV-03 (XXXV-VyOS-Summarisation / OSPF area range) covers the OSPF ABR summarisation.
• Part XXXV-06 (XXXV-VyOS-Summarisation / troubleshoot) covers the diagnostic method for missing summaries and orphaned blackholes.

Quiz