On this page
Key points
- Above 100Gbps, architecture matters more than the headline numberLink capacity, PPS, CPU, clean handoff and failover logic all need to be designed together if mitigation is meant to stay usable.
- Gbps is not the whole storyAttacks may break a service through bandwidth, packet rate or CPU cost before the app can react.
- Upstream relief mattersPre-filtering exists to do coarse reduction so that more intelligent layers remain stable.
- Specify the acceptance testAgree on packet sizes, rules, legitimate traffic, loss and recovery criteria; inspect the busiest queue and the remaining path after failure.
100 Gbit/s is a link rate, not a filtering result
Start with the first constrained segment and the layer at which the rate was measured. An observed attack, a physical port, an aggregate across locations and reserved customer capacity are different quantities. A 100 Gbit/s interface can be the bottleneck even when a provider advertises much more capacity elsewhere.
The following values are wire-rate arithmetic for one direction of an Ethernet link. Frame length includes the Ethernet frame and FCS; add 8 bytes of preamble/SFD and 12 bytes of inter-frame gap. Mpps = Gbit/s × 1,000 ÷ [8 × (frame bytes + 20)]. These values are not software benchmarks and do not account for a particular implementation’s packet-processing limits.
| Ethernet frame, including FCS | Theoretical rate at 100 Gbit/s | Interpretation |
|---|---|---|
| 64 bytes | 148.81 Mpps | Small frames require many packet decisions |
| 128 bytes | 84.46 Mpps | Same link bitrate, a different packet rate |
| 512 bytes | 23.50 Mpps | State and rules can still dominate cost |
| 1,518 bytes | 8.13 Mpps | Large frames do not prove small-packet performance |
Volumetric and application-layer attacks do not belong to the same layer
A volumetric attack first targets the network path: bandwidth, buffers, flow handling and packet rate. An application-layer attack aims to exhaust service logic, proxies or application resources. Both can coexist, but they should not be handled in the same place.
When talking about more than 100Gbps, the first priority is usually to survive the volume and the PPS. If the link collapses before that, your smartest L7 logic never gets a chance to work.
- Volumetric pressure has to be handled first at absorption level.
- Application-aware filtering comes afterwards and needs more context.
- Mixing both too early leads either to collateral damage or wasted CPU.
Link saturation, PPS saturation and CPU saturation are three different failures
A DDoS does not break a service in only one way. It may fill the link, overwhelm the path with packets per second or push too much CPU cost into the mitigation logic. That is why a simple capacity number says very little without an architecture behind it.
Measure per-queue and per-core load as well as totals. An uneven flow distribution can overload one queue while other cores are idle. A server with two 100G ports may use one for ingress and one for egress: that does not make a 200 Gbit/s one-way filtering path. State the direction, packet accounting and role of each port in the test report.
Link saturation
The port or transit fills before deeper analysis can happen.
PPS saturation
Packet rate becomes the real killer even when Gbps still looks manageable.
CPU saturation
The filtering stack sees the traffic but burns too many cycles to stay stable.
The role of upstream pre-filtering
Upstream pre-filtering exists to do coarse reduction. Its job is not to decide all legitimacy by itself, but to remove patterns that are obvious enough so that massive noise does not hit the most expensive stages.
That is often the best cost/performance point: send less raw noise to the filtering server, preserve link headroom and keep room for the traffic that actually needs intelligence.
The role of a filtering server
Accept a filtering server against a repeatable workload, not a CPU model alone. Record software and rule versions, NIC and driver, queue distribution, NUMA placement, packet sizes and the enabled stateful features. Measure received traffic, discarded attack traffic, forwarded legitimate traffic, packet loss and latency under the same conditions.
Use an isolated, authorized test environment. RFC 2544 is a benchmarking methodology; RFC 6815 explains why applying those tests to a production network can disrupt users. Test failure recovery and the surviving path at the planned load separately. A good laboratory result does not establish the capacity of an untested production topology.
The role of tunnels and clean traffic return
Mitigation alone is never enough. Clean traffic still has to be injected where the customer needs it, without forcing a full rebuild. That is where GRE, IPIP, VXLAN, BGP over GRE or cross-connect handoff models matter.
The right model depends on the context: an existing dedicated server, a backbone, a cluster, a proxy or the need to preserve public IPs. The key is not the tunnel name. The key is whether the handoff is coherent with the real topology.
- A good handoff avoids a full migration just to get protected.
- The tunnel is part of the operating model, not only a transport choice.
- Clean traffic return must be planned before the attack, not after saturation.
Common mistakes
- Thinking 100Gbps is only a bandwidth topic.
- Trying to place all mitigation logic in one layer.
- Ignoring clean traffic return until production can no longer accept the flow cleanly.
- Filtering too aggressively upstream without a real legitimate traffic baseline.
- Buying a mitigation promise without understanding the handoff model.
FAQ
Does a DDoS attack above 100Gbps automatically mean an outage?
No, but it requires a prepared architecture. Without absorption, coarse reduction and clean return, the risk rises very quickly.
Can a single filtering server be enough?
Not always. It can be extremely useful, but without upstream relief it may become the next bottleneck.
Why focus so much on clean traffic return?
Because mitigation only creates value if the customer gets usable legitimate traffic back.
Can an existing infrastructure be preserved?
Yes, very often. That is exactly why the delivery model matters so much.
What should you measure first before talking about 100Gbps?
Start by separating link saturation, packets-per-second saturation and CPU pressure. That is what prevents bad sizing decisions.
