devstack 7533276c
neutron aa40aef70f
This reproduction uses the openvswitch ml2 mechanism_driver and firewall_driver, but I believe this bug affects all mechanism_drivers.
# Choose a port number no other rule uses on the test host.
$ sudo ovs-ofctl dump-flows br-int | egrep 1234
[nothing]
# Create two security groups.
$ openstack security group create sg1
$ openstack security group create sg2
# Create a rule in sg1 that references sg2 (as remote group).
$ openstack security group rule create sg1 --ingress --ethertype IPv4 --dst-port 1234:1234 --protocol tcp --remote-group sg2
# The API returns the new rule.
$ openstack security group rule list sg1
+--------------------------------------+-------------+-----------+-----------+------------+-----------+--------------------------------------+----------------------+
| ID | IP Protocol | Ethertype | IP Range | Port Range | Direction | Remote Security Group | Remote Address Group |
+--------------------------------------+-------------+-----------+-----------+------------+-----------+--------------------------------------+----------------------+
| 77db9548-b3ab-46ea-94a5-f00f6a4062da | None | IPv4 | 0.0.0.0/0 | | egress | None | None |
| 9b569a88-177a-4422-a0f3-6ed039e0217a | tcp | IPv4 | 0.0.0.0/0 | 1234:1234 | ingress | 7df90218-3d52-4156-9630-43563a3d5ba6 | None |
| f40d258b-4d13-4dc8-a0c4-82ccce9922e0 | None | IPv6 | ::/0 | | egress | None | None |
+--------------------------------------+-------------+-----------+-----------+------------+-----------+--------------------------------------+----------------------+
# Make sure sg1 is used on the test host.
$ openstack server create --flavor cirros256 --image cirros-0.5.2-x86_64-disk --availability-zone :devstack0 --nic net-id=private --security-group sg1 vm1 --wait
# See if the rule is implemented in the backend.
$ sudo ovs-ofctl dump-flows br-int | egrep 1234
cookie=0x33704a39bf5031d7, duration=55.263s, table=82, n_packets=0, n_bytes=0, idle_age=57, priority=73,ct_state=+est-rel-rpl,tcp,reg5=0x20,tp_dst=1234 actions=conjunction(22,2/2)
cookie=0x33704a39bf5031d7, duration=55.263s, table=82, n_packets=0, n_bytes=0, idle_age=57, priority=73,ct_state=+new-est,tcp,reg5=0x20,tp_dst=1234 actions=conjunction(23,2/2)
# Delete sg2...
$ openstack security group delete sg2
# ...by cascade also delete the rule in sg1 referencing sg2. At least in the API.
$ openstack security group rule list sg1
+--------------------------------------+-------------+-----------+-----------+------------+-----------+-----------------------+----------------------+
| ID | IP Protocol | Ethertype | IP Range | Port Range | Direction | Remote Security Group | Remote Address Group |
+--------------------------------------+-------------+-----------+-----------+------------+-----------+-----------------------+----------------------+
| 77db9548-b3ab-46ea-94a5-f00f6a4062da | None | IPv4 | 0.0.0.0/0 | | egress | None | None |
| f40d258b-4d13-4dc8-a0c4-82ccce9922e0 | None | IPv6 | ::/0 | | egress | None | None |
+--------------------------------------+-------------+-----------+-----------+------------+-----------+-----------------------+----------------------+
# But the delete is not propagated to the backend.
$ sudo ovs-ofctl dump-flows br-int | egrep 1234
cookie=0x33704a39bf5031d7, duration=112.917s, table=82, n_packets=0, n_bytes=0, idle_age=115, priority=73,ct_state=+est-rel-rpl,tcp,reg5=0x20,tp_dst=1234 actions=conjunction(22,2/2)
cookie=0x33704a39bf5031d7, duration=112.917s, table=82, n_packets=0, n_bytes=0, idle_age=115, priority=73,ct_state=+new-est,tcp,reg5=0x20,tp_dst=1234 actions=conjunction(23,2/2)
# Clean up - even the left over backend flows.
$ openstack server delete vm1 --wait
$ sudo ovs-ofctl dump-flows br-int | egrep 1234
[nothing]
$ openstack security group delete sg2
$ openstack security group delete sg1
I've tested this bug with ML2/OVS and I can confirm it. When sg2 is deleted, sg1 rules are updated but the mech driver agent does not receive this update.
However, this is not happening in ML2/OVN. When the rule using sg2 is created, if there is no other VM using this SG, no local OF rule is created. If the SG is used in a VM, it cannot be deleted. So this is affecting only ML2/OVS (and most probably ML2/LB).