DDoS Blackhole Routing (RTBH): Last-Resort Traffic Dropping at Network Level

It was 2:47 AM on a Saturday in late 2018 when our NOC watched a 1.2 Tbps carpet-bombing attack light up every edge PoP from Frankfurt to Singapore. Scrubbing was saturated, upstream transits were flapping, and even our anycast steering couldn't keep the origin links alive. That's when my colleague hit the RTBH trigger — we null-routed a single /32 under attack and the entire network exhaled. Blackhole routing isn't elegant, and it isn't supposed to be. It is the last-resort hammer you pull when you can't absorb anymore and you'd rather drop traffic completely than let it take everything else down with it.

When Scrubbing Isn't Enough: Where Blackhole Routing Actually Fits

After a decade running CDN edge infrastructure, I've learned there's a hierarchy to DDoS mitigation and most teams get it backwards. You don't start with blackholing. You start with absorption and filtering — anycast diffusion, scrubbing centers, stateless ACLs, and rate limiting at the edge. If you're dealing with classic bandwidth floods, you'll want to have read up on DDoS Volumetric Attack Patterns: Identifying and Absorbing Bandwidth Floods first. Blackholing sits at the very bottom of that stack. It doesn't mitigate. It sacrifices.

I've seen junior teams trigger RTBH too early because panels make it easy — one click in a portal and the prefix is gone globally. But that /32 you just blackholed is completely offline to legitimate users too. That's the trade-off you’re making. We only authorize destination-based RTBH when we've confirmed two conditions: 1) the attack volume will cause collateral congestion for neighboring prefixes or customers sharing the same uplinks, and 2) scrubbing and filtering have failed to bring link utilization below 85% for more than 3 minutes. If you haven't hit both, you aren't ready for traffic dropping. You're just hiding the alert.

There's also a common misconception that blackhole routing is the same as shutting down an interface. It isn't. You're not withdrawing the route; you're re-advertising it with a specific community that tells every router in your AS — and often your peers — to forward that traffic to Null0. The prefix stays in BGP, so you don't trigger route flap dampening everywhere, but the next-hop is rewritten to a discard interface. Here's the trigger configuration we run on our dedicated RTBH route reflector (Cisco IOS XR style) — it's been largely unchanged since 2017 because it just works:

! RTBH Trigger - Do not redistribute into production RRs
router bgp 64512
 address-family ipv4 unicast
  network 192.0.2.0/24 route-policy RTBH-TRIGGER
 !
 neighbor 203.0.113.1 remote-as 64512
  address-family ipv4 unicast
   route-policy RTBH-OUT out
   send-community-ebgp
 !
community-set RTBH-COMMUNITY
  64512:666
end-set

route-policy RTBH-TRIGGER
  if community matches-any RTBH-COMMUNITY then
    set next-hop 192.0.2.1  ! RFC 7999 blackhole next-hop
    set local-preference 200
  endif
end-policy

! On all edge routers:
interface Null0
 description RTBH discard - do not monitor
!
router bgp 64512
 address-family ipv4 unicast
  bgp blackhole next-hop 192.0.2.1

Destination vs. Source RTBH: Two Tools That Don't Do the Same Job

Most engineers only ever touch destination-based RTBH (D/RTBH), where you blackhole traffic headed to the victim IP. It's simple, fast, and dangerously effective. You tag the victim's /32 with 64512:666, your trigger advertises it, and within seconds every edge router drops it. We've automated this so our detection system can propose a D/RTBH for any IP pushing over 400 Gbps for more than 90 seconds, but it still requires a human ACK. I don't trust full automation for something that’s functionally an outage you inflict on yourself.

Source-based RTBH (S/RTBH) is the one that has burned us more than once, so I’m cautious recommending it. Instead of dropping traffic to the victim, you're dropping traffic from a spoofed source or botnet range before it ever traverses your core. It sounds ideal for reflected attacks, especially when you're dealing with DDoS DNS Amplification Defense: Stopping Reflected Attacks at CDN Scale, and for DDoS Application Layer Attack Techniques: Slowloris, RUDY, and HTTP Floods where source validation might help. But S/RTBH only works if you've got strict unicast Reverse Path Forwarding (uRPF) deployed consistently on every ingress interface. Without it, the router has no way to validate the source and enforce the discard. We learned this the hard way in 2021 when a partial uRPF rollout meant our S/RTBH policy only dropped 60% of spoofed traffic in Ashburn while completely blackholing legitimate traffic in Amsterdam where loose uRPF was misconfigured.

