fragmentation Problem, MTU setting doesn't work

[basti79]

Hi,

i'm using an MTU of 1480 on my local tunnel interface, my internet connection has an MTU of full 1500. When i do a "ping6 -s 1460  2001:780:3:5::11f" the tcpdump looks like this:

20:18:52.460658 IP 178.27.217.52 > 216.66.80.30: IP6 2001:470:1f0a:1063::2 > 2001:780:3:5::11f: frag (0|1432) ICMP6, echo request, seq 1, length 1432
20:18:52.460672 IP 178.27.217.52 > 216.66.80.30: IP6 2001:470:1f0a:1063::2 > 2001:780:3:5::11f: frag (1432|36)
20:18:52.499018 IP 216.66.80.30 > 178.27.217.52: IP6 2001:780:3:5::11f > 2001:470:1f0a:1063::2: frag (1448|20)

Where 178.27.217.52 is my local IPv4 address an 216.66.80.30 the HE tunnel endpoint.

The first fragemnt of the answer is lost, i guess because the packet gets too big. So i tried to change the MTU setting in Advanced tab in HE web interface. But the second fragment of the answer always starts at 1448. Even if I set the MTU to a minimum of 1280 the packet is still this big.

Any suggestions what i am doing wrong?

Thanks
  Sebastian.

[techniq]

A couple of things:

1) it seems you are working from a Linux or BSD system.
2) if yes, then understand that when you set the packet size you are also setting the DF bit to 1 (yes, don't fragment)
3) On my linux system I can use the -M flag with an argument of either
        - do (prohibit fragmentation, even local one), 
        - want  (do  PMTU  discovery,  fragment locally when packet size is large), or
        - dont (do not set DF flag)

Examples:

Code Select Expand

linux> ping6 -s 1800 -M do -c 3 2001:470:7:3a0::2
PING 2001:470:7:3a0::2(2001:470:7:3a0::2) 1800 data bytes
From 2001:470:e0bb:13::10 icmp_seq=1 Packet too big: mtu=1500
From 2001:470:e0bb:13::10 icmp_seq=1 Packet too big: mtu=1500
From 2001:470:e0bb:13::10 icmp_seq=1 Packet too big: mtu=1500

--- 2001:470:7:3a0::2 ping statistics ---
0 packets transmitted, 0 received, +3 errors

linux> ping6 -s 1800 -M want -c 3 2001:470:7:3a0::2
PING 2001:470:7:3a0::2(2001:470:7:3a0::2) 1800 data bytes
1808 bytes from 2001:470:7:3a0::2: icmp_seq=1 ttl=64 time=3.95 ms
1808 bytes from 2001:470:7:3a0::2: icmp_seq=2 ttl=64 time=4.15 ms
1808 bytes from 2001:470:7:3a0::2: icmp_seq=3 ttl=64 time=3.95 ms

--- 2001:470:7:3a0::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 3.951/4.020/4.157/0.096 ms


linux> ping6 -s 1800 -M dont -c 3 2001:470:7:3a0::2
PING 2001:470:7:3a0::2(2001:470:7:3a0::2) 1800 data bytes
1808 bytes from 2001:470:7:3a0::2: icmp_seq=1 ttl=64 time=4.14 ms
1808 bytes from 2001:470:7:3a0::2: icmp_seq=2 ttl=64 time=4.10 ms
1808 bytes from 2001:470:7:3a0::2: icmp_seq=3 ttl=64 time=4.04 ms

--- 2001:470:7:3a0::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 4.041/4.096/4.141/0.084 ms

[kasperd]

Any suggestions what i am doing wrong?

I tried your ping command through two different tunnel providers. I saw the same symptom as you did. I guess the problem is on 2001:780:3:5::11f or the network it is located on.

[GaryGapinski]

As I mentioned in http://www.tunnelbroker.net/forums/index.php?topic=3014.msg17764#msg17764, I think the only size that is not subject to being dropped is (maximally) MTU-48.

http://www.potaroo.net/ispcol/2009-01/mtu6.html may also be useful.