Bug 1672431 - [RFE] Limit Tunnels to within Neutron availability zones
Summary: [RFE] Limit Tunnels to within Neutron availability zones
Keywords:
Status: CLOSED DUPLICATE of bug 1659651
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-networking-ovn
Version: 15.0 (Stein)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Assaf Muller
QA Contact: Eran Kuris
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-04 22:21 UTC by Dan Sneddon
Modified: 2019-09-09 14:31 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-04 22:47:07 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1808594 0 None None None 2019-02-04 22:21:44 UTC
Red Hat Bugzilla 1659651 0 low NEW [RFE] Neutron Availability Zone support so Geneve tunnels are limited to within AZ 2023-07-25 13:13:43 UTC

Description Dan Sneddon 2019-02-04 22:21:44 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.

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

How reproducible:
100%

Steps to Reproduce:
1. Deploy overcloud with 2+ Neutron Availability Zones
2. Create network(s)

Actual results:
Compute nodes will form tunnels between all nodes, even if those nodes are in a different Neutron AZ, even if they are in different sites.

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.

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.

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

This feature would be very useful for some edge computing topologies, as well as for deployments with different security zones. For edge sites that do not need East/West traffic between edge sites (only between the edge and central sites), having these tunnels between sites will add unnecessary inter-site traffic, and will potentially open up cross-site security issues. 

The overall feature request needs a spec. Please see the upstream bug for discussion of implementation ideas.


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