[ovs-discuss] Question on distributing snat traffic with OVN

[Francois]

On Tue, 4 May 2021 at 17:03, Numan Siddique <numans at ovn.org> wrote:
>
> On Sat, May 1, 2021 at 6:32 AM Francois <rigault.francois at gmail.com> wrote:
> >
> > Hi Open vSwitch
> > I am running an OVN stack with a dozen chassis, all of them able to
> > act as gateways.
> > I have many VMs without floating IPs on the same logical switch, doing
> > a lot of external traffic. Today, this traffic has to go through the
> > tunnel towards the unique chassis claiming the gateway to perform the
> > snat natting and send the traffic outside the stack.
> >
> > With this current design, I see a lot of BFD traffic, and a clear
> > bottleneck and spof with that single chassis doing the snat. A
> > workaround is to add floating IPs on each VM, but this means the end
> > user has to put the floating IP themself, it also means if a single
> > chassis runs 10 VMs, we need one floating IP per VM just for the snat,
> > while we could instead use a single IP per chassis for that.
> >
> > I was thinking of adding a "br-snat" bridge on each ovs, adding to it
> > one interface with a fixed IP, and (with some minimal development in
> > ovn northd) have the snat traffic of all its ports going out of that
> > interface instead of going through the tunnel towards the gateway.
> > Ideally the IP used today for the tunnel could be used too for the
> > snat traffic, but this seems less trivial to achieve.
> >
> > Before looking at the details of ddlog and the syntax of flows, I
> > would love to get some feedback on the idea, maybe there is something
> > fundamentally broken with my design, or maybe there is a smarter way
> > to achieve this?
>
> This is an interesting idea.  In order to do snat, OVN should know what IP
> to use.  But this IP should belong to the provider network subnet pool right ?
>
> If you think this can be done, you can probably attempt a quick PoC with just
> changes to the C version and post the patches as RFC. The ddlog part
> can be done later if the approach seems to be fine for the reviewers.


Ok! I have no idea if this can be done, but I will attempt something
nevertheless. You need one IP per chassis so if it is set on a different
interface, and statically (similar to the external-ids:ovn-encap-ip)
it should be fine too.

What will happen is that traffic going out will be seen from the outside,
as an IP of the chassis (and the compute running a VM is chosen at random
usually).  If there are firewall rules to open (on a firewall seating on
the external network), they will need to be opened for all hypervisors, for
all VMs (so firewall rules become less relevant in a sense).  It basically
"works" from a security standpoint, when all VMs belong to the same tenant.
Still since we are going to open whole ranges in the firewall, the IPs
should be limited to the IPs used for the SNAT, and not include any fIP, so it
should probably be a different subnet.

I think (I am still reading the doc!) a somewhat similar work was done when
addressing the MTU issue with the redirect-type=bridged, where packets
are sent through a different port, using statically set mac-mappings.

ddlog looked funnier! Do you have a plan for the removal of the C
version? Also is there still a plan to have ovn-controller rewritten in
ddlog?

Thanks a lot!
Francois

>
> Thanks
> Numan
>
> >
> > Thanks
> > Francois
> > _______________________________________________
> > discuss mailing list
> > discuss at openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> >