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

Francois rigault.francois at gmail.com
Tue May 4 18:40:02 UTC 2021


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.

>
> 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


More information about the discuss mailing list