> > But, the reality is that it is impossible to correctly > recognize server is unavailable or to correctly withdraw > routes only when server is unavailable. >
Not true at all. On Thu, Oct 7, 2021 at 9:50 AM Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > William Herrin wrote: > > >>> This is quite common to tie an underlying service announcement to BGP > >>> announcements in an Anycast or similar environment. > >> > >> Yes, that is a commonly seen mistake with anycast. > > > > You don't know what you're talking about. > > I do but you don't. > > > If your anycast node stops > > receiving updated data and you can't reach any of the other nodes to > > check whether they're online, 99 times out of 100 this means a local > > failure of some sort. > > Yes. In case of DNS, if expiration period of a zone is passed > without successful check of the current most zone version, > unicast or anycast name servers stop responding requests for > the zone. > > But, it has nothing specifically to do with anycast. As there > are other name servers with different IP addresses, there is > no reason to withdraw routes. So? > > > You withdraw the node's announcement so that you > > don't serve bad data to the end user. > > That will only introduce new failure modes of mismatches between > server availability and server reachability and is a bad idea. > > > That's what happened here - > > Yes, facebook did wrong thing to actively withdraw routes. > > > Simply > > turning themselves off, instead of withdrawing the routes, would > > result in suboptimal performance. > > This time, facebook is saying that they could not reach their > name servers even though the servers were perfectly working. > > How much performance, do you think, facebook enjoyed? A lot > less than "suboptimal", I'm afraid. > > > And 99 times out of 100, not doing > > one or the other would cause rather than prevent an outage. > > That is a commonly seen misconception wrongly assuming that > server routes were withdrawn if and only if the server is > unavailable. > > But, the reality is that it is impossible to correctly > recognize server is unavailable or to correctly withdraw > routes only when server is unavailable. > > Masataka Ohta >
