[ovs-build] Passed: ovsrobot/ovn#975 (series_200841 - 3b14d40)

Travis CI builds at travis-ci.com
Thu Sep 10 14:40:06 UTC 2020


Build Update for ovsrobot/ovn
-------------------------------------

Build: #975
Status: Passed

Duration: 22 mins and 35 secs
Commit: 3b14d40 (series_200841)
Author: Dumitru Ceara
Message: ofctrl: Add a predictable resolution for conflicting flow actions.

Until now, in case the ACL configuration generates openflows that have
the same match but different actions, ovn-controller was using the
following approach:
1. If the flow being added contains conjunctive actions, merge its
   actions with the already existing flow.
2. Otherwise, if the flow is being added incrementally
   (update_installed_flows_by_track), don't install the new flow but
   instead keep the old one.
3. Otherwise, (update_installed_flows_by_compare), don't install the
   new flow but instead keep the old one.

Even though one can argue that having an ACL with a match that includes
the match of another ACL is a misconfiguration, it can happen that the
users perform such configuration. Depending on the order of reading and
installing the logical flows, the above operations can yield
unpredictable results, e.g., allow specific traffic but then after
ovn-controller is restarted (or a recompute happens) that specific
traffic starts being dropped.

A simple example of ACL configuration is:
ovn-nbctl acl-add ls to-lport 3 '(ip4.src==10.0.0.1 ||
ip4.src==10.0.0.2) && (ip4.dst == 10.0.0.3 || ip4.dst == 10.0.0.4)' allow
ovn-nbctl acl-add ls to-lport 3 'ip4.src==10.0.0.1' allow
ovn-nbctl acl-add ls to-lport 2 'arp' allow
ovn-nbctl acl-add ls to-lport 1 'ip4' drop

This is follows a pattern used by most CMSs:
- define a default deny policy.
- punch holes in the default deny policy based on user specific
  configurations.

Without this commit the behavior for traffic from 10.0.0.1 to 10.0.0.5
is unpredictable. Depending on the order of operations traffic might be
dropped or allowed.

It's also quite hard to force the CMS to ensure that such match overlaps
never occur.

To address this issue we now resolve conflicts between flows with the
same match and different actions by giving precedence to less
restrictive flows. This means that if the installed flow has action
"conjunction" and the desired flow doesn't then we prefer the desired
flow. Similarly, if the desired flow has action "conjunction" and the
desired flow doesn't then we prefer the already installed flow.

CC: Daniel Alvarez <dalvarez at redhat.com>
CC: Han Zhou <hzhou at ovn.org>
CC: Mark Michelson <mmichels at redhat.com>
CC: Numan Siddique <numans at ovn.org>
Reported-at: https://bugzilla.redhat.com/1871931
Signed-off-by: Dumitru Ceara <dceara at redhat.com>
Signed-off-by: 0-day Robot <robot at bytheb.org>

View the changeset: https://github.com/ovsrobot/ovn/compare/69b56114bd25^...3b14d4079fbf

View the full build log and details: https://travis-ci.com/github/ovsrobot/ovn/builds/183741121?utm_medium=notification&utm_source=email


--

You can unsubscribe from build emails from the ovsrobot/ovn repository going to https://travis-ci.com/account/preferences/unsubscribe?repository=9136199&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-build/attachments/20200910/79ba6d2e/attachment-0001.html>


More information about the build mailing list