Peering vs transit for DDoS protection: what changes during an attack?

Definition of the problem

The problem is that peering can attract traffic without the same service model as protected transit. A public peering session may bring excellent latency to a major eyeball network, but if a flood enters through that peering port and there is no mitigation path, the low-latency path becomes the failure path.

Transit, on the other hand, is not automatically clean. A commodity transit provider may deliver global reachability and full routes, but if it only offers basic blackhole and no usable filtering, the protected service still needs another layer. The question is not “peering or transit?” but “which path has capacity, filtering, support and a controlled handoff during attack?”

DDoS also interacts with routing policy. A more specific route, AS path change or community can move traffic away from peering and toward protected transit. But if that policy is improvised during an incident, it may create asymmetric routing, poor return paths or unexpected cost.

Why it matters

This matters because many networks try to optimize for normal traffic first: lower transit commit, more peering, cheaper inbound, shorter paths. That can be smart, but DDoS is abnormal traffic. It can appear on the cheapest path, the fastest path or the least prepared path.

For game servers, streaming, SaaS or hosting, a peering decision can become a support issue. Users may say “the server is down” while the real cause is that traffic from one region enters through a congested exchange. Without visibility per ingress, the operator may blame the wrong firewall, host or application.

Transit is also part of a commercial promise. A protected transit provider should be able to explain filtering, blackhole alternatives, FlowSpec options, capacity limits and clean traffic delivery. Peering partners often do not provide that level of customer-specific DDoS service.

Possible solutions

One solution is to keep peering for normal low-latency traffic but route attacked prefixes through protected transit. This keeps performance benefits while giving engineers a mitigation path.

Another is to use selective de-preference: during attack, communities or route policy make certain paths less attractive without withdrawing the service entirely. This requires testing and monitoring.

A third option is to keep public peering but ensure the edge facing the exchange has enough capacity and filtering. That may include ACLs, sampling, FlowSpec internally and clear escalation with the IXP or peer when abuse is visible.

Finally, some services should simply use protected transit as the primary inbound path. If availability under attack is more important than saving a few milliseconds or euros, the cleanest model is to design protection first and optimize peering later.

Choosing peering or transit when the attack path changes

Peeryx positions protected IP transit as the path that should remain understandable during an attack. Peering can still be useful, but the protected path must have a defined role: attract traffic, filter, and return clean traffic without making the client guess what happened.

The approach is to map ingress paths by prefix and service. Some traffic may be safe over peering. Some should enter through mitigation all the time. Some can switch only when thresholds are crossed. The key is to avoid accidental protection gaps where an attacked service enters through an unprotected peering port.

For networks using BGP, Peeryx can work with route policy, tunnels, cross-connects or customer BGP sessions so the client keeps enough control while benefiting from a mitigation layer built for DDoS conditions.

Concrete use case

A gaming provider peers at an exchange for low latency to a large ISP and buys transit from two upstreams. Normal traffic looks great. Then attackers target the game query port from the same ISP footprint. The traffic enters through peering because that path is preferred and saturates the exchange port.

The quick but bad reaction is to shut the peering session. That may restore stability but increase latency for every user on that ISP. A better design is to move only the attacked prefix or service through protected transit, apply targeted filtering and keep the rest of peering alive where it remains safe.

After the incident, the operator can compare latency, packet loss, ingress volume and false positives. That feedback determines whether the service should stay on protected transit, return to peering or use a hybrid policy.

Frequent mistakes

• Assuming peering is always better because it is shorter.
• Using public peering as an unprotected bypass around the Anti-DDoS path.
• Buying transit only on price without asking about DDoS controls.
• Changing AS path or more-specifics during an attack without a rollback plan.
• Ignoring inbound capacity on IXP ports.
• Not separating normal traffic engineering from attack traffic engineering.

FAQ