Subject: Re: VLAN + bridging problems
To: Dobromir Montauk <dmontauk@rescomp.berkeley.edu>
From: William Waites <ww@styx.org>
List: tech-net
Date: 12/10/2002 02:50:00
>>> "Dobromir" == Dobromir Montauk <dmontauk@rescomp.berkeley.edu> writes:

    Dobromir> It's not.  But my guess  is that the NetBSD VLAN driver,
    Dobromir> like  the Linux driver,  should strip  off the  VLAN tag
    Dobromir> before doing anything else  - for example forwarding the
    Dobromir> packet  through  a   bridge...   

You   are   correct,   that   is   exactly   what's   happening.    In
sys/net/if_ethersubr.c the relevant  function is ether_input(), around
line  703.  The packet  is  bridged first,  then  the  vlan header  is
stripped off around line 754.

    Dobromir> In Linux,  supposedly, there's a special  option to turn
    Dobromir> this "feature" on/off.  I was hoping NetBSD had the same
    Dobromir> thing.

If  we strip  the vlan  header off  before bridging  the  packet, then
bridging under the vlans won't work   -- you can't make a repeater out
of  two NICs  that  will  forward packets  leaving  the 802.1q  header
intact.

As it is, there are four possible setups for a bridge:

- vlan and vlan as members of a bridge -- this works correctly because
  vlan_input calls  ether_input recursively after it  has stripped the
  header and neither parent interface is the member of a bridge.
- vlan and ether (not parent of  vlan) -- this works correctly as long
  as  tagged packets  are never  recieved on  the ether  interface. If
  tagged packets are recieved, an extra header gets tacked on.
- vlan and ether (parent of  vlan)  -- this will not work for the same
  reason -- ether must recieve tagged packets.
- ether and ether -- this is the repeater scenario above

Your setup is the third one, no?

Basically    the  the   third  and   fourth  scenarios   are  mutually
exclusive. The configuration option you are asking for would be a flag
that would toggle between the two, correct?

At  the moment it  isn't clear  to me  how to  do that  without making
ether_input()  start to look  like spaghetti...  But then  again, it's
getting late..

I suspect the reason that the switch vendors don't support this either
is to  avoid having their code  look like spaghetti  also. Maybe Linus
doesn't mind ;)

Cheers,
Will