Blackhole routes — silent drops for martians, aggregation, and DDoS mitigation

A blackhole route is a static route that matches a prefix and drops the packet silently — no forwarding, no ICMP unreachable, no notification. The route is in the RIB, the FIB has the prefix, the kernel accepts packets that match, and the packets disappear into the void. The blackhole pattern is one of the cleanest ways to defend a network against unwanted traffic: martian prefixes, BGP route aggregation with discard semantics, and DDoS mitigation all use it. This lesson covers the blackhole model in VyOS 1.5 LTS, the configuration idiom, and the production use cases the operator must recognise.

What a blackhole route is

flowchart TD
  A[Packet to 10.20.0.5] --> B[Kernel FIB lookup]
  B --> C{Longest-prefix match}
  C -->|match in blackhole| D[Drop silently]
  C -->|match in normal route| E[Forward to next-hop]
  C -->|no match| F[ICMP unreachable or default]
  D --> G[No ICMP generated]
  D --> H[Counter increments in FIB]

A blackhole route is a static route with the blackhole attribute. The kernel installs the route in the FIB with a special flag that tells it to drop packets that match. The drop is silent: no ICMP unreachable is sent, the source receives no signal that the packet was dropped, and the packet simply does not arrive at any destination.

The blackhole attribute renders to FRR as the blackhole keyword on the ip route line. The kernel installs the route with the RTN_BLACKHOLE type in the FIB. The kernel drops packets that match and increments a counter; the counter is visible in ip route show type blackhole.

The configuration idiom

A blackhole static route is a single set line with the blackhole attribute:

[edit]
vyos@vyos# set protocols static route 10.20.0.0/16 blackhole
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# save

The route is installed in the FIB as a blackhole. The route appears in show ip route:

vyos@vyos:~$ show ip route 10.20.0.0/16
S   10.20.0.0/16 [1/0] via 0.0.0.0, blackhole, weight 1

The route is S (static). The via 0.0.0.0 is the kernel’s representation of a blackhole. The weight 1 is the FRR weight (used in ECMP selection). The * for FIB installation is present for blackhole routes too — the route is in the FIB, the kernel is just dropping packets that match.

The kernel view:

vyos@vyos:~$ ip route show type blackhole
blackhole 10.20.0.0/16

The type blackhole filter is the canonical way to list all blackhole routes. The kernel tracks each one with a counter that increments for every dropped packet; the counter is visible in ip -s route show type blackhole.

Blackhole vs reject

The reject attribute is similar but generates an ICMP Destination Unreachable back to the source:

[edit]
vyos@vyos# set protocols static route 10.20.0.0/16 reject
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# save

The route is installed in the FIB with the RTN_UNREACHABLE type. The kernel drops packets that match and sends an ICMP Destination Unreachable (type 3, code 0) to the source.

vyos@vyos:~$ ping -c 3 10.20.0.5
PING 10.20.0.5 (10.20.0.5) 56(84) bytes of data.
From 192.0.2.1 icmp_seq=1 Destination Net Unreachable
From 192.0.2.1 icmp_seq=2 Destination Net Unreachable
From 192.0.2.1 icmp_seq=3 Destination Net Unreachable

--- 10.20.0.5 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

The host sees the unreachable. With blackhole, the host sees timeouts because no ICMP is sent:

vyos@vyos:~$ ping -c 3 10.20.0.5
PING 10.20.0.5 (10.20.0.5) 56(84) bytes of data.

--- 10.20.0.5 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss

The choice between blackhole and reject is operational. For a martian prefix that should never be reachable, the silent drop is preferred — the router does not generate ICMP that could be used for an ICMP-based DoS. For a prefix that should be reachable but the egress is misconfigured, reject gives the operator an immediate signal that the prefix is not forwarded.

Martian prefix handling

A martian prefix is a prefix that should never appear in the public routing table — RFC 1918 private space, the loopback range (127.0.0.0/8), the link-local range (169.254.0.0/16), and the IETF reserved ranges. A router connected to the public Internet should drop traffic to these prefixes silently; they are not valid destinations from outside the local network.

The standard defence is a blackhole route for each martian prefix. The route catches the packet before it can be forwarded to an upstream that might not drop it.

[edit]
vyos@vyos# set protocols static route 10.0.0.0/8 blackhole description 'RFC 1918'
[edit]
vyos@vyos# set protocols static route 172.16.0.0/12 blackhole description 'RFC 1918'
[edit]
vyos@vyos# set protocols static route 192.168.0.0/16 blackhole description 'RFC 1918'
[edit]
vyos@vyos# set protocols static route 127.0.0.0/8 blackhole description 'loopback'
[edit]
vyos@vyos# set protocols static route 169.254.0.0/16 blackhole description 'link-local'
[edit]
vyos@vyos# set protocols static route 224.0.0.0/4 blackhole description 'multicast'
[edit]
vyos@vyos# set protocols static route 240.0.0.0/4 blackhole description 'reserved'
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# save

Each martian prefix has a blackhole route with a description. Traffic to the prefix is dropped at this router; the upstream never sees it.

The martian-prefix pattern is often augmented with a set firewall network-group martian-ipv4 and a matching input chain on the upstream-facing interface, but the blackhole route is the cheaper defence. A route lookup is O(1); a firewall rule lookup is O(n) in the chain.

