What Is Blackhole Routing?

Blackhole routing is a network defence that sends every packet bound for a chosen IP address or prefix to a null interface, where the router discards it without a reply. Operators reach for it when a flood is large enough to saturate transit links, because a drop at the edge costs almost nothing in CPU, memory, or session state. The trade is deliberate and brutal: the targeted address goes dark for everyone, attacker and customer alike. This guide covers the mechanics, destination and source triggering, the BGP signalling that carries a blackhole request between networks, and the point where blackholing stops being the right answer.

Key Takeaways

• Blackhole routing installs a route whose next hop is a discard interface, so matching packets are dropped in the forwarding path with no state and no reply.
• It protects the network around the target rather than the target itself. The blackholed address stops answering for legitimate users too.
• Destination-based triggering matches the victim address and runs on any router. Source-based triggering matches attacker addresses and needs loose-mode uRPF.
• Remote Triggered Black Hole filtering turns one static route on a trigger router into a network-wide drop through iBGP, usually within seconds.
• The BLACKHOLE community 65535:666, standardised in RFC 7999, asks an upstream provider or an internet exchange to drop the traffic before it reaches your link.
• Blackholing is the fastest mitigation available and the least precise, so it belongs in the response plan as a first move, not a resting state.

How Blackhole Routing Drops Traffic Before It Hits Your Network

Blackhole routing works by installing a route whose next hop points to a discard interface. Once that route sits in the forwarding table, the router drops every packet matching the prefix at line rate, and on most carrier platforms it does so in hardware.

The router never inspects the payload, never opens a session record, and never sends an ICMP unreachable back to the sender. It performs the destination lookup, finds the null next hop, and the packet ends there. That is why the technique holds up when nothing else does. A drop costs about the same whether you are discarding 2 Gbps or 2 Tbps.

Compare that with a stateful device. A firewall tracking connections has a table with a hard ceiling, and a flood that fills the table takes the firewall down along with the service behind it. A null route has no table to fill and no session to exhaust.

Blackholing sits at the blunt end of the DDoS mitigation techniques a network operator can reach for. It is also the one that works when the attack is already bigger than your capacity, which is the situation the others were never designed for.

Two details make the mechanism concrete. RFC 5635, the IETF document that describes the practice, uses 192.0.2.1 as a fixed discard next hop and points that address at Null0, so any prefix resolving through it disappears. And Scale explains why operators still keep the option loaded: Cloudflare mitigated 935 network-layer attacks above 1 Tbps in the first half of the year, while 96.62% of network-layer attacks it saw stayed under 500 Mbps. Blackholing is the tool for the tail, not the median.

You might be thinking that dropping every packet to the target is exactly the outcome the attacker was paying for. That is correct, and it is the honest starting point for the rest of this guide. The question is never whether blackholing hurts. It is whether it hurts less than a saturated uplink taking every other customer down with it.

What happens the instant the route installs:

• Every packet destined for the matched prefix is discarded in the forwarding path.
• Upstream links stop carrying attack volume toward that prefix, so congestion clears for neighbouring services.
• The target address becomes unreachable from the whole internet, not just from the attacker.
• Return traffic for sessions that were already open dies with it, so expect a wave of application timeouts.

The next choice decides who actually loses service, and it comes down to what you match on.

Destination-Based vs Source-Based Blackhole Routing

Blackhole routing comes in two variants that share a discard route and share almost nothing else. Destination-based blackholing matches the address under attack. Source-based blackholing matches the addresses doing the attacking.

Destination-based blackhole routing

You announce a route for the victim address, usually a /32 for IPv4 or a /128 for IPv6, with the discard next hop. Everything sent to that address dies at the first router holding the route. No special feature is required, which is why it works on almost any platform in production today.

The cost is total. The address serves nobody until you withdraw the route, so the useful case is narrow: a single host or VIP that is absorbing a saturating flood and whose loss is cheaper than the loss of everything sharing the same uplink.

Source-based blackhole routing

Source-based blackholing installs discard routes for attacker prefixes and relies on loose-mode unicast reverse path forwarding to act on them. With loose uRPF enabled on the ingress interface, the router checks whether a route back toward the packet’s source exists. If the only route resolves to the discard next hop, the packet is dropped on arrival.

The upside is that the victim keeps serving everyone who is not on the list. The downside shows up fast. Spoofed source addresses make the match meaningless, and a botnet spread across tens of thousands of residential addresses produces a list too long and too volatile to maintain. Source-based filtering is closer in spirit to the custom IP lists you maintain at the application edge: excellent against a small, stable set of offenders, useless against a distributed one.

Knowing which one to reach for is only half the problem. The other half is getting the decision onto every router in the network at once.

How Remote Triggered Black Hole (RTBH) Filtering Works

Remote Triggered Black Hole filtering lets one operator, on one router, drop a flood across an entire network. You add a static route on a trigger box, iBGP carries it to every edge router, and the discard next hop does the rest.

