Blackhole Routing vs Scrubbing | DDoS Mitigation Compared

Blackhole routing and traffic scrubbing are the two primary techniques used to respond to volumetric DDoS attacks. Blackhole routing drops all traffic destined for the targeted IP address—stopping the attack and the service simultaneously. Traffic scrubbing filters malicious packets and forwards only clean traffic to the destination, maintaining availability while under attack.

TL;DR: Blackhole routing drops all traffic to an attacked IP address — stopping the attack but also blocking legitimate users. Traffic scrubbing filters attack traffic, forwarding only clean traffic to the origin. Blackhole routing is a last-resort measure when attack volume exceeds scrubbing capacity; scrubbing is the preferred approach when maintaining service availability is required.

Last updated: 2026-07-27

How Blackhole Routing Works

Blackhole routing, also called null routing or RTBH (Remotely Triggered Black Hole), instructs routers to discard all packets destined for a specific IP address or prefix. The route is advertised via BGP with a next-hop that leads to a discard interface—commonly labeled “Null0” in Cisco devices or “blackhole” in BIRD/FRR.

Normal routing:
Attacker ──▶ Internet ──▶ Router ──▶ Target server (IP: 203.0.113.1)

Blackhole routing activated:
Attacker ──▶ Internet ──▶ Router ──▶ Null0 (packets discarded)
Legitimate users ──▶ Internet ──▶ Router ──▶ Null0 (also discarded)

RTBH implementation flow:

1. Attack detected targeting 203.0.113.1
2. Operator or automation advertises 203.0.113.1/32 to upstream BGP peers
3. Peers set next-hop to Null0 across their networks
4. All traffic to that IP is discarded at the network edge
5. Attack traffic never reaches the origin—but neither does legitimate traffic

Destination-based RTBH (D-RTBH) drops based on destination IP. Source-based RTBH (S-RTBH) drops based on source IP and requires router support for uRPF (Unicast Reverse Path Forwarding)—useful for blocking known attack sources but impractical when sources are spoofed or distributed across millions of IPs.

How Traffic Scrubbing Works

Traffic scrubbing redirects all traffic destined for the attacked IP through a scrubbing center (also called a cleaning center). The center inspects packets, drops attack traffic, and forwards clean traffic to the origin server.

Normal routing:
Internet ──▶ Router ──▶ Target server

Under attack with scrubbing active:
Internet ──▶ Scrubbing Center ──(clean traffic only)──▶ Target server
                    │
                    └──▶ Malicious packets discarded

Scrubbing center techniques:

• BGP route injection or DNS-based traffic steering to redirect traffic
• Deep packet inspection (DPI) to identify attack signatures
• Rate limiting per source IP
• Protocol validation (SYN cookies for TCP, DNS response rate limiting)
• Behavioral analysis to distinguish bots from legitimate users
• GRE tunneling or MPLS to deliver clean traffic back to origin

Major mitigation providers operate scrubbing capacity across multiple geographic regions. Distributed scrubbing capacity matters because volumetric DDoS attacks can exceed the capacity of a single data center, ISP link, or appliance.

Side-by-Side Comparison

When to Use Blackhole Routing

Blackhole routing is appropriate when:

• Attack volume exceeds scrubbing capacity. If an attack delivers 2 Tbps and the scrubbing center handles 1 Tbps, scrubbing will not protect the network. Blackholing prevents the attack from saturating upstream links.
• The targeted IP is non-critical. A monitoring endpoint, a secondary DNS resolver, or a test server can be blackholed without business impact.
• Protecting the broader network is the priority. ISPs blackhole a customer’s IP to prevent congestion on shared infrastructure affecting all customers.
• Speed is critical. BGP blackhole convergence happens in under 30 seconds. Scrubbing redirection typically takes 1–5 minutes, during which attack traffic still flows.
• Attack IPs are known and static. Source-based RTBH blocks specific attack sources without dropping legitimate traffic—only practical when attack sources are few and non-spoofed.

When to Use Traffic Scrubbing

Traffic scrubbing is appropriate when:

• Service availability is required during the attack. E-commerce, financial services, and SaaS cannot tolerate complete outages; scrubbing filters attack traffic while legitimate users continue to access the service.
• Attack volume is within scrubbing capacity. Most commercial DDoS attacks peak below 500 Gbps. Scrubbing centers with 1–10 Tbps capacity handle these comfortably.
• Attacks are multi-vector. Layer 7 attacks alongside volumetric floods require inspection, not blind dropping. Scrubbing centers apply different filters per attack vector.
• Long-duration attacks require sustained response. Scrubbing can operate continuously for hours or days. Blackholing is typically a temporary measure—the target IP remains unreachable until manually deactivated.

