[OVS][FW] Do not delete flows with "--strict" parameter in the OVS FW

[Rodolfo Alonso]

The "--strict" parameter during the OF deletion was introduced to be able to define the parameter "priority" in the flow filter. Without "--strict" is not possible to filter by "priority". E.g.:

[root@compute-0 ~]# ovs-ofctl del-flows br-int priority=100,table=60,in_port=144 # error
ovs-ofctl: unknown keyword priority
[root@compute-0 ~]# ovs-ofctl del-flows --strict br-int priority=100,table=60,in_port=144 # ok

With deferred OF application (that means all flows are written/deleted at the same time, at the end of the deferred context), these strict flow deletion commands are executed before anything else. In some cases we have seen this small window can affect to some kind of traffic. For example UDP traffic is disrupted, the UDP packets arrive to the destination disordered. That could affect some applications.

Further considerations: with trunk ports, as printed in [1], we can see that each subport has its own port ID (for rules with priority 100) and each own VLAN+MAC (for rules with priority 90).

[1]https://paste.opendev.org/show/811353/

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/819900

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/819900
Committed: https://opendev.org/openstack/neutron/commit/ef7f673098c2a4574365f6f4ed20734f29309f08
Submitter: "Zuul (22348)"
Branch: master

commit ef7f673098c2a4574365f6f4ed20734f29309f08
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Tue Nov 30 16:01:27 2021 +0000

    Do no use "--strict" for OF deletion in TRANSIENT_TABLE

    There are two types of OF rules in TRANSIENT_TABLE:
    - With priority 100: these rules match by "in_port", that is a
      unique identifier.
    - With priority 90: these rules match by MAC address and VLAN ID.
      This combination (MAC, VLAN) is unique.

    That means when a deleting an OF rule in TRANSIENT_TABLE, it is
    enough to specify the "in_port" or the (MAC, VLAN) tuple. The
    "--strict" parameter, added to also define the priority, is not
    needed.

    By removing the "--strict" parameter, these deletion commands can
    be executed synchronously at the end of the OVS deferred context,
    when all the OF rule commands (addition or deletion), are executed
    at the same time. That removes the small window, detected in the
    related bug, when the OF rule set for a port is not complete.

    Closes-Bug: #1952770
    Change-Id: I9f5bd8a1404dde3a0aa163ce72aef2961f537676

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/xena
Review: https://review.opendev.org/c/openstack/neutron/+/820349

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/wallaby
Review: https://review.opendev.org/c/openstack/neutron/+/820490

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/victoria
Review: https://review.opendev.org/c/openstack/neutron/+/820491

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/ussuri
Review: https://review.opendev.org/c/openstack/neutron/+/820492

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/train
Review: https://review.opendev.org/c/openstack/neutron/+/820493

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/stein
Review: https://review.opendev.org/c/openstack/neutron/+/820481

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/rocky
Review: https://review.opendev.org/c/openstack/neutron/+/820495

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/queens
Review: https://review.opendev.org/c/openstack/neutron/+/820496

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/820492
Committed: https://opendev.org/openstack/neutron/commit/3ab6aea2639dd52867c3bc12fbca2fac3848452f
Submitter: "Zuul (22348)"
Branch: stable/ussuri

commit 3ab6aea2639dd52867c3bc12fbca2fac3848452f
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Tue Nov 30 16:01:27 2021 +0000

    Do no use "--strict" for OF deletion in TRANSIENT_TABLE

    There are two types of OF rules in TRANSIENT_TABLE:
    - With priority 100: these rules match by "in_port", that is a
      unique identifier.
    - With priority 90: these rules match by MAC address and VLAN ID.
      This combination (MAC, VLAN) is unique.

    That means when a deleting an OF rule in TRANSIENT_TABLE, it is
    enough to specify the "in_port" or the (MAC, VLAN) tuple. The
    "--strict" parameter, added to also define the priority, is not
    needed.

    By removing the "--strict" parameter, these deletion commands can
    be executed synchronously at the end of the OVS deferred context,
    when all the OF rule commands (addition or deletion), are executed
    at the same time. That removes the small window, detected in the
    related bug, when the OF rule set for a port is not complete.

    Closes-Bug: #1952770
    Change-Id: I9f5bd8a1404dde3a0aa163ce72aef2961f537676
    (cherry picked from commit ef7f673098c2a4574365f6f4ed20734f29309f08)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/820490
Committed: https://opendev.org/openstack/neutron/commit/0db5334ccf63226383f9fa85017c194bf01fcc38
Submitter: "Zuul (22348)"
Branch: stable/wallaby

