[Users] Networking questions (LONG)

[Juan Pablo Lorier]

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