Hi Dan, I take the chance to ask; why is that the untagged IF can see the traffic of the tagged vlans? Isn't that filtered at kernel level? Is this a virtualization design limitation or is it down to the kernel? I don't know how the kernel processes the packages, but I thought that packages that arrives to the nic are filtered by the kernel and sent to the respective vif (untagged to the "master" interface and tagged to the .XX interfaces). I ask because other virtualization platforms don't have this limitation and I wonder if it's because they "don't care" of because they solved this somehow. Regards,
On 10/01/14 09:32, Dan Kenigsberg wrote: > On Thu, Jan 09, 2014 at 10:53:25PM +0200, Lior Vernia wrote: >> Hello Alan, >> >> On 09/01/14 10:07, Alan Murrell wrote: >>> Hello, >>> >>> I am evaluating oVirt as a replacement/alternative to VMware deployments >>> we typically do. I have installed and all-in-one setup on a test box >>> (which itself used to be an ESXi server), but it only has one NIC. I >>> trying to duplicate our typical configuration we do in VMware, which is >>> this: >>> >>> 1.) we create several "port groups" on the vSwitch, each assigned a >>> VLAN ID, such as: >>> >>> - VLAN001 (VLAN ID: 1) >>> - VLAN002 (VLAN ID: 2) >>> - VLAN009 (VLAN ID: 9) >>> - VLAN010 (VLAN ID: 10) >>> - VLAN200 (VLAN ID: 200) >>> - TRUNK (VLAN ID: 4095 - in VMware-world, VLAN ID "4095" is "all >>> VLANS" and basically just passes the VLANs through to whatever is >>> attached to the port group for the VM to handle) >>> >>> 2.) We assign VMs to port groups appropriate for the VLAN they are >>> part of. >>> 3.) The only VM that has a NIC assigned to the "TRUNK" port group is >>> the firewall (which is Linux), and we create VLAN interfaces on it >>> (i.e., "eth1.1", "eth1.2", "eth1.10", "eth1.200"). The firewall VM acts >>> as the router between the various VLANs. >>> >>> To replicate the above in oVirt, I created logical networks for each >>> VLAN, and assigned the appropriate VLAN ID. It seems oVirt/KVM does not >>> have an equivalent for VMware's VLAN ID of "4095", so after some >>> searching around, so for the "TRUNK" network, I left it with no VLAN >>> assigned. Because i cannot add VLAN and non-VLAN networks to the same >>> physical NIC, after some searching around, it looks like I may have to >>> utilise two NICS: one for the VLAN networks and one for the "TRUNK" network. >> That is true. One non-VLAN network can in fact sit on the same NIC with >> VLAN networks, but it has to be non-VM. > This was devised as a security constraint - otherwise, a VM attached to > the non-VLAN network could sniff traffic from another (VLAN) network. > However, it seems that this is exactly what you need - a special VM that > is designed to do just that. > > And it's not only you: there's another recent request for lifting this > limitation: > Bug 1049476 - [RFE] Mix untagged and tagged Logical Networks on the > same NIC > >> However, I'm not sure that you in fact need a "TRUNK" VM network in >> oVirt. If you want your firewall VM to get all traffic from the VLANs, >> you could create a vNIC for each network, to which you'll attach a >> profile (oVirt's equivalent of port group if I'm not mistaken) of the >> corresponding network. The host can remain with just the VLAN networks >> attached to its NICs, without a designated "TRUNK". >> >> This way the firewall VM will get something like "eth1" for VLAN 1, >> "eth2" for VLAN 200 and so forth, which might be close enough to what >> you described on your previous setup (oVirt currently doesn't allow >> creating VLANs inside VMs). And if I correctly understood your needs it >> will save you the trouble you described below (well, you would need the >> one dummy interface). >> >>> Because, at this point, I am not yet concerned with making the test VMs >>> I will be setting up be accessible from outside the virtual lab >>> environment (i.e., everything will communicate within my oVirt >>> server/network for now), I am trying to make use of "dummy" interfaces, >>> but I am not sure the best way to make use of this. I am able to create >>> the dummy* interfaces and have them show up in oVirt, but I am not sure >>> of how they should be setup. Here is what I am *thinking* should be >>> done, but want to make sure it is correct before getting too deep: >>> >>> - I will use the physical NIC for management, therefore the >>> "ovirtmgmt" bridge with eth0 assigned to it will remain as-is >>> - Create two dummy interfaces: "dummy0" and "dummy1" >>> - Create a new bridge, "ovirtvm" and assign "dummy0" and "dummy1" to it >> This is something that currently can't be done from within the oVirt >> engine, but if my above suggestion works for you then it won't be needed. >> >>> - Attach the VLAN-enabled networks to "dummy0" >>> - Attach the "TRUNK" network to "dummy1" > I do not understand what you are trying to do with dummy devices (after > all, they are not going to send any packet anywhere). > > But if you are willing to mess with network configuration under the feet > of oVirt, you could do the following: > - create a network tagged with an id that is not really used in your > datacenter, say 999, and attach it to the host. > - build and install vdsm-hook-extnet rpm > - define a vnic profile using this network, and adding a custom propery > called "extnet" with the value of (say) "untagged". > - set up a bridge named "untagged" directly on top of your eth0 (say > "breth0") > - define a libvirt bridged network named "untagged", that uses "breth0". > - attach the vnic of your firewall VM to your vnic profile. > > Now, when you start up your firewall vm, the "extnet" hook gets into > action, and forces the firewall vm from the 999 network, into using your > hand-crafted network. > > This all sounds a bit long and hacky, but I believe it would work. I'll > love to hear if it does. > >>> Would the above be the way to go about this? The one thing I am not >>> sure of is whether or not having no VLAN assigned (on the "TRUNK" >>> network) accomplishes the same this as the "VLAN ID 4095" in VMware: >>> will oVirt/KVM just pass the traffic through for the VM attached to it >>> to deal with? > Yes. Untagged network passes all ethernet frames to the VM, be them > tagged or not. Inside the VM you can further process them (It's less > clear to me how you intend to do the processing, and how would the > firewall would block offensive traffic from reaching "normal" VMs). > _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users