Comment 13 for bug 2051935

Ok, here is the reproducer steps Rodolfo.

Starting with a fresh devstack install from master, and assuming something like:

1) router1 - which is the external gateway for 'private-subnet'

| external_gateway_info | {"network_id": "35f9b888-da3b-42c6-bc73-29395f7e2afe", "external_fixed_ips": [{"subnet_id": "61762e92-9684-4317-ab12-a362feae78a6", "ip_address": "172.24.4.128"}, {"subnet_id": "5f95efdf-6415-43a2-8164-7a9f97a6cbcc", "ip_address": "2001:db8::1"}], "enable_snat": |
| | true} |
| external_gateways | [{'network_id': '35f9b888-da3b-42c6-bc73-29395f7e2afe', 'external_fixed_ips': [{'ip_address': '172.24.4.128', 'subnet_id': '61762e92-9684-4317-ab12-a362feae78a6'}, {'ip_address': '2001:db8::1', 'subnet_id': '5f95efdf-6415-43a2-8164-7a9f97a6cbcc'}]}] |
| flavor_id | None |
| id | 56dd6de7-524e-4850-a5d7-57dbff1e7f7e |
| interfaces_info | [{"port_id": "1fbbfa1d-215b-443b-8464-8ec6cd5749c2", "ip_address": "fd8e:4fac:f388::1", "subnet_id": "88c913ef-69db-4684-ab0f-1de717044065"}, {"port_id": "407f32f2-fb96-43b2-8930-79752c4a2c26", "ip_address": "10.0.0.1", "subnet_id": |
| | "c49e2e09-d54a-4010-a84c-de646f6128f1"}]

2) private-subnet on network 'private'

| allocation_pools | 10.0.0.2-10.0.0.62 |
| cidr | 10.0.0.0/26

We can then create resources to demonstrate the issue.

Create a new private network

$ openstack network create private-network-nested

Create a subnet on it using the default IPv4 subnet pool

$ openstack subnet create --subnet-pool shared-default-subnetpool-v4 --network private-network-nested private-subnet-nested

Create a router that will act as the gateway to this network

$ openstack router create router-nested

| id | a8e69f7b-e8dc-40e1-a944-14bf3b0308dc |

Add an interface on the previously created private subnet

$ openstack router add subnet router-nested private-subnet-nested

Create a port on the initial private subnet/network for the nested router and add it to it

$ openstack port create --network private --fixed-ip subnet=private-subnet,ip-address=10.0.0.62 private-port
$ openstack router add port router-nested private-port

Resultant interfaces

| interfaces_info | [{"port_id": "41b643a1-583c-4909-8cc8-0d2dba994633", "ip_address": "10.0.0.62", "subnet_id": "c49e2e09-d54a-4010-a84c-de646f6128f1"}, {"port_id": "41b643a1-583c-4909-8cc8-0d2dba994633", "ip_address": "fd8e:4fac:f388:0:f816:3eff:fe2f:4e2e", "subnet_id": |
| | "88c913ef-69db-4684-ab0f-1de717044065"}, {"port_id": "bfcd9966-b994-42b0-bb1f-e9f2b16d9760", "ip_address": "10.0.0.65", "subnet_id": "72fbfa53-f732-417b-bea3-b4efc13c1baa"}]

Add routes on both routers

$ openstack router add route --route destination=10.0.0.64/26,gateway=10.0.0.62 router1
$ openstack router add route --route destination=0.0.0.0/0,gateway=10.0.0.1 router-nested

Launch an instance on the nested private network

$ openstack server create --flavor 1 --image cirros-0.6.2-x86_64-disk --key-name devstackkeypair --network private-network-nested test_server1

Login to the VNC console of the instance and run some pings (can't cut/paste from that session)

IP address: 10.0.0.107/26

First, ping the IPs of both router-nested and router1, which is where the external gateway is hosted

$ ping 10.0.0.65
(success)

$ ping 10.0.0.1
(success)

Then try google DNS

$ ping 8.8.8.8
(fails)

So let's check the OVN snat rules for the router

$ sudo ovn-nbctl lr-nat-list neutron-56dd6de7-524e-4850-a5d7-57dbff1e7f7e
TYPE EXTERNAL_IP EXTERNAL_PORT LOGICAL_IP EXTERNAL_MAC LOGICAL_PORT
snat 172.24.4.128 10.0.0.0/26

We can see there is no default SNAT rule for the private nested subnet, so let's add one and re-test

$ sudo ovn-nbctl lr-nat-add neutron-56dd6de7-524e-4850-a5d7-57dbff1e7f7e snat 172.24.4.128 10.0.0.64/26
$ sudo ovn-nbctl lr-nat-list neutron-56dd6de7-524e-4850-a5d7-57dbff1e7f7e
TYPE EXTERNAL_IP EXTERNAL_PORT LOGICAL_IP EXTERNAL_MAC LOGICAL_PORT
snat 172.24.4.128 10.0.0.64/26
snat 172.24.4.128 10.0.0.0/26

$ ping 8.8.8.8
(success)

That's essentially what the patch will do automatically, or when the OVN DB sync util is run in repair mode on an existing setup.

With ML2/OVS there was nothing extra required.

Hopefully that helps explain things.