Service provider story about tracking down TCP RSTs

Lee ler762 at gmail.com
Sat Sep 1 22:11:26 UTC 2018


On 9/1/18, William Herrin <bill at herrin.us> wrote:
> On Sat, Sep 1, 2018 at 4:00 PM, William Herrin <bill at herrin.us> wrote:
>> On Sat, Sep 1, 2018 at 2:51 PM,  <frnkblk at iname.com> wrote:
>>> pointing out that a
>>> single traceroute to a Fastly site was hitting two of their POPs (they
>>> use
>>> anycast) and because they don’t sync state between POPs the second POP
>>> would
>>> naturally issue a TCP RST (sidebar: fascinating blog article on Fastly’s
>>> infrastructure here:
>>> https://www.fastly.com/blog/building-and-scaling-fastly-network-part-2-balancing-requests).
>>
>> Better yet, do the job right and build an anycast TCP stack as
>> described here: https://bill.herrin.us/network/anycasttcp.html
>
> BTW, for anyone concerned about an explosion in state management
> overhead, the TL;DR version is: the anycast node which first accepts
> the TCP connection encodes its identity in the TCP sequence number
> where all the other nodes can statelessly find it in the subsequent
> packets. The exhaustive details for how that actually works are
> covered in the paper at the URL above, which you'll have to read
> despite its length if you want to understand.

An explosion in state management would be the least of my worries :)
I got as far as your Third hook: and thought of this
  https://www.jwz.org/doc/worse-is-better.html

I had it much easier with anycast in an enterprise setting.  With
anycast servers in data centers A & B, just make sure no site has an
equal cost path to A and B.  Any link/ router/ whatever failure & the
user can just re-try.

Lee



More information about the NANOG mailing list