BGP RTBH — Remotely Triggered Black Hole — is a routing technique that stops a volumetric DDoS attack by dropping the attack traffic upstream, at your transit provider or edge router, before it ever reaches the link you're trying to protect. It's one of the oldest DDoS mitigation techniques still in wide use, precisely because it solves a problem no on-server or edge-appliance defence can: an attack large enough to saturate your transit link doesn't need to reach your servers to take you offline — it just needs to fill the pipe.
The problem RTBH solves
Filtering an attack at your firewall or DDoS appliance only helps if the traffic actually arrives intact. A volumetric flood large enough to exceed your transit capacity congests or saturates the link itself — every packet, legitimate or not, competes for the same bandwidth. By the time attack traffic reaches your edge to be filtered, the damage to availability is already done. RTBH moves the block upstream, to a router that has the capacity to absorb and discard the flood before it consumes your link.
How it works, step by step
- An attack is detected against a specific destination IP on your network.
- That IP is tagged with a special BGP community string, agreed in advance with your upstream provider, that means "black-hole this route."
- A /32 route for the attacked IP is advertised via BGP — typically over iBGP to your own edge routers, or via eBGP to an upstream transit provider — with its next-hop set to a discard address (commonly
Null0). - Upstream routers install the black-hole route and begin silently dropping all traffic destined for that IP, at a point in the network with far more capacity to absorb the flood than your own link.
- The attack traffic never reaches you — and, just as importantly, never consumes transit capacity that other traffic on the same link needs.
The trade-off: RTBH blocks the destination, not the attacker
RTBH is a blunt instrument by design. It doesn't distinguish attack traffic from legitimate traffic to the same IP — everything destined for that address gets dropped upstream, meaning the attacked host becomes unreachable to real users too. For a single service under a large volumetric flood, that's usually still the better outcome: a short, controlled outage for one IP beats a saturated link taking down everything behind it. It's also why RTBH is typically reserved for confirmed, large-scale volumetric attacks rather than every blocked IP — and why more surgical alternatives exist for cases where blackholing an entire destination is too costly, a trade-off worth understanding before choosing a mitigation strategy.
Why ISPs and network operators rely on it
For an ISP, the stakes are higher than for a single enterprise: an attack against one customer's prefix can saturate shared upstream transit and degrade service for every other customer on the same link. RTBH lets an operator protect the shared network first, then work the specific incident — which is why it's a standard tool in ISP and network-operator DDoS playbooks, not just an enterprise one.
How eHAWK DDoS automates RTBH
Configuring and withdrawing black-hole routes by hand during a live attack is slow and error-prone at exactly the moment speed matters most. eHAWK DDoS, Hexalon's DDoS protection platform, automates the whole loop: the moment an attacking IP is blocked, eHAWK advertises the RTBH route to your upstream router automatically, with configurable AS number, peer AS, neighbor IP, next-hop and community string. A live route table view shows exactly what's currently black-holed, routes automatically resync after a restart, and an effectiveness report shows how much traffic was stopped at the router versus only at your server — the number that justifies the RTBH build-out to management in the first place.