strange ping and traceroute results

[Michael Tewner]

Heh - You _learn_ that Anycast isn't good for TCP, but LinkedIn proved
differently. Their website uses TCP (obviously), works almost always, and
gracefully recovers when Anycast throws a curve.

There's a great interview on Packet Pushers with LinkedIn Global
Engineering:

Packet Pushers: Show 286: Busting Anycast TCP Myths
http://packetpushers.net/podcast/podcasts/show-286-busting-anycast-tcp-myths/

...and a blog post:
https://engineering.linkedin.com/network-performance/tcp-over-ip-anycast-pipe-dream-or-reality

-Mike Tewner



On Fri, Nov 25, 2016 at 12:14 AM, Amos Shapira <amos.shapira at gmail.com>
wrote:

> Anycast is not suitable for TCP.
> It IS fantastic for DNS (which uses UDP), which is the first thing a
> client does most of the time to find the server.
> Akamai control server groups by allocating per-customer per-object host
> names, then these can be resolved using their very highly customised DNS
> servers to the right server (also taking into account dynamic changes like
> server cluster load or failure).
> Since DNS uses UDP and the traffic consists on one packet in each
> direction, Anycast is ideal for that scenario.
> The actual content transfer (e.g. move streams, which is where I with
> Akamai for stan.com.au) doesn't use Anycast.
>
> On 24 November 2016 at 04:06, Shachar Shemesh <shachar at shemesh.biz> wrote:
>
>> On 22/11/16 02:19, Amos Shapira wrote:
>>
>> On 21 November 2016 at 18:20, Shachar Shemesh <shachar at shemesh.biz>
>> wrote:
>>
>>> The DNS resolving google.com guesses your gegraphical location, and
>>> gives you an answer that is nearest where you are. If you use another DNS
>>> to query the domain, you will get a different IP:
>>>
>>
>> It's not always a "guess your geographic location". The smarter ones use
>> Anycast to advertise the same IP address from multiple locations on the
>> Internet and let BGP do its magic to route your packets to the nearest
>> server, taking into account any congestion or other transient connection
>> speed changes. This is how Google's DNS 8.8.8.8 works, or Akamai's CDN. The
>> nice thing about it is that you get optimal response even at the host
>> resolution stage. The DNS server can then take its knowledge of the DNS
>> query source address into account when it decides which IP address to
>> resolve to.
>>
>> It's pretty neat, personally I find it a fascinating trick:
>> https://en.wikipedia.org/wiki/Anycast
>>
>> It is, quite fascinating. It is not, unfortunately, as useful as you make
>> it out to be. Neither Google nor Akamai use it for web traffic, for example.
>>
>> The reason is twofold. First, anycast is poorly equipted to handle TCP
>> connections. There is a (remote) possibility that the handler of your IP
>> would change mid-request, which would not play nice with your connection.
>>
>> The second, more pertinent, reason is that , at least for Akamai, they
>> would like to be able to control which server you reach when you make a
>> request. The would like to be able to re-route your in case something bad
>> happens to that server. DNS TTL can be set as low as 30 or 60 seconds. BGP
>> routes have much longer settle times.
>>
>> Shachar
>>
>
>
>
> --
> <http://au.linkedin.com/in/gliderflyer>
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20161125/36e14f15/attachment-0001.html>