[RFE] Add a 'promiscuous mode' extension for ports

[shihanzhang]

Now the VM's VNIC with neutron port is in a promiscuous mode, sometimes it will affect the application performance if there are too many traffic, some hypervisor like Huawei FusionSphere and VMware have the ability to set VNIC promiscuous mode. In Neutron, the NSX plugin already had a extension (mac learning)[1], so this proposal will add a new extension for port promiscuous mode, it is like port_security extension.

[1]https://github.com/openstack/vmware-nsx/blob/master/vmware_nsx/extensions/maclearning.py

[Armando Migliaccio (armando-migliaccio)]

I am not sure I fully grasp the use case being requested. Why would you associate promiscuous mode and QoS together? I don't see the relationship.

[Miguel Angel Ajo (mangelajo)]

I agree with Armando here,

I understand the issue of setting a port as promiscuous (that's a quality/low level setting of the port), in that case, your VM will get a lot of extra traffic, eventually overwhelming of the CPU.

I understand VM-ingress bandwidth limit could mitigate that (although at the expense of loosing packets).

But I don't believe QoS is related with the control of port promiscuity, or shall be aware of such setting in any way.

Also, the QoS framework does not offer yet any VM-ingress traffic bandwidth limiting (only egress), that's planned and will be done eventually.

This RFE could fit a bit better within the ml2 extension framework (see port security extension), once you had such setting for a port, you then could do it in two steps:

1) set port promiscuity ON
2) set an vm-ingress bandwidth limit on the port.

[shihanzhang (shihanzhang)]

hi ajo, your understanding are exactly right, I think carefully and agree with you, it is not related with Qos, your suggestion is very good, we can do it as port security extension. thanks very much for your comments!

[Armando Migliaccio (armando-migliaccio)]

From an API standpoint this would be simply a flag to mark a port in promiscuous mode. The nsx plugin had a similar extension (mac learning), do you have a sense of how this would work with the ovs agent and what the implications are in relation to security groups and the port security extension?

[1] https://github.com/openstack/vmware-nsx/blob/master/vmware_nsx/extensions/maclearning.py

[Armando Migliaccio (armando-migliaccio)]

No reply since last solicitation.

[Launchpad Janitor (janitor)]

[Expired for neutron because there has been no activity for 60 days.]

[shihanzhang (shihanzhang)]

hi armando, I'm sorry for late reply. Firstly thanks for your comment, you are right, enable/disable 'promiscuous mode' for instance VNIC is usefull, especially for NFV, NSX plugin and our production already have a private extension, so I want to make it to be a common extension in neutron API, for your question:
1.what the implications are in relation to security groups and the port security extension
  - 'promiscuous' mode for neutron port just affects the ingress traffic, security group rule take action on the traffic which destination is this port's IP, so from security perspective, 'promiscuous' mode is enhancements for security group.

2. how this would work with the ovs agent
 - for the implementation on ovs agent, there are two proposal: a. change the pipline of br-int, add a new to ovs table to handle the traffic based on dl_dst. b. add a new ovs bridge like vlan-trunk, then filter the traffic on the new bridge. which proposal is adopted depend on ohters feedback.

I hope this features can be land at Ocata release, do you agree to change this RFE to new status and discuss it at next driver meeting?

[Kevin Benton (kevinbenton)]

I'm not sure I understand what traffic is being flooded to the VM that doesn't belong there, can you elaborate on that? Specifically, it seems like you are implying that the VM is receiving traffic directed to another VM. If that's the case, that's just a bug and it's something we should fix without an API change.

If you're talking about the VM just receiving multicast/broadcast traffic, that's not the same thing as promiscuous mode, that's just normal behavior.

Please elaborate.

[shihanzhang (shihanzhang)]

hi kevin, thanks for your comments. for a switch, it will food the unknown traffic if it failed to lookup it's fdb, so the VM will receive many traffic which destination MAC does not belong to it, for a no-promiscuous NIC, it should just receive all the multicast/broadcast traffic and which destination MAC belongs to it.

[Armando Migliaccio (armando-migliaccio)]

This seems like a nice carrier-grade enabler feature, we should look into it.

[Armando Migliaccio (armando-migliaccio)]

Please provide more details in the form a neutron spec.

[Armando Migliaccio (armando-migliaccio)]

One week without feedback. Let's wait to see if the author comes back, otherwise we'll have to recycle.

[zhaobo (zhaobo6)]

spec: https://review.openstack.org/#/c/445771/
we can discuss in that spec.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Slawek Kaplonski (<email address hidden>) on branch: master
Review: https://review.opendev.org/445771
Reason: According to what we agreed during Shanghai PTG, I abandon this patch for now due to no activity. If You would be interested in continue work on this, feel free to restore the patch.