BGP route aggregation with blackhole

A site that aggregates multiple specific prefixes into a summary prefix has a problem when some of the specifics are not reachable. The summary still advertises the aggregate, but the traffic for the unreachable specific gets forwarded into a black hole inside the site.

The standard defence is a blackhole route for the aggregate that is the only route for the prefix until a specific route is installed. When the specific route is installed, it overrides the aggregate; the specific traffic is forwarded correctly. When the specific route is withdrawn, the aggregate blackhole takes over; the traffic is dropped silently at the edge.

[edit]
vyos@vyos# set protocols static route 10.0.0.0/8 blackhole description 'aggregate-anchor'
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# save

The aggregate-anchor blackhole is at distance 1 (the static default). When a more-specific route is installed (e.g. from a connected interface, a dynamic protocol, or another static), the specific wins the longest-prefix-match and the traffic is forwarded. When the specific is withdrawn, the aggregate blackhole is the most-specific route and the traffic is dropped at the edge.

The pattern is called “summary-only with blackhole” or “discard prefix” depending on the vendor. The VyOS form is a static blackhole. The BGP form would be a bgp aggregate- address with a discard route in the IGP.

DDoS mitigation with BGP BLACKHOLE community

The BGP BLACKHOLE community (RFC 7999) is a standard BGP community that signals to a provider that the customer wants the provider to drop traffic for the announced prefix. The customer detects the attack, announces the prefix with the BLACKHOLE community, and the provider installs a blackhole route for the prefix at the provider edge.

The customer’s local configuration is a static blackhole for the attacked prefix. The route is installed at the customer edge; the customer’s network does not carry the attack traffic. The provider’s blackhole is installed at the provider edge; the attack traffic is dropped before it reaches the customer.

[edit]
vyos@vyos# set protocols static route 10.20.0.0/16 blackhole description 'DDoS-mitigation-target'
[edit]
vyos@vyos# set policy route-map RM-BGP-BLACKHOLE rule 10 action permit
[edit]
vyos@vyos# set policy route-map RM-BGP-BLACKHOLE rule 10 set community 65535:666
[edit]
vyos@vyos# set protocols bgp neighbor <provider> address-family ipv4-unicast route-map RM-BGP-BLACKHOLE out
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# save

The customer configures the static blackhole and a route-map that sets the BLACKHOLE community. The provider’s BGP configuration recognises the community and installs a blackhole at the provider edge. The attack traffic is dropped at the provider; the customer network is unaffected.

How the result is validated

The validation command set confirms the blackhole is active:

vyos@vyos:~$ show ip route 10.20.0.0/16
S   10.20.0.0/16 [1/0] via 0.0.0.0, blackhole, weight 1

The blackhole keyword confirms the route type. The via 0.0.0.0 is the kernel’s representation.

vyos@vyos:~$ ip route show type blackhole
blackhole 10.20.0.0/16

The kernel confirms the route type.

The traffic test confirms the drop:

vyos@vyos:~$ ping -c 3 10.20.0.5
PING 10.20.0.5 (10.20.0.5) 56(84) bytes of data.

--- 10.20.0.5 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss

The host sees timeouts. No ICMP unreachable. The packet disappeared.

The counter test confirms the drop is happening:

vyos@vyos:~$ ip -s route show type blackhole
blackhole 10.20.0.0/16
    packets 0 bytes 0

After the ping, the counter increments. The drop is real.

How it fails

The production failure modes the engineer must recognise:

• Blackhole on the wrong prefix. A typo in the prefix matches the wrong traffic. A site becomes unreachable because the operator blackholed its own prefix.
• Blackhole without a more-specific. A blackhole for a summary with no more-specific route. The summary advertises reachability; the blackhole drops the traffic. The site is unreachable.
• Reject instead of blackhole. A reject route generates ICMP unreachable. The ICMP can be used for an ICMP-based DoS. The operational intent was silent drop; the configuration produced ICMP generation.
• Missing martian coverage. A martian prefix that is not in the blackhole list. The traffic is forwarded to the upstream, which may or may not drop it.
• DDoS mitigation without provider coordination. A customer blackhole for an attacked prefix without coordinating with the provider. The traffic is dropped at the customer edge, but the customer’s upstream is still carrying the attack traffic. The provider’s resources are consumed.

Rollback

The recovery from a bad blackhole configuration:

• Wrong prefix: delete protocols static route <prefix> blackhole; commit; save.
• Wrong description: set protocols static route <prefix> blackhole description <correct>; commit; save.
• Convert blackhole to reject: delete protocols static route <prefix> blackhole; set protocols static route <prefix> reject; commit; save.
• Convert reject to blackhole: delete protocols static route <prefix> reject; set protocols static route <prefix> blackhole; commit; save.
• Whole-tree rollback: rollback N; commit; save.

Production discipline

Cross-course references

The BGP course’s XXIX-BGP-Communities covers the BLACKHOLE community and how a provider’s BGP configuration recognises it. The Firewall course’s XXXVII-Firewall covers the netfilter chains that can complement the blackhole for finer-grained filtering. The Observability course’s XLIX-Monitoring covers the packet counters and the metrics that prove the blackhole is doing its job.

Quiz