Bug 1049476

Summary:	[RFE] Mix untagged and tagged Logical Networks on the same NIC
Product:	[oVirt] vdsm	Reporter:	Juan Pablo Lorier <jplorier>
Component:	RFEs	Assignee:	Ido Barkan <ibarkan>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Meni Yakove <myakove>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	---	CC:	bazulay, bugs, danken, ibarkan, iheim, jplorier, mburman, mgoldboi, myakove, nyechiel, rbalakri, s.kieske, yeylon, ylavi
Target Milestone:	ovirt-3.6.0-rc	Keywords:	FutureFeature
Target Release:	---	Flags:	rule-engine: ovirt-3.6.0+ ylavi: planning_ack+ rule-engine: devel_ack+ rule-engine: testing_ack+
Hardware:	Unspecified
OS:	Linux
Whiteboard:	network
Fixed In Version:	3.6.0-11	Doc Type:	Enhancement
Doc Text:	Feature: Network Reason: Needed to adapt to network topology Result (if any):	Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-11-27 07:52:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Network	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	668847, 1227865

Description Juan Pablo Lorier 2014-01-07 15:36:08 UTC

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.

Comment 2 Nir Yechiel 2014-02-05 09:34:41 UTC

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

Comment 3 Ido Barkan 2014-10-29 13:17:48 UTC

the related patch (http://gerrit.ovirt.org/#/c/34538/) removes option #3 above from vdsm side. No specific manual Engine configuration needed.

Comment 4 Juan Pablo Lorier 2014-10-31 12:42:39 UTC

Hi Ido,

I didn't get your post. You mean that because of that path, now vdsm does allow mixing tags?
Regards

Comment 5 Ido Barkan 2014-11-02 20:10:38 UTC

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

Comment 6 Ido Barkan 2015-01-21 13:02:09 UTC

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.

Comment 7 Michael Burman 2015-08-23 07:52:54 UTC

If it going to be released on 4.0 please remove the ON_QA

Comment 8 Sven Kieske 2015-08-25 09:40:03 UTC

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

Comment 9 Red Hat Bugzilla Rules Engine 2015-10-18 08:34:46 UTC

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.

Comment 10 Red Hat Bugzilla Rules Engine 2015-11-02 12:27:15 UTC

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.

Comment 11 Sandro Bonazzola 2015-11-04 14:43:49 UTC

This issue should be fixed in oVirt 3.6.0 released on November 4th 2015 but still need to be checked by QE

Comment 12 Michael Burman 2015-11-04 15:16:17 UTC

Verified on - 3.6.0.3-0.1.el6 and vdsm-4.17.10.1-0.el7ev.noarch

Comment 13 Sandro Bonazzola 2015-11-27 07:52:55 UTC

Since oVirt 3.6.0 has been released, moving from verified to closed current release.