Re: [openstack-dev] [Neutron] VLAN trunking network for NFV
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 ruijing@intel.com 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:ijw.ubu...@cack.org.uk] *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 daniele.cas...@dektech.com.au 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] VLAN trunking network for NFV
Today: You need to ensure that your cloud is using a suitable networking config - with ML2, use Linuxbridge and either VXLAN or GRE. If you're using either OVS or VLAN you won't get a trunking network. A tenant can't tell this, so they can't easily tell that all or any networks are VLAN trunks without testing the network. Tomorrow (i.e. on trunk, or when Kilo is released): You can use the vlan_transparent flag on a network to explicitly request a trunk. The dataplane code hasn't changed, so the cloud will report that the network is a trunk if you're using ML2 with Linuxbridge and GRE or VXLAN, and will report you can't have a trunk if you use OVS or VLAN. This means that you are no more likely to get a trunk if you ask for one - you still need a suitable configuration - but your application will immediately know if it works or not (the old alternative was pretty much to start it and see if it works, which wasn't helpful). ML2 now has a reference implementation of this; other plugins (to the best of my knowledge) don't support the flag. When they do, then any plugin or driver can theoretically be written to behave differently if you have ask for a trunk; for instance, in the future we can change the code to program OVS differently if you want a trunk, or change ML2 to use a trunk-safe VXLAN overlay even though VLAN networks are also available in a system. No driver does this today. -- Ian. On 24 March 2015 at 17:48, Guo, Ruijing ruijing@intel.com 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:ijw.ubu...@cack.org.uk] *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 daniele.cas...@dektech.com.au 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] VLAN trunking network for NFV
- Original Message - *From:* Ian Wells [mailto: ijw.ubuntu at cack.org.uk ] *Sent:* Wednesday, March 25, 2015 2:18 AM 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. 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. The linuxbridge agent does not support GRE. I tried sending tagged packets over linuxbridge+VxLAN and it did not work - I didn't look into it any further. This was a strong premise of the spec when it was under discussion, that we at least some part of the reference implementation (LB + VXLAN was cited) that works. If it doesn't, I think it's problematic to introduce new API without a reference implementation. I also tried over linuxbridge+FLAT - this works when the physical switch ports are trunks - they would need to permit all VLAN ids to be fully VLAN transparent. I think linuxbridge+VLAN would work too, as along as the switch ports are also configured for Q-in-Q. Currently the linuxbridge mechanism driver cannot know if a Neutron network is VLAN transparent or not. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] VLAN trunking network for NFV
*From:* Ian Wells [mailto:ijw.ubuntu at cack.org.uk] *Sent:* Wednesday, March 25, 2015 2:18 AM 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. 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.The linuxbridge agent does not support GRE.I tried sending tagged packets over linuxbridge+VxLAN and it did not work - I didn't look into it any further.I also tried over linuxbridge+FLAT - this works when the physical switch ports are trunks - they would need to permit all VLAN ids to be fully VLAN transparent. I think linuxbridge+VLAN would work too, as along as the switch ports are also configured for Q-in-Q.Currently the linuxbridge mechanism driver cannot know if a Neutron network is VLAN transparent or not. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] VLAN trunking network for NFV
On 24 March 2015 at 11:45, Armando M. arma...@gmail.com wrote: This may be besides the point, but I really clash with the idea that we provide a reference implementation on something we don't have CI for... Aside from the unit testing, it is going to get a test for the case we can test - when using the standard config networking that Tempest runs with, does it return the right answer? That's pretty much the level of commitment that the entire test suite gives. Beyond that, it is about as well tested by the upstream testing as the ML2 plugin (which, in the main tests, is tested in one config only) and more well tested than the LB driver (I don't eisn't touched by the system tests but is still in-tree). I'm not out to make the test coverage any worse, and I apologise that we can't test this when it's returning a positive result, but the system tests do have limitations in this regard. That said, I'd love to put a positive test in the system tests if only we can work out how to do one - suggestions welcome... -- Ian. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] VLAN trunking network for NFV
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:ijw.ubu...@cack.org.uk] 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 daniele.cas...@dektech.com.aumailto:daniele.cas...@dektech.com.au 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] VLAN trunking network for NFV
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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] VLAN trunking network for NFV
From spec [1], I read: - Of the core drivers, the VLAN and OVS drivers will be marked as not supporting VLAN transparent networks and the LB, VXLAN and GRE drivers will be marked as supporting VLAN transparent networks. Other drivers will have legacy behaviour. I can't seem to find in the code where this is implemented though. Can you elaborate? This may be besides the point, but I really clash with the idea that we provide a reference implementation on something we don't have CI for...for that reason, I am starting to become really wary of the shape this has been merged in. Let's hope we tie the appropriate loose ends in the next couple of days, otherwise we're left with no other option than pulling this out of Kilo. A [1] http://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html On 24 March 2015 at 11:17, Ian Wells ijw.ubu...@cack.org.uk wrote: 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 daniele.cas...@dektech.com.au 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: openstack-dev-requ...@lists.openstack.org?subject: unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 daniele.cas...@dektech.com.au 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