Hybrid Approach

Many organizations and providers combine both techniques in a tiered response:

1. Scrubbing first: Redirect traffic through scrubbing for attacks below capacity threshold.
2. Blackhole as last resort: If attack volume overwhelms scrubbing or upstream links saturate, blackhole the targeted IP to protect the rest of the infrastructure.
3. Surgical blackholing: Use S-RTBH to blackhole identified attack source prefixes while continuing to scrub remaining traffic.

This approach protects service availability for moderate attacks while maintaining a mechanism to protect the broader network during extreme events.

Frequently Asked Questions

What is blackhole routing in DDoS mitigation? Blackhole routing is a technique that discards all packets destined for a specific IP address by advertising that IP via BGP with a null next-hop. It stops the attack instantly but makes the targeted IP completely unreachable, including for legitimate users.

What is traffic scrubbing? Traffic scrubbing redirects all traffic through a specialized filtering infrastructure (scrubbing center) that separates malicious packets from legitimate requests. Clean traffic is forwarded to the origin; attack traffic is dropped. Service continues during the attack.

Does blackhole routing stop a DDoS attack? Blackhole routing stops attack traffic from reaching the origin, but it also stops all other traffic. The attack itself may continue generating traffic in the network—the blackhole prevents it from consuming origin resources and upstream link capacity.

What is RTBH? RTBH (Remotely Triggered Black Hole) is a BGP-based mechanism to propagate blackhole routes to multiple routers or upstream providers simultaneously. An operator injects a /32 or /128 host route tagged with a specific BGP community, and peer routers automatically set the next-hop to discard.

How much traffic can a scrubbing center handle? Scrubbing center capacity varies by provider and architecture. Individual scrubbing locations can range from hundreds of Gbps to multi-Tbps capacity, while distributed anycast architectures spread attack traffic across many locations instead of forcing one site to absorb the full load.

Is traffic scrubbing always better than blackholing? Not always. If an attack exceeds scrubbing capacity, scrubbing fails and all traffic—including attack traffic—backs up in the network. Blackholing guarantees that attack traffic does not reach or saturate critical links. The right choice depends on attack volume and service requirements.

What is anycast and how does it relate to scrubbing? Anycast advertises the same IP prefix from multiple geographic locations simultaneously. Traffic routes to the nearest location. During a DDoS attack, anycast distributes attack traffic across multiple scrubbing points, preventing any single location from being overwhelmed. Azion uses this distributed model to keep mitigation close to attack sources.

Can I implement blackhole routing without my ISP’s help? You can implement null routing locally on your own routers to discard traffic arriving at your border. However, the attack traffic still flows through your upstream links to reach your router. For upstream protection, you need your ISP or upstream provider to participate in RTBH by accepting your blackhole BGP communities.

How long does blackhole routing stay active? Blackhole routes are typically configured with a short BGP TTL (time-to-live) or timer—commonly 30 minutes to a few hours—to prevent indefinite service outages. Operators manually deactivate the blackhole once the attack subsides.

What is the difference between D-RTBH and S-RTBH? D-RTBH (Destination-based RTBH) blackholes all traffic to a specific destination IP, dropping both attack and legitimate traffic. S-RTBH (Source-based RTBH) blackholes traffic from specific source IPs, preserving service for legitimate users while blocking identified attack sources. S-RTBH is more precise but requires uRPF support and known, non-spoofed attack sources.

How to Implement on Azion

Azion’s distributed network absorbs DDoS traffic across edge locations using anycast routing before it reaches your origin. This functions as a distributed scrubbing layer—attack traffic is detected and mitigated at the network edge closest to the source, reducing the volume that needs to be processed centrally.

For volumetric attacks:

• DDoS Protection provides always-on mitigation with no traffic redirection delay
• Network Layer Protection applies network-level rules at the edge to block attack patterns
• Edge Firewall enables custom rules to filter traffic before it reaches your application

Azion does not require manual intervention to activate scrubbing—protection is always active. For application-layer attacks on top of volumetric floods, combine DDoS Protection with the WAF.

Related Resources

• What Is DDoS Protection and Mitigation?
• What Is a DDoS Attack?
• DDoS Attack Types
• Azion DDoS Protection
• Azion Network Layer Protection

Sources:

