RE: dropping of un-matched tagged packets?

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

It shouldn't happen. I mean: there is a VLAN ID range for host itself
(900-1000) and other range for virtual machines (100-899) that don't
overlap.

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

I'll read a bit more about ebtables. However, I would like to know if the
tool can be configured to implement this solution or if you are refering to
a feature that would be implemented in the ebtable code (I'm asking just to
not start pursuing a magic ebtable configuration that actually doesn't
exists :)

However, maybe the best solution is just to use two physical interfaces:
letting eth2 for the virtual machines (and no configure any host vlan on it)
and using another (for example, eth3) for the host vlans (eth3.900,
eth3.901, etc.). I didn't think at the begining that multiplexing virtual
machines and host VLANs in the same physical interface could be so
difficult! :)

Thank you again for all your support!

Best regards,

--------------------
Fermin Galan Marquez
CTTC - Centre Tecnologic de Telecomunicacions de Catalunya
Parc Mediterrani de la Tecnologia, Av. del Canal Olimpic s/n, 08860
Castelldefels, Spain
Room 1.02
Tel : +34 93 645 29 12
Fax : +34 93 645 29 01
Email address: [email protected]