Opened 9 years ago

Closed 9 years ago

Last modified 7 years ago

#3 closed defect (fixed)

mtu problem on v6

Reported by: Jari Arkko <jari.arkko@…> Owned by: andrew.lange@…
Priority: major Milestone:
Component: network Keywords:
Cc: My Current Location:
My MAC Address: My OS:

Description (last modified by Bill Fenner)

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 9 years ago by Jari Arkko

id: 3

This message has 0 attachment(s)

comment:2 Changed 9 years ago by llynch@…

Cc: andrew.lange@… added
Description: modified (diff)
Status: newassigned

Jim -

Looks like someone needs to chase this, Andrew is cc:ed

1st hop issue.

  • Lucy

comment:3 Changed 9 years ago by Bill Fenner

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 9 years ago by llynch@…

Cc: andrew.lange@… removed
Component: unassignednetwork
Milestone: IETF Weekpre-show
Owner: changed from llynch@… to andrew.lange@…
Priority: minormajor
Type: requestdefect

comment:5 Changed 9 years ago by anonymous

Jari, we think this is fixed.

We changed the tunnel mtu, and moved it up.

Could you please test? Thanks!

comment:6 Changed 9 years ago by llynch@…

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 9 years ago by andrew.lange@…

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 9 years ago by llynch@…

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 9 years ago by andrew.lange@…

Status: assignedclosed

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.

comment:10 Changed 7 years ago by (none)

Milestone: pre-show ietf72

Milestone pre-show ietf72 deleted

Note: See TracTickets for help on using tickets.