Logging into forty routers during an attack is not a plan. RTBH exists so that the response is a single action with a single point of audit, which also means a single place to undo it.

1. On the trigger router, add a static route for the target prefix pointing at a documented discard address, tagged so a policy can find it.
2. A route-map matches the tag, rewrites the next hop to the discard address, raises local preference, and attaches the internal blackhole community plus NO_EXPORT.
3. The static route is redistributed into iBGP and propagates to every edge router in the AS.
4. Each edge router already has the discard address routed to its null interface, so the prefix resolves to a drop in its forwarding table.
5. To push the drop off your own links, send the prefix to the upstream provider tagged with the community they publish for blackholing.

The configuration is short enough to read in one pass. This is the announcing side, following the pattern in RFC 5635:

Two operational habits separate a network that survives its own RTBH from one that does not. Restrict the receiving policy to host routes with an empty AS path so a leaked or malformed announcement cannot black out a whole aggregate. And keep the discard address inside documentation space such as 192.0.2.0/24, so nobody accidentally routes it somewhere real.

RTBH runs above your security stack rather than inside it. Teams that already rely on advanced firewall integration at the edge sometimes assume the firewall covers this case, but a blackhole route is what keeps the flood off the link that firewall sits behind. The two solve different halves of the problem.

Dropping traffic inside your own AS still means the attack rode your transit to get there. The fix for that is a community your upstream already understands.

What the BLACKHOLE Community 65535:666 Does for You

The BLACKHOLE community is a well-known BGP community, value 65535:666, that tells a receiving network to discard traffic for the announced prefix. It was standardised in RFC 7999 so operators could stop maintaining a different blackhole community per provider.

Before it existed, every transit provider and exchange published its own value, so the response to an attack began with looking up which value applied to which session. A single well-known value takes that lookup off the critical path.

“666, a value commonly associated with BGP blackholing among network operators”

Three rules govern how the community is meant to be handled. Announcements carrying it should also carry NO_EXPORT, so the request stops at the neighbouring AS instead of propagating across the internet. Receiving networks are expected to accept more-specific prefixes down to /32 for IPv4 and /128 for IPv6, which is an explicit exception to the usual filtering minimum. And the receiver still has to validate that the announcing peer is entitled to that address space, because a community carries no authorisation on its own.

Adoption is what makes the value useful. Internet exchanges on several continents accept it on their route servers, and transit providers that offer blackholing at all increasingly publish 65535:666 as the value to send. If your traffic already arrives over an Anycast Network, you get a related benefit for free: the flood is split across many points of presence, so a blackhole applied at one site removes far less of your reachable surface than a blackhole applied at a single origin.

Signalling is solved. Deciding when to send the signal is not.

When Blackhole Routing Is the Right Call During a DDoS Attack

Blackhole the traffic when the attack volume exceeds what your links or your scrubbing path can absorb, and when the address under attack is worth less than everything sharing that path. Outside those conditions, a finer filter is almost always better.

The judgement changes minute by minute. An attack that starts at 40 Gbps against a marketing landing page is an easy call. The same volume against a payment API is not, and the answer flips again if the attack climbs past your transit capacity.

A pure bandwidth flood is the clearest case. A volumetric DDoS attack measured in hundreds of gigabits does not care how clever your application-layer rules are, because the packets never reach the application. Amplification patterns behave the same way. In a Smurf attack, the victim receives a torrent of ICMP replies from networks that were themselves abused, so there is no meaningful source list to filter on and no payload signature to match.

Signals that argue for pulling the trigger:

• Interface counters show sustained input drops on transit or peering links.
• The attack targets a single address rather than a spread of services.
• Detection cannot classify the traffic quickly enough to build a specific filter.
• Neighbouring customers or internal services are already degraded by congestion.

Signals that argue against it:

• The address handles revenue or safety-critical traffic.
• The attack fits comfortably inside your capacity and can be filtered on port, protocol, or rate.
• You would have to blackhole an aggregate prefix because the specific host route will not propagate.

Which brings up the part most write-ups skip: the bill.

What Blackholing Actually Costs You

Blackholing hands the attacker the availability outcome they wanted for the targeted address, and it does so with your own routers. The gain is that the loss stops at that address instead of spreading across every link between you and your upstreams.

Yes, it works. But the research on how it works in production is less flattering than the vendor framing. A measurement study of blackholing across public and private BGP datasets found the practice widespread and effective at the packet level, while also confirming that the drops include real user traffic.

“blackholing is indeed highly effective in dropping traffic before it reaches its destination”

The same study measured how far the practice has spread. More than 250 transit, access, and content networks offer a blackholing service, along with roughly 50 internet exchanges. Over the three-year window the researchers tracked, the count of blackholed prefixes grew sixfold, peaking near 5,000 concurrent prefixes announced by up to 400 autonomous systems. That is not a rarely used emergency lever. It is routine infrastructure, running constantly, quietly removing addresses from the internet.

