RE: dropping of un-matched tagged packets?

> 
> If I'm understanding well, this solution would work as far as the hw
> acceleration is not being activated by the host (that contains the
virtual
> machine) kernel vlan module, that is, when no VLANs are being used in
the
> host itself. Right?
> 
> Unfortunatelly,  this is not my case: in addition to the virtual
machines,
> the host itself is using some VLANs in eth2 (eth2.900, eth2.901,
etc.).
> 
> In summary, when a tagged packet arrives to eth2 physical interface,
the
> behaviour that I need is:
> 
> - Host kernel: if the tag is within the ones used by the host itself
(900,
> 901, etc.), deliver the packet (untagged) to the suitable interface
> (eth2.900, eth.902, etc.). Otherwise, deliver the package (tagged) to
the
> bridge. That causes the package arrives to the virtual machines
trought
> the
> tunnels (tun0, tun1, etc.; there is so many tunnels as virtual
> machines -vm0, vm1, etc- and in the "virtual machine side" the tunnel
> connects always with eth0).
> - Virtual machine kernel: if the tag is within the ones used by the
> virtual
> machine (200, 300, etc.), deliver the packet to the suitable interface
> (eth0.200, eth3.300, etc.). Otherwise, the packet is drop.
> 

Aha. Then you have a problem :) Is there ever the case where you have a
vlan that needs to be visible in both the physical and virtual machine?

I have kind of worked around this under xen but I'm not real happy with
the solution, and it wouldn't work for uml anyway (uses virtual
interface endpoints provided by xen).

I think the ultimate solution to this problem would be an ebtables thing
where instead of just giving the choice of BROUTE-ING the packet or not,
you could give a copy of the packet to the bridge code and to the vlan
code.

James