Multi-upstream DDoS protection: why one transit provider is rarely enough

Definition of the problem

The common mistake is to treat a second transit provider as an Anti-DDoS product. It is not. A second upstream can protect against a provider outage, improve reachability and offer more capacity, but a large DDoS can still saturate both links if routing attracts traffic in the wrong places.

During an attack, the Internet does not automatically balance traffic in a fair or useful way. Some eyeball networks may prefer one upstream, others may prefer another, and a more-specific announcement can override a carefully planned aggregate. If policies are unclear, engineers end up changing routes during the incident without knowing the side effects.

Multi-upstream also increases complexity: prefix limits, route filters, RPKI validation, AS-SETs, communities, FlowSpec capability, blackhole support and NOC escalation paths may differ by provider. The design must account for these differences instead of assuming all transit is equivalent.

Why it matters

For a hosting provider or service provider, upstream diversity is a business continuity topic. One carrier outage should not disconnect customers. One congested path should not make a country unreachable. One DDoS pattern should not force the whole network into a blackhole when another upstream or mitigation path could still carry clean traffic.

It is equally important for negotiation and scaling. If every protected prefix depends on one contract, one port and one support team, growth becomes fragile. Multiple upstreams allow staged capacity increases, traffic engineering and stronger bargaining power, but only if the network has a clear operating model.

The DDoS angle is subtle: redundancy is useful only when combined with filtering and visibility. Otherwise, the network may pay for more capacity while still failing at the first saturation point. The question is not “how many upstreams do we have?” but “what happens to this prefix, through which provider, when this type of attack appears?”

Possible solutions

The first model is active/backup. One upstream carries normal traffic and the second is kept for failover. It is simple to understand but can be inefficient if the backup is untested or under-sized.

The second model is active/active multi-homing. Traffic enters through several providers at the same time. This can improve latency and capacity, but it requires careful local preference, communities, route maps and monitoring to avoid unexpected asymmetry.

The third model is protected transit plus commodity transit. The protected path attracts attacked prefixes, while other upstreams keep normal outbound or non-critical traffic. This can be cost-effective, but it must be documented precisely so incidents do not trigger chaotic route changes.

The fourth model is multi-site or anycast delivery. Several PoPs announce the same service and absorb traffic closer to users. It can help, but anycast does not replace filtering: it distributes load; it does not automatically distinguish legitimate traffic from a flood.

• Anycast DDoS protection: when it helps, when it does not ↗

  Understand when anycast helps and when it is not enough.

Two 100 Gbit/s ports: check each ingress

Two 100 Gbit/s ports provide 200 Gbit/s of nominal aggregate ingress, not a guaranteed equal split. A 120 Gbit/s attack alone cannot fill both ports to 100 Gbit/s at once. It can still overload one port if, for example, 110 Gbit/s follows one path and 10 Gbit/s the other.

Normal traffic, packet-processing limits and shared infrastructure can create additional constraints. Measure each port and its packet rate; a spare 90 Gbit/s on the second port does not automatically relieve the first. BGP chooses routes according to policy, not instantaneous load.

Local preference primarily selects your outbound path. Inbound steering depends on what remote networks accept and prefer, including your announcements and supported provider communities. Validate prefix authorization, route propagation and clean delivery before relying on a protected backup path.

Frequent mistakes

• Buying multiple upstreams but using identical policies everywhere.
• Assuming BGP automatically balances attack traffic intelligently.
• Not testing backup capacity before a real incident.
• Ignoring RPKI, IRR and prefix-filter requirements for new upstreams.
• Mixing protected and unprotected paths without documenting which prefix uses which model.
• Letting providers apply different blackhole or FlowSpec behavior without a runbook.

FAQ