Many exposed services still rely on a classic connectivity model: one or more transit providers, a billing model based on 95th percentile or raw traffic, and standard upstream protection that was not designed around the exact way the application behaves.
That can be enough until the first serious DDoS event. Then the same model can become expensive, slow to adapt and, in the worst case, operationally brutal: links saturate, traffic bills spike and the attacked IP is blackholed to preserve the rest of the platform.
Protected IP transit anti-DDoS exists to solve that problem in a cleaner way. Instead of accepting malicious and legitimate traffic on the same path and hoping generic protection is enough, the traffic is brought through a mitigation layer designed to filter the attack before clean traffic is delivered back to the client infrastructure.
Why the classic model becomes fragile and expensive under DDoS
In a traditional setup, an attack can hurt the customer in three different ways at the same time. First, it can saturate the network edge. A 10G, 25G or even 100G port can be overwhelmed long before the application itself has a chance to react. Once the ingress is full, the service is already losing.
Second, the cost model can turn against the customer. When connectivity is billed on 95th percentile or on raw traffic volume, an attack does not only create operational pain. It can also distort the bill. A few hours of large, sustained unwanted traffic can materially change the monthly cost profile.
Third, if one IP is specifically targeted, the emergency response in classic environments is often simple blackholing. That may protect the rest of the network, but it also takes the attacked service fully offline. For the customer behind that IP, the result is still downtime.
This is the structural weakness of the classic model: malicious traffic is allowed to get too close to the production environment before decisive filtering happens.
What protected IP transit anti-DDoS actually is
Protected IP transit anti-DDoS combines network transit and mitigation. The client establishes a BGP relationship with the mitigation provider and lets the incoming traffic for the protected prefixes pass through that provider’s anti-DDoS layer before clean traffic is delivered to the final infrastructure.
That delivery can be done with or without the client announcing BGP on the handoff side. Depending on the deployment model, clean traffic can be delivered through cross-connect, GRE, IPIP, VXLAN or via a router VM that lets the customer build and manage their own tunnels.
The value is not only that traffic is filtered upstream. It is that the customer keeps a flexible network design while moving the highest-risk part of the DDoS problem away from the production edge.
How the Peeryx delivery model works in practice
At Peeryx, the client can use the service permanently or only activate it during DDoS events. The second model is possible, but it is not the preferred one because BGP convergence time is still a real operational factor. The cleaner model is to keep the protection path in place so mitigation is immediate when an attack begins.
The service works in both symmetric and asymmetric routing. That matters because a customer may want ingress to arrive through Peeryx while keeping outbound traffic local to another provider. In practice, that can lower outbound cost and reduce egress latency without degrading mitigation quality.
Once traffic reaches the mitigation fabric, the job is not to blindly rate-limit or apply heavy static restrictions. The goal is to understand what legitimate traffic looks like for that customer, detect the attack, create the right filtering logic and deliver clean traffic at line rate.
The mitigation fabric itself is designed around a DPDK-based packet-processing architecture optimized for both throughput and high packets-per-second pressure. That matters because real attacks do not only challenge bandwidth figures. They also stress packet handling at scale.
Adaptive mitigation instead of rigid predefined profiles
A common design choice in the market is to rely heavily on predefined mitigation profiles. That can work well for common gaming patterns or other standardized use cases, but it is naturally less flexible when legitimate traffic deviates from the expected template.
Peeryx takes a different approach. By default, no restrictive predefined application filter is forced onto customer traffic during normal conditions. Optional application-aware policies can be enabled when useful, including gaming-oriented filters and predefined profiles for services such as SSH, WireGuard or OpenVPN, but the baseline model is adaptive rather than rigid.
The platform continuously observes legitimate traffic outside mitigation to understand how the service normally behaves. When an attack is detected, the system correlates attack signatures and traffic patterns with that legitimate baseline and automatically generates custom mitigation rules in under 20 milliseconds. The point is not simply to stop the attack fast. It is to stop it fast without blocking what the customer actually needs.
This is also why throughput claims alone are not enough when evaluating anti-DDoS. Some solutions can advertise very high Gbps capacity and still handle comparatively fewer packets per second. In practice, both Gbps and Mpps matter.
Symmetric and asymmetric routing both work
Customers sometimes assume that a mitigation provider must also be the exclusive outbound path. That is not true here. Peeryx can protect incoming traffic while the customer exits locally through another transit provider. That asymmetry can be desirable for latency and for commercial reasons.
What matters is that the anti-DDoS layer sees the protected ingress and has the routing information required to deliver clean traffic correctly. Because the mitigation logic is based on legitimate-traffic understanding rather than simplistic rate caps, the filtering quality does not depend on forcing symmetric egress through the same platform.
For customers who want a single provider on both directions, symmetric routing is equally possible. The design is operationally flexible rather than prescriptive.
Extreme volumetric attacks, no protocol rate limiting and selective FlowSpec usage
Another important differentiator is what does not happen during mitigation. Peeryx does not rate-limit protocols such as TCP, UDP or GRE as a generic defense mechanism. That means legitimate transfers are not artificially slowed down simply because mitigation is active.
For very large volumetric floods, especially high-scale amplification scenarios, BGP FlowSpec can be used automatically and intelligently as a short-lived upstream relief mechanism. The purpose is not to apply broad, damaging filters. It is to shave enough malicious volume off the top when absolutely necessary, based on the same understanding of legitimate traffic, and only for a limited time.
Used this way, FlowSpec becomes a controlled tool for extreme situations rather than a blunt instrument. It also means the platform can absorb attack volumes meaningfully above the headline mitigation number under the right conditions.
What serious buyers should evaluate before choosing an anti-DDoS provider
Do not compare providers only on the number of advertised terabits. Ask how the mitigation adapts to legitimate traffic, how much packet-per-second pressure it can really tolerate, whether asymmetric routing is supported, whether protocols are rate-limited and how clean traffic is delivered back to your infrastructure.
Also ask what happens to your cost model during an attack, whether the provider can protect a prefix without forcing a full migration, and whether you can keep your own downstream filtering logic on dedicated servers, appliances or custom packet-processing stacks.
The best anti-DDoS design is not the most theatrical one. It is the one that still lets your real traffic pass under stress.
Frequently asked questions
Can I keep my current infrastructure and still use protected transit?
Yes. Clean traffic can be delivered back to your infrastructure through GRE, IPIP, VXLAN, cross-connect or a router VM depending on the design you choose.
Does Peeryx require symmetric routing?
No. The service supports both symmetric and asymmetric routing, so inbound protection can pass through Peeryx while outbound traffic can remain local elsewhere if desired.
Will mitigation slow down legitimate traffic?
The platform does not rely on generic protocol rate limiting. The objective is to block malicious traffic while preserving legitimate throughput.
Why does packets per second matter as much as throughput?
Because many attacks hurt a platform through packet pressure before raw bandwidth becomes the visible limit. A provider can look strong in Gbps and still be weaker in high-PPS conditions.
Conclusion
Protected IP transit anti-DDoS is not just about putting a bigger number in front of a customer. It is about changing where the attack is handled, how quickly filtering adapts and how much legitimate traffic is preserved while the attack is active.
For customers exposed to large attacks, sensitive to latency or billed on transit usage, that difference is operationally and commercially significant. The right design can avoid saturation, avoid unnecessary blackholing and protect the business logic of the service—not only the network edge.
Need a protected transit design that fits your real traffic?
Talk to Peeryx about protected IP transit, clean traffic delivery, asymmetric routing and mitigation strategies built around legitimate traffic rather than one-size-fits-all profiles.