Guo, AFAIU, the guest will tag frames with VLAN, then the host won't remove this tag ASA the underlying host uses an overlay encapsulation (VXLAN or GRE) to encapsulate the entire frame, including the VLAN submitted by the guest. This will be only compatible with LinuxBridge running on the host, since OVS overwrites VLAN tags with its own VLAN tags to isolate traffic of one network on a host. Linuxbridge isolate the traffic by dedicating a bridge per network.
However I'm not sure that the compatibility matrix proposed in the spec is accurate since LB doesn't seem to support GRE encapsulation. The question raised in this thread is more about how the Linuxbridge implementation in Neutron can evolve. It is currently not tested by the CI, is it? Does it mean that evolution of this kind of implementation should be blocked? The next step of the spin out of drivers might move LB and OVS MD out of Neutron tree. Will there be any volunteer to support the LinuxBridge implementation? If not, does it mean that LB implementation will be deprecated? On Wed, Mar 25, 2015 at 1:48 AM, Guo, Ruijing <[email protected]> wrote: > I am trying to understand how guest os use trunking network. > > > > If guest os use bridge like Linuxbride and OVS, how we launch it and how > libvirt to support it? > > > > Thanks, > > -Ruijing > > > > > > *From:* Ian Wells [mailto:[email protected]] > *Sent:* Wednesday, March 25, 2015 2:18 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron] VLAN trunking network for NFV > > > > That spec ensures that you can tell what the plugin is doing. You can ask > for a VLAN transparent network, but the cloud may tell you it can't make > one. > > The OVS driver in Openstack drops VLAN tagged packets, I'm afraid, and the > spec you're referring to doesn't change that. The spec does ensure that if > you try and create a VLAN trunk on a cloud that uses the OVS driver, you'll > be told you can't. in the future, the OVS driver can be fixed, but that's > how things stand at present. Fixing the OVS driver really involves getting > in at the OVS flow level - can be done, but we started with the basics. > > If you want to use a VLAN trunk using the current code, I recommend VXLAN > or GRE along with the Linuxbridge driver, both of which support VLAN > transparent networking. If they're configured and you ask for a VLAN trunk > you'll be told you got one. > -- > > Ian. > > > > > > On 24 March 2015 at 09:43, Daniele Casini <[email protected]> > wrote: > > Hi all: > > in reference to the following specification about the creation of VLAN > trunking network for NFV > > https://review.openstack.org/#/c/136554/3/specs/kilo/nfv-vlan-trunks.rst > > I would like to better understand how the tagged traffic will be realized. > In order to explain myself, I report the following use case: > > A VNF is deployed in one VM, which has a trunk port carrying traffic for > two VLANs over a single link able to transport more than one VLAN through a > single integration-bridge (br-int) port. So, How does br-int manage the > VLAN-ID? In other words, what are the action performed by the br-int when a > VM forwards traffic to another host? > Does it put an additional tag or replace the existing one keeping the > match with a table or something like that? > > Thank you very much. > > Daniele > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