• IETF. “Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF).” RFC 5635. 2009.
• IETF. “BGP Communities Attribute.” RFC 1997. 1996.
• CISA. “Understanding and Responding to Distributed Denial-of-Service Attacks.”
• NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.
• Cisco Systems. “Remotely Triggered Black Hole Filtering—Destination Based and Source Based.” 2005. When a volumetric DDoS attack hits its target, the connectivity provider often offers a “solution”: blackhole routing. In March 2013, the attack against Spamhaus generated reported peaks near 300 Gbps, based on DNS reflection and amplification. Applying blackhole routing to the attacked IP does not necessarily stop the attack: it discards, at the operator’s network edge, both the malicious traffic and the legitimate traffic destined to the target. While it protects adjacent infrastructure from saturation, it temporarily sacrifices service availability and may produce exactly the denial-of-service effect the attacker intended.

Blackhole routing (or null routing) is a network engineering technique that discards all traffic destined for a specific IP address by redirecting it to a null interface. Attack traffic is eliminated — but so is all legitimate traffic. Scrubbing, on the other hand, is the process of selectively inspecting and filtering traffic, discarding only malicious packets and forwarding legitimate ones to their destination.

How blackhole routing works — RTBH and RFC 7999

Blackhole routing operates via BGP (RFC 4271). The most widely used mechanism is RTBH (Remotely Triggered Black Hole), standardized by RFC 5635, which allows triggering the discard on multiple remote routers through a BGP signaling session.

Operationally, the flow proceeds as follows:

1. The operator detects a volumetric attack targeting IP 192.0.2.10/32.
2. A trigger router announces via iBGP the route 192.0.2.10/32 with the next-hop set to 192.0.2.1 (an address reserved as the blackhole trigger).
3. Edge routers, upon receiving this announcement, consult their static table and redirect the prefix to the null0 interface.
4. All traffic destined to the victim’s IP is dropped at the operator’s network edges.

RFC 7999 standardized the BGP well-known community BLACKHOLE (65535:666) to signal blackhole routes in an interoperable manner between autonomous systems. When an organization announces a prefix with this community to its upstream provider, the prefix is dropped throughout the provider’s network. The attributes NO_ADVERTISE and NO_EXPORT are frequently combined to limit announcement propagation:

• NO_ADVERTISE (community 0xFFFFFF02): prevents the receiving router from propagating the announcement to any peer.
• NO_EXPORT (community 0xFFFFFF01): prevents propagation to eBGP peers outside the confederation, containing the blackhole within the receiving AS.

The availability outcome is unambiguous: blackhole activates in seconds and protects upstream infrastructure (ISP links and routers) from saturation. But from a business perspective, the effect is identical to the attack: total unavailability.

When blackhole routing is used

Despite its limitations, blackholing has valid use cases:

• Shared infrastructure protection: When an attack threatens to impact other ISP customers beyond the victim, blackhole isolates the problem and protects shared link capacity.
• Sacrificed IP: When the attacked IP is secondary and the main service can be maintained via other IPs or prefixes.
• Emergency temporary measure: As a first-aid response while a scrubbing solution is activated and propagated.
• Non-critical IP under attack: When the attacked IP is not required for operational service continuity.

BGP FlowSpec — granular filtering in the control plane

BGP FlowSpec, originally defined by RFC 5575 and updated by RFC 8955, represents a significant evolution over RTBH: instead of discarding all traffic for a prefix, it allows creating granular ACL rules distributed via the BGP control plane.

FlowSpec operates through match tuples combined with actions via extended communities:

Match fields:

• Source and destination IP address (prefix)
• Transport protocol (TCP, UDP, ICMP)
• Source and destination ports (ranges and lists)
• TCP flags (SYN, ACK, RST, FIN)
• Packet size (range)
• DSCP value (QoS marking)
• Packet fragmentation

Actions (via extended communities):

• traffic-rate:AS:rate — discards (rate=0) or limits forwarding rate in bits/s
• traffic-action — marks or redirects for analysis (mirroring)
• redirect:VRF — diverts matching traffic to a dedicated scrubbing VRF
• redirect-to-NH — redirects to a specific next-hop (scrubbing center)

FlowSpec rule example:

A rule that drops UDP packets with destination port 53, size between 60 and 80 bytes, and destination IP 198.51.100.0/24 — a DNS amplification pattern — would be distributed to all edge routers via BGP without manual intervention on each device.

FlowSpec positions itself as an intermediate technique between total blackhole and the scrubbing center:

• More granular than RTBH: allows dropping only malicious traffic while preserving legitimate traffic.
• Simpler than a scrubbing center: operates in the BGP control plane without requiring traffic diversion to dedicated infrastructure.
• Has limitations: does not inspect Layer 7 content and does not scale well for highly dynamic or high-cardinality rules.

