Description of problem: can't assign logical netwoks with tagged vlan and wit untagged on the same interface Version-Release number of selected component (if applicable): How reproducible: Try to coexist the two types of logical networks Steps to Reproduce: 1.Create a tagged logical network 2. Creat an untagged logical network 3.Try to attach both to the same interface on a host Actual results: Not allowed Expected results: Should be able. Additional info: So easy on every other platform (xen, vmware, proxmox, etc) Other bugs on this matter are long closed with claims that it's included in 3.2 or stuck without aparent attention.
With the current bridge implementation, all frames are exposed to the untagged network. As of today: 1. Different tagged VM networks on the same pNIC – supported and properly isolated 2. Different tagged VM networks + (one) untagged mgmt non-VM network – supported (yet the mgmt network can still capture all tagged VM traffic) 3. Different tagged VM networks + untagged VM network – unsupported. This option is blocked for proper security/isolation between VM networks Our prefered solution for that is: - Leave the default as is, but make option #3 above supported through an explicit manual Engine configuration change - so only users who want this will get it - Update the documentation and include a proper explanation/warning. The configuration will be supported, but the user should understand the security implications
the related patch (http://gerrit.ovirt.org/#/c/34538/) removes option #3 above from vdsm side. No specific manual Engine configuration needed.
Hi Ido, I didn't get your post. You mean that because of that path, now vdsm does allow mixing tags? Regards
Juan, correct. Vdsm now allows multiple tagged and untagged networks on the same interface given there are no two networks with the same vlan tag and there are no two untagged networks on the same interface at the same time. Ido
After some more research we have come to a conclusion that mixing tagged and untagged networks on a physical NIC does not expose a security issue. For refreshing the memory, the discussed topology is as such (inside the hypervisor): VM1 VM (guest) eth0| |eth1 ___/ ___/ | | bridge0 bridge1 | | | / vlan162 / \ / \ / | eth0 (physical NIC on the host) * eth0 is connected to vlan162 Since RHEL6, when tagged frames arrive at the physical NIC the VLAN devices (e.g. eth0.162) takes precedence on every other network device and so tagged packets will never be seen inside the untagged networks (e.g. bridge1). Therefore, the validation against mixing tagged and untagged networks, that was previously removed from VDSM can be safely removed from the engine.
If it going to be released on 4.0 please remove the ON_QA
(In reply to Michael Burman from comment #7) > If it going to be released on 4.0 please remove the ON_QA This has severity "high", why is the target release being pushed? Is this too much work to backport for 3.6 ?
Bug tickets that are moved to testing must have target release set to make sure tester knows what to test. Please set the correct target release before moving to ON_QA.
This issue should be fixed in oVirt 3.6.0 released on November 4th 2015 but still need to be checked by QE
Verified on - 3.6.0.3-0.1.el6 and vdsm-4.17.10.1-0.el7ev.noarch
Since oVirt 3.6.0 has been released, moving from verified to closed current release.