The joke is you have to use anycast if you want any redundancy in your network. If you advertise your address space on a single upstream you're praying that they never have any issues.
>BGP route flapping
So what? Your traffic will go over to one of the other locations you're advertising on, and you keep ticking along merrily, with some extra latency.
>single connection traffic being split between different servers
That shouldn't happen. Keep in mind traffic just gets driven to your router, from there you load balance as you see fit. Unless you mean split between different ingress points -- TCP will happily renegotiate with very little overhead, if you're getting more serious issues your application sucks and should should be more resilient to connection state changes (if this is causing you problems, you're probably also dropping users who switch mobile to wifi...). Not to mention that these kinds of path cost updates are pretty rare on the real internet, you're not going to see this more often than once a month maybe.
I think you are overestimating the resilience of TCP, yes it will probably eventually renegotiate, but you create a horrible user experience.
Have a read of some of the cloudflare engineering blogs, they give some sense of the technical challenges of deploying anycast.
I wouldnt recommend a company deploy connection based anycast services, unless they are prepared to spend a lot on the engineering challenges.
> Since packets will follow the shortest path, if a particular path is withdrawn then packets will find their way to the next shortest available route. For simple protocols like UDP that don't maintain state, Anycast is ideal and it has been used widely to load balance DNS for some time. At CloudFlare, we've done a significant amount of engineering to allow TCP to run across Anycast without flapping. This involves carefully adjusting routes in order to get optimal routing and also adjusting the way we handle protocol negotiation itself. While more complex to maintain than a Unicast network, the benefit is we can lose an entire data center and packets flow to the next closest facility without anyone noticing and hiccup.
> WARP was experiencing so many failures because devices were switching servers much more often than we expected. If you recall, our ECMP router configuration uses a combination of (Source IP, Source Port, Destination IP, Destination Port) to match a packet to a server. Destination IP doesn’t generally change, WARP clients are always connecting to the same Anycast addresses. Similarly, Destination Port doesn’t change, we always listen on the same port for WARP traffic. The other two values, Source IP and Source Port, were changing much more frequently than we had planned.
>BGP route flapping
So what? Your traffic will go over to one of the other locations you're advertising on, and you keep ticking along merrily, with some extra latency.
>single connection traffic being split between different servers
That shouldn't happen. Keep in mind traffic just gets driven to your router, from there you load balance as you see fit. Unless you mean split between different ingress points -- TCP will happily renegotiate with very little overhead, if you're getting more serious issues your application sucks and should should be more resilient to connection state changes (if this is causing you problems, you're probably also dropping users who switch mobile to wifi...). Not to mention that these kinds of path cost updates are pretty rare on the real internet, you're not going to see this more often than once a month maybe.