commit 0db5334ccf63226383f9fa85017c194bf01fcc38
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Tue Nov 30 16:01:27 2021 +0000

    Do no use "--strict" for OF deletion in TRANSIENT_TABLE

    There are two types of OF rules in TRANSIENT_TABLE:
    - With priority 100: these rules match by "in_port", that is a
      unique identifier.
    - With priority 90: these rules match by MAC address and VLAN ID.
      This combination (MAC, VLAN) is unique.

    That means when a deleting an OF rule in TRANSIENT_TABLE, it is
    enough to specify the "in_port" or the (MAC, VLAN) tuple. The
    "--strict" parameter, added to also define the priority, is not
    needed.

    By removing the "--strict" parameter, these deletion commands can
    be executed synchronously at the end of the OVS deferred context,
    when all the OF rule commands (addition or deletion), are executed
    at the same time. That removes the small window, detected in the
    related bug, when the OF rule set for a port is not complete.

    Closes-Bug: #1952770
    Change-Id: I9f5bd8a1404dde3a0aa163ce72aef2961f537676
    (cherry picked from commit ef7f673098c2a4574365f6f4ed20734f29309f08)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/820349
Committed: https://opendev.org/openstack/neutron/commit/893e321b3e5d165bc041f2ce77db45bec044f354
Submitter: "Zuul (22348)"
Branch: stable/xena

commit 893e321b3e5d165bc041f2ce77db45bec044f354
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Tue Nov 30 16:01:27 2021 +0000

    Do no use "--strict" for OF deletion in TRANSIENT_TABLE

    There are two types of OF rules in TRANSIENT_TABLE:
    - With priority 100: these rules match by "in_port", that is a
      unique identifier.
    - With priority 90: these rules match by MAC address and VLAN ID.
      This combination (MAC, VLAN) is unique.

    That means when a deleting an OF rule in TRANSIENT_TABLE, it is
    enough to specify the "in_port" or the (MAC, VLAN) tuple. The
    "--strict" parameter, added to also define the priority, is not
    needed.

    By removing the "--strict" parameter, these deletion commands can
    be executed synchronously at the end of the OVS deferred context,
    when all the OF rule commands (addition or deletion), are executed
    at the same time. That removes the small window, detected in the
    related bug, when the OF rule set for a port is not complete.

    Closes-Bug: #1952770
    Change-Id: I9f5bd8a1404dde3a0aa163ce72aef2961f537676
    (cherry picked from commit ef7f673098c2a4574365f6f4ed20734f29309f08)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/820491
Committed: https://opendev.org/openstack/neutron/commit/e1791dee93045179073cbbb76a12a83f7cf6a633
Submitter: "Zuul (22348)"
Branch: stable/victoria

commit e1791dee93045179073cbbb76a12a83f7cf6a633
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Tue Nov 30 16:01:27 2021 +0000

    Do no use "--strict" for OF deletion in TRANSIENT_TABLE

    There are two types of OF rules in TRANSIENT_TABLE:
    - With priority 100: these rules match by "in_port", that is a
      unique identifier.
    - With priority 90: these rules match by MAC address and VLAN ID.
      This combination (MAC, VLAN) is unique.

    That means when a deleting an OF rule in TRANSIENT_TABLE, it is
    enough to specify the "in_port" or the (MAC, VLAN) tuple. The
    "--strict" parameter, added to also define the priority, is not
    needed.

    By removing the "--strict" parameter, these deletion commands can
    be executed synchronously at the end of the OVS deferred context,
    when all the OF rule commands (addition or deletion), are executed
    at the same time. That removes the small window, detected in the
    related bug, when the OF rule set for a port is not complete.

    Closes-Bug: #1952770
    Change-Id: I9f5bd8a1404dde3a0aa163ce72aef2961f537676
    (cherry picked from commit ef7f673098c2a4574365f6f4ed20734f29309f08)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 19.1.0 release.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/820493
Committed: https://opendev.org/openstack/neutron/commit/c886bea8d931b83b958b19c10673c3c6f7579ff2
Submitter: "Zuul (22348)"
Branch: stable/train

commit c886bea8d931b83b958b19c10673c3c6f7579ff2
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Tue Nov 30 16:01:27 2021 +0000

    Do no use "--strict" for OF deletion in TRANSIENT_TABLE

    There are two types of OF rules in TRANSIENT_TABLE:
    - With priority 100: these rules match by "in_port", that is a
      unique identifier.
    - With priority 90: these rules match by MAC address and VLAN ID.
      This combination (MAC, VLAN) is unique.

    That means when a deleting an OF rule in TRANSIENT_TABLE, it is
    enough to specify the "in_port" or the (MAC, VLAN) tuple. The
    "--strict" parameter, added to also define the priority, is not
    needed.

    By removing the "--strict" parameter, these deletion commands can
    be executed synchronously at the end of the OVS deferred context,
    when all the OF rule commands (addition or deletion), are executed
    at the same time. That removes the small window, detected in the
    related bug, when the OF rule set for a port is not complete.

    Conflicts:
        neutron/tests/unit/agent/linux/openvswitch_firewall/test_firewall.py

    Closes-Bug: #1952770
    Change-Id: I9f5bd8a1404dde3a0aa163ce72aef2961f537676
    (cherry picked from commit ef7f673098c2a4574365f6f4ed20734f29309f08)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 17.3.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 18.2.0 release.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/820495
