Dear James, >> Well, it's a bit more complicated... The idea is to bridge the >> physical interface (eth2) with some tun devices (for example, tun0, tun1, etc.) >> that are connected to interfaces inside a virtual machine running in the >> host (using User Mode Linux, http://user-mode-linux.sourceforge.net/, maybe >> you know about it) (tun0 to eth0 in virtual machine, tun1 to eth1 in >> virtual machine, etc.) and to create the VLANs inside the virtual machine >> (eth0.200 in the virtual machine, eth1.300 in the virtual methince, etc.) not in >> the bridge itself. Therefore, the bridge would have to switch trunk >> traffic transparently, so this traffic reach the virtual machine and the >> virtual machine kernel vlan interface can deal with the tagged packet (and >> deliver it untagged to eth0.200, eth1.300 or whatever). > > If that's all you need to do, then you should be able to bridge the > physical interface to the tun interfaces without having to worry about > vlans in the physical machine... hmmm... but maybe mtu might be a > problem. 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. > I do almost exactly the same thing with xen (proper virtualisation, you > should try it some time :) In fact, I'm not using plain UML, but a front-end called VNUML (http://www.dit.upm.es/vnuml) that enhances the UML virtualization backend using a high-level scenario specification in XML to build complex network enviroments. Testing Xen (many people has told me about it :) is in my TODO list, but not in the near future. >> Although I know I'm trying a weird UML/VLAN/bridge application :), I >> think such patch could be useful in general, due to it would increase the >> flexibility of the VLAN support for people using cards with hw >> acceleration, like me. > > Seriously, just try bridging the interfaces without vlanning anything in > the physical machine. If that doesn't work, post back here and we'll > talk :) I'm still thinking the patch should be useful given it improves flexibility and improving flexibility in general is (almost) always good. However, given that I'm not a kernel or vconfig expert, I can not estimate the complexity of preparing it :). Sorry for not providing "the whole picture" of my application in the very first mail, but I think that, given that I play with weird things :), it is better understable in small pieces. 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: fermin.galan@xxxxxxx
