Featured articlePublished on April 16, 2026Reading time: 8 min
Protected IP Transit Against DDoS: Mitigation Designed to Preserve Legitimate Traffic
A practical guide to link saturation, 95th percentile billing risk, blackholing, asymmetric routing, adaptive filtering and the importance of both Gbps and Mpps.
Prevent saturation
An attack can fill the port long before the application has any chance to react.
Reduce billing risk
Malicious spikes can distort 95th percentile or traffic-based connectivity bills.
Preserve latency
Asymmetric routing allows ingress via Peeryx while keeping local egress when it makes sense.
Block without breaking
The goal is not only to filter fast, but to keep legitimate traffic working while the attack is stopped.
Today, many Internet-facing infrastructures — SaaS platforms, real-time services, hosting environments, gaming stacks or APIs — are regularly exposed to larger and more sophisticated DDoS attacks.
In a classic connectivity model, those attacks can quickly saturate links, interrupt service, inflate transit bills when billing is based on 95th percentile or raw traffic, or force blackholing of the attacked IP, directly impacting legitimate users.
That is exactly why protected IP transit anti-DDoS matters. Instead of allowing malicious traffic to reach the production edge and reacting too late, the traffic is brought through a mitigation layer designed to filter the attack before only clean traffic is delivered back.
The limits of the classic model under DDoS
Before looking at protected transit, it is important to understand why the classic model stops working once a service starts attracting serious or repeated attacks.
In a standard environment, malicious traffic gets too close to production before decisive filtering happens. That is where saturation, invoice spikes and overly destructive emergency responses begin.
When malicious traffic gets too close to production, the risk is not only technical. It becomes operational and financial as well.
Network saturation
A volumetric attack can exceed 100 Gbps or even several Tbps. A 10G, 25G or even 100G port can fill up long before the service has any chance to defend itself.
Billing spike
When connectivity is billed on 95th percentile or raw traffic, a few hours of sustained unwanted traffic can materially distort the monthly bill.
IP blackholing
In many environments, the emergency response becomes a blackhole on the attacked IP. The rest of the network survives, but the targeted customer still goes offline.
Profiles that are too generic
Standard protection often relies on predefined mitigation profiles. They may work on common patterns, but they are less flexible on atypical traffic and more exposed to collateral filtering.
What is protected IP transit anti-DDoS?
Protected IP transit anti-DDoS means that the traffic destined to your IP prefixes is carried through a mitigation infrastructure able to filter the attack upstream and then deliver only legitimate traffic back to your infrastructure.
Unlike a closed protection model or mitigation based only on rigid static profiles, this design preserves real control over the network architecture, delivery methods and the way traffic is handed back to the customer.
carry the traffic through a mitigation infrastructure
filter attacks upstream
deliver only legitimate traffic to the final infrastructure
keep flexibility on BGP, tunnels and delivery models
How protected transit works in practice
The customer announces IP prefixes through BGP. From there, several models are possible: using protected transit permanently, activating it only during attacks — which is less ideal because BGP convergence time still matters — or choosing symmetric or asymmetric routing depending on operational constraints.
At Peeryx, asymmetric routing is not a degraded mode. A customer can ingest traffic through Peeryx while keeping outbound traffic local through another transit provider if that improves latency or commercial efficiency. That does not reduce mitigation quality.
Once traffic reaches the mitigation fabric, the goal is not blind rate limiting. The goal is to understand legitimate traffic, detect the attack, generate the right filtering logic and deliver clean traffic back at line rate.
1. BGP integration
The customer announces the prefixes and chooses a permanent or attack-triggered operating mode.
2. Traffic analysis
Legitimate traffic is continuously observed so a usable baseline exists when an attack starts.
3. Rule generation
As soon as the attack is detected, custom filters are generated from the live signatures and the service’s real behaviour.
4. Clean delivery
Filtered traffic is handed back through cross-connect, GRE, IPIP, VXLAN or a router VM depending on the architecture.
Automatic adaptive mitigation
Many solutions on the market rely mainly on predefined mitigation profiles. That can fit some very standard use cases, especially classic gaming patterns, but it becomes limiting when legitimate traffic does not match the expected template.
By contrast, Peeryx does not force restrictive application filters by default. Optional predefined policies can be added when they are useful — for example for FiveM, Minecraft, Rust, Garry’s Mod, Hytale, SSH, WireGuard or OpenVPN — but the baseline platform behaviour is adaptive.
The system continuously analyses legitimate traffic outside mitigation windows to understand usage, normal flows and service-specific characteristics. When an attack is detected, it correlates signatures and patterns with that baseline and generates custom rules in under 20 ms to stop the attack without blocking useful traffic.
The difference is not only headline Gbps. The real difference appears when the attack must be blocked without damaging legitimate traffic.
Clean traffic delivery
Clean traffic can be delivered with or without BGP announcement on the handoff side. The point is to adapt to the customer architecture rather than forcing a single interconnection model.
GRE / IPIP tunnel
Simple and fast to deploy when an existing infrastructure must be protected without heavy migration.
VXLAN
More flexible for advanced architectures or environments where richer encapsulation is desirable.
Cross-connect
Lowest possible latency and maximum performance for customers present in the same datacenter environment.
Router VM
Full control for customers that want to create and manage their own tunnels and handoff logic.
Concrete use cases
Protect an existing server
Add a protection layer to an OVH, Hetzner or similar dedicated server without moving the whole infrastructure.
Host your own filtering logic
Use a dedicated server with XDP or other logic to finish filtering after upstream relief.
Gaming workloads
FiveM, Minecraft and other latency-sensitive services need mitigation that is fast, clean and minimally intrusive.
SaaS, APIs and critical services
Non-standard applications and atypical flows benefit strongly from mitigation designed around real traffic behaviour.
Why this approach is more advanced
This approach is not only about “holding Gbps”. It is about understanding the protected service, preserving its application logic and handling the reality of PPS pressure as well. Some solutions can advertise impressive bandwidth figures while being less comfortable when the real pressure is primarily packet-rate driven.
Another important point is what does not happen during mitigation: no generic protocol rate limiting is applied on TCP, UDP, GRE or other protocols. Mitigation should not slow down legitimate transfers or artificially cap performance simply because protection is active.
For truly extreme floods, especially some volumetric amplification scenarios, BGP FlowSpec can be used automatically and intelligently, but only when there is a real need, for light upstream relief and for a short time. The goal is not to become overly strict. The goal is to shave enough volume off the top without sacrificing legitimate traffic.
Baseline analysis, attack detection, custom rule generation and selective FlowSpec form a coherent chain, not a pile of static filters.
no rigid rules forced by default
no generic blocking without understanding the service
continuous awareness of legitimate traffic
designed for both Gbps and Mpps realities
selective BGP FlowSpec usage only when it is truly needed
Common mistakes to avoid
A good anti-DDoS design must protect the link, the bill, the user experience and the business logic of the service. If it only protects one of those layers, it remains incomplete.
Focusing only on Gbps when PPS is often the real limiting factor.
Choosing a generic protection model for traffic that does not fit standard patterns.
Ignoring routing design even though symmetric and asymmetric models can have very different commercial and latency implications.
Assuming protected transit replaces every complementary layer when a multi-layer design is often still the cleanest operational model.
FAQ
Can I keep my current infrastructure?
Yes. Clean traffic can be delivered back through tunnels or through a BGP design adapted to the infrastructure you already have.
Does mitigation impact performance?
No. There is no generic protocol rate limiting applied during mitigation.
Will legitimate traffic be blocked?
The whole purpose of the platform is to avoid that by generating filters from the service’s real traffic and the patterns observed during the attack.
Is it suitable for very large attacks?
Yes. And for extreme cases, BGP FlowSpec can be used in a short and selective way to shave the volume without damaging legitimate traffic.
Conclusion
Protected IP transit anti-DDoS is now a core building block for exposed infrastructures that want to avoid saturation, unnecessary blackholing and overly destructive generic responses.
It allows massive attacks to be absorbed, protects services without forcing a full migration, preserves real routing control and adapts mitigation to each workload instead of imposing static profiles.
Modern solutions should not only advertise capacity numbers. They should be able to understand legitimate traffic and adapt dynamically to the real behaviour of the service under protection.
Go deeper into the architecture
These pages help move from a standalone article to a clearer understanding of the offers and delivery model.
Peeryx provides protected IP transit anti-DDoS, symmetric or asymmetric routing, adaptive mitigation based on legitimate traffic, delivery through GRE, IPIP, VXLAN or cross-connect, and an architecture designed to protect without breaking what makes the service work.
