With anycast, it would be possible to have the same IP address at multiple locations in the world, without the need of a proxy or VPN that forwards the packets to its final destination.

If you would just use IP spoofing to change the source IP address to for example, normally you would not be able to just receive the response packets for this IP address, as the Border Gateway Protocol determines a different path back for the response packet that you normally won't be able to intercept.

What does anycast do so you can reliably receive IP packets meant for this particular IP address? Since the shortest paths BGP relies on can change, which mechanism ensures that when you send a request at location C that has IP address, you will receive the entire response back to location C and you won't receive a response with also a few packets delivered at location A that has IP address and another few packets delivered at location B that also has IP address

For DNS it might not matter, but Anycast is also used by CloudFlare for the content delivery network, which would be HTTP(S) over TCP and not just UDP Packets.

How about this scenario: Server A and B have the same IP address with anycast. Server B connects to an external server that is very close to server A and very far away from server B, since server A is closer, the response will be routed back to server A, isn't it possible to always route this type of requests back to server B, since server B initiated the connection to the external server?

  • Welcome to Information Security Q&A. I am no moderator but IMHO this is better suitable for Computer Networking. Anyway, I think you can tune BGP to reduce switching, and you can maybe cluster global vpn nodes to share the states. Not sure if that would be worth effort, maybe GSLB would do the trick. BGP might be switching but the ping for the user would not change much.
    – Aria
    Commented Aug 8, 2016 at 0:06
  • Please don't post the same question on multiple stack exchanges.
    – Teun Vink
    Commented Aug 8, 2016 at 5:19

1 Answer 1


It is counter intuitive, but various providers have talked about their experiences over the years and going back as far as 2 decades have shown Anycast to be at least as stable and often more stable even for TCP/HTTP traffic than Unicast.

Why is this-

To a first approximation the internet is divided among Tier x backbone connectivity providers, corporate endpoints, and ISPs serving last mile. These parties exchange traffic through either peering agreements or transit agreements. Peering agreements are least cost and make sense when there is a significant flow of traffic in both directions. Transit agreements are more expensive and exist where there is an imbalance of traffic flow.

Very significant care goes into the planning of points of presence for corporate endpoints from which Anycast announcements will be made, and therefore into the peering and transit agreements by which user traffic flowing out of ISPs will reach those endpoints in a least cost manner, where cost is measured both financially and topologically.

That is, these agreements are ideally structured such that there will be a preferred least cost global route for any individual customer to a specific POP, with fallback more expensive (in both topological and financial terms) global routes to other POPs.

So the magic isn't necessarily in Anycast and BGP but in these peering and transit agreements. These allow Anycast and BGP to optimize local path decisions to deliver global topological stability over the lifetimes of relevant TCP sessions (usually at most minutes).

There is some talk of major global players like Google who play in backbone, endpoint and ISP performing their own proprietary magic TCP state replication between POPs, but that's not the common case. The common case is that network architects deliberately construct agreements that optimize for global stability.

  • What would be your answer to the scenario mentioned at the end of the question?
    – Jomad
    Commented Aug 8, 2016 at 3:43
  • In practice, deployments don't use Anycast addresses as source addresses. The advertised Anycast addresses are themselves abstractions that can be bound to different individual hosts through a variety of means (though movement between hosts can cause TCP session breakage). Traffic initiated from hosts that may be serving as Anycast recipients will often be NATed and will egress with a fixed non-Anycast public IP. Commented Aug 8, 2016 at 4:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .