Subject: Re: 802.1Q tagged VLAN for NetBSD
To: Michael Graff <email@example.com>
From: Scott Reynolds <scottr@Plexus.COM>
Date: 11/08/1999 15:01:16
Subinterfaces make a lot of sense. Having been heavily exposed to a
VLAN-oriented network (of our own free will ;-) for the last 6 months,
I've become quite comfortable with the idea of VLAN trunking and how it's
implemented in the Cisco world and in the Intel NICs under NT. Your
proposal in general seems rational to me, and fits the model I've been
using. However, I'd like to suggest a modification to your idea.
On 8 Oct 1999, Michael Graff wrote:
> I'd implement this by removing the interface address information from
> the link-level physical interface structure, and hanging a linked list
> of subinterface structures off the physical interface.
I'm not sure if there is a hardware limitation on the 8255x or not, but
consider the possibility that an 802.1Q-enabled network may have both
tagged and untagged frames on it. Rationally, there are at least two ways
to handle this:
1) Specify that one subinterface must handle this special case of native
Ethernet frames, perhaps with a flag.
2) Allow an address to be configured on the physical interface, handling
all native frames through that interface and all tagged frames through the
With the hardware I have, the NICs won't currently handled native frames.
I don't know if that's a hardware or software limitation, but I'd hate for
us to have the same limitation if it wasn't necessary.
> Another thing I would love to get going is the concept of bonded
> interfaces, where an address can be used on multiple interfaces. Say,
> two 100baseTX-FDX interfaces bonded into a single trunk, going to a
Agreed. With the amount of Cisco equipment installed worldwide, it might
make sense for someone to contact them and see if we can get specs to
implement their version of this. (It's called Fast EtherChannel (FEC) or
GigaChannel (GC) in all of their literature, that I've seen.)
> I don't yet know how these two can be combined, but I think having
> them would help a lot in the "Net" part of NetBSD :)
I, for one, could use this functionality today, if we had it. Fortunately
I'm not crippled by the lack thereof. :-)