v6 cdn problems
jeroen at massar.ch
Sat Nov 8 23:10:20 UTC 2014
On 2014-11-08 23:55, Pete Carah wrote:
> Symptom with akamai is that it connects immediately then data transfer
> times out.
> With google, symptom involves both slow connection, and data transfer
> timing out.
See amongst others:
and already reported in various places, eg [email protected] etc.
Akamai is working on it as they have noted in various places already,
(thanks to Marty etc).
Google does not seem to be home. They used to have a handy
ipv6 at google.com address, but alas, that does not exist anymore.
And it does not look their own employees actually use IPv6 otherwise
they would have noticed it themselves, or like you know their monitoring
systems showing that lots of connections are hanging and never actually
> I don't know if chrome's happy eyeballs is working since if
> it was, and absent address caching, I shouldn't see the slow connection.
Chrome's Happy Eyeballs does not work when the TCP session has been
made. (At least that is what it looks like on OSX). Hence, when the
session gets stuck it is waiting for the TCP timeout to happen before it
retries. It then does seem to remember that that connections is broken.
> Is this a provisioning problem where v6 eyeballs are outstripping cdn
> provisioning (since win7 and 8 both default to v6)? Or is something
> else going on. Since this seems to affect more than one cdn, it seems odd.
Coincidence it seems.
> When I disable the HE tunnel, (and restart the browser - apparently
> happy-eyeballs caches), everything works just fine, so the problem does
> appear to relate to v6.
*TEMPORARY* null routing the relevant prefixes on your *CPE* resolves
the problems you are seeing as then your local router reports !N and
your browser falls back to IPv4, which then works again.
More information about the NANOG