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.
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.
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.
- 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.
Need a design adapted to your real traffic?
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.