On this page
Key points
- PPS breaks firstA firewall or server can collapse under 100Mpps even when bandwidth is not fully used.
- Drop earlyThe closer the drop happens to the network edge, the less CPU, memory and queue pressure the attack creates.
- Deliver clean trafficThe useful result is a reachable service, not only a prettier blocked-traffic chart.
100 Mpps has a physical bandwidth requirement
100 Mpps means 100 million packets per second. For minimum 64-byte Ethernet frames, including FCS, add 8 bytes of preamble/start delimiter and 12 bytes of inter-frame gap. The nominal wire-rate budget is 100,000,000 × (64 + 20) × 8 = 67.2 Gbit/s.
This is a physical calculation, not a filtering benchmark. Larger frames require more bandwidth. IP-byte counters, frame-byte counters and aggregate ingress/egress counters use different boundaries; record the convention before comparing results.
Why it matters for revenue and availability
When a service fails under high PPS, users do not see a “complex attack”. They see an offline application, an unplayable game server, timeouts or support overload.
High PPS also increases false-positive risk. Under pressure, many teams apply broad emergency blocks that save the platform but break legitimate UDP, TCP sessions or latency-sensitive flows.
Selling protected IP transit, Anti-DDoS dedicated servers or gaming protection requires proving that the design understands real packet-rate limits, not only Tbps marketing.
handling 100 Mpps requires thinking in CPU cycles, NIC queues, drop path and out-of-hot-path observability.
Possible solutions for 100Mpps+
The first answer is upstream filtering: reduce packet noise before it reaches the customer port or server. This can involve FlowSpec, network ACLs, scrubbing capacity or protected transit.
The second layer is fast local filtering: XDP, eBPF, DPDK, VPP or specialized appliances depending on the environment. The hot path should stay simple, measurable and as stateless as possible.
Finally, delivery matters. GRE, IPIP, VXLAN, cross-connect or router VM must be sized for the remaining clean traffic with predictable latency.
- Upstream relief
- Reduce PPS before the customer receives the flood.
- Local fast path
- Avoid state, expensive logs and unnecessary parsing on the hot path.
- Clean handoff
- Return useful traffic through the delivery model that fits the topology.
Gaming service under 120Mpps
At the same minimum-frame convention, 120 Mpps occupies 80.64 Gbit/s. A 100 Gbit/s Ethernet port has a theoretical ceiling of approximately 148.81 Mpps for those frames. Neither figure establishes how many packets a particular software policy can filter or forward.
Qualify the complete workload: receive queues, CPU and NUMA placement, active rules, flow count, tunnel processing, loss and legitimate transaction success. A suitably qualified server may meet the requirement; its port speed or CPU model alone is insufficient evidence.
Common mistakes
The first mistake is sizing only in Gbps. The second is allowing a stateful firewall to see the full flood before mitigation. The third is assuming a powerful server will compensate for bad topology.
Another mistake is confusing mitigation charts with real quality. If clean traffic returns with heavy jitter or false positives, the protection does not meet the business need.
- Looking only at Gbps and ignoring packets per second.
- Letting a stateful firewall absorb the first wave.
- Using broad rules that break UDP or legitimate sessions.
- Forgetting latency and jitter after mitigation.
Continue reading
These resources connect the 100Mpps+ topic with concrete offers: transit, dedicated server and gaming reverse proxy.
Questions and answers
Can 100 Mpps fit on a 10 Gbit/s Ethernet port?
Not as 100 million minimum Ethernet frames per second on one direction of that port. That requires 67.2 Gbit/s with the stated 64-byte-frame convention. Check whether a reported rate aggregates several interfaces or directions.
Does a 100 Gbit/s port prove 100 Mpps filtering?
No. The physical link budget and the filtering engine’s measured capacity are different limits. Test the actual hardware, software version and active policy.
What should a benchmark include?
State frame sizes, overhead convention, directions, flow distribution, rules, hardware and software versions, duration, offered load, loss and legitimate-traffic results. Keep load tests on an authorized isolated setup.