If you are going to run S/RTBH, your edge config needs to be explicit about it. On Juniper MX, where most of our PoPs terminate, the difference is one line that people always miss. You must tie the discard to the uRPF check, not just to the static route:

/* Source RTBH - Requires strict-mode uRPF on customer/peer interfaces */
routing-options {
    static {
        route 198.51.100.0/24 {
            community [ 64512:666 S-RTBH ];
            discard;
            inactive: no-resolve;
        }
    }
}
policy-options {
    community S-RTBH members 64512:667;
    policy-statement RTBH-SOURCE {
        term 1 {
            from community S-RTBH;
            then {
                next-hop 198.51.100.1; /* discard next-hop */
                accept;
            }
        }
    }
}
interfaces {
    xe-0/0/0 {
        unit 0 {
            family inet {
                rpf-check {
                    mode strict;
                    fail-filter RTBH-LOG;
                }
                address 203.0.113.2/30;
            }
        }
    }
}
/* Verify with: show route protocol static + show interfaces extensive | match RPF */

Trigger Architecture, Propagation Speed and the Real Cost of Dropping

How you inject the blackhole matters as much as which type you use. In the early days we let any edge router act as a trigger — convenient, but it led to route reflector loops and inconsistent communities when two NOC engineers triggered overlapping /32s at once. Now we isolate it. We run two dedicated trigger routers (one per region) that peer via iBGP to all edge routers but never carry transit traffic themselves. They are the only devices allowed to originate the 192.0.2.1 next-hop. That single design change cut our global propagation time from 45-60 seconds down to under 7 seconds, and it gave us auditability. Every RTBH announcement is logged to our SIEM with who triggered it, TTL, and the associated ticket. For protocol-level context on how communities and next-hops are actually signaled, I still point new engineers to the HTTP Working Group Specifications for HTTP-layer behavior and the web.dev Articles for a clear view of how browser and transport impacts manifest when you abruptly drop traffic — even if RTBH itself lives down at BGP.

Don't kid yourself that RTBH is free just because the router CPU impact is near zero. Forwarding to Null0 is cheap for the box, but expensive for the business. That dropped prefix is still counted against your BGP table, your monitoring will scream, and if you're doing remote-triggered blackholing with an upstream provider (RTBH via BGP community 43350:666 or 64999:0 depending on the carrier), you might be blackholing well beyond your own AS. I've seen carriers honor our blackhole community for 2-4 hours after we withdrew it because their import policy had a longer hold timer. Always set a max TTL — we use 4 hours by default, 30 minutes for customer-initiated triggers — and automate the withdrawal.

We benchmark every method quarterly in our lab PoP using replayed attack pcaps. The numbers below are from our last run in Q1 2024 on MX204 and ASR 9901 platforms at 100G ingress. Your hardware will vary, but the ratios hold:

Putting RTBH Into Production: Trigger Router to Edge in Under 5 Seconds

We've all been there at 3 AM — your scrubbing center is pegged at 800 Gbps, latency's spiking to 400ms, and the upstream's calling about saturated peering links. That's when you pull the RTBH trigger. The implementation itself isn't complex, but you've got to get the plumbing right *before* the attack hits. At its core, you're using iBGP to weaponize your own routing table. You designate a trigger router (it doesn't even need to forward traffic) and have all your edge and border routers listen to it. When you inject a /32 (or /128 for v6) with a blackhole community, every edge router installs a discard route in under 2-3 seconds. No manual hop-by-hop config.

The classic setup uses RFC 7999's well-known BLACKHOLE community (65535:666) or a provider-specific one like 64999:0, with next-hop set to 192.0.2.1 — an address you’ve pre-configured on every edge router to point to Null0. Don't use 0.0.0.0 or you'll create headaches with your monitoring. We typically set next-hop 192.0.2.1/32 to discard and tag it with no-export so it never leaks to peers or transit. If it does leak, you're effectively asking the entire internet to drop traffic to your customer — that's a career-limiting event. That's why we always pair the trigger with strict inbound filters on border sessions: deny any incoming prefix with our blackhole community unless it's from our own trigger.

