Your server is under a 300 Gbps DDoS attack. Your upstream provider’s links are saturated. Other customers on the same infrastructure are experiencing collateral damage. Your provider calls you with a simple message: “We’re blackholing your IP.”
Within seconds, all traffic to your attacked IP address — every packet, every connection, every legitimate user — disappears into a routing void. The attack stops. Your service also stops. And the attacker has achieved exactly what they wanted.
This is BGP blackholing. It’s fast, it’s effective at stopping collateral damage, and it’s one of the worst things that can happen to your business during an attack.
How BGP Works (The Short Version)
To understand blackholing, you first need to understand how internet routing works.
The internet is a network of networks. Each network — called an Autonomous System (AS) — uses BGP (Border Gateway Protocol) to announce which IP addresses it owns and which paths traffic should take to reach them. When you type a website address into your browser, your ISP’s routers use BGP routing tables to determine the best path from your location to the destination server.
BGP is the glue that holds the internet together. Every route, every prefix, every path between networks exists because some router somewhere is announcing it via BGP.
What BGP Blackholing Actually Does
BGP blackholing — formally known as RTBH (Remotely Triggered Black Hole) — is a technique where a network operator intentionally changes the BGP routing for a specific IP address so that all traffic destined for that address is dropped at the network edge.
Here’s how it works in practice:
Step 1. An attack is detected against one of your IP addresses — say, 203.0.113.50.
Step 2. You (or your upstream provider) announce a BGP route for 203.0.113.50/32 with a special “blackhole” community tag. This tag tells upstream routers to discard any traffic bound for that address instead of forwarding it.
Step 3. As the blackhole route propagates through the internet’s BGP routing tables, routers at every hop begin dropping traffic for 203.0.113.50. Within minutes, no traffic — of any kind — reaches the address.
Step 4. The attack flood never reaches your network, because it’s being discarded hundreds of kilometers upstream at your provider’s edge routers. Your other IP addresses and services remain unaffected.
Step 5. When the attack ends, you withdraw the blackhole route, and traffic resumes normally.
The entire process relies on BGP’s natural propagation mechanism. No special hardware. No deep packet inspection. Just a routing change that tells the internet “this address doesn’t exist right now.”
When BGP Blackholing Is the Right Choice
Despite its drawbacks, there are legitimate scenarios where blackholing is the correct decision:
Protecting Shared Infrastructure
If you’re an ISP with thousands of customers sharing the same upstream links, a 500 Gbps attack against a single customer can saturate your entire network. Every other customer suffers. In this scenario, blackholing the attacked IP — sacrificing one customer — is the responsible engineering decision. It’s the networking equivalent of a controlled demolition: you lose one building to save the block.
When the Attacked IP Is Non-Critical
Some IP addresses are expendable. If the target is a secondary DNS resolver, a backup MX server, or a development environment, blackholing it during an attack may have minimal business impact. The service is temporarily unreachable, but nothing critical depends on it.
When No Alternative Mitigation Exists
If your network has no DDoS mitigation service — no scrubbing center, no cloud-based filtering, no on-premise appliance — blackholing may be your only option to prevent total network failure. It’s a last resort, but it’s better than losing everything.
When the Attack Exceeds All Available Capacity
Even with mitigation in place, there are theoretical scenarios where an attack exceeds the combined scrubbing capacity of your provider. In such extreme cases, blackholing specific addresses while maintaining scrubbing on others is a valid triage strategy.
The Problem: Blackholing Completes the Attacker’s Mission
Here’s the fundamental paradox of BGP blackholing: it achieves exactly what the attacker wanted.
The entire purpose of a DDoS attack is to make your service unreachable. When you blackhole your own IP, you’re doing the attacker’s job for them — taking the service offline yourself. The attacker sends a flood, you respond by removing the target from the internet, and the result is indistinguishable from a successful attack.
For any service where availability matters — e-commerce platforms, payment processors, gaming servers, SaaS applications, API endpoints — blackholing is not mitigation. It’s capitulation.
The Collateral Damage Problem
Blackholing is binary. It doesn’t distinguish between a 300 Gbps UDP flood from a botnet and a legitimate HTTPS request from your most important customer. Both are dropped. Both are destroyed. There is no selectivity, no intelligence, no nuance.
If your server hosts multiple services on the same IP — web, API, email, DNS — blackholing kills all of them simultaneously. If you have users in the middle of transactions, sessions, or uploads, their connections are severed without notice.
The Duration Problem
How long do you keep the blackhole active? Remove it too early, and the attack resumes. Keep it too long, and you’re effectively offline for hours. Many operators leave blackhole routes in place for 2-4 hours after the last observed attack traffic — meaning a 10-minute attack can result in hours of downtime.
Some attacks are designed specifically to exploit this behavior. The attacker floods for 5 minutes, waits for the blackhole, then stops. The operator eventually removes the blackhole. The attacker floods again. This cycle can repeat indefinitely, keeping the target offline for as long as the attacker chooses.
The Visibility Problem
Once traffic is blackholed, you lose all visibility into it. You can’t analyze the attack characteristics, identify the sources, measure the volume, or understand the vectors. The traffic simply disappears at upstream routers that you don’t control and can’t inspect.
This means you learn nothing from the attack. You can’t improve your defenses. You can’t provide forensic data to law enforcement. You can’t even confirm when the attack actually stopped — you just guess, remove the blackhole, and hope.
Blackholing vs. Scrubbing: A Fundamental Difference
The alternative to blackholing is traffic scrubbing — routing your traffic through a filtering infrastructure that separates attack packets from legitimate traffic and forwards only the clean traffic to your servers.
| Aspect | BGP Blackholing | Traffic Scrubbing |
|---|---|---|
| Attack traffic | Dropped | Dropped |
| Legitimate traffic | Also dropped | Forwarded to your server |
| Service availability | Offline | Online |
| Attack visibility | None | Full analytics and reporting |
| Selectivity | None — all or nothing | Per-packet, per-protocol, per-source |
| Duration impact | Downtime = blackhole duration | Zero downtime if mitigation is active |
| Attacker’s goal achieved? | Yes | No |
| Cost of attack to attacker | Low — one burst takes you offline | High — sustained attack with no impact |
The distinction is fundamental. Blackholing is a network-level survival mechanism — it saves your infrastructure at the expense of your service. Scrubbing is a service-level mitigation strategy — it saves both your infrastructure and your service.
How Traffic Scrubbing Works
In a scrubbing architecture, your traffic flows through a filtering layer before reaching your servers. This layer inspects every packet, applies filtering rules, and forwards only clean traffic.
There are three main deployment models:
Cloud-Based Scrubbing (BGP Diversion)
Your IP prefixes are announced via BGP through the scrubbing provider’s network. All traffic destined for your addresses arrives at the scrubbing center first. Attack traffic is filtered. Clean traffic is delivered to your infrastructure via GRE tunnel, direct cross-connect, or IX peering.
This is the most common model for volumetric attack mitigation. The scrubbing center absorbs the full bandwidth of the attack — hundreds of gigabits or even terabits — using infrastructure specifically designed for this purpose. Your own network only receives the clean traffic that passes through the filters.
On-Premises Scrubbing
A filtering device or server is deployed inline within your datacenter, between your upstream connection and your servers. All traffic passes through this device, which drops attack traffic and forwards legitimate packets.
This model is ideal for organizations with data sovereignty requirements or extremely low latency demands. The filtering happens locally — your traffic never leaves your facility.
Hybrid Scrubbing
Large volumetric attacks are absorbed by cloud-based scrubbing centers, while smaller, more sophisticated application-layer attacks are handled by on-premises filtering. This approach combines the bandwidth capacity of cloud scrubbing with the low latency and granular control of local filtering.
How CoreTech Eliminates the Need for Blackholing
CoreTech is a traffic scrubbing provider. Our entire architecture is designed so that you never have to blackhole your own addresses.
CoreEdge™ filters attack traffic at the XDP layer — the lowest possible interception point in the Linux networking stack. Every packet is inspected at wire speed. Attack packets are dropped at the network card. Clean traffic continues to your servers with zero added latency.
The capacity to absorb volumetric floods is built into the infrastructure. When a 300 Gbps UDP flood arrives, CoreEdge™ processes every packet without forwarding a single attack byte to your network. Your services stay online. Your users stay connected. The attacker wastes bandwidth, money, and botnet resources — with nothing to show for it.
CoreDetection™ ensures that mitigation is fast and accurate. Within seconds of detecting an anomaly, the behavioral engine classifies the attack type, generates precise filtering rules, and deploys them to CoreEdge™. There’s no manual triage, no SOC engineer deciding whether to blackhole, no 30-minute escalation process. Detection to mitigation in under sixty seconds.
The Client Portal gives you complete visibility. During an attack, you see every metric in real time — bandwidth, packets per second, attack vectors, source countries, source ASNs, severity classification. You see exactly what’s being filtered and exactly what’s reaching your servers. This is the visibility that blackholing destroys.
Self-service firewall management lets you pre-configure filtering rules before an attack even begins. Define per-source rate limits, TCP flag validation, ICMP controls, GeoIP blocks, and protocol-specific policies through the portal. When an attack arrives, your pre-configured rules engage immediately — before CoreDetection™‘s automated rules even deploy.
When CoreTech Customers Use Blackholing
Almost never. In our operational history, blackholing is reserved for one scenario: when a customer explicitly requests it for a specific IP address that they’ve determined is non-critical. It’s always the customer’s decision, never ours.
For every other scenario — volumetric floods, SYN floods, amplification attacks, application-layer attacks, multi-vector campaigns — CoreEdge™ scrubs the traffic and keeps your services online.
Transitioning Away from Blackholing
If your current DDoS strategy relies on your upstream provider’s RTBH capability, transitioning to scrubbing-based mitigation is straightforward:
Step 1. Establish a BGP session with CoreTech. We support three connectivity methods: direct cross-connect, GRE tunnel, and Internet Exchange (IX) peering. GRE tunnels can be provisioned same-day with no physical infrastructure changes.
Step 2. Announce your IP prefixes through CoreTech’s network. All traffic now routes through our scrubbing infrastructure.
Step 3. Configure your baseline firewall rules through the Client Portal. Pre-configured rules ensure instant mitigation the moment attack traffic arrives.
Step 4. CoreDetection™ learns your traffic patterns during normal operations. This behavioral baseline enables accurate anomaly detection when an attack begins.
Your RTBH capability remains available as an absolute last resort. But once scrubbing is active, the scenarios where you’d need it shrink to essentially zero.
The Bottom Line
BGP blackholing is a tool that saves your network by destroying your service. It was designed for an era when the only alternative to absorbing an attack was collapsing under it.
That era is over. Modern scrubbing infrastructure can absorb terabit-scale attacks while keeping your services fully operational. Every packet inspected. Every legitimate connection preserved. Every attack neutralized at the network card.
Stop blackholing your revenue. Start scrubbing your traffic.
10-day free trial — full CoreEdge™ scrubbing capacity, full CoreDetection™ behavioral analysis, full Client Portal visibility.
Want to see this in action?
Get a live demonstration of CoreTech's DDoS mitigation platform.
