DDoS response is not only a firewall problem.

For networks that depend on IP Transit, the most important question during a large attack is often where the unwanted traffic gets dropped. If the attack traffic is discarded only after it has already crossed your transit port, your router, your cross-connect, or your downstream links, the damage may already be done.

That is why blackhole communities matter.

A BGP blackhole community gives a customer a way to signal to an upstream provider that traffic toward a specific destination prefix should be discarded inside the provider network. In practice, this is usually used during a DDoS attack to protect the rest of the customer network by sacrificing reachability to the targeted IP or prefix.

It is not a complete DDoS mitigation platform. It does not clean the traffic. It does not keep the attacked service online.

But when used correctly, BGP blackholing can be one of the fastest routing-layer tools available to an IP Transit customer.

What Is a BGP Blackhole Community?

A BGP community is a routing attribute that can be attached to a route announcement. Network operators use communities to signal routing policy, traffic engineering behavior, local preference changes, no-export rules, and blackholing instructions.

A blackhole community is a specific community value that tells the receiving network to discard traffic destined for the tagged route.

In an IP Transit relationship, the customer announces a prefix to the transit provider and attaches the provider’s blackhole community. The provider’s routing policy matches that community and installs a discard or null route for that destination inside its network.

The simplified flow looks like this:

Step	What Happens	Why It Matters
1	Customer identifies the attacked IP or prefix	The target must be specific enough to avoid unnecessary impact
2	Customer announces the route with a blackhole community	BGP carries the signal to the upstream provider
3	Provider policy matches the community	The provider decides whether to honor the request
4	Provider discards traffic toward the target	Attack traffic is dropped before it reaches the customer link
5	Customer withdraws the blackhole route after the attack	Normal reachability can be restored

The key idea is that blackholing moves the discard point upstream.

That matters because DDoS traffic can saturate the customer-facing port before local filtering has any chance to help. If a 10G attack hits a 1G customer port, dropping the traffic on the customer router does not solve the congestion problem. The link is already full.

Upstream blackholing helps by discarding the unwanted traffic earlier in the path.

RTBH: Remote-Triggered Blackhole Routing

Blackhole communities are often used as part of RTBH, or remote-triggered blackhole routing.

RTBH is a routing technique where a customer or operator triggers a blackhole action through BGP instead of manually logging into every router and adding filters. The route announcement becomes the control signal.

In a typical destination-based RTBH setup, the network announces a more specific route for the attacked destination and tags it with the provider’s blackhole community. The upstream provider then routes traffic for that destination to a discard next hop or null interface.

For IPv4, this is commonly done with a /32 host route. For IPv6, it is commonly done with a /128 host route. Provider policies vary, so customers should always confirm accepted prefix lengths and filtering rules before relying on the feature.

The benefit is speed.

During a DDoS event, minutes matter. A pre-agreed BGP blackhole community can allow the customer to trigger a defensive action quickly, often faster than opening a support ticket and waiting for manual intervention.

The tradeoff is availability.

A blackholed destination is intentionally unreachable. The attacked IP is protected from consuming capacity, but the service behind that IP is also taken offline until the blackhole route is withdrawn or replaced by a different mitigation strategy.

Blackholing vs DDoS Scrubbing

Blackholing and DDoS scrubbing are not the same thing.

Blackholing discards traffic. Scrubbing attempts to separate malicious traffic from legitimate traffic and forward the clean traffic to the customer.

Method	What It Does	Best Use Case	Main Tradeoff
Blackholing	Drops traffic toward the attacked prefix	Emergency protection when the attack threatens network stability	The target becomes unreachable
Scrubbing	Filters attack traffic and forwards clean traffic	Keeping the service online during an attack	More complex and usually more expensive
ACL/filtering	Blocks traffic based on rule sets	Smaller or more specific attacks	May not help if the transit link is already saturated
Rate limiting	Caps traffic volume	Containing certain traffic patterns	Can also degrade legitimate traffic

Blackholing is blunt, but useful.

If an attack is large enough to threaten the entire customer port, a blackhole can protect the wider network. For hosting providers, ISPs, WISPs, and infrastructure operators, that can be the difference between one customer IP going dark and an entire edge becoming congested.

This is why blackholing should be viewed as a containment tool, not a full mitigation strategy.

Why Blackholing Belongs in the IP Transit Conversation

Many customers ask IP Transit providers about bandwidth commits, port speeds, BGP sessions, route tables, and price per Mbps.

Fewer customers ask how DDoS blackholing works.

That is a mistake.

If you operate customer-facing infrastructure, a hosting network, a regional ISP, a WISP, game servers, SaaS infrastructure, or any service that can become an attack target, your IP Transit provider’s blackhole policy matters.

Before you need it, you should know whether your provider supports blackhole communities, what community value to use, which prefixes are accepted, how fast the policy takes effect, and whether the blackhole stays inside the provider network or propagates further.

The worst time to learn your provider’s blackhole process is during an active attack.

Provider Policy Matters

A blackhole community is only useful if the provider has configured its network to honor it.

The community itself is just a signal. It does not automatically force every router to discard traffic. The provider has to build routing policy that matches the community and applies the correct discard behavior.

That policy should include guardrails.

