Race condition adding a security group rule when another is in-progress
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Security Advisory |
Won't Fix
|
Undecided
|
Unassigned | ||
neutron |
Fix Released
|
High
|
Brian Haley | ||
Icehouse |
Fix Released
|
Undecided
|
Unassigned | ||
Juno |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
I've come across a race condition where I sometimes see a security group rule is never added to iptables, if the OVS agent is in the middle of applying another security group rule when the RPC arrives.
Here's an example scenario:
nova boot --flavor 1 --image $nova_image dev_server1
sleep 4
neutron security-
neutron security-
Wait for VM to complete booting, then check iptables:
$ sudo iptables-save | grep 111
-A neutron-
The second rule is missing, and will only get added if you either add another rule, or restart the agent.
My config is just devstack, running with the latest openstack bits as of today. OVS agent w/vxlan and DVR enabled, nothing fancy.
I've been able to track this down to the following code (i'll attach the complete log as a file due to line wraps):
OVS agent receives RPC to setup port
Port info is gathered for devices and filters for security groups are created
Iptables "apply" is called
New security group rule is added, triggering RPC message
RPC received, and agent seems to add device to list that needs refresh
Adding [u'741ff910-
Iptables "apply" is finished
rpc_loop() in OVS agent does not notice there is more work to do on next loop, so rule never gets added
At this point I'm thinking it could be that self.devices_
I will continue to investigate, but if someone has an "aha!" moment after reading this far please add a note.
A colleague here has also been able to duplicate this on his own devstack install, so it wasn't my fat-fingering that caused it.
Changed in neutron: | |
assignee: | nobody → Brian Haley (brian-haley) |
tags: | added: sg-fw |
Changed in neutron: | |
importance: | Undecided → High |
status: | New → Confirmed |
Changed in neutron: | |
milestone: | none → kilo-1 |
tags: | added: juno-backport-potential |
Changed in neutron: | |
status: | Fix Committed → Fix Released |
Changed in ossa: | |
status: | New → Incomplete |
information type: | Public → Public Security |
Changed in neutron: | |
milestone: | kilo-1 → 2015.1.0 |
Just a follow-up as to what happens when you add another SG rule, the orphaned one does get added:
$ sudo iptables-save | grep 111 openvswi- i741ff910- 1 -p tcp -m tcp --dport 1111 -j RETURN
-A neutron-
$ neutron security- group-rule- create --direction ingress --protocol tcp --port_range_min 1113 --port_range_max 1113 default
$ sudo iptables-save | grep 111 openvswi- i741ff910- 1 -p tcp -m tcp --dport 1111 -j RETURN openvswi- i741ff910- 1 -p tcp -m tcp --dport 1113 -j RETURN openvswi- i741ff910- 1 -p tcp -m tcp --dport 1112 -j RETURN
-A neutron-
-A neutron-
-A neutron-