Consider a puzzle that seems impossible: you type a single IP address, yet somehow your request arrives at a server just a few milliseconds away, not one on the opposite side of the planet. This is IP anycast at work—a routing technique where the same IP address exists simultaneously at dozens or hundreds of locations worldwide.

Unlike traditional unicast routing, where one address means one destination, anycast lets the network itself decide which server should answer your request. The Border Gateway Protocol (BGP), the internet's core routing system, naturally selects the "nearest" location based on network topology rather than geographic distance.

This technique underpins critical internet infrastructure: root DNS servers, content delivery networks, and DDoS mitigation services all depend on anycast to distribute load and minimize latency. Understanding how anycast actually works—from BGP announcements to catchment dynamics—reveals elegant engineering that keeps global services responsive and resilient.

When multiple locations announce the same IP prefix via BGP, routers across the internet must decide which announcement to prefer. BGP's decision process evaluates several attributes in sequence: local preference, AS path length, origin type, and multiple tie-breakers. For anycast, the AS path length typically dominates—requests flow toward whichever announcing location requires traversing the fewest autonomous systems.

This creates an elegant self-organizing system. When you announce 192.0.2.0/24 from data centers in Frankfurt, Singapore, and Chicago, each announcement propagates through the BGP mesh. Routers closer to Frankfurt learn a shorter path to that announcement than to Singapore's, so they route traffic accordingly. No central controller coordinates this; the distributed nature of BGP makes it happen automatically.

The "nearest" location in anycast terms means topologically nearest, not geographically nearest. A user in a city with direct peering to your Singapore data center might route there even if Chicago is physically closer. This network-centric definition of proximity often produces better latency than geographic routing would, since it reflects actual packet paths rather than map distances.

Operators tune this behavior through careful BGP configuration. By adjusting AS path prepending—artificially lengthening the AS path in certain announcements—you can steer traffic away from locations during maintenance or rebalance load across sites. More aggressive tools like BGP communities let upstream providers apply specific routing policies, giving operators granular control over how traffic distributes globally.

Takeaway

Anycast routing works because BGP's path selection algorithm naturally prefers shorter AS paths, causing traffic to flow toward the topologically nearest server without requiring any centralized coordination or geographic awareness.

Each anycast location attracts traffic from a specific region of the internet's topology—its catchment area. These catchments emerge from the cumulative routing decisions of thousands of networks, creating invisible boundaries that determine which users reach which servers. Unlike fixed geographic regions, catchments shift constantly as the internet's topology changes.

Measuring catchment stability requires distributed vantage points. Tools like RIPE Atlas probes or commercial monitoring services send queries to your anycast address from locations worldwide, recording which server responds. Over time, this reveals your catchment map and highlights instability—probes that flip between answering locations indicate catchment boundaries where small routing changes alter the outcome.

Outages create the most dramatic catchment shifts. When a site goes offline and withdraws its BGP announcement, traffic instantly redistributes to remaining locations. This failover happens at BGP convergence speed, typically seconds to minutes depending on network conditions. The redistribution isn't uniform; catchment boundaries shift as routers recalculate paths, potentially overloading nearby sites.

Capacity planning must account for these dynamics. If your Frankfurt site handles 40% of European traffic during normal operation, its neighbors must absorb that load during outages. This means sizing each location not just for its steady-state catchment but for failure scenarios where it inherits traffic from adjacent sites. Monitoring catchment ratios continuously helps detect routing anomalies before they cause performance problems.

Takeaway

Catchment areas are dynamic zones defined by network topology, not geography—always monitor them from distributed vantage points and provision capacity assuming each site must handle traffic from its neighbors during outages.

Anycast works beautifully for stateless protocols like DNS, where each query-response pair is independent. But long-lived connections face a fundamental problem: if routing changes mid-connection, subsequent packets might reach a different server than the one holding your session state. That server has no context for your connection and must reject the packets.

This happens more often than you might expect. BGP routing fluctuates continuously as links fail, traffic engineering policies change, and networks adjust their announcements. A TCP connection lasting several minutes has meaningful probability of experiencing a route change. For UDP-based protocols with application-layer sessions, the situation is similar—your packets suddenly arrive at a server that doesn't recognize you.

Several strategies address connection persistence. QUIC's connection ID mechanism allows connections to survive IP address changes, making it more anycast-friendly than TCP. Some CDNs use anycast only for initial connection establishment, then redirect to a unicast address for the session duration. Others accept occasional connection resets as an acceptable trade-off for anycast's benefits.

The decision framework depends on your traffic profile. DNS resolvers use pure anycast because queries complete in milliseconds—routing changes between queries don't matter. Video streaming services might use anycast for DNS and initial TLS handshakes but deliver content via unicast. Understanding your protocol's tolerance for mid-connection routing changes determines whether anycast, unicast, or a hybrid approach fits your architecture.

Takeaway

Reserve anycast for short-lived or stateless transactions; for long-lived connections, consider unicast fallback after initial contact or protocols like QUIC that maintain session identity independent of routing paths.

IP anycast transforms a single address into a globally distributed service by leveraging BGP's natural preference for shorter paths. The technique requires no special protocol support—it emerges from how internet routing already works, making it both elegant and robust.

Success with anycast demands understanding its operational realities: catchments shift, connections can break on route changes, and capacity planning must assume failure scenarios. These aren't flaws but characteristics that inform correct deployment choices.

For the right workloads—DNS, DDoS scrubbing, CDN edge selection—anycast delivers latency reduction and automatic failover that would be difficult to achieve otherwise. The key is matching the technique to protocols and architectures that embrace its distributed, stateless nature.