Three costs are worth naming plainly. Legitimate users of the address lose service for the full duration. Any prefix broader than a host route takes unrelated services down with it. And every black hole is a signal to the attacker that pressure works, which is exactly the feedback loop extortion campaigns are built on.

The way out is capacity you do not own the whole cost of. Absorbing a flood at layer 4 DDoS protection scale means the transport-layer flood is spread across a distributed edge instead of arriving on one link, and a service such as L4 Shield filters TCP and UDP floods before the question of blackholing comes up at all. Blackholing then becomes the last resort it was designed to be.

Seeing where it sits against the alternatives makes the trade easier to argue in a change review.

Blackhole Routing vs Scrubbing, FlowSpec, and Edge Filtering

Blackhole routing is the fastest and least selective option on the shelf. Every alternative buys precision by spending time, money, or both.

BGP FlowSpec is the closest relative. It distributes match criteria rather than a discard route, so you can drop or rate-limit by protocol, port, packet length, or fragment flags instead of by destination alone. It carries a real cost in hardware support and in the operational care needed to keep a bad rule from spreading, but it answers the exact complaint people have about blackholing.

Scrubbing centres take the opposite approach. Traffic is diverted, inspected, cleaned, and returned, which preserves service for real users at the price of added latency and a diversion that takes minutes to converge. Edge filtering closes the gap for application-layer floods, where rate limiting caps requests per client without touching anyone else, and a content delivery network absorbs volume across many points of presence so no single origin sees the full load.

In practice, these layers rather than compete. CDN-based DDoS protection handles the daily background noise, load balancing keeps a single origin from becoming the pressure point, and blackhole routing waits in the runbook for the day something arrives that none of them can hold. The networks that ride out large attacks are rarely the ones with the cleverest single control. They are the ones that practised the handoff between controls.

Practising it starts with building the trigger path properly.

How to Set Up Blackhole Routing Without Causing Your Own Outage

Set it up in calm conditions, document it, and test the withdrawal as carefully as the trigger. Almost every blackhole-related incident traces back to a route that was easy to announce and hard to remove.

• Pick a discard next hop from documentation space, such as an address inside 192.0.2.0/24, and route it to the null interface on every router in the AS.
• Build the trigger policy on a dedicated router or route reflector, matching a reserved tag so nothing else can accidentally hit it.
• Restrict the accepting policy to host routes with an empty AS path, and refuse the RTBH community from anywhere it should not originate.
• Confirm which community each upstream and each exchange expects, and record whether they honour 65535:666 or a provider-specific value.
• Enable loose-mode uRPF on ingress interfaces if you want source-based triggering available as well.
• Write the withdrawal procedure into the runbook, with a named owner and a maximum lifetime for any announced blackhole.
• Run the whole sequence during a maintenance window against a test address, and verify from an external looking glass that the drop and the withdrawal both took effect.

If you would rather not carry that operational burden in-house, a managed DDoS solution moves detection, triggering, and withdrawal to a platform that watches the traffic continuously, which matters when more than 90% of network-layer attacks end in under ten minutes.

Even a well-built trigger path fails in predictable ways, and the failures repeat across networks.

Blackhole Routing Mistakes That Turn One Outage Into Three

The recurring failures are not exotic. They come from prefix length, missing expiry, and policy that was never tested from outside the network.

Blackholing a /24 when a /32 would do

Operators reach for an aggregate because the host route is not propagating, then discover they have taken 255 other addresses offline alongside the target. If the more-specific route is not being accepted, the problem is the receiving policy, not the prefix length. Fix the policy.

Announcing a blackhole with no expiry

A discard route has no natural end. Attacks do. Without a hard lifetime, the route outlives the incident and becomes a mystery outage that survives several shift handovers before anyone connects it to a change made days earlier.

Letting the announcement leak past the intended neighbour

A blackhole request tagged for one upstream but propagated further can black out the prefix from networks that never agreed to it. NO_EXPORT exists for this reason, and it belongs on the announcement rather than in the incident report.

Treating it as the whole plan

Blackholing is a containment move, not a defence. A network whose only answer to a flood is a discard route has agreed in advance to take the outage the attacker asked for, every time.

Final Thought on Blackhole Routing

Blackhole routing earns its place because it is the one mitigation that still works after the links are full. A discard route costs nothing to enforce, applies in seconds, and keeps a flood aimed at one address from taking down everything sharing the path to it. That is a real win, and it is the only win on offer at that point in an incident.

It is also a controlled loss. The address you blackhole stops serving real users for as long as the route stands, which is why the discipline around it matters more than the configuration. Keep the prefix as specific as the receiving policy allows, attach an expiry before you announce, and treat the withdrawal as the part of the runbook that gets rehearsed.

Build the finer controls first and let blackholing sit underneath them as the floor you never expect to reach. Networks that rehearse the handoff between filtering, absorption, and blackholing lose one address for the length of the attack. Networks that rehearse nothing lose the whole prefix and work out why afterwards.

Common Questions About Blackhole Routing