Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Feb 2000 00:21:42 -0500
From:      "C. Stephen Gunn" <csg@dustdevil.waterspout.com>
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>
In-Reply-To: <200002031847.NAA62013@khavrinen.lcs.mit.edu>
References:  <Pine.OSF.4.21.0002031711230.1338-100000@haddock.euitt.upm.es> <Pine.BSF.4.21.0002031236160.479-100000@sasami.jurai.net> <200002031847.NAA62013@khavrinen.lcs.mit.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
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. <sigh>)

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000214002142.A12511>