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

Han Zhou hzhou at ovn.org
Wed May 5 04:35:07 UTC 2021


On Tue, May 4, 2021 at 11:40 AM Francois <rigault.francois at gmail.com> wrote:
>
> On Tue, 4 May 2021 at 19:24, Han Zhou <hzhou at ovn.org> wrote:
> >
> >
> > This is interesting. One question here. Not sure if I understand the
proposal correctly, but if you want to use the chassis's IP for snat, then
how would the return traffic hit the br-int? The return traffic (to the VM,
with destination IP being the chassis IP and destination mac address being
the chassis MAC) would go directly to the host interface (e.g. br0) without
going to the virtual network pipelines, right?
>
> I saw some user documentation.. where the ovn-encap-ip was handled by
> a br-tun bridge, and was hoping there would be hope...
>
> >
> > The original problem was to avoid using floating IPs per VM, but if it
is ok to have an extra IP per chassis, then I think current OVN
implementation already supports it by creating a per chassis Gateway Router
and configuring SNAT using the Gateway Router's uplink IP. Each chassis is
now both a HV and a gateway, and you will need one extra IP per chassis as
the Gateway Router IP. I think this is similar to the ovn-kubernetes
topology. Of course there may be other drawbacks such as you may need a
logical switch per chassis so that you can route the traffic to the
chassis's own Gateway Router. Not sure if it is something that could help
in your use cases.
> >
>
> What I wish to have is  VMs without floating IP, from different
> tenants, having their traffic transparently (as in, no fIP or any
> particular thing to add from a user perspective),  sent out from the
> chassis directly.
>
> Just to rephrase the suggestion, I can create a logical switch per
> chassis, then give to all the VMs on the chassis a new interface that
> connects them to the second network, and the routing rules on the VM
> must be configured so that the traffic to external is sent through
> that interface.
>
> If I understand correctly, I think it describes well my usecase (SNAT
> is well distributed), but you need some work from the tenant point of
> view ("if you want efficient snat you need to route traffic through
> that second interface") even if we patch OpenStack to magically add
> new ports to VMs.
>
> I am going to check ovn-kubernetes doc then.

In ovn-kubernetes it is done through a single interface per workload. Each
workload is connected to the chassis level LS, which has a default route to
a join router, but the join router can make decision based on src-route
policies to redirect external traffic back to the chassis level gateway
router. Physically this routing decision is made locally by OVS on the
chassis. Of course the logical topology and routing is a little complex,
while with dual interfaces per VM you could make it more flexible (but may
introduce some other operational challenges).

>
> >
> > There is a plan to remove the C version once the DDlog is stable
enough. The timeline is not clear (at least to me).
> > There is also a plan to rewrite ovn-controller in ddlog, but it is more
complex than northd and there are different options moving forward, and the
timeline is even less clear.
> >
> > Thanks,
> > Han
>
> Thanks!
> Francois
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20210504/48bd5ac6/attachment.html>


More information about the discuss mailing list