Mailing List Archive: MTU Problem: Akamai,HE,GTT

MTU Problem: Akamai,HE,GTT

Sep 22, 2014, 2:16 AM

Post #1 of 3 (2289 views)

Hi,

for at least one weatheronline.co.uk seems to hang most of the time for
some of my users. The reason is javascript code unconditionally loaded
from connect.facebook.net.

connect.facebook.net is an alias for connect.facebook.net.edgekey.net.
connect.facebook.net.edgekey.net is an alias for e3821.dspe1.akamaiedge.net.
e3821.dspe1.akamaiedge.net has IPv6 address 2a02:26f0:6a:191::eed
e3821.dspe1.akamaiedge.net has IPv6 address 2a02:26f0:6a:18f::eed

The latter two networks (or at least one of them) seem to block
IPv6 packets of too large a size.

I get replies to ICMPv6 echo requests with PING6(1280=40+8+1232 bytes)
but not bigger; I suspect an icmpv6 black hole somwehere.

However, some others show the same problem.

Working (addresses shortened):

2001:638:a000:: (fully inside DFN), but also

2a00:19e0::
2001:608::
2001:200::

so I think it's not a problem with two DFN internal tunnels I'm aware of
(one inside Univ. of Bonn, one the UoB's next hop).

Not working:

2001:470:: (routed through he.net)
2001:1900:2254:: (routed through he.net/yahoo)
2a02:26f0:6a:: (routed through gtt.net)

I can workaround on my workgroup edge router, but I guess it would be
more helpful if the real problem would be fixed.

Regards,
Ignatios Souvatzis

Re: MTU Problem: Akamai,HE,GTT [ In reply to ]

erik at nygren

Sep 22, 2014, 7:06 AM

Post #2 of 3 (2242 views)

Permalink

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 noc@akamai.com).
>From here I'm able to ping it fine with large packets:

$ ping6 -s 1452 2a02:26f0:6a:18f::eed
PING 2a02:26f0:6a:18f::eed(2a02:26f0:6a:18f::eed) 1452 data bytes
1460 bytes from 2a02:26f0:6a:18f::eed: icmp_seq=1 ttl=52 time=105 ms
1460 bytes from 2a02:26f0:6a:18f::eed: icmp_seq=2 ttl=52 time=105 ms
1460 bytes from 2a02:26f0:6a:18f::eed: icmp_seq=3 ttl=52 time=106 ms
1460 bytes from 2a02:26f0:6a:18f::eed: icmp_seq=4 ttl=52 time=105 ms

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.

Erik

On Mon, Sep 22, 2014 at 5:16 AM, Ignatios Souvatzis <ignatios@cs.uni-bonn.de
> wrote:

> Hi,
>
> for at least one weatheronline.co.uk seems to hang most of the time for
> some of my users. The reason is javascript code unconditionally loaded
> from connect.facebook.net.
>
> connect.facebook.net is an alias for connect.facebook.net.edgekey.net.
> connect.facebook.net.edgekey.net is an alias for
> e3821.dspe1.akamaiedge.net.
> e3821.dspe1.akamaiedge.net has IPv6 address 2a02:26f0:6a:191::eed
> e3821.dspe1.akamaiedge.net has IPv6 address 2a02:26f0:6a:18f::eed
>
> The latter two networks (or at least one of them) seem to block
> IPv6 packets of too large a size.
>
> I get replies to ICMPv6 echo requests with PING6(1280=40+8+1232 bytes)
> but not bigger; I suspect an icmpv6 black hole somwehere.
>
> However, some others show the same problem.
>
> Working (addresses shortened):
>
> 2001:638:a000:: (fully inside DFN), but also
>
> 2a00:19e0::
> 2001:608::
> 2001:200::
>
> so I think it's not a problem with two DFN internal tunnels I'm aware of
> (one inside Univ. of Bonn, one the UoB's next hop).
>
> Not working:
>
> 2001:470:: (routed through he.net)
> 2001:1900:2254:: (routed through he.net/yahoo)
> 2a02:26f0:6a:: (routed through gtt.net)
>
> I can workaround on my workgroup edge router, but I guess it would be
> more helpful if the real problem would be fixed.
>
> Regards,
> Ignatios Souvatzis
>

Re: MTU Problem: Akamai,HE,GTT [ In reply to ]

nick at foobar

Sep 22, 2014, 7:16 AM

Post #3 of 3 (2248 views)

Permalink

On 22/09/2014 15:06, Erik Nygren wrote:
> 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 noc@akamai.com
> <mailto:noc@akamai.com>). From here I'm able to ping it fine with large
> packets:

scamper is your friend here:

> cheesecake# scamper -I "trace -P udp -M 2a02:26f0:6a:18f::eed"
> traceroute from 2a03:8900:0:100::5 to 2a02:26f0:6a:18f::eed
> 1 2a03:8900:0:100::1 0.216 ms [mtu: 1500]
> 2 2a02:8900:0:200::209 0.216 ms [mtu: 1500]
> 3 2a01:258:8:3::1 0.634 ms [mtu: 1500]
> 4 2001:1900:5:2:2::2dd9 1.053 ms [mtu: 1500]
> 5 2001:1900:5:1::319 12.990 ms [mtu: 1500]
> 6 2001:1900:5:1::412 12.926 ms [mtu: 1500]
> 7 2001:1900:5:3::21e 11.290 ms [mtu: 1500]
> 8 2001:41a8:600::1e 26.975 ms [mtu: 1500]
> 9 2001:41a8:600:2::b6 27.529 ms [mtu: 1500]
> 10 *
> 11 2a02:26f0:6a::210:d9a3 25.227 ms [mtu: 1500]
> cheesecake#

This means no path mtu problems from as1197 to 2a02:26f0:6a:18f::eed.

Nick