yahoo-eng-team team mailing list archive

[Corey Bryant <1881157@xxxxxxxxxxxxxxxxxx>]

** Changed in: cloud-archive/victoria
       Status: Fix Committed => Fix Released

** Changed in: neutron (Ubuntu Groovy)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1881157

Title:
  [OVS][FW] Remote SG IDs left behind when a SG is removed

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive queens series:
  Triaged
Status in Ubuntu Cloud Archive stein series:
  Fix Released
Status in Ubuntu Cloud Archive train series:
  Fix Released
Status in Ubuntu Cloud Archive ussuri series:
  Fix Released
Status in Ubuntu Cloud Archive victoria series:
  Fix Released
Status in neutron:
  New
Status in neutron package in Ubuntu:
  Fix Committed
Status in neutron source package in Bionic:
  Fix Committed
Status in neutron source package in Focal:
  Fix Released
Status in neutron source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  neutron does not remove all trace of remote sg conj ids when deleting
  a security group.

  [Test Case]

   * deploy openstack (no particular feature needed)
   * create two networks N1, N2 with security groups SG1, SG2 respectively
   * SG2 must have a custom ingress tcp rule from remote SG1
   * create a vm on each network, make a note of their fixed_ip then delete those vms
   * on compute host running VM2 do the following:
   * sudo ovs-ofctl dump-flows br-int table=82| grep <vm1-ip>
   * sudo ovs-ofctl dump-flows br-int table=82| egrep "conjunction([0-9]+,2/2)"
   * the above should not return anything

  [Regression Potential]
  Since the flows being deleted belong to deleted ports their deletion is not expected to have a noticeable impact but as this bug describes, their existance could be having an unexpected impact on ports that have a security that happens to share the same conjunction id.

  -------------------------------------------------------------------------

  When any port in the OVS agent is using a SG, is marked to be deleted.
  This deletion process is done in [1].

  The SG deletion process consists on removing any reference of this SG
  from the firewall and the SG port map. The firewall removes this SG in
  [2].

  The information of a SG is stored in:
  - ConjIPFlowManager.conj_id_map = ConjIdMap(). This class stores the conjunction IDS (conj_ids) in a dictionary using the following keys:
    ConjIdMap.id_map[(sg_id, remote_sg_id, direction, ethertype, conj_ids)] = conj_id_XXX

  - ConjIPFlowManager.conj_ids is a nested dictionary, built in the following way:
    self.conj_ids[vlan_tag][(direction, ethertype)][remote_sg_id] = set([conj_id_1, conj_id_2, ...])

  When a SG is removed, this reference should be deleted both from
  "conj_id_map" and "conj_ids". From "conj_id_map" is correctly removed
  in [3]. But from "conj_ids" is not being deleted properly. Instead of
  the current logic, what we should do is to walk through the nested
  dictionary and remove any entry with "remote_sg_id" == "sg_id" (<-- SG
  ID to be removed).

  The current implementation leaves some "remote_sg_id" in the nested dictionary "conj_ids". That could cause:
  - A memory leak in the OVS agent, storing in memory those unneeded remote SG.
  - A increase in the complexity of the OVS rules, adding those unused SG (actually the conj_ids related to those SG)
  - A security breach between SGs if the conj_ids left in an unused SG is deleted and reused again (the FW stores the unused conj_ids to be recycled in later rules).

  [1]https://github.com/openstack/neutron/blob/118930f03d31f157f8c7a9e6c57122ecea8982b9/neutron/agent/linux/openvswitch_firewall/firewall.py#L731
  [2]https://github.com/openstack/neutron/blob/118930f03d31f157f8c7a9e6c57122ecea8982b9/neutron/agent/linux/openvswitch_firewall/firewall.py#L399
  [3]https://github.com/openstack/neutron/blob/118930f03d31f157f8c7a9e6c57122ecea8982b9/neutron/agent/linux/openvswitch_firewall/firewall.py#L296

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1881157/+subscriptions