Bug 1846019 - [RFE] Support for vlan transparency
Summary: [RFE] Support for vlan transparency
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-networking-ovn
Version: 16.1 (Train)
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: z4
: 16.1 (Train on RHEL 8.2)
Assignee: Slawek Kaplonski
QA Contact: Eduardo Olivares
URL:
Whiteboard:
: 1843935 1898082 (view as bug list)
Depends On: 1846018 1904141 1907779 1914388 1914816 1990872 1991998
Blocks: 1843935 1922497
TreeView+ depends on / blocked
 
Reported: 2020-06-10 15:21 UTC by Slawek Kaplonski
Modified: 2023-09-15 01:29 UTC (History)
19 users (show)

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.
Clone Of:
Environment:
Last Closed: 2021-03-17 15:30:39 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OSP-4171 0 None None None 2022-08-17 15:19:38 UTC
Red Hat Product Errata RHBA-2021:0817 0 None None None 2021-03-17 15:37:48 UTC

Description Slawek Kaplonski 2020-06-10 15:21:03 UTC
When https://bugzilla.redhat.com/show_bug.cgi?id=1846018 will be done we would need to add support for vlan transparency in neutron ovn driver.

Comment 1 Daniel Alvarez Sanchez 2020-11-05 14:12:05 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."

Comment 2 Eduardo Olivares 2020-11-18 11:32:14 UTC
*** Bug 1898082 has been marked as a duplicate of this bug. ***

Comment 25 Anita Tragler 2021-01-30 12:46:00 UTC
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.

Comment 26 Jakub Libosvar 2021-02-10 10:23:31 UTC
*** Bug 1843935 has been marked as a duplicate of this bug. ***

Comment 41 errata-xmlrpc 2021-03-17 15:30:39 UTC
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

Comment 42 errata-xmlrpc 2021-03-17 15:37:33 UTC
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

Comment 43 Red Hat Bugzilla 2023-09-15 01:29:52 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days


Note You need to log in before you can comment on or make changes to this bug.