Keep network control
Protected transit makes sense when customer prefixes, edge design and BGP policy must stay central to the architecture.
Protected IP Transit
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.
Relevant when you want to keep BGP and network control
Relevant when production already exists and should not be rebuilt
Relevant when latency, operating cost and handoff quality really matter
Relevant when you need several serious ways to get clean traffic back
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
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.
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
Peeryx network blueprint
From exposed traffic to clean traffic
A readable model: protected ingress, mitigation, handoff decision and clean delivery aligned with your topology.
Protected ingress
Targeted mitigation
Clean traffic handoff
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
Existing dedicated server integration
Protection without rebuilding production
Peeryx can clean traffic upstream and hand legitimate traffic back to a server that is already live.
Fast deployment
Preserve existing infra
Clean return path
XDP vs DPDK for Anti-DDoS filtering: which one should you choose?
The xdp vs dpdk anti ddos question comes up all the time. This guide gives a practical answer for network and security teams: what XDP does extremely well, where DPDK becomes the right tool, and which approach usually offers the best cost/performance ratio.
Read the article
Peeryx network blueprint
From exposed traffic to clean traffic
A readable model: protected ingress, mitigation, handoff decision and clean delivery aligned with your topology.
Protected ingress
Targeted mitigation
Clean traffic handoff
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.