One IP Address Can Exist in Three Places at Once

Why Anycast is not a feature, but a property of the internet.

At the end of the last article, we left the internet at an interesting point. We had seen that the internet consists of thousands of independent networks. That each of these networks makes its own routing decisions. And that the Border Gateway Protocol does not try to find the fastest path, but a reachable one. That is exactly where a new question begins. If the internet knows neither applications nor data centers, how can the same application still reach users in Hamburg, Frankfurt, or Munich almost always through the nearest point of presence? Many people assume GeoDNS at this point. Others think of load balancers. Still others imagine a central database that decides which data center should be used based on the user's location. None of these assumptions describes Anycast.

Let us first look at what the browser actually knows. Once DNS has done its job, the client has exactly one piece of information. A single IP address.

https://api.example.de

        │

        ▼

203.0.113.42

The browser knows nothing more. No region. No point of presence. No cloud. No information about where this address is actually operated. For the browser, there is only a connection.

Most people automatically associate an IP address with a server. At first, that seems logical. After all, we connect to an address and receive a response. Historically, this model was even largely correct. One server. One address. One application. Today, however, that picture is becoming less and less accurate. A public IP address no longer necessarily describes a single machine. It often describes an entire network. And that is where Anycast begins.

Imagine that the same platform operates points of presence in Hamburg, Frankfurt, and Alsbach. Each of these locations announces the same prefix.

             203.0.113.0/24

                  │

      announced simultaneously

     +----------+----------+----------+
     |          |          |          |
     v          v          v

 Hamburg    Frankfurt   Alsbach

At first, this situation may seem contradictory. How can the same address exist in multiple places at the same time? The answer is simple: because the internet never learned that it was only allowed to exist in one place. From BGP's point of view, these are simply multiple reachable paths to the same prefix. Nothing more. Nothing less.

Something remarkable happens here. The browser does not decide which point of presence is used. DNS does not decide either. The application itself has no knowledge of it. The decision is made entirely within routing. Each Autonomous System considers the different reachable paths and chooses the preferred one according to its routing policies. For a user in northern Germany, that may be Hamburg. For a user in the Rhine-Main region, Frankfurt. For another user, Alsbach. They all use the same URL. They all receive the same IP address. And yet they reach different locations. Not because of an application. But because of the architecture of the internet itself.

Perhaps this is the biggest misconception around Anycast. Anycast is often described as if it were a feature. Almost as if there were some service somewhere intelligently distributing users across different data centers. In reality, no such service exists. Anycast is not software. Not an appliance. Not a load balancer. And not a separate network protocol. It exists solely because multiple locations announce the same prefixes through the same Autonomous System. The rest is routing.

At this point, a small thought experiment is useful. Imagine Frankfurt disappears. Not slowly. Not in a planned way. But right now. The point of presence goes completely offline. Which address needs to be changed? None. Which DNS records need to be adjusted? None. Which application needs to know about it? None either. What actually disappears is only a route. Frankfurt no longer announces the prefix. Neighboring networks receive this information. They update their routing tables. New connections automatically reach the remaining locations.

             Before

          203.0.113.42

      +--------+--------+--------+
      |        |        |
      v        v        v

     HAM      FRA      ALS


             After

          203.0.113.42

      +--------+                 +--------+
      |        |                 |
      v        v                 v

     HAM                     ALS

       Frankfurt withdrawn

Perhaps this behavior explains why Anycast is often perceived as especially fault tolerant. Not because it prevents failures. But because failures often simply cause the internet to use another reachable path. The address remains identical. Ideally, the user notices nothing at all.

But that immediately raises a new question. How does a platform actually know whether a point of presence is still reachable? How does it know that a backend is still responding, but has already become far too slow? And how does it decide when traffic must be redirected? At exactly this point, routing alone is no longer enough. A second architectural layer begins. Health checks. Load balancing. Traffic steering. And the question of why modern high availability today has far more to do with network architecture than with simply adding more servers. That is what the next part of this series will be about.