How centralized scrubbing works

Centralized scrubbing diverts traffic to a dedicated cleaning center where it is inspected across multiple layers. The process occurs in four steps:

1. During an attack, the operator announces via BGP that the affected prefix should be routed to the scrubbing center (typically via a provider-specific BGP community).
2. Traffic from the entire internet is redirected to the scrubbing center, where it undergoes Layer 3 and 4 inspection (IP, port, protocol filtering) and Layer 7 inspection (HTTP behavioral analysis, rate limiting, signature detection).
3. Clean traffic is forwarded back to the origin server via GRE or MPLS tunnel.
4. When the attack subsides, the operator reverts the BGP announcement and traffic returns to the normal path.

Limitations of centralized scrubbing — hairpin and L7 attacks

The centralized scrubbing center model has two critical structural problems.

Hairpin latency: Traffic from a user in São Paulo to a server in São Paulo may be diverted to a scrubbing center in Miami or Amsterdam, increasing latency by 50–150ms.

Layer 7 attacks and cryptographic exhaustion: Traditional scrubbing centers primarily operate at Layers 3 and 4. HTTP Flood, Slowloris, and R.U.D.Y. attacks use syntactically valid HTTP requests at low volume — invisible to L3/L4 filtering.

Even more critical: TLS/SSL handshake exhaustion attacks like THC-SSL-DoS exploit the computational asymmetry of the TLS protocol, where establishing a TLS session costs approximately 15 times more CPU on the server than on the client. An attacker with modest hardware can initiate mass renegotiations and saturate the origin server’s cryptographic capacity before saturating the network. A scrubbing center that does not perform TLS termination passes these connections to the origin server uninspected, leaving it vulnerable.

Distributed edge scrubbing

The most modern model eliminates hairpin and resolves L7 and TLS limitations: instead of diverting traffic to a centralized scrubbing center, scrubbing happens at each data center in the distribution network, close to the attack source.

The protection flow with distributed scrubbing works as follows:

1. Attack traffic originating in Europe reaches the nearest European edge data center via Anycast routing.
2. The European data center applies L3/L4 inspection (volumetric), L7 inspection (HTTP behavior), and inspects connections after TLS termination.
3. Only traffic that passes all inspection layers is forwarded to the origin server.
4. The same process occurs simultaneously in US, APAC, and other regional data centers for traffic generated in those locations.
5. The origin server receives exclusively complete, valid, and inspected requests — regardless of attack scale.

The benefits are structural:

• Attack traffic filtered close to the source, reducing load transported across the network.
• Legitimate users experience no route detour and maintain their original latency.
• TLS termination at the edge enables Layer 7 inspection over decrypted traffic, without exposing the origin server to cryptographic processing load.

Edge TLS Termination and protection against cryptographic exhaustion

TLS termination at the edge specifically resolves the cryptographic exhaustion vector. The process works as follows:

1. TLS connections from clients are terminated at edge data centers, which operate hardware with dedicated cryptographic acceleration (AES-NI, Intel QAT).
2. After the TLS handshake is completed at the edge, the HTTP request is decrypted and submitted to real-time WAF inspection and behavioral analysis.
3. Only approved requests are forwarded to the origin server — on a separate connection that may be plain HTTP or TLS with an already-established handshake.
4. The origin server never processes TLS handshakes from external clients, completely eliminating the cryptographic exhaustion vector.

Comparative matrix of the four architectures

The collateral damage problem of blackhole

A frequently overlooked aspect: when an ISP applies blackhole routing, the victim’s IP may be announced as a “black hole” across multiple BGP routers. This can cause:

• Reputation damage: IP reputation systems record the IP as problematic, affecting email delivery and CDN trust.
• Impact on related services: Other services on the same /24 block may be affected by subnet-based filters.
• Slow removal: Withdrawing the blackhole can take hours to propagate via BGP depending on network topology and peer timers.

Signs that blackhole was applied to your IP

Common mistakes and solutions

Mistake: Accepting blackhole as an ISP “mitigation solution” without questioning alternatives. Solution: Demand scrubbing SLAs with legitimate traffic preservation. Blackhole protects the ISP’s infrastructure — it is not a solution for the victim’s business.

Mistake: Implementing centralized scrubbing without considering latency impact. Solution: Evaluate your users’ geographic distribution. If they are globally distributed, a single scrubbing center introduces unacceptable hairpin. Prefer distributed scrubbing or FlowSpec for simple L3/L4 attacks.

