From owner-freebsd-net@FreeBSD.ORG Sat Jul 21 08:06:09 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F1D516A417 for ; Sat, 21 Jul 2007 08:06:09 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id A003C13C467 for ; Sat, 21 Jul 2007 08:06:06 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from [192.168.32.4] (aviko.aws-net.org.ua [192.168.32.4]) by alf.aws-net.org.ua (8.13.8/8.13.8) with ESMTP id l6L85lHN063556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 21 Jul 2007 11:05:47 +0300 (EEST) (envelope-from artem@aws-net.org.ua) Message-ID: <46A1BE5B.60509@aws-net.org.ua> Date: Sat, 21 Jul 2007 11:05:47 +0300 From: Artyom Viklenko Organization: Art&Co. User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Eli Dart References: <200707150237.l6F2bAgZ011098@redrock.karels.net> <469E0FFF.8070802@seclark.us> <20070720172021.8EA3D13C4B3@mx1.freebsd.org> <46A10063.9010902@elischer.org> <46A10860.50804@es.net> In-Reply-To: <46A10860.50804@es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-3.0 (alf.aws-net.org.ua [192.168.32.253]); Sat, 21 Jul 2007 11:05:47 +0300 (EEST) X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on localhost X-Virus-Status: Clean Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: 6.2 mtu now limits size of incomming packet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 08:06:09 -0000 Eli Dart wrote: > > The networks that are apparently working fine are most likely > misconfigured, IMHO. > > Others have made a case for permitting an interface to accept as large a > packet as it can, regardless of configured MTU. That's fine for theory. > > My operational experience leads me to a different place. If an > interface receives a packet that is larger than its configured MTU, I > would prefer that the packet be dropped as a giant and a giants counter > incremented, regardless of whether the hardware can theoretically > receive the packet. In modern networks, an MTU mismatch within a > broadcast domain indicates a broken network, IMHO. If the devices in > the network are configured to enforce MTU for both tx and rx, more > problems get spotted during turnup, rather than surfacing later on as > difficult-to-diagnose problems that users only call about after they are > truly frustrated. And, if you have a giants counter (or input error > counter) you can look at, it makes it straightforward to spot the problem. > > (one could also stretch a bit and say that enforcing MTU on rx might > provide less surprise to code that consumes packets and has knowledge of > the MTU setting of an interface.....unfortunately I don't know enough > about the details of the network stack to know if this is a real concern) 100% agree! :) -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org