From owner-freebsd-net Mon Aug 19 15:59:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF08C37B400; Mon, 19 Aug 2002 15:59:05 -0700 (PDT) Received: from 66-162-33-178.gen.twtelecom.net (66-162-33-178.gen.twtelecom.net [66.162.33.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E19C43E3B; Mon, 19 Aug 2002 15:59:05 -0700 (PDT) (envelope-from sfrancis@expertcity.com) Received: from [10.4.2.41] (helo=expertcity.com) by 66-162-33-178.gen.twtelecom.net with esmtp (Exim 3.22 #4) id 17gvUG-0003GK-00; Mon, 19 Aug 2002 15:59:04 -0700 Message-ID: <3D617842.4020304@expertcity.com> Date: Mon, 19 Aug 2002 15:59:14 -0700 From: Steve Francis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Jesper Skriver Cc: Jeff Behl , net@freebsd.org Subject: Re: MTU not working? References: <3D585310.8010709@expertcity.com> <20020819151623.GD48757@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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