High PPS attack mitigation: protect routers, firewalls and game servers

PPS attacks target decisions per second

Every packet requires work: receive, queue, parse, match rules, update counters or decide whether to keep state. Small packets make that work happen more often for the same bandwidth.

A high PPS flood can therefore hurt even when the link is not full. The bottleneck becomes packet decisions, memory access, interrupts, NIC queues or firewall state.

Why Mpps matters for customer experience

When PPS limits are reached, latency becomes unstable before the service fully disappears. Games feel laggy, APIs return intermittent errors and VPS customers report random network issues.

This is commercially dangerous because the attack looks like poor infrastructure quality. Customers may not care that bandwidth graphs look acceptable; they care that packets are lost.

The practical objective is to protect revenue, support teams and brand trust, not just to make a graph look clean. A mitigation article must therefore connect technical symptoms to business continuity: what stays online, what is degraded and how quickly the client can recover normal routing.

How to mitigate high PPS floods

The best mitigation drops unwanted traffic as early and cheaply as possible. Stateless first-pass filters, upstream relief, FlowSpec or ACL assistance and careful queue design all matter.

Stateful inspection should be used after the obvious noise is removed. Otherwise the attacker forces expensive logic to run on packets that should never reach that layer.

Before choosing a model, define the protected asset precisely: a full ASN, a single prefix, one VPS, one dedicated server or one game endpoint. The best solution changes when the bottleneck is upstream bandwidth, packet rate, firewall state or protocol behavior.

How Peeryx handles PPS pressure

Peeryx reads PPS and Gbps together. A 10 Gbps high-PPS flood can be more urgent than a larger flood with easy-to-classify packets. The mitigation path is chosen according to the bottleneck.

For protected transit, that means reducing noise before delivery. For servers and gaming, it means preserving legitimate small-packet behavior while removing abusive rates and patterns.

This is also why Peeryx separates delivery models instead of forcing every customer into the same product. Transit customers need routing freedom, while gaming and server customers often need a more operationally simple path.

Concrete example

A game server receives only 7 Gbps, but the packet rate reaches several Mpps. The host firewall becomes unstable and legitimate players disconnect. Increasing port speed alone will not solve it.

Early filtering removes the repeated pattern before the server. Clean traffic is then delivered through the appropriate path, keeping the game responsive.

Common mistakes

Testing only with large packets gives false confidence. Real attacks often use small packets specifically to pressure processing.

Another mistake is placing verbose counters, logging or stateful rules in the hot path. During high PPS, every extra operation matters.

Why choose Peeryx

The right choice is not only advertised capacity: it is the filtering point, precision, clean handoff and the ability to keep customers online during the attack.

Related Peeryx resources

FAQ