On this page
Key points
- The first bottleneck mattersLocal filtering is useless if the link is already saturated before it.
- Filtering is not blackholingGood upstream filtering removes precise attack patterns instead of dropping the whole prefix.
- Clean handoff still mattersAfter upstream relief, legitimate traffic must return through a stable and observable path.
Definition of the problem
The core problem is that many architectures put the real filtering layer too low in the path. Traffic first reaches a carrier port, crosses a router and may then hit a firewall, load balancer or server. A UDP reflection attack, a high-PPS TCP flood or a mix of tiny packets can saturate the first link long before your local logic sees enough samples to react.
Upstream filtering moves part of the decision higher in the path. The upstream provider can apply volumetric rules, ACLs, BGP FlowSpec, targeted rate-limits or redirection to a scrubbing center. This layer does not replace fine-grained mitigation because it often has less application context. Its job is to shave the attack down before physical or billing saturation turns into an outage.
You also need to separate three ideas: blackholing a prefix, filtering an attack pattern and delivering clean traffic. Blackholing protects the provider network but kills the service. Intelligent upstream filtering reduces the attack while trying to preserve users. Clean delivery then keeps the service reachable.
Why it matters
This matters for hosting providers, operators, game servers and exposed platforms because the cost of a bad first reaction is immediate: lost players, customer tickets, saturated ports, 95th-percentile billing spikes or blackhole communities activated too early. A 40 Gbps attack against a 10 Gbps connected service is not primarily a firewall problem; it is an ingress capacity problem.
Upstream filtering also reduces the risk of huge false positives. If the only available response is “blackhole the /32” or “drop all UDP”, the service remains unavailable even if the attack is technically handled. A good upstream strategy should use the smallest effective action: protocol, ports, packet lengths, flags or obvious reflection sources, with a short lifetime and a clear rollback.
It also affects commercial trust. A B2B buyer does not only want to hear about terabits of capacity. They want to know where the attack is stopped, how long the rule stays active, how legitimate traffic is preserved and how support will explain the action during the incident.
Possible solutions
The first option is BGP blackholing, useful as a last resort when the priority is to save the rest of the network. It is simple, fast and widely supported by transit providers, but it is destructive for the targeted service. It should not be sold as true availability protection.
The second option is static provider-side filtering: ACLs or classic anti-amplification profiles for DNS, NTP, SSDP, memcached and similar vectors. It works well against obvious attacks but is weaker when the attack imitates normal traffic or changes shape quickly.
The third option is controlled BGP FlowSpec. FlowSpec can propagate rules matching several traffic fields, not only a destination. Used well, it relieves the port without dropping the entire prefix. Used badly, it breaks legitimate traffic as quickly as it stops the flood.
The fourth option is upstream scrubbing with clean traffic returned through GRE, IPIP, VXLAN, cross-connect or a router VM. This is often the cleanest model when the customer needs to stay online during the attack and keep more precise logic behind the first layer.
- BGP Blackhole vs BGP FlowSpec: choosing the right DDoS filtering tool
Compare blackholing and targeted FlowSpec rules.
Concrete use case
Consider a hosting provider exposing several game servers behind a 10G port. A 70 Gbps UDP reflection flood arrives with highly recognizable packets. If everything reaches the customer port, the service disappears. The correct response is not to block all UDP because the games need UDP to work.
A cleaner strategy applies a short upstream rule on attack characteristics such as reflection source ports, a packet-length range and a precise destination. The volume falls below available capacity. Then the specialized mitigation layer continues separating legitimate flows from suspicious ones.
The customer still sees the service online while the attack continues. Support can explain the rule, duration, expected impact and removal plan. That is the difference between “we absorbed traffic” and “we protected the service without unnecessary collateral damage”.
Frequent mistakes
- Confusing upstream filtering with total blackholing of the service.
- Applying a rule that is too broad on UDP or TCP without understanding legitimate traffic.
- Leaving a FlowSpec rule active after the attack ends.
- Not measuring 95th percentile and real saturation thresholds.
- Not preparing the clean return path before the incident.
- Buying only on advertised capacity without asking how filtering decisions are made.
FAQ
Does upstream filtering replace specialized Anti-DDoS?
No. It relieves upstream saturation, but fine mitigation is still needed to preserve legitimate traffic, especially for gaming, UDP and application-specific services.
Is BGP FlowSpec dangerous?
It is dangerous when it is broad, permanent or poorly validated. It is useful when it is precise, temporary and based on observed attack characteristics.
Why not blackhole immediately?
A blackhole cuts the service. It can save the backbone, but it does not protect customer availability.
Can upstream filtering work with a GRE tunnel?
Yes. Upstream filtering can reduce the attack before clean traffic is returned over GRE, IPIP, VXLAN or cross-connect.
