From owner-freebsd-net@FreeBSD.ORG Fri Jul 20 19:09:44 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 E3F3816A41B for ; Fri, 20 Jul 2007 19:09:44 +0000 (UTC) (envelope-from SRS0=a3fa025e4cd4e551cf489a0571430d1df480ce2b=402=es.net=dart@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id 71AC713C442 for ; Fri, 20 Jul 2007 19:09:44 +0000 (UTC) (envelope-from SRS0=a3fa025e4cd4e551cf489a0571430d1df480ce2b=402=es.net=dart@es.net) Received: from [192.168.13.32] (c-24-4-182-157.hsd1.ca.comcast.net [24.4.182.157]) by postal1.es.net (Postal Node 1) with ASMTP (SSL) id ZAD61743; Fri, 20 Jul 2007 12:09:43 -0700 Message-ID: <46A10860.50804@es.net> Date: Fri, 20 Jul 2007 12:09:20 -0700 From: Eli Dart User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Julian Elischer References: <200707150237.l6F2bAgZ011098@redrock.karels.net> <469E0FFF.8070802@seclark.us> <20070720172021.8EA3D13C4B3@mx1.freebsd.org> <46A10063.9010902@elischer.org> In-Reply-To: <46A10063.9010902@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org 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: Fri, 20 Jul 2007 19:09:45 -0000 see below... Julian Elischer wrote: > Eli Dart wrote: >> >> >> Stephen Clark wrote: >> >>>> >>> So was any decision reached on this issue - will FreeBSD changed >>> to accept a packet on an interface that is larger than the mtu on >>> that interface? >> >> If possible, I'd like to see the ability to enforce interface MTU >> for received packets preserved in a sysctl if it is removed for the >> default config... In other words, something like: >> >> net.link.mtu_limits_received_pktsize = 0|1 >> >> Then, default it to 0 to preserve 4.x behavior. > > what would this achieve? > > Answering himself.. it MAY allow a driver to optimise a bit by not > needing to cope with the posibility of receiving jubo packets? I can > not think of any other reason.. (except to break networks that are > apparently working fine). 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) Many thanks, --eli -- Eli Dart Office: (510) 486-5629 ESnet Network Engineering Group Fax: (510) 486-6712 Lawrence Berkeley National Laboratory PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3