Date: Mon, 19 Aug 2002 15:59:14 -0700 From: Steve Francis <sfrancis@expertcity.com> To: Jesper Skriver <jesper@FreeBSD.org> Cc: Jeff Behl <jeff@expertcity.com>, net@freebsd.org Subject: Re: MTU not working? Message-ID: <3D617842.4020304@expertcity.com> References: <3D585310.8010709@expertcity.com> <20020819151623.GD48757@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Allow me to respond for Jeff (we work at same place, and have both been looking this issue) ICMP's being blocked are the most common explanation for this - but this is not the case here. tcpdump run on the server system shows the ICMP fragmention required - DF bit set messages being received, and - the irrefutable proof that it is not an ICMP filtering issue -the FreeBSD system DOES lower the MTU for that host's cloned route to the value specified in the ICMP (1420 in the snippet below). New packets are segmented to sizes <= the new MTU, but it continues resend the original packet over and over, in the original 1500 byte size. So I still say FreeBSD has broken pMTU-D code. This is reproducible at will, so we can collect whatever info anyone wants. The ICMP's Jesper Skriver wrote: > > On Mon, Aug 12, 2002 at 05:30:08PM -0700, Jeff Behl wrote: > > We're seeing something odd that is seriously impacting our service for > > some clients. Even though a the box seems to have the correct MTU in > > the routing table, it doesn't seem to follow it in all cases. > > > > dell350-12.snv#sysctl -a | grep mtu > > net.inet.tcp.path_mtu_discovery: 1 > > > > dell350-12.snv#uname -a > > FreeBSD dell350-12.snv 4.4-RELEASE FreeBSD 4.4-RELEASE #0: Fri Aug 2 > > 03:24:36 PDT 2002 > > root@dell350-12.snv:/usr/src/sys/compile/COMMS44-2 i386 > > > > > > dell350-12.snv#netstat -rnal | grep 10.4.1.134 > > 10.4.1.134 63.xxx.224.129 UGHW 1 2268 1420 fxp0 > > > > > > but tcpdump shows: > > > > > > 17:21:43.497275 63.xxx.224.154.80 > 10.4.1.134.2314: . 1:1461(1460) ack > > 248 win 17520 (DF) > > 17:21:51.497212 63.xxx.224.154.80 > 10.4.1.134.2314: . 1:1461(1460) ack > > 248 win 17520 (DF) > > 17:22:07.497065 63.xxx.224.154.80 > 10.4.1.134.2314: . 1:1461(1460) ack > > 248 win 17520 (DF) > > > > > > obviosly the packet isn't making it back to the client as it's too big. > > any ideas? I don't see any bug reports on it. We believe the same > > situation exsits with a 4.6 server but I haven't checked that thorougly > > enough yet. > > It's most likely a firewall or router filter, that block the > ICMP messages coming back to your server. > > /Jesper > > -- > Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 > Senior network engineer @ AS3292, TDC Tele Danmark > > One Unix to rule them all, One Resolver to find them, > One IP to bring them all and in the zone to bind them. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D617842.4020304>