Peace, On Wed, Aug 4, 2021 at 7:52 PM Theodore Ts'o <tytso@xxxxxxx> wrote: > If you have an established TCP flow, and there is a DDOS which kills a > particular endpoint, replicating all TCP state across dozens of > location across the globe for hundreds of thousands of TCP connections > per second, such that an Anycast endpoint could be redirected from > say, Hong Kong to Singapore or Australia, is simply not practical. This is pretty specific use case, it's not expected to occur frequently. In this case, it has always been easier to reset the existing connections and establish new ones. This results in some negotiation overhead and some delays in transmission, but you must expect that once a part of your infrastructure suddenly died. Things like that should never happen under a DDoS attack, because you risk getting a chain reaction over your PoPs otherwise. > Most stateful transport protocols (e.g., TCP), without modification, > do not understand the properties of anycast; hence, they will fail > probabilistically, but possibly catastrophically, when using anycast > addresses in the presence of "normal" routing dynamics. Yep, and you need to account for that in your application architecture. This is what RFC 7094 is about. This is fine. This is not a death sentence to TCP over anycast. > The changes in Linux five years ago may have made certain broken > architecures more likely to fail. The reason why no some seems to > care is because those were broken designs in the first place, which > RFC-7094 warns against Surely there are several ways to read 7094! > and there are plenty companies of which are > actively solving the DDOS problem for thier customers --- with many of > these companies using modern Linux kernels and Anycast, without the > problems cited by the original poster in this thread. This experience might have something to do with the poor state of IPv6 adoption, though. -- Töma
