Skip to content

SYSTEM Cited by 1 source

Magic Transit

Magic Transit is Cloudflare's IP-network- level DDoS-protection product: a customer advertises one or more IP prefixes via global anycast from Cloudflare's edge fleet, and all traffic to those prefixes is L3-routed to Cloudflare, scrubbed, and forwarded to the customer origin over tunnels. It is the layer that sits in front of a customer's IP network — intended for hosting providers, cloud providers, ISPs, game servers, and any workload where TCP/UDP visibility (not just HTTP) is required.

Role in the wiki

Magic Transit is the customer product in the canonical wiki instance of anycast as a volumetric-DDoS defence primitive and patterns/autonomous-distributed-mitigation. The 2025-05 7.3 Tbps / 4.8 Bpps / 37.4 TB in 45 seconds attack that Cloudflare disclosed on 2025-06-20 targeted a hosting-provider Magic Transit customer — the largest DDoS attack ever reported at the time — and was mitigated fully autonomously across 477 data centers / 293 locations.

Shape

  • Customer side: Cloudflare advertises the customer's IP prefixes via BGP from every POP; traffic to those prefixes lands at the nearest POP regardless of source.
  • Scrubbing side: DDoS detection and mitigation run on every server in every POP (see systems/dosd) using XDP/eBPF (systems/ebpf) as the kernel-side data plane; fingerprinted attack traffic is dropped at the XDP hook before reaching user space.
  • Origin side: surviving traffic is tunneled to the customer's origin network over GRE or Anycast GRE.
  • Control plane: fingerprints are compiled into eBPF programs per-server and gossiped within and across data centres.

Why the defence works

  • concepts/anycast inverts attacker distribution: the more geographically spread the botnet, the more Cloudflare POPs share the per-source load. The 7.3 Tbps attack's 122,145 source IPs across 161 countries landed close to their geographic peers at the nearest POP rather than converging on one scrubbing centre.
  • No central scrubbing tier = no central bottleneck, no single alert surface, and no co-location cost of shipping flood traffic to a dedicated facility. Every POP is a scrubbing facility.
  • In-XDP drops (concepts/in-kernel-filtering) keep the mitigation cost near zero per packet, so the CPU penalty of running mitigation on every server on every packet is tolerable even under 4.8 Bpps flood conditions.

Caveats

  • The 2025-06-20 post does not publish per-POP traffic share, dosd sample rate, fingerprint-compile latency, or gossip convergence time. "No incidents caused" is the only customer-impact claim.
  • "Hosting providers and critical Internet infrastructure have increasingly become targets" — Cloudflare's Q1 2025 DDoS threat report notes 13.5 M attacks against Cloudflare infrastructure + Magic-Transit-protected hosting providers in Jan-Feb 2025 alone.
  • This stub captures Magic Transit in its DDoS-defence role only. Magic Transit's packet-routing / BGP-policy / Magic Firewall / Argo-for-Packets (smart-routing) features are orthogonal and not covered by the ingested source.

Seen in

Last updated · 200 distilled / 1,178 read