In message <a3e266a0-2e94-4623-9300-2e15fe574...@delong.com>, Owen DeLong writes: > > > On Sep 24, 2016, at 8:47 AM, John Levine <jo...@iecc.com> wrote: > > > >>> Well...by anycast, I meant BGP anycast, spreading the "target" > >>> geographically to a dozen or more well connected/peered origins. At > that > >>> point, your ~600G DDoS might only be around > >> > >> anycast and tcp? the heck you say! :) > > > > People who've tried it say it works fine. Routes don't flap that often. > > Itâs not just about route flap. > > Imagine the following. For any two any cast points A,B, one can draw a > simple Venn diagram of two circles with equal radii overlapping to form > an OGIVE. > > Consider that everyone in the nonintersecting portion of circle A will > reach server A without issue. > Likewise, everyone in the nonintersecting portion of circle B will reach > server B without issue. > However, for some subset of those within the OGIVE, itâs entirely likely > that they will, instead, be broken by ECMP to both A and B. > > Hereâs where it gets tricky⦠> > The people running A and B are unlikely to ever know because of the > layers between the end user trapped in the OGIVE and the people running A > and B. Most likely, the end users will suffer in silence or go to another > website for their needs. If this is a small enough fraction of users, > then it wonât be statistically noticeable drop in overall traffic and A,B > may never know. For those few end-users that may actually attempt to > resolve the issue in some meaningful way, most likely they will call > their ISP rather than the administrators of A,B and if their ISP does > anything, rather than bug A,B, they will most likely simple make routing > more deterministic for this site for this end-user. > > This is the nature of any cast and how any cast problems with TCP get > solved (or donât in most cases). > > Itâs safe to ignore the silent minority that cannot really tell what is > happening in most cases, but that doesnât mean it âworksâ for any > standard I would consider valid. > > Owen
Which is why sane operators carefully choose where they deploy ECMP or include hashes of the source and destination addresses into the distribution of traffic over otherwise equal paths. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
