<div dir="ltr"><div>Can you pass me along a traceroute6 to 2a02:26f0:6a:18f::eed and I'll pass it along to the Akamai NOCC? (Or you can email details to <a href="mailto:noc@akamai.com">noc@akamai.com</a>). From here I'm able to ping it fine with large packets:<br><br>$ ping6 -s 1452 2a02:26f0:6a:18f::eed<br>PING 2a02:26f0:6a:18f::eed(2a02:26f0:6a:18f::eed) 1452 data bytes<br>1460 bytes from 2a02:26f0:6a:18f::eed: icmp_seq=1 ttl=52 time=105 ms<br>1460 bytes from 2a02:26f0:6a:18f::eed: icmp_seq=2 ttl=52 time=105 ms<br>1460 bytes from 2a02:26f0:6a:18f::eed: icmp_seq=3 ttl=52 time=106 ms<br>1460 bytes from 2a02:26f0:6a:18f::eed: icmp_seq=4 ttl=52 time=105 ms<br><br>Are any of the others Akamai IPs that you're having problems with? While we have intentionally not lowered our initial MSS (we don't want a broken Internet where ICMPv6 PMTUD doesn't work), we very rarely hear of issues and almost all of them end up being last-mile misconfigurations near the end-user.<br><br></div> Erik<br><br>
</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 22, 2014 at 5:16 AM, Ignatios Souvatzis <span dir="ltr"><<a href="mailto:ignatios@cs.uni-bonn.de" target="_blank">ignatios@cs.uni-bonn.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
for at least one <a href="http://weatheronline.co.uk" target="_blank">weatheronline.co.uk</a> seems to hang most of the time for<br>
some of my users. The reason is javascript code unconditionally loaded<br>
from <a href="http://connect.facebook.net" target="_blank">connect.facebook.net</a>.<br>
<br>
<a href="http://connect.facebook.net" target="_blank">connect.facebook.net</a> is an alias for <a href="http://connect.facebook.net.edgekey.net" target="_blank">connect.facebook.net.edgekey.net</a>.<br>
<a href="http://connect.facebook.net.edgekey.net" target="_blank">connect.facebook.net.edgekey.net</a> is an alias for <a href="http://e3821.dspe1.akamaiedge.net" target="_blank">e3821.dspe1.akamaiedge.net</a>.<br>
<a href="http://e3821.dspe1.akamaiedge.net" target="_blank">e3821.dspe1.akamaiedge.net</a> has IPv6 address 2a02:26f0:6a:191::eed<br>
<a href="http://e3821.dspe1.akamaiedge.net" target="_blank">e3821.dspe1.akamaiedge.net</a> has IPv6 address 2a02:26f0:6a:18f::eed<br>
<br>
The latter two networks (or at least one of them) seem to block<br>
IPv6 packets of too large a size.<br>
<br>
I get replies to ICMPv6 echo requests with PING6(1280=40+8+1232 bytes)<br>
but not bigger; I suspect an icmpv6 black hole somwehere.<br>
<br>
However, some others show the same problem.<br>
<br>
Working (addresses shortened):<br>
<br>
2001:638:a000:: (fully inside DFN), but also<br>
<br>
2a00:19e0::<br>
2001:608::<br>
2001:200::<br>
<br>
so I think it's not a problem with two DFN internal tunnels I'm aware of<br>
(one inside Univ. of Bonn, one the UoB's next hop).<br>
<br>
Not working:<br>
<br>
2001:470:: (routed through <a href="http://he.net" target="_blank">he.net</a>)<br>
2001:1900:2254:: (routed through <a href="http://he.net/yahoo" target="_blank">he.net/yahoo</a>)<br>
2a02:26f0:6a:: (routed through <a href="http://gtt.net" target="_blank">gtt.net</a>)<br>
<br>
I can workaround on my workgroup edge router, but I guess it would be<br>
more helpful if the real problem would be fixed.<br>
<br>
Regards,<br>
Ignatios Souvatzis<br>
</blockquote></div><br></div>