[ovs-dev] RFC: stateless filter design

Numan Siddique numans at ovn.org
Wed Jan 20 05:55:08 UTC 2021


On Tue, Jan 19, 2021 at 11:07 AM Ihar Hrachyshka <ihrachys at redhat.com>
wrote:

> Hi all,
>
> This email is primarily about choosing a preferred path to design API for
> stateless filter support. There are also some related implementation
> questions
> at the bottom.
>
> ===
>
> Problem: we need a way to configure stateless ACL filters in OVN.
>
> Alternatives:
> 1. new Stateless_Filter NB object. This approach was already prototyped in
> [1]
>    primarily with OpenShift in mind.
>    - pro: simplify implementation. May reduce the number of objects in
>      particular scenarios.
>    - con: yet another first order object to deal with. CMS may have to deal
>      with both ACL and Stateless_Filter objects.
>
> 2. reuse the existing 'allow' ACL type (comp. 'allow-related'). This
> approach
>    is discussed below.
>    - pro: fewer object types to deal with. No DB schema change.
>    - con: implementation/runtime complexity; more flows in existing stages;
>      backwards incompatibility due to 'allow' verb use.
>
> Let me know if there are other concerns with reusing the 'allow' verb for
> the
> need.
>
> ===
>
> The (2) approach would look as follows, (quoting Dumitru)
>
> "An alternative is to have ovn-northd automatically generate two sets of
> logical flows for stateless ACLs.  E.g., for all ACLs with action
> "allow" and match M:
>
> a. in the LS pipeline, stage "in/out-pre-acl", add a flow matching on M
> with action "next", i.e., not setting bit REGBIT_CONNTRACK_DEFRAG, and
> avoiding conntrack in the "in/out-pre-stateful" stages.
>
> b. in the LS pipeline, stage "in-pre-lb", if there's a load balancer
> configured on the LS then REGBIT_CONNTRACK_DEFRAG is set to 1.  This is
> already done by [2] and should remain like this for the time being.
>
> c. in the LS pipeline, stage "in/out-acl" add a flow matching on M *but
> not on conntrack hint registers* (REGBIT_ACL_HINT*) to allow the traffic
> in a stateless way."
>
> ===
>
> From API cleanliness perspective, (2) approach seems preferable if we can
> keep
> runtime impact in check. In OpenStack, 'stateless' is a security group rule
> attribute, and they would like to avoid maintaining two separate objects
> for
> stateless support. (There was no other example in the CMS where they would
> do
> that, at least till now, and this would complicate their implementation.)
>
> The backwards incompatibility of extending 'allow' verb to support
> stateless
> filters seems acceptable, its current behavior may be considered a bug.
>
> We'll have to measure the runtime impact of (2) approach and compare it
> with
> (1). I am prototyping it here. Do we have tools / environments to test
> the impact
> of flow table changes in a set of common scenarios?
>
>
I would say (2) is better if we can handle all the intricacies of not
sending such traffic
to conntrack properly.

When I did some testing earlier, I was running  "ovs-dpctl  dump-flows" and
monitoring
the number of upcalls due to conntrack recirculation. You could probably do
the same
and make sure that for "allow" acl related traffic, there are no additional
upcalls and
the traffic is not sent to conntrack.


> ===
>
> There's also an issue of traffic sent to conntrack twice (in ingress and
> egress) due to [2], see b. in (2) approach. I am told with [3] the OVN
> commit
> is no longer needed. How do we track minimal kernel versions supported by
> OVN?
>

This will be tricky. We can probably document about the minimal kernel
version required
for certain functionality to work.

Thanks
Numan


> ===
>
> [1]:
> https://patchwork.ozlabs.org/project/openvswitch/patch/1597922284-3341-1-git-send-email-dceara@redhat.com/
> [2]:
> https://github.com/ovn-org/ovn/commit/64cc065e2c59c0696edeef738180989d993ceceb
> [3]:
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/net/openvswitch/conntrack.c?id=e2ef5203c817a60bfb591343ffd851b6537370ff
>
> ===
>
> Thanks for comments,
> Ihar
>
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>


More information about the dev mailing list