From owner-freebsd-net Fri Aug 4 5:40:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from smtp.whitebarn.com (Spin.WhiteBarn.Com [216.0.13.113]) by hub.freebsd.org (Postfix) with ESMTP id 9545437BAA0 for ; Fri, 4 Aug 2000 05:40:28 -0700 (PDT) (envelope-from Bob@WhiteBarn.Com) Received: from WhiteBarn.Com (Relent.Bob.WhiteBarn.Com [216.0.13.50]) by smtp.whitebarn.com (8.9.3/8.9.3) with ESMTP id HAA00797; Fri, 4 Aug 2000 07:39:56 -0500 (CDT) (envelope-from Bob@WhiteBarn.Com) Message-ID: <398AB99C.9D5938B9@WhiteBarn.Com> Date: Fri, 04 Aug 2000 07:39:56 -0500 From: Bob Van Valzah X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Louis A. Mamakos" Cc: freebsd-net@FreeBSD.ORG Subject: Re: VLAN MTU? 1500? 1504? Why? References: <398A3549.902A31F5@WhiteBarn.Com> <200008040434.AAA41523@whizzo.transsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Louie, Thanks for your comments and for framing the question more clearly. Let's assume we do want to do 1500-byte frames on the virtual interfaces and go on to an ugly aspect of implementing it. Longer frames seem to require that the physical interface "know" that 1504-byte frames should be allowed when the VLAN or 802.1p driver is above it but prohibited otherwise. Conversely, the VLAN driver should "ask" before assuming that the physical interface can handle the larger frames so that it can fail the open in those cases where the driver can't handle them? Is there any existing mechanism for "negotiation" of MTU between the physical layer and virtual layer? If not, should there be? I suppose we could crank the MTU of all physical interfaces up to whatever they can really handle instead of artificially limiting them to 1500 bytes, but that sounds icky. In short, it seem kind of gross to have to hack the source code of the physical driver when you intend to use it with a virtual driver above it. Is it worth making an elegant solution to this or should we just let the few who need longer frames continue futzing the source of the physical drivers? Thanks, Bob "Louis A. Mamakos" wrote: > You've got the wrong alternatives considered. > > The two to choose between are: > > 1. The IPv4 MTU for packets on an Ethernet are always 1500 bytes. To > this, the ethernet driver adds various link-layer headers (source > and destination MAC addresses, Ethernet Type/802.3 length) as well as > trailers (Ethernet CRC). > > For some ethernet links which use VLAN trunking, there are additional > fields in the link layer headers which are added to support VLANs and > 802.1p priority. Ethernet interfaces which choose to participate in > explicit VLAN tagging need to be able to add and remove this header, > which may result in maximal length frames a few byte longer than > previously. > > 2. The IPv4 MTU for packets is decreased because the hardware you > have can't accomodate the addition of VLAN tagging when you want to > use explicit tagging of frames, and the IP payload is "large." > > I would argue that if your Ethernet hardware can't send and receive > frames with the "normal" sized payload AND the addition of VLAN tags, > then you have no business using it on explicitly tagged VLAN ethernet > segments. E.g., alternative 1 is correct. > > It's important to distinguish between the payload length that the > link layer (e.g., ethernet) offers to transport for the higher level > protocol (IPv4 in this discussion) with the constraints that the > physical layer protocol has. Ethernet MTUs have never been 1500 > bytes; that's the IP MTU of IP packets carried inside of Ethernet > frames. The length of the Ethernet frame was sacred until someone > wanted to do VLAN tagging (which has to be consented to by the > parties) and they allowed the packets to grow larger to accomodate > this. > > This makes sense when you consider that the primary application of > explicit VLAN tags is on a VLAN trunk between Ethernet switches. The > end system using the ethernet switches should not have to care (or > even be aware) that the link between a couple of switches is just > a plain ethernet, or a VLAN trunk carrying multiple distinct > broadcast domains, one per VLAN. > > louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message