1. 9
  1.  

  2. 3

    Given that routes can change at any time, I always assumed this approach would fail for connection-based protocols such as TCP. There’s a risk that different packets from a TCP session might show up at different servers with the same anycast address. I assumed you’d need to run some extra state management on each server to redirect packets to the server that received the SYN packet.

    However, both this article and another article I found on building an anycast network don’t mention this, so I wonder whether it matters in practice.

    1. 6

      I hadn’t thought of that (I helped review this blog post). It looks like that’s entirely possible but mostly a non-issue in practice because a BGP route doesn’t (or shouldn’t) be changing frequently.

      BGP will notice flapping, and it will penalize the flapping link, and the link will get dropped from routing updates. You would be hard-pressed to find what you fear in the real world. ISPs take stability very seriously, and they will block partnerships which display instability.

      source: https://networkengineering.stackexchange.com/a/33827

      If a BGP route does change and starts sending TCP packets mid-connection to a different server, the new server won’t have a record of that connection and will respond with a TCP reset packet I think, which would effectively terminate that connection.