The two dominant paradigms for volumetric DDoS mitigation — Anycast-based scrubbing and on-demand traffic diversion to dedicated scrubbing centers — represent fundamentally different trade-offs between baseline latency, mitigation capacity, detection lag, and operational complexity. Understanding which trade-offs your infrastructure can absorb is the single most important question a network architect should answer before signing a mitigation contract.
This piece dissects both architectures at the routing and signalling layer, presents simulated BGP re-routing latency data across realistic attack scenarios, and provides a decision matrix for selecting or combining approaches based on workload profile.
The Two Architectures — What They Actually Do
The two dominant paradigms for volumetric DDoS mitigation — Anycast-based scrubbing and on-demand traffic diversion to dedicated scrubbing centers — represent fundamentally different trade-offs between baseline latency, mitigation capacity, detection lag, and operational complexity. Understanding which trade-offs your infrastructure can absorb is the single most important question a network architect should answer before signing a mitigation contract.
This piece dissects both architectures at the routing and signalling layer, presents simulated BGP re-routing latency data across realistic attack scenarios, and provides a decision matrix for selecting or combining approaches based on workload profile.
Anycast Diffusion
In an Anycast topology, the same IP prefix is announced from multiple Points of Presence (PoPs) simultaneously across the global routing table. Inbound attack traffic is drawn to the nearest PoP by BGP shortest-path selection. Each PoP performs inline scrubbing — volumetric packets are dropped at ingress before clean traffic transits to the origin.
The fundamental advantage is geometric: attack volume is distributed across N PoPs, so the effective saturation threshold per PoP equals Total Attack Volume ÷ N. A 2 Tbps carpet-bomb attack hitting a 30-PoP network lands as approximately 67 Gbps per PoP — within scrubbing capacity at each site.
The latency equation is also geometrically favourable. Clean traffic exits the nearest PoP to the legitimate user, so the incremental latency above baseline is the intra-PoP scrubbing pipeline — typically 1–4 ms for hardware-accelerated ASIC-based inspection.
On-Demand Scrubbing Center (Traffic Diversion)
In an on-demand scrubbing model, traffic follows its normal routing path during clean periods. When an attack is detected — either by the customer’s edge telemetry or by the provider’s monitoring — BGP route advertisements are modified to divert all inbound traffic to a centralized scrubbing facility. Clean traffic is then tunnelled back (GRE or MPLS) to the customer’s origin.
The Tbps capacity advantage is real: a single scrubbing center running purpose-built traffic-processing clusters can achieve 10–20 Tbps of clean pipe throughput, exceeding what most distributed Anycast networks aggregate globally. For sustained, hyper-volumetric attacks targeting a single prefix, this matters.
But the latency penalty is where datasheets go silent. The BGP diversion process — propagation of new route announcements, convergence across the global routing table, GRE tunnel establishment, and route stabilization — introduces a latency spike at the worst possible moment: the peak of an active attack.
Simulated BGP Re-Routing Latency Data
The following dataset is simulated from a realistic enterprise scenario: a 10 Gbps DDoS attack targeting a /24 prefix, customer origin in Mumbai, scrubbing center in Singapore, using a tier-2 BGP transit provider without pre-configured scrubbing peering.
Phase | Duration | RTT Impact | Packet Loss | Notes |
Baseline (pre-attack) | — | 8 ms | 0% | Normal BGP path, Mumbai-origin served direct |
Attack onset (volumetric) | 0–30s | 8–210 ms | 12–34% | Congestion at uplink before detection |
Detection lag (flow telemetry) | 30–90s | 210 ms sustained | 28% | NetFlow/sFlow sampling delay at 1:1000 |
BGP route withdrawal propagation | 90–180s | 180–240 ms | 18% | Re-routing in progress, partial convergence |
GRE tunnel establishment | 3–4 min | 55–80 ms | 2% | Tunnel up, scrubbing active but not fully tuned |
Scrubbing center stable state | 4 min+ | +22 ms above baseline | < 0.1% | Clean pipe stable; GRE overhead + distance penalty |
Attack cessation + re-route back | T+recovery | +8 ms baseline restored | 0% | BGP reconvergence to direct path: ~4 min |
Why This Matters for SLA Arithmetic If your application SLA specifies 99.95% monthly uptime (≈22 min downtime budget), a single 10-minute sustained attack event — spanning detection, diversion, and tunnel stabilization — consumes 45% of that monthly budget in one incident. Real-time applications (VoIP, trading platforms, gaming backends) with sub-20 ms RTT requirements will breach latency SLAs during the stabilization window even after the attack is mitigated.
Why Anycast Doesn't Have This Problem
In an Anycast architecture, there is no diversion event. Traffic is always flowing through the nearest PoP. When a volumetric attack begins, the PoP’s inline scrubbing pipeline activates — no BGP changes, no tunnel establishment, no convergence wait. The latency jump is bounded by the ASIC scrubbing pipeline overhead (1–4 ms) and any legitimate congestion at the PoP ingress interface, which is proportional to the fraction of the attack that lands at that PoP.
The caveat: Anycast latency optimality depends on PoP density and geographic distribution. A 5-PoP Anycast network has far worse attack distribution geometry than a 30-PoP network. Vendors selling ‘Anycast DDoS mitigation’ with fewer than 15 PoPs are selling a capacity argument, not a latency argument
The Detection Lag Problem — Where Both Architectures Fail
The scrubbing center model’s detection lag is well-documented. Less discussed is that Anycast networks suffer their own variant of this problem at the flow-classification layer.
Anycast PoPs using sampled NetFlow (1:1000 or 1:2000 sampling rates) at 10 Gbps+ interfaces have a statistical detection floor. Low-bandwidth application-layer attacks — HTTP floods, DNS amplification at sub-Gbps rates — can persist for 60–120 seconds before the sampling density produces enough flow records to trigger mitigation. During this window, the attack is hitting origin directly (for scrubbing models) or passing through the PoP uninspected (for Anycast models without L7 inspection).
Attack Type | Volume | Anycast Detection Time | Scrubbing Detect Time | SLA Risk |
UDP flood (volumetric) | > 100 Gbps | < 5 sec (threshold breach) | 30–90 sec (flow telemetry) | High for scrubbing |
DNS amplification | 10–50 Gbps | 5–15 sec | 45–120 sec | Moderate |
TCP SYN flood | 5–20 Gbps | 8–20 sec | 30–60 sec | Moderate |
HTTP GET flood (L7) | < 1 Gbps | 60–120 sec (sampling floor) | 60–180 sec | High for both |
Slowloris / slow-read | < 100 Mbps | Not detectable by volume | Not detectable by volume | Requires WAF layer |
The last two rows define the architectural boundary of both approaches. Application-layer attacks below the volumetric detection threshold require L7 inspection — which means WAF integration. Neither a scrubbing center nor an Anycast PoP doing L3/L4 filtering can reliably detect HTTP-layer abuse without deep packet inspection. This is the direct integration point between Anti-DDoS infrastructure and WAF deployment.
The Hybrid Architecture — What Mature Deployments Actually Run
Production deployments at enterprises with serious SLA requirements don’t choose between Anycast and scrubbing centers — they stack them. The architecture assigns responsibilities by attack class:
- Anycast PoPs handle volumetric L3/L4 attacks with inline ASIC-based filtering. No BGP changes, no latency spike, no detection lag beyond threshold breach.
- Scrubbing centers sit in reserve for hyper-volumetric events exceeding per-PoP scrubbing capacity. Activation is pre-configured via BGP communities, not reactive flow-triggered diversion, reducing convergence time to under 60 seconds.
- WAF layer handles L7 attacks below volumetric detection thresholds — HTTP floods, API abuse, slowloris — at the application inspection layer.
- Global Load Balancers (GSLB) provide the health-check and traffic-steering layer that redirects clean traffic away from PoPs or origin regions experiencing residual congestion post-attack.
Decision Matrix — Which Architecture for Which Workload
Workload Profile | Primary Risk | Recommended Mitigation | Latency Sensitivity |
E-commerce / web (L7 dominant) | HTTP floods, API abuse | Anycast PoP + WAF inline | Medium — tolerates +5 ms |
Financial trading / HFT | UDP floods targeting market data feeds | Anycast (< 15 PoPs = reject vendor) | Extreme — SLA < 5 ms RTT |
DNS infrastructure | DNS amplification, NXD floods | Anycast (BGP announced from resolver PoPs) | High — resolution latency SLA |
Gaming backend (UDP/WebSocket) | UDP carpet-bomb + L7 WS abuse | Anycast + WAF L7 inspection | High — sub-50 ms required |
SaaS / multi-tenant API platform | Volumetric + L7 mixed | Anycast + scrubbing standby + WAF | Medium |
Streaming / CDN origin | Volumetric surge + hot-object abuse | CDN edge absorption + Anti-DDoS hybrid | Low — buffered delivery |
Government / critical infra | State-actor sustained volumetric | Scrubbing center primary + Anycast overflow | Variable |
Vendor Evaluation Checklist — What to Ask Before Signing
Standard DDoS mitigation RFPs request peak Tbps capacity, PoP count, and uptime SLA. The following questions extract the data that actually predicts performance under attack:
- What is the BGP convergence time for on-demand scrubbing activation from your nearest PoP to my region — not globally averaged?
- What is the GRE tunnel RTT overhead from scrubbing center back to my origin, measured during active scrubbing (not idle)?
- What sampling rate does your detection engine use at 10 Gbps+ interfaces — and what is the minimum attack bandwidth detectable within 30 seconds?
- How many of your Anycast PoPs have ASIC-based inline scrubbing vs. software-based filtering? What is the throughput ceiling per PoP?
- How is the BGP community pre-configuration handled for scrubbing center standby mode — and what is the activation latency with that config in place?
- Does your WAF integrate inline at the PoP, or does L7 inspection require a separate diversion path?
- What happens to legitimate traffic during BGP reconvergence back to direct path after attack cessation?
India/South Asia Infrastructure Context
Deployments in India face additional routing geometry constraints. BGP path selection from Indian ISPs (BSNL, Airtel, Jio) to scrubbing centers in Singapore or Hong Kong traverses an average of 3–4 AS hops, with convergence times averaging 4–6 minutes for non-peered prefix changes — above the global average of 3–4 minutes. This compounds the scrubbing center detection-to-clean-pipe latency significantly.
Anycast PoPs physically located in Mumbai, Chennai, or Delhi/NCR reduce this penalty by anchoring BGP path selection to domestic announcements. Vendors without India-resident PoPs are routing Indian attack traffic internationally before scrubbing — a meaningful latency penalty that appears in no datasheet.
CERT-In’s 6-hour breach reporting mandate (Directions under Section 70B, April 2022) has an indirect implication: a DDoS event that causes service disruption exceeding 30 minutes — within the detection + diversion + stabilization window of a poorly configured scrubbing center setup — may trigger reporting obligations if the service handles personal data or critical infrastructure. Infrastructure architects should model this exposure into their mitigation architecture selection, not just their incident response playbooks.
The Tbps number on a vendor datasheet describes maximum theoretical capacity at a scrubbing facility under controlled conditions. It does not describe the RTT your application’s users experience during the 4-minute window between attack onset and clean-pipe stabilization. It does not describe the packet loss your real-time protocol stack absorbs during BGP reconvergence. It does not describe what happens to your SLA arithmetic during that window.
Anycast-based mitigation eliminates the diversion latency problem by design — but only if the PoP network is dense enough to distribute attack volume below per-PoP saturation thresholds. Scrubbing center models provide superior hyper-volumetric capacity — but require pre-configured BGP community activation and GRE tunnel pre-provisioning to compress the detection-to-clean-pipe window to under 60 seconds.
The production-grade answer is a layered stack: Anycast inline at the edge, scrubbing standby for overflow, WAF for L7, and GSLB for health-aware traffic steering. Any single-vendor pitch that collapses this into one product category deserves the vendor evaluation checklist in Section 6 — applied line by line.