For destination-based RTBH, the trigger announcement is brutally simple. Source-based RTBH (S/RTBH) is where folks stumble — it relies on loose uRPF on the edge to drop traffic where the *source* matches the blackholed prefix, which won't work if your edge does strict uRPF or if you're not fully controlling the ingress path. We'll stick to destination for most last-resort cases. Compared to surgical filtering for something like DDoS NTP Reflection Mitigation: Blocking Monlist-Based Amplification Attacks, RTBH isn't surgical at all — it's an amputation. But when a 1.5 Tbps DDoS Memcached Amplification Defense: Neutralizing 51,000x Amplification Factor is melting your core, amputation keeps the patient alive.

! --- On EVERY edge/border router (pre-config, one time) ---
ip route 192.0.2.1 255.255.255.255 Null0
!
router bgp 64512
 bgp listen limit 200
 neighbor RTBH-Trigger peer-group
 neighbor RTBH-Trigger remote-as 64512
 neighbor RTBH-Trigger update-source Loopback0
 neighbor RTBH-Trigger send-community
 neighbor 10.255.0.1 peer-group RTBH-Trigger ! Trigger router IP
!
route-map RTBH permit 10
 match community BLACKHOLE
 match ip address prefix-list RTBH-TRIGGER
 set ip next-hop 192.0.2.1
 set community no-export
 set local-preference 200
!
ip community-list standard BLACKHOLE permit 65535:666
ip prefix-list RTBH-TRIGGER seq 5 permit 192.0.2.1/32

! --- On Trigger Router (when under attack) ---
router bgp 64512
 network 203.0.113.45 mask 255.255.255.255 route-map SET-BLACKHOLE
!
route-map SET-BLACKHOLE permit 10
 set community 65535:666 no-export
 set ip next-hop 192.0.2.1
 set origin igp
! Announce and withdraw in <3 seconds across full iBGP mesh with BFD + tuned BGP timers

Advanced Patterns: S-RTBH, Flowspec Hybrids and Why Your Blackhole Leaked

Once you've got basic D/RTBH automated, the next maturity level isn't faster blackholing — it's more selective dropping. That's where S/RTBH and BGP Flowspec come in. S/RTBH lets you drop based on source when the attack sources are concentrated in a few networks, which we see a lot less often now that botnets are so distributed. You'll configure ip verify unicast source reachable-via any on edge interfaces and the same trigger mechanism, but now the discard happens on ingress lookup of the source address. It’s powerful for blocking a persistent reflection source without nuking your own destination, but if your upstreams don't honor it consistently, traffic from other ingress points will still hit you. We only enable S/RTBH on customer-facing edges where we control uRPF loose-mode explicitly.

The smarter pattern we've moved to is RTBH as a failsafe under Flowspec. Think of it as a layered defense: Flowspec gives you 5-tuple granularity (drop UDP port 11211 to 203.0.113.45/32 at 95% reduction) and RTBH is the big red button when Flowspec can't keep up or your Flowspec controller is overwhelmed. In production, we automate this with a tiered response — Flowspec rate-limit at 100 Mbps, then Flowspec discard, then RTBH if the edge CPU or link utilization stays above 92% for 60 seconds. And for the nightmare scenario that breaks both models, DDoS Carpet Bombing Defense: When Attackers Spread Traffic Across Your Entire Subnet — where attackers spray 50k pps across your entire /22 instead of hammering one IP — a single /32 blackhole won't save you. You'll need to blackhole the whole subnet or dynamically trigger Flowspec to block the carpet across the range. Don't learn this during an attack.

Troubleshooting is mostly about what *didn't* happen. If your trigger announcement isn't propagating, check three things immediately: 1) Did you forget `send-community` on the iBGP session to the reflector? We've seen this kill deployments. 2) Is your route-reflector correctly reflecting the community? By default some IOS-XR versions strip it. 3) Did your blackhole static route actually get installed? `show ip route 192.0.2.1` should show Null0 on every edge — if it's missing after a reboot, your discard fails open and you just advertised a reachable next-hop. Also monitor withdrawal carefully. We've seen triggers left active for 14 hours after an attack ended because the NOC forgot to withdraw. Set a TTL — our tooling auto-withdraws any RTBH after 4 hours unless re-confirmed. And always log: we export every trigger/withdraw to syslog and BMP so you can prove to a customer why their IP was unreachable for 22 minutes.

Frequently Asked Questions