Committed: https://opendev.org/openstack/neutron/commit/bd40e621fde5ebbe88322af774753c80bc0e1bd6
Submitter: "Zuul (22348)"
Branch: stable/rocky

commit bd40e621fde5ebbe88322af774753c80bc0e1bd6
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Tue Nov 30 16:01:27 2021 +0000

    Do no use "--strict" for OF deletion in TRANSIENT_TABLE

    There are two types of OF rules in TRANSIENT_TABLE:
    - With priority 100: these rules match by "in_port", that is a
      unique identifier.
    - With priority 90: these rules match by MAC address and VLAN ID.
      This combination (MAC, VLAN) is unique.

    That means when a deleting an OF rule in TRANSIENT_TABLE, it is
    enough to specify the "in_port" or the (MAC, VLAN) tuple. The
    "--strict" parameter, added to also define the priority, is not
    needed.

    By removing the "--strict" parameter, these deletion commands can
    be executed synchronously at the end of the OVS deferred context,
    when all the OF rule commands (addition or deletion), are executed
    at the same time. That removes the small window, detected in the
    related bug, when the OF rule set for a port is not complete.

    Conflicts:
        neutron/agent/linux/openvswitch_firewall/firewall.py
        neutron/tests/unit/agent/linux/openvswitch_firewall/test_firewall.py

    Closes-Bug: #1952770
    Change-Id: I9f5bd8a1404dde3a0aa163ce72aef2961f537676
    (cherry picked from commit ef7f673098c2a4574365f6f4ed20734f29309f08)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/820496
Committed: https://opendev.org/openstack/neutron/commit/8b5427dbdaf21c86f24f5451151e4603062a7360
Submitter: "Zuul (22348)"
Branch: stable/queens

commit 8b5427dbdaf21c86f24f5451151e4603062a7360
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Tue Nov 30 16:01:27 2021 +0000

    Do no use "--strict" for OF deletion in TRANSIENT_TABLE

    There are two types of OF rules in TRANSIENT_TABLE:
    - With priority 100: these rules match by "in_port", that is a
      unique identifier.
    - With priority 90: these rules match by MAC address and VLAN ID.
      This combination (MAC, VLAN) is unique.

    That means when a deleting an OF rule in TRANSIENT_TABLE, it is
    enough to specify the "in_port" or the (MAC, VLAN) tuple. The
    "--strict" parameter, added to also define the priority, is not
    needed.

    By removing the "--strict" parameter, these deletion commands can
    be executed synchronously at the end of the OVS deferred context,
    when all the OF rule commands (addition or deletion), are executed
    at the same time. That removes the small window, detected in the
    related bug, when the OF rule set for a port is not complete.

    Conflicts:
        neutron/agent/linux/openvswitch_firewall/firewall.py
        neutron/tests/unit/agent/linux/openvswitch_firewall/test_firewall.py

    Closes-Bug: #1952770
    Change-Id: I9f5bd8a1404dde3a0aa163ce72aef2961f537676
    (cherry picked from commit ef7f673098c2a4574365f6f4ed20734f29309f08)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron/+/820481
Committed: https://opendev.org/openstack/neutron/commit/557458e45052164d5fb32c1a3f3241131aec127c
Submitter: "Zuul (22348)"
Branch: stable/stein

commit 557458e45052164d5fb32c1a3f3241131aec127c
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Tue Nov 30 16:01:27 2021 +0000

    Do no use "--strict" for OF deletion in TRANSIENT_TABLE

    There are two types of OF rules in TRANSIENT_TABLE:
    - With priority 100: these rules match by "in_port", that is a
      unique identifier.
    - With priority 90: these rules match by MAC address and VLAN ID.
      This combination (MAC, VLAN) is unique.

    That means when a deleting an OF rule in TRANSIENT_TABLE, it is
    enough to specify the "in_port" or the (MAC, VLAN) tuple. The
    "--strict" parameter, added to also define the priority, is not
    needed.

    By removing the "--strict" parameter, these deletion commands can
    be executed synchronously at the end of the OVS deferred context,
    when all the OF rule commands (addition or deletion), are executed
    at the same time. That removes the small window, detected in the
    related bug, when the OF rule set for a port is not complete.

    Conflicts:
        neutron/agent/linux/openvswitch_firewall/firewall.py
        neutron/tests/unit/agent/linux/openvswitch_firewall/test_firewall.py

    Closes-Bug: #1952770
    Change-Id: I9f5bd8a1404dde3a0aa163ce72aef2961f537676
    (cherry picked from commit ef7f673098c2a4574365f6f4ed20734f29309f08)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 20.0.0.0rc1 release candidate.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron queens-eol release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron rocky-eol release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron stein-eol release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron train-eol release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron ussuri-eol release.