[ovs-dev] is the OVN load balancer also intended to be a firewall?

[Ben Pfaff]

On Wed, Jul 07, 2021 at 05:17:17PM -0700, Han Zhou wrote:
> On Wed, Jul 7, 2021 at 3:39 PM Ben Pfaff <blp at ovn.org> wrote:
> >
> > Hi, I've been talking to Shay Vargaftik (CC'd), also a researcher at
> > VMware, about some work he's done on optimizing load balancers.  What
> > he's come up with is a technique that in many cases avoids putting
> > connections into the connection-tracking table, because it can achieve
> > per-connection consistency without needing to do that.  This improves
> > performance by reducing the size of the connection-tracking table, which
> > is therefore more likely to fit inside a CPU cache and cheaper to
> > search.
> >
> > I'm trying to determine whether this technique would apply to OVN's load
> > balancer.  There would be challenges in any case, but one fundamental
> > question I have is: is the OVN load balancer also supposed to be a
> > firewall?  If it's not, then it's worth continuing to look to see if the
> > technique is applicable.  On the other hand, if it is, then every
> > connection needs to be tracked in any case, so the technique can't be
> > useful.
> >
> > Anyone's thoughts would be welcome.
> >
> For my understanding OVN LB doesn't directly relate to FW (OVN ACLs),
> although they both use conntrack. For LB, we use conntrack for NAT (convert
> the client IP to an LB owned IP) purposes. Does this technique support NAT
> without using conntrack?

Some kinds of NAT just change IP addresses.  These kinds of NAT don't
fundamentally need to track per-connection state, so this kind of NAT
would not demand conntrack.  Other kinds of NAT pull a port number from
a pool and assign it to each connection.  The latter kind does need to
track per-connection state, so it does need conntrack.  I'm not sure
which category the OVN LB is in.

> Moreover, maybe for the future, we also need to consider the cases when a
> LB is applied on a OVN gateway, for HA purposes the NAT tracking entries
> need to be able to be replicated across nodes, so that when failover
> happens the existing connections can continue working through another
> gateway node.

I don't think this is a problem for Shay's technique, which is called
JET (for Just Enough Tracking).  JET is designed to gracefully cope with
failover.  In fact, this is possibly an even better case for JET,
because fewer entries mean less replication.

> There are also OVN LB use cases that don't require NAT. If this technique
> doesn't support NAT, it is probably still useful for those scenarios.

That makes sense.

Do you have any idea which of the various cases that OVN supports are
commonly used?  Or whether performance is an issue for them in practice?
It would be silly to spend a lot of time optimizing the performance of
something that is already fast enough.