On this page
Key points
- Peering is selective reachabilityIt can reduce latency and cost for specific networks, but it is not global Internet coverage.
- Transit is operational coverageA transit provider gives broader reachability and often more DDoS-related controls.
- DDoS changes economicsCheap inbound traffic is not cheap if it saturates ports and bypasses mitigation.
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.
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.
- How BGP works: prefixes, AS paths, routing decisions and DDoS impact
Review prefixes, AS path and BGP decisions.
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
Is peering bad for DDoS protection?
No. Peering can be excellent, but it must not bypass the mitigation path for services that require protection.
Is transit always safer?
Not automatically. Protected transit with filtering and clean handoff is different from commodity transit with only blackhole support.
Can I combine peering and protected transit?
Yes. Many strong designs keep peering for normal traffic and use protected transit for attacked or critical prefixes.
Does peering reduce latency?
Often, but only for specific networks. If the peering path saturates during attack, the real user experience becomes worse than a slightly longer protected route.
