What Is Anycast? How CDNs Route Traffic in 2026

In March 2026, a major European streaming platform traced a 340 ms TTFB spike across Southeast Asia to a single misconfigured BGP community string. The fix took eleven minutes. The revenue impact, based on their own telemetry, exceeded €90,000. The routing method that both caused and resolved the incident was anycast. If you operate anything at the edge, understanding what is anycast at the BGP level — not the glossary level — is table stakes. This article gives you the mechanics, the failure modes that matter in production, a decision framework for anycast vs. unicast routing, and the tuning levers that separate a working deployment from a performant one.

What Is Anycast in Networking?

Anycast is a network addressing and routing methodology where an identical IP prefix is originated from multiple autonomous systems or multiple locations within the same AS. When a client sends a packet to that address, the internet's BGP routing fabric forwards it to the topologically closest origin — not necessarily the geographically closest one. The distinction matters enormously.

In a unicast model, one IP resolves to one host. In an anycast network, one IP resolves to many hosts, and BGP's best-path selection algorithm — factoring AS-path length, local preference, MED, IGP cost, and tie-breaking rules — determines where the packet lands. Every router along the path makes this decision independently, using its own RIB. That means two users in the same city, on different ISPs, can reach different anycast endpoints for the same destination address.

How Anycast Routing Works at the BGP Level

The mechanics are straightforward but the operational subtleties are not. Each edge site advertises the same /24 (or shorter) prefix via BGP to its upstream transit providers and peering partners. Routers across the internet propagate these announcements and select the best path per their local policy. Traffic converges on the "winning" announcement for each source network.

Path Selection Realities in 2026

As of Q1 2026, the global BGP table exceeds 1.05 million prefixes. Convergence after a withdrawal event typically takes 30–90 seconds for well-connected prefixes, though dampening and MRAI timers can stretch this. For anycast operators, this means failover is not instant — it is "fast enough" for most use cases, but not for stateful protocols mid-flow. More on that below.

What determines which site a user hits:

• AS-path length: Shorter paths win by default. A site with direct peering at an IXP will attract traffic from that exchange's members.
• Local preference: The user's ISP may prefer certain upstreams for cost or capacity reasons, overriding shorter AS-paths.
• Community-based traffic engineering: Anycast operators use BGP communities to selectively prepend, depref, or blackhole announcements at specific peers, sculpting catchment areas.
• Cold-potato routing: Many tier-1 networks hand off traffic as early as possible, which can send users to a site that is topologically close to the ingress router but far from the user.

The practical result: "nearest" in anycast routing is a BGP concept, not a geographic one. A CDN operating an anycast network must continuously measure real-user latency and adjust BGP announcements — prepending paths at sites that are attracting traffic they cannot serve well, and broadening announcements at underutilized sites.

Anycast vs. Unicast for Content Delivery

The anycast vs. unicast decision is not binary. Most production CDN architectures use both, layered together.

The hybrid approach most CDNs run in 2026: anycast for the initial DNS resolution and for short-lived HTTP transactions (static assets, API calls), with unicast fallback or EDNS Client Subnet steering for long-lived sessions like video streams and WebSocket connections. This avoids the TCP-reset problem that anycast introduces when BGP paths flap mid-connection.

How CDNs Use Anycast for Efficient Routing

Anycast CDN architectures solve three problems simultaneously. First, latency: by placing the same prefix at dozens or hundreds of locations and letting BGP select the shortest path, the median round-trip time drops. Measurements from public RIPE Atlas probes in Q1 2026 show that well-operated anycast CDNs achieve sub-20 ms median RTT to 80% of global eyeball networks. Second, availability: if a site goes down, its BGP session drops, the prefix is withdrawn, and traffic reconverges to surviving sites without any client-side intervention. Third, operational simplicity: a single IP in DNS records, TLS certificates, and application configs.

Anycast DNS is the most mature use case. All 13 root server letters use anycast, collectively operating over 1,700 instances as of early 2026. Public resolvers from Google and Cloudflare are anycast. But the same pattern now extends deep into CDN request routing: the edge address a browser connects to for HTTPS is increasingly an anycast address, with connection coalescing and QUIC connection migration helping mitigate the stateful-flow problem.

Production Failure Modes: What Breaks and Why

Most anycast explainers skip the failure scenarios. In production, these are the ones that generate pages:

1. BGP Flap-Induced TCP Resets

