From owner-freebsd-net Sun Feb 13 21:21:35 2000 Delivered-To: freebsd-net@freebsd.org Received: from dustdevil.waterspout.com (dustdevil.waterspout.com [208.13.60.151]) by builder.freebsd.org (Postfix) with ESMTP id A81C34839; Sun, 13 Feb 2000 21:21:31 -0800 (PST) Received: by dustdevil.waterspout.com (Postfix, from userid 1000) id A7ED24B; Mon, 14 Feb 2000 00:21:42 -0500 (EST) Date: Mon, 14 Feb 2000 00:21:42 -0500 From: "C. Stephen Gunn" To: freebsd-net@freebsd.org Cc: wollman@freebsd.org, wpaul@freebsd.org, mdodd@freebsd.org, csg@waterspout.com Subject: Re: 802.1Q VLANs Message-ID: <20000214002142.A12511@dustdevil.waterspout.com> References: <200002031847.NAA62013@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <200002031847.NAA62013@khavrinen.lcs.mit.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Feb 03, 2000 at 01:47:08PM -0500, Garrett Wollman wrote: > 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. But this isn't necissairly true. IEEE 802.1Q says that proper implementations will be able to handle tagged and untagged packets on the same physical link. So we have some packets that arrive with tags (18 bytes), and some untagged, on the "native" vlan for the given interface (14 bytes). Right now untagged traffic (on a mixed link) is presented to the upper protocol layers by the parent device. This isn't quite kosher since 802.1Q states this should be routed to the "default" VLAN for the given interface. It _IS_ permissable to mark a given interface as "Tagged" traffic only. In this case we should increase ifi_hdrlen, but only in this case. This also requires some awareness elsewhere that a given interface in the kernel is a "trunk" and not a normal interface. Any untagged traffic should generate an error condition, as should attempts to set the network address/netmask, etc. > > 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. I agree that adjusting the MTU is simply not a viable option. Most of the world (incorrectly, albeit) assumes that ETHERMTU will always be 1500 bytes. (This includes the guys who run the routers that connect me to the world. ) With the gracious assistance of Bill Paul (wpaul@freebsd.org), I've hacked up the xl(4) driver to accomodate 1522 byte payloads. It works in my experiments. According to Bill, this hack will only operate on the newer 3c905B-TX xl cards from 3com. There's a lot of missing infrastructure to support 802.1Q well in FreeBSD. This is a kludge to get VLANs working with a 1500 byte MTU _NOW_. Nothing more. If VLANs are compiled into the kernel, it simply adjusts the "MAXPKTSIZE" register on the card on if_attach() and when handling SIOCSIMTU. It does not adjust ifi_hdrlen for the reasons state above. I'd appreciate review/suggestions on the changes and how to implement the features "across the board." - Steve -- C. Stephen Gunn URL: http://www.waterspout.com/ WaterSpout Communications, Inc. Email: csg@waterspout.com 427 North 6th Street Phone: +1 765.742.6628 Lafayette, IN 47901 Fax: +1 765.742.0646 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message