#3 closed defect (fixed)
mtu problem on v6
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | network | Keywords: | |
| Cc: | My Current Location: | ||
| My MAC Address: | My OS: |
Description (last modified by )
I had a problem communicating with datatracker.ietf.org. With the help of Bill Fenner and some debugging we figured out that this is due to IPv6 MTU problem on the second hop from the hotel. You can't ping6 2001:770:8:45::1 with 1500 bytes, but you can with 1300. In practice this means that anyone using IPv6 will have serious problems. I tested to www.kame.net and MTU of 1432+40+8=1480 works, but nothing higher than that. So presumably we have a 20 byte IPv4 tunnel header somewhere. ICMPv6 packet too bigs or something should be generated, or the tunnel MTU changed. Fragments seem to have a problem too. Here's what's happening: root@dummy3:/tmp# traceroute6 datatracker.ietf.org traceroute to datatracker.ietf.org (2001:1890:1112:1::21) from 2001:df8:0:16:216:6fff:fe75:6607, 30 hops max, 16 byte packets 1 rtrextb-wireless-open.meeting.ietf.org (2001:df8:0:16::3) 8.519 ms 1.457 ms 1.504 ms 2 2001:770:8:45::1 (2001:770:8:45::1) 3.219 ms 3.129 ms 8.079 ms 3 gig0-12-0-2-cr2-cwt.hea.net (2001:770:400:37::1) 8.505 ms 3.86 ms 6.389 ms 4 xe-2-1-0.dub20.ip6.tiscali.net (2001:668:0:3::c000:71) 3.134 ms 16.201 ms 3.308 ms 5 so-2-1-0.nyc22.ip6.tiscali.net (2001:668:0:2::1:421) 82.814 ms 94.329 ms 88.522 ms 6 so-3-0-0.was11.ip6.tiscali.net (2001:668:0:2::1:261) 101.731 ms 88.808 ms 89.34 ms 7 so-7-0-0.was10.ip6.tiscali.net (2001:668:0:2::1:232) 89.285 ms 89.508 ms 94.378 ms 8 ibr01-ve96.asbn01.occaid.net (2001:504:0:2:0:3:71:1) 92.142 ms 90.306 ms root@dummy3:/tmp# root@dummy3:/tmp# ping6 -s 1434 www.kame.net PING www.kame.net(orange.kame.net) 1434 data bytes --- www.kame.net ping statistics --- 11 packets transmitted, 0 received, 100% packet loss, time 10010ms root@dummy3:/tmp# ping6 -s 1432 www.kame.net PING www.kame.net(orange.kame.net) 1432 data bytes 1440 bytes from orange.kame.net: icmp_seq=1 ttl=47 time=317 ms 1440 bytes from orange.kame.net: icmp_seq=2 ttl=47 time=300 ms --- www.kame.net ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 300.619/308.966/317.313/8.347 ms root@dummy3:/tmp# ping6 -s 1500 rtrextb-wireless-open.meeting.ietf.org PING rtrextb-wireless-open.meeting.ietf.org(rtrextb-wireless-open.meeting.ietf.org) 1500 data bytes 1508 bytes from rtrextb-wireless-open.meeting.ietf.org: icmp_seq=1 ttl=64 time=9.48 ms 1508 bytes from rtrextb-wireless-open.meeting.ietf.org: icmp_seq=2 ttl=64 time=6.31 ms --- rtrextb-wireless-open.meeting.ietf.org ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 6.310/7.895/9.481/1.587 ms root@dummy3:/tmp# root@dummy3:/tmp# ping6 -s 1500 2001:770:8:45::1 PING 2001:770:8:45::1(2001:770:8:45::1) 1500 data bytes --- 2001:770:8:45::1 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3010ms root@dummy3:/tmp# ping6 -s 1300 2001:770:8:45::1 PING 2001:770:8:45::1(2001:770:8:45::1) 1300 data bytes 1308 bytes from 2001:770:8:45::1: icmp_seq=1 ttl=63 time=9.46 ms --- 2001:770:8:45::1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 9.463/9.463/9.463/0.000 ms Jari
Change history (10)
comment:1 Changed 10 years ago by
| id: | → 3 |
|---|
comment:2 Changed 10 years ago by
| Cc: | andrew.lange@… added |
|---|---|
| Description: | modified (diff) |
| Status: | new → assigned |
Jim -
Looks like someone needs to chase this, Andrew is cc:ed
1st hop issue.
- Lucy
comment:3 Changed 10 years ago by
| Description: | modified (diff) |
|---|
Seems to me like the IPv6 tunnel entrance probably is not sending ICMP errors in response to packets that are too big for the tunnel.
comment:4 Changed 10 years ago by
| Cc: | andrew.lange@… removed |
|---|---|
| Component: | unassigned → network |
| Milestone: | IETF Week → pre-show |
| Owner: | changed from llynch@… to andrew.lange@… |
| Priority: | minor → major |
| Type: | request → defect |
comment:5 Changed 10 years ago by
Jari, we think this is fixed.
We changed the tunnel mtu, and moved it up.
Could you please test? Thanks!
comment:6 Changed 10 years ago by
Jari relies by email
Date: Sat, 26 Jul 2008 13:40:25 +0100
From: Jari Arkko <jari.arkko@piuha.net>
To: trac@meeting.ietf.org
Cc: andrew.lange@alcatel-lucent.com, llynch@civil-tongue.net, fenner@fenron.com
Subject: Re: [IETF Meeting/NOC] #3: mtu problem on v6
[ The following text is in the "UTF-8" character set. ]
[ Your display is set for the "US-ASCII" character set. ]
[ Some characters may be displayed incorrectly. ]
Does not seem to work, still:
Here's a trace of a packet that my host sends but never sees a response:
13:39:00.021120 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1448)
2001:df8:0:16:216:6fff:fe75:6607 > 2001:200:0:8002:203:47ff:fea5:3085: ICMP6,
echo request, length 1448, seq 27
(This was from the last test below, ping6 -s 1440 www.kame.net)
More details:
root@dummy3:/tmp# ifconfig eth0 mtu 1500
root@dummy3:/tmp# ping6 www.kame.net
PING www.kame.net(orange.kame.net) 56 data bytes
64 bytes from orange.kame.net: icmp_seq=1 ttl=47 time=301 ms
64 bytes from orange.kame.net: icmp_seq=2 ttl=47 time=325 ms
64 bytes from orange.kame.net: icmp_seq=3 ttl=47 time=304 ms
^P
--- www.kame.net ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 3004ms
rtt min/avg/max/mdev = 301.842/310.384/325.034/10.406 ms
root@dummy3:/tmp# ping6 -s 1450 www.kame.net
PING www.kame.net(orange.kame.net) 1450 data bytes
--- www.kame.net ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7000ms
root@dummy3:/tmp# ping6 -s 1430 www.kame.net
PING www.kame.net(orange.kame.net) 1430 data bytes
1438 bytes from orange.kame.net: icmp_seq=2 ttl=47 time=333 ms
1438 bytes from orange.kame.net: icmp_seq=3 ttl=47 time=302 ms
1438 bytes from orange.kame.net: icmp_seq=4 ttl=47 time=333 ms
--- www.kame.net ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 2999ms
rtt min/avg/max/mdev = 302.523/322.934/333.200/14.432 ms
root@dummy3:/tmp# ping6 -s 1440 www.kame.net
PING www.kame.net(orange.kame.net) 1440 data bytes
--- www.kame.net ping statistics ---
13 packets transmitted, 0 received, 100% packet loss, time 12007ms
comment:7 Changed 10 years ago by
Jari,
The problem appears to be that the tunnel mtu on the cisco's on the other end is set to 1480. Things seem to be okay on the SR/IETF side. So, in order to work around this, until we can get the tunnel mtu fixed on the Eircom/HEANET routers, I've changed the mtu in router-advertisement to 1480. Right now this is set only on the v6ONLY Wireless net. It seems to work:
demiurge2:~ alange$ ping6 -s 1500 2001:770:8:44::1
PING6(1548=40+8+1500 bytes) 2001:df8::8:21f:5bff:fec7:ee0a --> 2001:770:8:44::1
1508 bytes from 2001:770:8:44::1, icmp_seq=0 hlim=63 time=7.131 ms
1508 bytes from 2001:770:8:44::1, icmp_seq=1 hlim=63 time=8.911 ms
1508 bytes from 2001:770:8:44::1, icmp_seq=2 hlim=63 time=3.912 ms
1508 bytes from 2001:770:8:44::1, icmp_seq=3 hlim=63 time=3.563 ms
1508 bytes from 2001:770:8:44::1, icmp_seq=4 hlim=63 time=4.482 ms
C
--- 2001:770:8:44::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 3.563/5.600/8.911 ms
Jari, could you please associate with the v6ONLY network, and see if it works from your box. If it does, we can deploy the fix to the other networks.
comment:8 Changed 10 years ago by
Jari says:
Date: Sat, 26 Jul 2008 15:48:58 +0100
From: Jari Arkko <jari.arkko@piuha.net>
To: trac@meeting.ietf.org
Cc: andrew.lange@alcatel-lucent.com, llynch@civil-tongue.net,
fenner@fenron.com
Subject: Re: [IETF Meeting/NOC] #3: mtu problem on v6
[ The following text is in the "UTF-8" character set. ]
[ Your display is set for the "US-ASCII" character set. ]
[ Some characters may be displayed incorrectly. ]
I can confirm that this now works on the "ietf" SSID as well. Big thanks!
Jari
comment:9 Changed 10 years ago by
| Status: | assigned → closed |
|---|
Since Jari has confirmed that this works now, I have deployed the router-advertisement mtu 1480 function on all of the networks, on both routers.
We should be good to close this ticket.
This message has 0 attachment(s)