Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1474823

Summary: [RFE] Require a feature similar to private VLAN for instance ports / admin security groups
Product: Red Hat OpenStack Reporter: Andrew Ludwar <aludwar>
Component: openstack-neutronAssignee: OSP Team <rhos-maint>
Status: CLOSED WONTFIX QA Contact: Toni Freger <tfreger>
Severity: medium Docs Contact:
Priority: medium    
Version: 10.0 (Newton)CC: dhill, dholler, gprocunier, mtomaska, nyechiel, srevivo, vkoul
Target Milestone: ---Keywords: FutureFeature, Reopened
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1752343 (view as bug list) Environment:
Last Closed: 2023-10-11 19:20:01 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:    
Bug Blocks: 1752343    

Description Andrew Ludwar 2017-07-25 13:13:29 UTC
1. Proposed title of this feature request

Require a feature similar to private VLAN for instance ports.


2. Who is the customer behind the request?


Account: Telus
Account #: 5649866

TAM customer: yes
SRM customer: no
Strategic: yes


3. What is the nature and description of the request?

We require the ability to restrict the range of an ARP broadcast on provider networks, whether they be VLAN, Flat, or VXLAN based.  

Currently, if two instances are on the same network and one sends an ARP request, it is visible to the other instance.  Port security doesn't (seem to) provide a mechanism to block this.  

Private VLANs are not implemented in neutron/OVS, and wouldn't be a viable solution for non-VLAN based networks anyhow.  They do, however, provide the same functionality we desire.


4. Why does the customer need this? (List the business requirements here)

This is a security request to isolate hosts sharing the same network, forcing upstream policy via a firewall or router.


5. How would the customer like to achieve this? (List the functional requirements here)

Customer is open to interpretation of how best to implement. But customer would like the ability to filter ARP traffic on provider networks, likely in the form of traffic filtering or port grouping.


6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.

Customer or Red Hat can generate ARP traffic on each provider network type (VLAN, VXLAN, GRE, Flat), and tcpdump listen on an instance attached to a filtered/grouped port to see if the broadcast traffic reaches that private grouping.


7. Is there already an existing RFE upstream or in Red Hat Bugzilla?

There is a spec and upstream change for isolated network, but they've both been abandoned in 2013.

https://blueprints.launchpad.net/neutron/+spec/isolated-network
https://review.openstack.org/#/q/topic:bp/isolated-network,n,z


8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?

As soon as possible.


9. Is the sales team involved in this request and do they have any additional input?

Not at this time.


10. List any affected packages or components.

OSP10, and/or future versions.


11. Would the customer be able to assist in testing this functionality if implemented?

Yes.

Comment 1 Nir Yechiel 2018-03-18 00:22:47 UTC
I don't see enough demand for such a feature and realistically this is not going to be implemented by Red Hat any time soon. Please re-open if you think otherwise.

Comment 4 Assaf Muller 2019-09-17 11:46:43 UTC
*** Bug 1752343 has been marked as a duplicate of this bug. ***

Comment 7 Greg Procunier 2019-09-18 06:03:20 UTC
We are interested in configuring a shared services L2 network used by manila to prevent cross tenant backdoors (In OSP13 and onwards).


Eg.

               Manila-NFS-VIP
               192.168.103.4
                     |          
              SharedNFS Network
              (192.168.103.4/24)
             /                 \
          Tenant A           Tenant B
              |                 |
        SharedNFS Port     SharedNFS Port
        192.168.103.10     192.168.103.20
              |                 |
           Instance          Instance
              |                 |
        Internal NIC       Internal NIC
        172.16.0.50        192.168.20.20

If openstack neutron/ovn supported PVLAN we could configure the uplink of the tenant nic on that network to be exclusively the Manila-NFS vip and stop any potential of backdoor access from other clients on that network.

In my diagram you can see that the storageNFS network is a shared layer 2 domain.  At no point can we assume that tenants will do the right thing with regards to security groups.

PVLAN solves this issue by preventing isolate ports from learning about each other, and the destination (in this case the NFS ganesha vip) is set in promiscuous mode.

This is a diagram of PVLAN operation from Cisco:
https://www.cisco.com/c/dam/en/us/td/i/100001-200000/180001-190000/182001-183000/182773.eps/_jcr_content/renditions/182773.jpg

This is the actual writeup by Cisco on this capability: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/6-x/layer2/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Layer_2_Switching_Configuration_Guide/b_Cisco_Nexus_9000_Series_NX-OS_Layer_2_Switching_Configuration_Guide_chapter_0101.html#con_1344155

I spoke with Tom Barron (Manila PTL) and Ryan Tidwell (Neutron Developer) and they both agreed this was a problem that PVLAN could solve.   As Symcor is looking to leverage OpenStack with Manila across a multi tenant environment we want to be able to provide high performance Layer 2 access to our StorageNFS network without the security backdoors a regular layer 2 domain creates.

Implementing PVLAN in neutron would certainly help our use of the product and also add some fairly powerful capabilty to OpenStack.