Mistake: Automatically activating blackhole as the first response to any attack. Solution: Reserve blackhole for situations where upstream infrastructure is at immediate saturation risk. Use scrubbing or FlowSpec as the default response to preserve availability.

Mistake: Assuming centralized scrubbing resolves Layer 7 attacks and TLS exhaustion. Solution: L3/L4 scrubbing is effective against volumetric attacks. L7 attacks like HTTP Flood, Slowloris, and TLS handshake exhaustion require edge TLS termination and integrated Layer 7 inspection.

Frequently asked questions

What is the BGP BLACKHOLE community (65535:666) and how is it used? Community 65535:666, standardized by RFC 7999, is a BGP well-known community that signals to the receiver that the announced prefix should be blackholed. To use it, the organization announces the attacked prefix with this community to its upstream provider(s). Provider routers that recognize the community drop the traffic before forwarding it to the victim’s network. It is more interoperable than proprietary solutions, as it is recognized by equipment from multiple vendors and ISPs.

What is the difference between RTBH (RFC 5635) and BGP FlowSpec (RFC 8955)? RTBH drops all traffic for a /32 IP prefix (host-route) without distinction of protocol, port, or behavior — it is binary: everything or nothing. FlowSpec allows creating granular rules with multiple match fields (IP, port, protocol, packet size, TCP flags, DSCP) and different actions (discard, rate limiting, redirect to VRF). FlowSpec is distributed via BGP like RTBH, but acts as a remote ACL, allowing protection of legitimate traffic while dropping only malicious patterns.

Can blackhole routing be partial — only for certain traffic types? Traditional BGP blackhole via RTBH drops all traffic for the IP. The D/RTBH (Destination-based RTBH) variation allows filtering by attacker source prefix, but requires intelligence about the attack IPs. For filtering by protocol, port, or behavior, BGP FlowSpec is needed — which provides that granularity while maintaining BGP control plane distribution.

Does centralized scrubbing still make sense in 2026? Yes, in specific scenarios: when the scrubbing center is geographically close to users, when the attack is exclusively volumetric L3/L4, and when the organization doesn’t have access to a distributed edge network. For modern multi-vector attacks combining volumetric flood with HTTP Flood, TLS exhaustion, and Slowloris, the distributed edge model is superior because it operates across all layers simultaneously.

Why do Slowloris and R.U.D.Y. attacks pass through traditional scrubbing centers undetected? Low and slow attacks like Slowloris and R.U.D.Y. use syntactically valid HTTP connections transmitted at extremely slow rates. From a network volume perspective (packets per second, bits per second), they are invisible to L3/L4 filters. Detection requires Layer 7 inspection with behavioral analysis: open connections per IP, request completion rate, header transmission time, and client fingerprinting (JA3/JA4). This is only possible after TLS termination and with L7 analysis capability at the inspection point.

Can a scrubbing center be overwhelmed? Yes. Attacks above a provider’s scrubbing capacity can saturate the scrubbing center’s own inbound links. Providers with distributed scrubbing have greater total aggregate capacity because they distribute load across dozens of data centers. A 1 Tbps attack that would saturate a single 500 Gbps scrubbing center is diluted across 20 data centers of 100 Gbps each without saturating any of them individually.

How to implement on Azion

Azion operates an always-on distributed scrubbing model that addresses all vectors discussed in this article:

1. Edge scrubbing with a global Anycast network: Traffic is inspected at each of Azion’s 100+ data centers, close to the attack source. Anycast routing ensures legitimate users experience no route detour and no latency increase — inspection occurs on the same path traffic would normally take.
2. Always-on DDoS Protection: No manual activation, BGP redirection, or route announcement adjustment required during the attack. Protection is always active, with automatic mitigation starting in seconds for volumetric L3/L4 attacks.
3. Edge TLS Termination with L7 inspection: TLS connections are terminated at Azion’s data centers, which use hardware with cryptographic acceleration. The origin server never processes TLS handshakes from external clients, eliminating the cryptographic exhaustion vector (THC-SSL-DoS and similar). Over decrypted traffic, the integrated WAF applies real-time Layer 7 inspection, detecting HTTP Flood, Slowloris, R.U.D.Y., and other low and slow attacks.
4. No forced blackhole: Azion does not apply blackhole routing to customer IPs as a default response. The goal is to keep the service available during the attack, not just protect network infrastructure. The policy is to filter malicious traffic and forward legitimate traffic to its destination — regardless of attack scale.

Learn more in the Azion DDoS Protection documentation.