BGP Blackhole vs BGP FlowSpec: choosing the right DDoS filtering tool

Defining the problem

Remote triggered blackhole announces a special route to discard all traffic toward an IP or prefix. It is easy to operate and widely supported, but the protected service becomes unreachable.

FlowSpec carries filtering rules in BGP. A rule may match protocol, source and destination ports, packet length, TCP flags or fragments, then apply discard or rate-limit. This precision is powerful, but a broad rule can silently damage real traffic.

The operational difference becomes obvious during saturation. Blackhole changes reachability for a destination; FlowSpec changes packet treatment inside the routing infrastructure. That means FlowSpec needs a confidence level: which fields are stable, which fields are normal for users, and which action can be removed without waiting for a maintenance window.

Why this matters

The wrong mitigation choice can cost more than the attack. Blackholing a shared IP, a FiveM endpoint or a customer gateway prevents saturation but creates a full outage. A bad FlowSpec rule may look cleaner in graphs while real users fail.

For protected transit, customers pay for reachability, not only backbone survival. Decisions must rely on evidence: packets per second, Gbps, affected ports, packet profile, error rate and how stable the attack signature is.

A useful runbook should also define who is allowed to propagate a rule upstream. Local drops can be tested quickly; upstream FlowSpec affects a larger domain. For customers carrying third-party traffic, approval, logging and expiry are part of the product, not paperwork.

For search and onboarding, this distinction should be explained plainly on the page. Buyers are often comparing providers that all claim large capacity; the differentiator is whether the routing and mitigation model can be audited before an outage.

Possible solutions

Manual RTBH is appropriate when a destination must not threaten other customers or when volume exceeds available ports. It is an emergency brake, not fine mitigation.

Manual FlowSpec after packet capture works for stable attacks with clear characteristics. It becomes too slow when the signature changes frequently or when no engineer is available.

The strongest model is controlled automation: thresholds per port, short-lived rules, expiry, legitimate traffic monitoring and blackhole only as last resort.

Rate-limiting is sometimes safer than discard. If an attack signature overlaps with legitimate traffic, a temporary policer may reduce pressure while packet captures and application metrics confirm whether a stricter rule is safe.

A practical design should include acceptance criteria: expected latency, maximum tolerated packet loss during mitigation, handoff bandwidth, escalation contacts and the exact conditions under which a disruptive control such as blackhole may be used.

Choosing blackhole or FlowSpec without collateral damage

Peeryx treats FlowSpec as upstream volume reduction. The goal is to lower attack pressure before transit ports saturate, not to replace the full DDoS stack with a BGP rule.

A healthy rule combines destination, protocol, port ranges, observed length and traffic context. It is documented, short-lived and removed if real-user indicators degrade.

Clean traffic is then delivered by GRE, IPIP, VXLAN, router VM or cross-connect. The customer keeps a readable network model: where traffic enters, how it is filtered and how it returns.

This is why Peeryx separates gross-volume control from service-aware decisions. Upstream tools reduce the flood; the local mitigation path keeps enough context to avoid turning a DDoS event into a self-inflicted outage.

Concrete use case

A game server receives 80 Gbps of UDP on its public port. Blackholing the IP stops saturation but disconnects everyone. Dropping all UDP to the game port is almost as bad.

The safer response is to look at packet length, source-port ranges, pps/Gbps ratio and fragments. A combined FlowSpec rule can remove most of the attack while preserving real clients, then disappear when the signature changes.

The same logic applies to TCP floods. A rule on TCP flags may help for abnormal SYN or ACK patterns, but it must be compared against normal connection behavior for the protected service.

Frequent mistakes

Most mistakes come from reacting too fast without enough evidence. Speed matters, but an incorrect rule propagated upstream can be more damaging than a local filter.

Another common issue is forgetting the customer communication layer. When blackhole is used, the customer must know that reachability is intentionally sacrificed; when FlowSpec is used, the customer needs confirmation that the rule is temporary and monitored.

• Treating FlowSpec as an application firewall.
• Leaving rules active after the attack.
• Filtering on one field such as packet length.
• Blackholing a whole prefix for one attacked IP.
• Not comparing legitimate traffic before and after the rule.

FAQ