Hi everyone,

While looking at an OVS->OVN migration, we came across a use-case that doesn’t provide 1:1 compatibility and I wanted to check with the community to see if there were any suggestions or ideas on how to proceed.

In an OVS-based environment, we have users with a typical layout:

<external provider network>

                        |

         <neutron router>

               |               |

<tenantnet1>   <tenantnet2>

The users have implemented static routes on the Neutron router using the extraroutes API, which works great, and the default SNAT behavior implemented within the qrouter namespace handles any network traffic egressing the router, not just directly-connected tenant networks (see iptables entries below):

-A neutron-l3-agent-snat -j neutron-l3-agent-float-snat

-A neutron-l3-agent-snat -o qg-700f84b0-6b -j SNAT --to-source 168.47.160.223 --random-fully

-A neutron-l3-agent-snat -m mark ! --mark 0x2/0xffff -m conntrack --ctstate DNAT -j SNAT --to-source 168.47.160.223 --random-fully

-A neutron-postrouting-bottom -m comment --comment "Perform source NAT on outgoing traffic." -j neutron-l3-agent-snat

OVN, on the other hand, appears to implement snat rules in the logical router based on directly-connected tenant networks, which means that traffic sourcing from other networks (not managed by Neutron but routable within a Neutron router, including to a VM or appliance) is not source NAT’d and egresses the router as its real IP. This behavior results in the traffic being effectively blackholed, as there’s no return route and no real desire to have exposed those IPs anyway.

Here’s an example of the nat list which includes the directly connected tenant network:

root@lab-controller01:~# ovn-nbctl lr-nat-list  neutron-edfd7115-5a81-46b7-9692-fe227d395b0b
TYPE             GATEWAY_PORT          EXTERNAL_IP        EXTERNAL_PORT    LOGICAL_IP          EXTERNAL_MAC         LOGICAL_PORT
snat                                                       192.168.3.33                                          10.254.254.0/24

The extraroute in the router is:

destination: 172.16.0.0/24, nexthop: 10.254.254.6

I can add an entry manually, which allows the snat for the secondary network to work as expected, but results in some other issues where the snat(s) don’t get added back on a disable/enable of the router:

root@lab-controller01:~# ovn-nbctl lr-nat-add neutron-edfd7115-5a81-46b7-9692-fe227d395b0b snat 192.168.3.33 172.16.0.0/24
root@lab-controller01:~# ovn-nbctl lr-nat-list  neutron-edfd7115-5a81-46b7-9692-fe227d395b0b
TYPE             GATEWAY_PORT          EXTERNAL_IP        EXTERNAL_PORT    LOGICAL_IP          EXTERNAL_MAC         LOGICAL_PORT
snat                                                      192.168.3.33                                           10.254.254.0/29
snat                                                      192.168.3.33                                           172.16.0.0/24

I understand this is probably not a supported usecase, but one that worked nonetheless, so any suggestions on how to mirror this functionality in a supported way would be greatly appreciated.

Thanks,

James