When a path change moves an active TCP flow from one anycast site to another, the receiving site has no state for that connection. It sends a RST. For short HTTP/1.1 transactions, this is rarely noticed. For long-lived HTTP/2 streams, gRPC, or WebSocket connections, it causes user-visible errors. Mitigation in 2026 centers on QUIC's connection ID-based routing and consistent-hashing load balancers at each site that can absorb intra-site path changes.

2. Catchment Drift

Peering changes, transit de-provisioning, or a new IXP interconnect can silently shift which users land at which site. If the newly attracted traffic exceeds the site's cache warmth or compute capacity, performance degrades without any alerting unless you are monitoring per-site catchment populations. Best practice: instrument per-site unique-ASN counts and alert on significant deviations from baseline.

3. Asymmetric Path Failures

Anycast governs the forward path. Return traffic follows the unicast source-address route, which may traverse entirely different networks. A congested return path can degrade throughput even when the forward path is clean. Operators who measure only inbound latency miss this entirely.

4. Prefix Hijack Amplification

Because anycast prefixes are globally announced from many origins, a BGP hijack of that prefix can be harder to detect — it looks like "just another legitimate announcement." RPKI ROV adoption, which crossed 55% of routed IPv4 space in 2026 measurements, is the primary defense.

Tuning an Anycast CDN: The Levers That Matter

If you run or evaluate an anycast CDN, these are the variables worth instrumenting:

• Per-site prepend depth: Prepending your AS 1–3 times at specific upstreams narrows a site's catchment when it is overloaded. This is the most common BGP traffic-engineering lever.
• Selective announcement scope: Announcing the prefix to IXP route servers but not to transit at a given site keeps catchment local to that exchange's membership.
• Healthcheck-driven withdrawal: Automating BGP session teardown when application-layer health checks fail. The gap between "BGP session is up" and "the service behind it is healthy" is where outages hide.
• ECMP-aware hashing: At sites with multiple uplinks, ensuring ECMP hashing is flow-consistent prevents packet reordering that kills TCP throughput.

For teams evaluating CDN providers in 2026, cost at scale is equally critical. BlazingCDN runs an anycast network engineered for high-throughput delivery — media, software distribution, SaaS assets — with volume-based pricing that scales from $4/TB at 25 TB/month down to $2/TB at the 2 PB tier. That pricing, combined with 100% uptime SLAs and the ability to absorb demand spikes without renegotiation, puts it in the same reliability class as Amazon CloudFront at a fraction of the cost. Sony is among its enterprise clients.

FAQ

What is the difference between anycast and multicast?

Anycast delivers a packet to one of many destinations sharing an address — the topologically nearest one. Multicast delivers a packet to all members of a group simultaneously. They solve fundamentally different problems: anycast is for request routing; multicast is for one-to-many distribution like IPTV.

Does anycast work with TCP, or only UDP?

Anycast works with both. UDP-based anycast (DNS, NTP) is simpler because each query is independent. TCP-based anycast is common in CDNs but requires careful engineering to handle flow disruption during BGP path changes. QUIC's connection-ID mechanism, increasingly adopted in 2026, mitigates this for HTTP/3.

How does anycast reduce latency compared to DNS-based load balancing?

DNS-based load balancing steers at resolution time and is bound by TTL caching. Anycast steers at the network layer continuously — every packet is routed by BGP's current best path. This means anycast reacts to path changes in seconds to minutes, while DNS changes propagate over minutes to hours depending on TTL.

Can anycast cause problems during BGP route leaks?

Yes. A route leak can attract traffic intended for one anycast site to an unrelated network, causing a localized outage. RPKI with ROV validation, which now covers over 55% of routed IPv4 space as of 2026, is the primary mitigation. Operators should sign their prefixes and monitor ROA validity.

How many anycast sites does a CDN need to be effective?

There is no universal number. What matters is peering density in your users' networks, not raw site count. A CDN with 40 sites at major IXPs and direct peering with top eyeball ASNs will outperform one with 200 sites behind a single transit provider. Measure real-user RTT, not marketing numbers.

What to Measure This Week

Pick one of these and run it against your current CDN configuration before your next architecture review. Query your anycast-addressed edge from RIPE Atlas probes in your top five user markets and record the site each probe reaches — compare that to the site you expect. If more than 15% of probes land at the wrong site, your catchment model is stale and you are leaving latency on the table. Then pull your per-site TTFB percentiles from real-user monitoring and overlay them against the catchment map. The gap between where traffic goes and where it should go is the single highest-leverage optimization most teams have never measured.