> > 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
