Public bug reported:
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/
** Affects: neutron
Importance: Undecided
Assignee: Rodolfo Alonso (rodolfo-alonso-hernandez)
Status: New
** Changed in: neutron
Assignee: (unassigned) => Rodolfo Alonso (rodolfo-alonso-hernandez)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1952770
Title:
[OVS][FW] Do not delete flows with "--strict" parameter in the OVS FW
Status in neutron:
New
Bug description:
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/
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1952770/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
