Bug 1846019
Summary: | [RFE] Support for vlan transparency | ||
---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Slawek Kaplonski <skaplons> |
Component: | python-networking-ovn | Assignee: | Slawek Kaplonski <skaplons> |
Status: | CLOSED ERRATA | QA Contact: | Eduardo Olivares <eolivare> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 16.1 (Train) | CC: | apevec, astupnik, atragler, dalvarez, egarver, ekuris, eolivare, fleitner, ihrachys, jamsmith, jlibosva, lhh, majopela, nsatsia, peli, scohen, spower, sputhenp, vkoul |
Target Milestone: | z4 | Keywords: | FutureFeature, Triaged |
Target Release: | 16.1 (Train on RHEL 8.2) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | python-networking-ovn-7.3.1-1.20201114024043.el8ost | Doc Type: | Enhancement |
Doc Text: |
This enhancement adds support for vlan transparency in the ML2/OVN mechanism driver with vlan and geneve network type drivers.
+
With vlan transparency, you can manage vlan tags by using instances on Networking (neutron) service networks. You can create vlan interfaces on an instance and use any vlan tag without affecting other networks. The Networking service is not aware of these vlan tags.
+
NOTE:
* When using vlan transparency on a vlan type network, the inner and outer ethertype of the packets is 802.1Q (0x8100).
* The ML2/OVN mechanism driver does not support vlan transparency on flat provider networks. For more information, see https://bugzilla.redhat.com/show_bug.cgi?id=1916334.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2021-03-17 15:30:39 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1846018, 1904141, 1907779, 1914388, 1914816, 1990872, 1991998 | ||
Bug Blocks: | 1843935, 1922497 |
Description
Slawek Kaplonski
2020-06-10 15:21:03 UTC
Just to be clear, this feature is mutually exclusive with trunk/subports as it can be seen in the upstream doc: https://docs.openstack.org/neutron/latest/contributor/internals/openvswitch_agent.html#tackling-the-network-trunking-use-case "VLAN transparency is for better or for worse intertwined with vlan awareness. The former is about making the platform not interfere with the tag associated to the packets sent by the VM, and let the underlay figure out where the packet needs to be sent out; the latter is about making the platform use the vlan tag associated to packet to determine where the packet needs to go. Ideally, a design choice to satisfy the awareness use case will not have a negative impact for solving the transparency use case. Having said that, the two features are still meant to be mutually exclusive in their application, and plugging subports into networks whose vlan-transparency flag is set to True might have unexpected results. In fact, it would be impossible from the platform’s point of view discerning which tagged packets are meant to be treated ‘transparently’ and which ones are meant to be used for demultiplexing (in order to reach the right destination). The outcome might only be predictable if two layers of vlan tags are stacked up together, making guest support even more crucial for the combined use case." *** Bug 1898082 has been marked as a duplicate of this bug. *** Known limitations for OVN VLAN transparency Not supported with ML2/OVS this is an ONV only feature Bug 1914816 - [OVS 2.13 RFE] VLAN Transparency: packets dropped with flat provider network Bug 1907779 - VLAN Transparency: packets dropped with flat provider network Bug 1904141 - VLAN Transparency: packets dropped when allowed-address-pairs used with vlan tenant and provider networks (need to disable port security ) Bug 1914388 - VLAN Transparency: neutron network mtu should be 4 bytes lower for transparent-vlan network When using provider VLANs external switch needs to support 802.1q VLAN stacking using ethertype 0x8100 on both VLANs. OVN VLAN transparency does not support 802.1ad QinQ with outer provider VLAN ethertype set to 0x88A8 or 0x9100. *** Bug 1843935 has been marked as a duplicate of this bug. *** Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Red Hat OpenStack Platform 16.1.4 director bug fix advisory), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:0817 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Red Hat OpenStack Platform 16.1.4 director bug fix advisory), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:0817 The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days |