yahoo-eng-team team mailing list archive

[Ivar Lazzaro <1455630@xxxxxxxxxxxxxxxxxx>]

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