From owner-freebsd-net Thu Feb 3 10:51:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by builder.freebsd.org (Postfix) with ESMTP id 237DE3F66 for ; Thu, 3 Feb 2000 10:51:39 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id NAA62013; Thu, 3 Feb 2000 13:47:08 -0500 (EST) (envelope-from wollman) Date: Thu, 3 Feb 2000 13:47:08 -0500 (EST) From: Garrett Wollman Message-Id: <200002031847.NAA62013@khavrinen.lcs.mit.edu> To: "Matthew N. Dodd" Cc: "Pedro J. Lobo" , freebsd-net@FreeBSD.ORG Subject: Re: 802.1Q VLANs In-Reply-To: References: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Humm... Ideally the VLAN driver should be able to set the MTU for its > parent and deal with being able to set the MTU > 1500. No, you've got it the wrong way 'round. If the interface driver is written to be able to accept 1500-byte frames with an 18-byte header (as opposed to the ``normal'' 14-byte header), it needs to inform the upper layers of this by setting its advertised header length (ifi_hdrlen) to 18 rather than 14. The driver should always do this, if the hardware is capable, so that those frames will be made available to bpf. > Well, I see no reason to restrict people to cards that don't support large > frames; if they really need to use VLANs they can adjust the MTU down. In > the real world MTU discovery will insure that they aren't too big of a > problem. No, it won't. In the real world, MTU discovery will never be invoked, because switches do not allow users to reconfigure the MTU. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message