Hi, This has been broken for quite a while, but I haven't gotten around to debug it until now. I have an IPv6-in-IPv4 tunnel between two points, both with MTU 1500 on the regular v4 network. (I've verified that I can indeed send 1500-byte packets and fragments over IPv4 from the two points.) By default, Linux assigns MTU 1480 to this tunnel. However, if I try to ping -s 5000 from one side of the tunnel to the other, I get first "Packet too big, mtu=1480" and then on the next packet (when the machine tries to send 1480-byte fragments) "Packet too big, mtu=1472". After that, the packet goes through. However, in some cases it seems I do not seem to get the "Packet too big" ICMP at all. In particular, if I change to a GRE tunnel (where the default MTU is 1476), and send in 1476-byte packets, they are just eaten. They clearly go into the GRE tunnel (according to tcpdump), but no IPv4 packets ever go out on the other side, and no ICMPs are sent back. (There's no iptables rules on the router in question, nor any relevant sysctl settings except that IPv6 forwarding is of course turned on.) If I lower MTU on the interfaces to 1468, everything seems to work just fine. (I cannot change the MTU of a regular ipip tunnel, so it's impossible for me to check whether a lower MTU would have fixed the issues for those as well, but it seems reasonable.) Any idea where the extra eight bytes go? Is there some inner layer of encapsulation in the kernel (adding eight bytes internally) that I've missed?
Bleh, this bug is invalid. It turns out the real path MTU between the two machines were 1492, not 1500 -- a bad combination of path MTU, automatic fragmentation, bad tcpdump filters, and ICMP rate limiting from the router in question made it look like it was 1500 to me initially. It might be that this should have been easier to debug somehow (I still don't like that the packets were simply eaten on the side not limited to 1492), but it probably isn't a bug in the kernel. Closing, sorry about the noise.
Reply-To: akpm@linux-foundation.org On Sat, 23 Feb 2008 09:17:14 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=10073 > > Summary: Just-small-enough packets in tunnels are silently eaten > Product: Networking > Version: 2.5 > KernelVersion: 2.6.23 (mainline), 2.6.25-rc2 (mainline), 2.6.18-6-amd64 > (Debian > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: IPV6 > AssignedTo: yoshfuji@linux-ipv6.org > ReportedBy: sgunderson@bigfoot.com > > > Hi, > > This has been broken for quite a while, but I haven't gotten around to debug > it > until now. > > I have an IPv6-in-IPv4 tunnel between two points, both with MTU 1500 on the > regular v4 network. (I've verified that I can indeed send 1500-byte packets > and > fragments over IPv4 from the two points.) By default, Linux assigns MTU 1480 > to > this tunnel. > > However, if I try to ping -s 5000 from one side of the tunnel to the other, I > get > first "Packet too big, mtu=1480" and then on the next packet (when the > machine > tries to send 1480-byte fragments) "Packet too big, mtu=1472". After that, > the > packet goes through. > > However, in some cases it seems I do not seem to get the "Packet too big" > ICMP > at all. In particular, if I change to a GRE tunnel (where the default MTU is > 1476), and send in 1476-byte packets, they are just eaten. They clearly go > into > the GRE tunnel (according to tcpdump), but no IPv4 packets ever go out on the > other side, and no ICMPs are sent back. (There's no iptables rules on the > router in question, nor any relevant sysctl settings except that IPv6 > forwarding is of course turned on.) If I lower MTU on the interfaces to 1468, > everything seems to work just fine. (I cannot change the MTU of a regular > ipip > tunnel, so it's impossible for me to check whether a lower MTU would have > fixed > the issues for those as well, but it seems reasonable.) > > Any idea where the extra eight bytes go? Is there some inner layer of > encapsulation in the kernel (adding eight bytes internally) that I've missed? >