Comment 7 for bug 1536028

I am able to reproduce this problem on devstack+ovn.

For the ML2+OVS+iptables firewall, the behavior is as follows:

After all SG rules are deleted (so the SG is empty), ingress/egress chains contain the following.

Some notes:
     1) DHCP (server-ip-matched -> client) traffic is allowed by default
     2) DHCP (client -> server) traffic is allowed by default
     3) DHCP spoofing by VM is prevented by default ! << this is interesting !

So, it appears DHCP rules are added no matter what - and I dont think the port-security-extension impacts that either.
(I need to verify that)

I will fix this bug and in the process bootstrap on ovn.

Chain neutron-openvswi-i8e221f95-9 (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere state RELATED,ESTABLISHED /* Direct packets associated with a known session to the RETURN chain. */
RETURN udp -- 172.17.1.2 anywhere udp spt:bootps dpt:bootpc
DROP all -- anywhere anywhere state INVALID /* Drop packets that appear related to an existing connection (e.g. TCP ACK/FIN) but do not have an entry in conntrack. */
neutron-openvswi-sg-fallback all -- anywhere anywhere /* Send unmatched traffic to the fallback chain. */

Chain neutron-openvswi-o8e221f95-9 (2 references)
target prot opt source destination
RETURN udp -- anywhere anywhere udp spt:bootpc dpt:bootps /* Allow DHCP client traffic. */
neutron-openvswi-s8e221f95-9 all -- anywhere anywhere
DROP udp -- anywhere anywhere udp spt:bootps dpt:bootpc /* Prevent DHCP Spoofing by VM. */
RETURN all -- anywhere anywhere state RELATED,ESTABLISHED /* Direct packets associated with a known session to the RETURN chain. */
DROP all -- anywhere anywhere state INVALID /* Drop packets that appear related to an existing connection (e.g. TCP ACK/FIN) but do not have an entry in conntrack. */
neutron-openvswi-sg-fallback all -- anywhere anywhere /* Send unmatched traffic to the fallback chain. */