A good provider should not blindly accept blackhole requests for any prefix from any customer. The customer should only be able to blackhole prefixes they are authorized to announce. The provider should apply prefix filters, route validation, max-prefix controls, and clear policy boundaries.

Otherwise, blackholing can become dangerous.

A misconfigured customer should not be able to blackhole unrelated networks. A leaked blackhole route should not propagate in ways that cause unexpected reachability loss. A provider should also have logging and visibility into blackhole events so support and NOC teams can understand what happened after the fact.

In technical terms, blackholing is simple.

Operationally, it needs discipline.

Destination-Based Blackholing vs Source-Based Filtering

Most customer-facing IP Transit blackhole communities are destination-based.

That means the provider discards traffic based on where the traffic is going. If the target is 192.0.2.10 and the customer announces 192.0.2.10/32 with the blackhole community, traffic toward that IP is dropped.

This is useful when the destination is under attack.

Source-based filtering is different. It attempts to block traffic based on where it comes from. That can be useful in some cases, but it is harder to operate at scale because attack sources may be spoofed, distributed, or constantly changing.

For many DDoS events, destination-based RTBH is simpler and faster.

The network does not need to identify every attacking source. It only needs to identify the target that must be protected or isolated.

The downside is obvious: legitimate traffic to that target is dropped too.

When Blackholing Makes Sense

Blackholing makes the most sense when the priority is protecting the rest of the network.

If one IP is under attack and the traffic is saturating the customer’s transit port, blackholing that IP upstream may preserve service for other customers, other prefixes, or other infrastructure behind the same edge.

It can also be useful when the attacked service is less important than the wider network. For example, a hosting provider may blackhole one customer server to protect the shared platform. A WISP may blackhole a targeted destination to prevent upstream saturation from affecting subscribers. A SaaS operator may blackhole a non-critical endpoint while shifting production traffic elsewhere.

Blackholing is less useful when the targeted service must remain online at all costs.

In that case, scrubbing, anycast, traffic engineering, application-layer protection, or a dedicated DDoS mitigation provider may be more appropriate.

The decision is not “blackhole or no protection.”

The decision is what level of availability you need during an attack.

Operational Risks and Mistakes

Blackholing is powerful because it is fast.

That also means mistakes can be fast.

The most common operational risks include blackholing the wrong prefix, leaving a blackhole route active after the attack ends, announcing a blackhole route that is too broad, using the wrong community, or relying on a provider policy that was never tested.

A /32 blackhole for one attacked IPv4 address is very different from accidentally blackholing a larger customer prefix. The same principle applies in IPv6. Specificity matters.

Operators should treat blackholing like an emergency control, not a casual routing change.

A good process includes clear documentation, route filters, role-based access, change logging, monitoring alerts, and a withdrawal procedure. The team should know how to trigger the blackhole, how to verify that it is active, and how to remove it when the attack is over.

Testing matters too.

If a provider supports blackhole communities, customers should confirm the process before production depends on it. That does not mean causing disruption. It means having a safe test plan, clear maintenance window if needed, and confirmation that the provider’s NOC knows how the policy is expected to behave.

What to Ask Your IP Transit Provider

Before relying on BGP blackholing, customers should ask direct technical questions.

The goal is to understand what the provider actually supports, not just whether “DDoS protection” appears on a marketing page.

Useful questions include:

• Do you support BGP blackhole communities for customer-triggered RTBH?
• What community value should be used?
• Do you support the well-known BLACKHOLE community or a provider-specific community?
• What prefix lengths are accepted for blackholing?
• Can customers blackhole IPv4 /32 and IPv6 /128 routes?
• Is the blackhole local to your network or propagated to upstreams/peers?
• What route filters and authorization checks are applied?
• How quickly does the blackhole take effect after the BGP update?
• How can the customer verify that the blackhole is active?
• Are blackhole events logged and visible to support teams?
• What is the process for emergency manual blackholing if BGP is unavailable?

These questions separate operationally mature IP Transit providers from providers that only sell bandwidth.

A serious provider should be able to explain how the feature works, what its limits are, and how customers should use it safely.

Blackholing Is Not a Replacement for Good Network Design

BGP blackholing is useful, but it should not be the entire DDoS strategy.

A stronger design may include upstream diversity, DDoS scrubbing, anycast distribution, rate limiting, sensible ACLs, source address validation, application-layer protection, monitoring, and a documented incident response process.

Blackholing fits into that design as a fast containment tool.

It is especially useful when the attack is large enough to threaten the customer’s access circuit or when the operator needs to protect the wider network quickly.

But it comes with a clear cost: the destination being blackholed is unreachable.

For some incidents, that is the right tradeoff. For others, it is not.

The important thing is to decide before the attack starts.

Work With SHIFT on IP Transit and DDoS Response Planning

SHIFT provides IP Transit for infrastructure operators that need BGP support, upstream diversity, scalable bandwidth, and practical routing control.

For customers that operate hosting environments, ISP networks, WISP infrastructure, enterprise systems, or bandwidth-heavy services, DDoS response should be part of the IP Transit conversation.

That includes understanding blackhole communities, provider policy, accepted prefix lengths, escalation paths, and how routing-layer response fits into the wider network design.

If you are reviewing IP Transit providers or want to understand how your network should handle DDoS blackholing, SHIFT can help review the right approach.

Email: sales@shifthosting.com