Bug 1167496

The problem are the unconditional egress_rules which are added
to every port here:

_add_fixed_egress_rules
https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L362


_drop_dhcp_rule:

https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L277


I suppose the idea is enforcing those rules, even if this was set on security groups instead and the tenant removed it (in the context of shared networks with other tenants).

May be an option could be to disable this by a flag, on specific ports by admin or completely when the port is not connected to a shared network (then the tenant can be responsible of his own security groups).

Adding a link to the u/s spec for implementing this.
The spec is approved for Kilo and is not available as part of the Juno release(which is the release OSP-6 is based on).

Terry - can you please take a look what is the status os this feature. Is it available in Kilo?

*** Bug 1109456 has been marked as a duplicate of this bug. ***

This feature has been committed upstream Neutron. python-neutronclient does not appear to have been updated to allow port_security_enabled=False to be passed during network/port creates/updates.

(In reply to Terry Wilson from comment #9)
> This feature has been committed upstream Neutron. python-neutronclient does
> not appear to have been updated to allow port_security_enabled=False to be
> passed during network/port creates/updates.

Terry can you submit the patch to neutronclient to enable this?

> Terry can you submit the patch to neutronclient to enable this?

lpeer: Something must have been messed up with my setup, because after researching how to add this, it seems to already be working now.

[vagrant@localhost devstack]$ neutron net-create --port-security-enabled=False mynet
Created a new network:
+---------------------------+--------------------------------------+
| Field                     | Value                                |
+---------------------------+--------------------------------------+
| admin_state_up            | True                                 |
| id                        | 008fa245-34a3-4c2e-81aa-2912060071bc |
| mtu                       | 0                                    |
| name                      | mynet                                |
| port_security_enabled     | False                                |<--
| provider:network_type     | vxlan                                |
| provider:physical_network |                                      |
| provider:segmentation_id  | 1003                                 |
| router:external           | False                                |
| shared                    | False                                |
| status                    | ACTIVE                               |
| subnets                   |                                      |
| tenant_id                 | f7c2ea32db8f46c48c10bca7c5ed3211     |
| vlan_transparent          | False                                |
+---------------------------+--------------------------------------+


Tested with net/port create/update and all seem to work.

Terry ,  I finished to write the test plan and I attached it to "External Trackers". Please take a look and tell me if you have any comments .

Eran: There appear to be 3 test cases. Am I reviewing all 3 or just one of them?

The user member role stuff still mentions creating user roles, since 'network creator' is based on the tenant, and doesn't have anything to do with user roles this test will always fail. I see a note in one of the test cases, but not the others--so those probably need updating/that section could be deleted or changed to specify testing on 'public' shared networks and different tenants.

As far as the mac spoofing stuff goes, I may not be qualified to comment as I haven't ever tried spoofing a mac address on a VM before today. I've gone through an abbreviated version of the test with devstack, just launching two VMs on the same host with the default settings and logging in and following the instructions to spoof the mac address on VM1. VM1 is still able to ssh to VM2, even though port security is enabled. So I'm not sure the given test is sufficient to test the port security feature.

Test performed:
1) Standard devstack single network basic setup: https://wiki.openstack.org/wiki/NeutronDevstack
2) nova boot --image cirros-0.3.4-x86_64-uec --flavor 1 --nic net-id=$(neutron net-show -F id -f value private) --num-instances=2 test
3) nova get-vnc-console test1 novnc
4) Through console, test connectivity to VM2  # SUCCESS
5) Through console, complete step 11 for mac spoofing: https://tcms.engineering.redhat.com/case/478418/  # SSH still successful

If I'm misunderstanding something/doing something wrong and you get a negative result w/o setting port-security-enabled=False, go for it. If not, we'll have to figure something else out.

Hi Terry . 
You need to review all 3 test cases. 
In my ENV I tested spoof mac address scenario and it worked as well 
I don't really understand what's the difference between what I did and what you ran. I will run the test again to verify it again .

Tested on Kilo 7.0-RHEL-7-Beta/2015-05-28.1 

https://tcms.engineering.redhat.com/run/248627/

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2015:1548