When “Nearby” Isn’t Nearby: How Remote Peering Undermines Anycast

Many Internet services we rely on daily (from website loading and video streaming to DNS lookups and DDoS protection) depend on a networking technique called anycast.

Anycast works by advertising the same IP address from many locations around the world, allowing the Internet’s routing system to send each user to the “nearest” anycast site. In principle, this keeps latency low and performance high.

Internet Exchange Points (IXPs) also help keep latency low and performance high by providing a more affordable alternative to sending local Internet traffic abroad.

However, a growing interconnection practice called remote peering is undermining the benefits of both by routing users thousands of kilometers away from the nearest site.

Traditionally, networks connect to IXPs by physically collocating in the same data center. Remote peering changes that model by removing the need for physical presence. It allows networks to connect to an IXP from afar, often via third-party transport providers. This is cheaper and more flexible, but it masks physical distance with what appears to be a short, efficient connection.

Similarly, remote peering challenges the mental model we have for anycast: that it relies on the idea that routing paths roughly reflect geographic proximity. A route that appears “short” to Internet routers may cross continents before reaching an anycast site.

We, and our colleagues at the University of Twente, show in our recent CNSM’25 paper that most local links add only a few milliseconds of latency. But remote peering introduces a long tail of significantly higher delays.

In the most extreme cases (Figure 1, left), single traceroute hops add over 60 milliseconds of delay, an eternity for latency-sensitive services like DNS resolution.

Geographically, the story is similar. While many remote peering links connect relatively close locations, a non-trivial fraction spans hundreds or even thousands of kilometers (Figure 1, right). These long-distance links are exactly the ones that cause trouble for anycast.

Latency alone doesn’t tell the whole story. Figure 2 looks at how far traffic actually travels compared to how far it should travel.

Ideally, traffic follows something close to a straight line (green line) from the user to the service. In reality, we observe many cases, especially when remote peering is involved, where traffic travels two (orange line), four (red line), or even more times the direct distance. These are not rare measurement artifacts; they reflect real routing decisions made every day.

These detours affect:

• Users who experience slower page loads, lagging apps, and less reliable services.
• Operators who waste capacity and need to troubleshoot unpredictable performance —Remote peering is largely invisible. It is not clearly signaled in routing data, and its physical footprint is hidden behind resellers and shared infrastructure.
• Policymakers and regulators who come to understand the uncomfortable reality: critical Internet infrastructure depends on opaque interconnection arrangements (i.e., paths traversing multiple countries and continents) with real performance consequences. Furthermore, privacy concerns arise when such detours traverse or end up in non-compliant countries.

Our findings point to several practical steps:

• Network operators need tools to identify when remote peering affects routing.
• Routing policies should account for physical distance, not just path length.
• IXPs could standardize ways to signal remote connections.
• Anycast is not “set and forget”; it requires ongoing measurement.

Remote peering has quietly reshaped how networks interconnect. As anycast continues to underpin critical digital services, understanding and managing its side effects demands serious attention.

For readers interested in the full methodology and detailed results, we encourage you to explore our paper.

Remi Hendriks is a PhD student at the University of Twente. His work focuses on measuring and improving Internet resilience.

Contributors: Stefano Servillo, University of Rome; Savvas Kastanakis, University of Twente.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of the Internet Society.

Photo by Circe Denyer Via NeedPix