Bug 1659651 - [RFE] Neutron Availability Zone support so Geneve tunnels are limited to within AZ
Summary: [RFE] Neutron Availability Zone support so Geneve tunnels are limited to with...
Keywords:
Status: NEW
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-networking-ovn
Version: 17.0 (Wallaby)
Hardware: All
OS: Linux
low
medium
Target Milestone: ga
: ---
Assignee: Lucas Alvares Gomes
QA Contact: Eran Kuris
URL:
Whiteboard:
: 1672431 (view as bug list)
Depends On:
Blocks: 1702550
TreeView+ depends on / blocked
 
Reported: 2018-12-14 22:04 UTC by Dan Sneddon
Modified: 2023-07-25 13:12 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1702550 (view as bug list)
Environment:
Last Closed: 2020-11-04 19:56:29 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1808594 0 None None None 2018-12-14 22:04:25 UTC
Red Hat Bugzilla 1658390 0 unspecified CLOSED [RFE] Limit VXLAN to within Neutron availability zones 2022-06-20 12:49:18 UTC
Red Hat Issue Tracker OSP-517 0 None None None 2021-11-25 12:48:35 UTC

Internal Links: 1658390 1672431

Description Dan Sneddon 2018-12-14 22:04:26 UTC
Description of problem:
Creating multiple Neutron availability zones allows the operator to schedule DHCP and L3 agents within a single AZ. Neutron OVN will still try to form a Geneve mesh between all nodes in all availability zones, which creates inter-AZ dependencies and may not work when strict firewalls are placed between AZs. This bug is a clone of BZ 1658390, but that RFE applies to ML2/OVS and this RFE applies to OVN.

Version-Release number of selected component (if applicable):
OSP15/Stein

Actual results:
The desired end-state configuration would have separate DHCP and L3 agents hosted in each AZ, along with tunnels formed only inside the AZ. This would allow, for instance, multiple edge sites within a single deployment that each performed local networking only. Any particular Neutron network would be limited to one AZ. A new flag would allow AZs to be truly autonomous and remove cross-AZ dependencies.

Expected results:
This behavior should be configurable, so that L2 may be limited to a particular AZ, and no tunnels are formed between different AZs. This will prevent Neutron from trying to form tunnels when the tunnel cannot function, and may enhance security when AZs are in different security zones.

Additional info:
Note that it appears that NSX-T has a concept called "Transport Zones" that enables the feature that is being requested here. Compute nodes within a given transport zone will only be able to communicate with compute nodes within that same transport zone. This prevents network traffic from being sent between zones. More information here:

https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.3/com.vmware.nsxt.install.doc/GUID-F47989B2-2B9D-4214-B3BA-5DDF66A1B0E6.html

NSX-T also supports Availability Zones, but it appears that those are separate from the Transport Zone functionality:

https://docs.vmware.com/en/VMware-Integrated-OpenStack/5.0/com.vmware.openstack.admin.doc/GUID-37F0E9DE-BD19-4AB0-964C-D1D12B06345C.html

It's possible that limiting tunneling traffic to a particular AZ may be outside the intended functions of Neutron AZs, but I think this is a valid use case.

Comment 1 Dan Sneddon 2019-02-04 22:47:07 UTC
*** Bug 1672431 has been marked as a duplicate of this bug. ***

Comment 2 Dan Sneddon 2019-02-04 22:54:47 UTC
Moving this to the OVN component. If it turns out that we can implement this at a higher level in Neutron, we can reassign to the Neutron component.

See more at the upstream bug: https://bugs.launchpad.net/neutron/+bug/1808594

Comment 14 stchen 2020-11-04 19:56:29 UTC
Closing EOL, OSP 16.0 has been retired as of Oct 27, 2020

Comment 15 Brian Haley 2020-11-09 22:38:58 UTC
Re-opening targeted at 16.1


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