La page ne vend plus juste une capacité brute : elle met visuellement en avant le chemin réseau, les modes de raccordement et la partie trafic propre.
Protected BGP transit · Operator-grade Anti-DDoS
Protected IP transit to keep your prefixes
Built for network teams that want to filter the attack, keep BGP logic and get clean traffic back in a usable form.
Clean traffic, controlled handoff, network control preserved.
15 Tbpsannounced Anti-DDoS capacity
5 modesGRE, IPIP, VXLAN, cross-connect, router VM
BGP includedunder-ASN, AS-SET, no prefix limit
Ingress et upstream filtering.
L3/L4, profils légitimes, règles ciblées.
GRE, IPIP, VXLAN, cross-connect ou VM routeur.
European footprint
European points of presence
Marseille is the initial scrubbing center. Paris is part of the launch design for handoff and network integration. Frankfurt, Amsterdam and Madrid follow in the next expansion phases.
Live / included at launch
Coming soon
Paris
Included point of presence
Marseille
Primary scrubbing center
Frankfurt
Coming soon
Amsterdam
Coming soon
Madrid
Coming soon
When to choose Peeryx protected IP transit
The right fit when you need a real network product
This model is for teams that need more than a single protected IP or a one-size-fits-all tunnel. It preserves prefixes, BGP control and multiple clean-traffic handoff models while protecting infrastructure that is already in production.
- You keep your prefixes, announcement policy and routing constraints
- You need to protect existing infrastructure without a forced migration
- You want a clean comparison between BGP, GRE, cross-connect, protected IPs and hybrid models
- Your team needs a service that is documentable, integrable and operable every day
Keep network control
Protected transit makes sense when customer prefixes, edge design and BGP policy must stay central to the architecture.
Return clean traffic the right way
Cross-connect, GRE, IPIP, VXLAN or a router VM are not sales details. They are the mechanisms that define the real quality of the integration.
Compare service quality, not just price
A technical buyer wants to see the traffic path, mitigation model, handoff design and the constraints that remain on the customer side.
Prepare a clean deployment scope
A good model lets you frame prefixes, links, target latency, current hoster and legitimate traffic return paths from the start.
Because it makes compatibility with the existing environment, handoff quality and long-term operating cost visible from the beginning.
What you keep with Peeryx
A serious anti-DDoS service should not make your architecture opaque
Peeryx protected transit is built so the customer keeps the useful part of the design: prefixes, BGP logic, edge, handoff model and complementary filters whenever that makes sense.
Prefixes, ASN and policy
When the design requires it, Peeryx integrates without taking away control over prefixes, ASN or useful BGP policy.
Infrastructure already in place
Dedicated servers, clusters, proxies, edge routers and existing links can stay at the core of production.
Credible handoff models
The choice between cross-connect, GRE, IPIP, VXLAN, protected IPs or a router VM should answer a real constraint, not a marketing claim.
Complementary filtering on your side
After Peeryx pre-filtering, you can still finish the job with your own XDP, DPDK, ACL or application-proxy logic.
How Peeryx works
Peeryx intercepts the attack, filters precisely and hands back only useful traffic
Peeryx sits between the Internet and your production as a specialized network layer. Depending on the scenario, your prefixes are announced toward the platform or your services are exposed through protected IPs, then legitimate traffic is returned through the delivery model that best fits your environment.
Protected transit or protected IPs depending on the need
BGP included with under-ASN and AS-SET support
GRE / IPIP / VXLAN / cross-connect / router VM
Compatible with symmetric or asymmetric routing
Controlled network exposure
BGP announcements for your prefixes or exposure through protected IPs depending on the level of control you want, rollout speed and the way your network already operates.
Mitigation built around real traffic
Filtering is designed to preserve legitimate traffic, with continuous observation, targeted signatures and upstream relief only when attack volume truly requires it.
Delivery matched to your topology
Cross-connect, GRE, IPIP, VXLAN or a router VM: Peeryx does not force a single model. The right handoff depends on your edge, hoster, target latency and operating style.
Existing infrastructure preserved
Dedicated servers, clusters, gaming platforms, APIs and critical services can stay where they are. The goal is to protect what already runs before considering wider changes.
How Peeryx receives traffic, how mitigation is applied, how clean traffic comes back and how much network control the customer keeps.
Delivery models
Choose the right integration model
Depending on your topology, clean traffic can be delivered through protected IPs, GRE, IPIP, VXLAN, cross-connect or a router VM. The right choice depends mainly on the infrastructure already in place and the level of network control you need.
Protected IPs
A practical way to start quickly with clean public exposure and lower early complexity.
GRE tunnel
A standard model for protecting an existing dedicated server without rebuilding the full architecture.
BGP
Best suited when your own prefixes and routing policies need to remain in place.
Production-first approach
The objective remains to add protection without disrupting the customer’s daily operations.
Why choose real protected transit
Transit first
A clear focus on protected transit for infrastructure, hosting and public-facing services.
Flexible delivery
Cross-connect, GRE, IPIP, VXLAN and router VM delivery models let you fit Peeryx into your existing network design.
Policy control
Five included post-filter firewall rules let you ratelimit, accept or drop traffic after mitigation.
Built for serious traffic
Protection spans L3, L4, L5 and L7, including DDoS targeting all L3/L4 protocols.
Clean-traffic handoff models
Cross-connect
Protected transit delivered directly in datacenter for low-latency, high-trust interconnection.
GRE tunnel
Fast deployment model for secure protected transit over established GRE encapsulation.
IPIP tunnel
Simple routed delivery option when IPIP better matches your infrastructure constraints.
VXLAN tunnel
Flexible protected delivery for environments built around overlay network designs.
Router VM
Prefer to keep tunnel control on your side? Peeryx can provide a router VM for iBGP or eBGP return paths.
From attack to clean handoff
1. Delivery design
Choose cross-connect, tunnels or router VM based on your existing topology and operational preferences.
2. Protected ingress
Traffic enters the Peeryx mitigation fabric where volumetric and protocol attacks are filtered in real time.
3. Post-filter policy
Firewall rules and behavioral analysis refine the accepted traffic profile after core mitigation.
4. Clean handoff
Filtered traffic is handed back to your infrastructure through the chosen delivery method, with BGP included.
Protected transit pricing
Commit-based pricing that stays readable, with a model built for real production, BGP control and clean traffic delivery.
100 Mbps → 500 Mbps
€1/Mbps
Commit pricing
500 Mbps → 1 Gbps
€0.60/Mbps
Commit pricing
1 Gbps → 5 Gbps
€0.44/Mbps
Commit pricing
5 Gbps → 10 Gbps
€0.29/Mbps
Commit pricing
Overcommit excess: €1.50/month per exceeded Mbps
24h free trial available before purchase
Everything included in the default offer
Everything included in the default offer
- BGP announcement included
- No prefix announcement limit
- Under-ASN support included
- AS-SET parameter supported
- Anti-DDoS firewall included
- Behavioral AI-based mitigation included
- 5 included firewall rules
- Additional rules available at low extra cost
Router VM
Router VM to keep control
If you want to keep control over BGP sessions, tunnels or handoff logic, Peeryx can provide a router VM that fits your architecture.
Option
Optional game filtering
Add specialized gaming traffic filtering for €190/month when you need deeper rules tailored to game protocols and session patterns.
Deployment windows
Tunnel delivery
Up to 24 hours
Cross-connect delivery
Up to 72 hours
Urgent activation
Under 2 hours with €250 setup
Typical use cases
Hosting providers
Protect public-facing customer workloads without sacrificing delivery flexibility.
Infrastructure operators
Add premium Anti-DDoS protected transit to exposed backbone segments and edge services.
Enterprise services
Secure business-critical applications, APIs and platforms against disruptive traffic spikes.
Gaming-related networks
Protect game-adjacent infrastructure while keeping the transit product as the operational core.
Technical fit and network operations
When protected IP transit is the right design
Protected IP transit anti-DDoS makes sense when you need upstream mitigation, clean traffic delivery and a network model that still fits existing production constraints.
Keep routing ownership
Peeryx fits best when you want to preserve visibility over routing, prefixes and handoff choices instead of accepting an opaque mitigation model.
Get clean traffic back in a usable way
The goal is not only to absorb the attack. It is to return clean traffic to a server, cluster, proxy or edge that remains useful in production.
Pre-filter before your custom stack
Peeryx can act as the first anti-DDoS layer before your own XDP, DPDK, reverse proxy or specialised application logic.
Scale port capacity without redesigning everything
When requirements move from 2x10G to larger ports, the right model is the one that avoids a full redesign of architecture and operations.
What helps us scope a serious technical project faster
What helps us scope a serious technical project faster
The clearer the network and operations constraints are, the faster Peeryx can propose a clean and realistic delivery design.
- Prefixes or IP ranges to protect, usual traffic profile and target port size
- Type of exposed services, latency constraints and critical countries or regions
- Preferred clean-delivery model: cross-connect, GRE, IPIP, VXLAN or router VM
- BGP expectations: ASN, under-ASN, AS-SET, announcements and routing limits
- Target environment behind Peeryx: existing server, cluster, proxy or custom filter
- Operational requirements: observability, rollback path, test plan and growth model
Blog
Why this topic matters before choosing an anti-DDoS provider
Before buying protected transit, buyers should understand link saturation, 95th percentile billing, blackholing, asymmetric routing and the difference between static profiles and truly adaptive mitigation.
FiveM “Failed to getinfo after 3 attempts” / “Fetching info from server”: blocked UDP, bad proxy or incompatible Anti-DDoS?
In FiveM, “Failed to getinfo after 3 attempts” and “Fetching info from server” often point to the same issue: the join phase is degraded by blocked UDP, a bad proxy, unsuitable Anti-DDoS filtering or a limited hoster. Here is how to diagnose it and why Peeryx FiveM Reverse Proxy Anti-DDoS can prevent it.
Read article
What to do when your hoster’s Anti-DDoS is no longer enough
When your hoster’s Anti-DDoS is no longer enough, the worst decision is often to migrate in a hurry. This guide explains how to identify the real limit, keep the existing server when possible, then add specialised protection with tunnels, reverse proxy, router VM or protected IP transit.
Read article
How to choose an Anti-DDoS provider without getting trapped
Choosing an Anti-DDoS provider should not be reduced to a Tbps number or a promise of unlimited protection. What matters is how traffic enters the mitigation layer, how it is filtered, how clean traffic is delivered back, what visibility you get during an attack and which limits actually exist.
Read article
How do you mitigate a DDoS attack above 100Gbps?
Link, PPS, CPU, upstream relief and clean handoff: the real framework behind credible 100Gbps mitigation.
Read the article
BGP Flowspec for DDoS: useful or dangerous?
What Flowspec does well, what it should never do alone and how to fit it into a safe multi-layer strategy.
Read the article
Upstream Anti-DDoS pre-filtering: when to use it and why it changes everything
Upstream Anti-DDoS pre-filtering is meant to relieve pressure early, protect links and reduce load before fine-grained decision layers take over. This guide explains when to use it, what it should actually do and why it changes the global cost/performance ratio. It also helps compare upstream Anti-DDoS pre-filtering, link relief, volumetric reduction and layered mitigation with an operator-grade architecture, operations and buying logic.
Read the article
Dedicated Anti-DDoS filtering server: what is it really for?
A dedicated Anti-DDoS filtering server separates production from the decision layer, enables more precise logic and keeps the existing stack behind it. This guide explains when the model makes sense, when it does not and how to place it cleanly inside the architecture. It also helps compare dedicated Anti-DDoS filtering server, upstream filtering, clean handoff and production architecture with an operator-grade architecture, operations and buying logic.
Read the article
Anti-DDoS clean traffic delivery: why the handoff matters as much as mitigation
In Anti-DDoS architecture, mitigation alone is not enough: legitimate traffic still has to be delivered back correctly. This guide explains why clean traffic handoff matters as much as scrubbing, how to choose the right delivery model and which mistakes break daily operations. It also helps compare clean traffic delivery, clean handoff, GRE, IPIP, VXLAN and cross-connect with an operator-grade architecture, operations and buying logic.
Read the article
Gaming Anti-DDoS: why generic filtering is not always enough
Gaming needs Anti-DDoS protection built around sessions, latency, false positives and real protocol behaviour. This guide explains why generic filtering is not always enough and how to design a more serious gaming protection model. It also helps compare gaming Anti-DDoS, false positives, session stability and game-specific filtering with an operator-grade architecture, operations and buying logic.
Read the article
Protected transit FAQ
When should I choose Protected IP Transit instead of a simple protected IP or proxy?
Protected IP Transit makes sense when you want real network control, keep your prefixes or integrate mitigation into an architecture already structured around BGP and clean handoff.
Can I keep my prefixes, ASN and routing policies?
Yes. Peeryx is built for customers that want to preserve network logic, with BGP included, under-ASN support and delivery models compatible with several designs.
Which clean-traffic handoff models are available?
Clean traffic can be returned through cross-connect, GRE, IPIP, VXLAN or a router VM depending on topology, operations and latency targets.
Can Peeryx be used as pre-filtering before my own program or internal edge?
Yes. In some scenarios, Peeryx can protect upstream and hand clean traffic back so your own filtering logic or internal network edge can do the rest.
Can Peeryx be used only as a pre-filter before my own XDP or DPDK engine?
Yes. Peeryx can clean traffic upstream and then deliver it back through GRE, IPIP, VXLAN, cross-connect or a router VM. That is useful when your own custom logic still sits behind it.
Do I need to migrate my whole architecture to use protected IP transit?
No. The goal is to match the existing environment as closely as possible. Depending on the case, Peeryx can integrate while preserving your prefixes, edge design or existing proxies.
Let’s review your transit architecture
Share your network context, latency targets, preferred handoff model and the services you need to protect. We’ll tell you whether protected transit is the right fit and how to integrate it cleanly.