Protected IP Transit Against DDoS: Mitigation Designed to Preserve Legitimate Traffic

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

No. The effect depends on the billing interval, measurement point, sample duration and the share of high samples. Compare the contracted commit with the measured P95; do not infer it from the maximum traffic spike.

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.

What is protected IP transit anti-DDoS?

Protected IP transit combines Internet connectivity with DDoS filtering upstream of the agreed delivery point. The objective is to reduce attack traffic while maintaining access to the protected services. Its effectiveness depends on the traffic, policy, available capacity and delivery path.

How protected transit works in practice

Traffic for the protected prefixes is attracted through the agreed routing policy. BGP controls reachability; filtering is performed by the mitigation infrastructure. Always-on and on-demand paths have different convergence and operating requirements.

Filtered traffic is delivered through the contracted handoff. Validate the receiving capacity, MTU, return path and real application traffic before production use. Platform-wide mitigation capacity is not the bandwidth reserved for an individual port or tunnel.

1. Routing

   Verify the announced prefixes, authorization and intended ingress.

2. Observation

   Compare bandwidth, packet rate and application symptoms with normal traffic.

3. Filtering

   Apply the selected policy and verify its effective state.

4. Delivery

   Check the receiving path and successful legitimate transactions.

Detection, rule application and verification

Mitigation compares observed traffic with configured thresholds and filtering rules. Detection, decision, rule application and service recovery are separate stages. Their delays depend on sampling, the attack, the deployed configuration and the traffic path.

This guide does not establish a measured end-to-end reaction time. During qualification, record when the abnormal traffic starts, when the rule is applied and when legitimate application transactions recover. A fast local decision alone does not demonstrate recovery across the network.

Clean traffic delivery

The handoff can preserve the existing infrastructure when addressing, routing and endpoint capacity allow it. Encapsulation transports packets; it does not itself identify malicious traffic.

GRE / IPIP

L3 delivery to an existing endpoint; check the underlay, MTU and return route.

VXLAN

An overlay option when Ethernet delivery and segmentation are required; account for its additional overhead.

Cross-connect

A physical interconnection whose port, VLAN, redundancy and available capacity must be confirmed.

Router VM

A routing or tunnel-termination point. Its usable throughput depends on the virtualized path and allocated resources.

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.

Evaluate filtering with legitimate traffic

Measure accepted and rejected traffic, new-connection success, loss and application response times. Lower attack volume is useful only if the required service remains usable. No filtering policy can be assumed to have zero false positives or zero performance impact.

Port capacity, packet rate, encapsulation and the receiving equipment limit delivery. Optional per-source UDP or TCP controls must be evaluated against shared NAT, VPNs and legitimate bursts. A source address can represent several users.

Upstream FlowSpec can reduce a verified attack pattern before a constrained link. Its scope, supported action, withdrawal condition and effect on legitimate traffic must be checked. A broad rule can interrupt a service even when the attack graph improves.

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.

Questions and answers