Public bug reported:
When using the remote security group feature for SG rules, there are
certain cases in which the IPSet entries on the Hosts are not updated
properly.
Let's say we have two ports, respectively assigned with security groups
A and B:
If we add a rule in A saying "allow TCP from B", everything works as expected
(IPTable is updated, and IPSet created with the proper member).
However, once we *disassociate* B from the port, the update is not correctly
received/consumed by the Agent, and the IPSet previously created is not
updated! This will cause traffic to keep flowing even though it should be
disallowed.
If now we were to *associate* a new port to security group B, the IPSet
would still be unchanged and this new port wouldn't be able to send
traffic to A.
The root cause of the issue seems to be the way we notify agents when a
port is added or removed from a Security Group. Today, it seems like
only the agent that "owns" the port gets notified while the "related"
agents should be too, so that they can update their IPSet properly. This
happens independently whether the whole scenario exists in a single node
or not.
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1455630
Title:
remote security group membership not updated properly
Status in OpenStack Neutron (virtual network service):
New
Bug description:
When using the remote security group feature for SG rules, there are
certain cases in which the IPSet entries on the Hosts are not updated
properly.
Let's say we have two ports, respectively assigned with security
groups A and B:
If we add a rule in A saying "allow TCP from B", everything works as expected
(IPTable is updated, and IPSet created with the proper member).
However, once we *disassociate* B from the port, the update is not correctly
received/consumed by the Agent, and the IPSet previously created is not
updated! This will cause traffic to keep flowing even though it should be
disallowed.
If now we were to *associate* a new port to security group B, the
IPSet would still be unchanged and this new port wouldn't be able to
send traffic to A.
The root cause of the issue seems to be the way we notify agents when
a port is added or removed from a Security Group. Today, it seems like
only the agent that "owns" the port gets notified while the "related"
agents should be too, so that they can update their IPSet properly.
This happens independently whether the whole scenario exists in a
single node or not.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1455630/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
