Bug 1658390 - [RFE] Limit VXLAN to within Neutron availability zones
Summary: [RFE] Limit VXLAN to within Neutron availability zones
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 15.0 (Stein)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: OSP Team
QA Contact: Eran Kuris
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-11 23:02 UTC by Dan Sneddon
Modified: 2022-06-20 12:24 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-06-20 12:24:17 UTC
Target Upstream Version:
Embargoed:
bhaley: needinfo-


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1808062 0 None None None 2018-12-11 23:02:19 UTC
Red Hat Bugzilla 1659651 0 low CLOSED [RFE] Neutron Availability Zone support so Geneve tunnels are limited to within AZ 2023-10-20 18:22:01 UTC
Red Hat Issue Tracker OSP-2361 0 None None None 2022-03-24 13:36:33 UTC

Internal Links: 1659651

Description Dan Sneddon 2018-12-11 23:02:19 UTC
Description of problem:
Creating multiple Neutron availability zones allows the operator to schedule DHCP and L3 agents within a single AZ. Neutron will still try to form a VXLAN 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):
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:
Example: Suppose to AZs, AZ1 (control plane 10.1.1.0/24) and AZ2 (control plane 172.16.2.0/24).

Here is example output from a node in AZ1. It is forming tunnels between members of both AZs. The desired configuration would have VXLAN tunnels only formed between endpoints in the same AZ.

    Bridge br-tun
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port "vxlan-1e0094c8"
            Interface "vxlan-1e0094c8"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="10.1.1.20", out_key=flow, remote_ip="10.1.1.200"}
        Port br-tun
            Interface br-tun
                type: internal
        Port "vxlan-1e0094d6"
            Interface "vxlan-1e0094d6"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="10.1.1.20", out_key=flow, remote_ip="172.16.2.214"}
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}

Comment 2 Dan Sneddon 2018-12-13 19:32:29 UTC
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.


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