[ovn] use of address scopes does not automatically disable router snat

[James Page]

OpenStack Ussuri
OVN 20.03.x
Ubuntu 20.04

When multiple networks/subnets are attached to a router which all form part of the same subnet pool and associated address scope SNAT is not automatically disabled to support routing between the subnets attached to the router.

Ensuring the router is created with SNAT disabled resolves this issue but that's an extra non-obvious step for a cloud admin/end user.

[Bence Romsics (bence-romsics)]

Could you please provide a set of commands leading to this error? Also what behavior you expected and what happened instead?

I'm asking this because there are many moving parts here. If you meant the enable_snat bit in the API, I'm afraid it's impossible to automatically set that, since we can't predict if the user will later attach a subnet from a different address scope.

If you meant the SNAT-ting behavior between an internal subnet and the external gw of the same address scope then this may very well be a valid bug.

However I'm not able to reproduce it yet. This is what I tried (in an all-in-one ovn master devstack):

# set ovs bridge mappings and hostname
sudo ovs-vsctl add-br br-physnet0
sudo ovs-vsctl set Open_vSwitch . external_ids:ovn-bridge-mappings=public:br-ex,physnet0:br-physnet0
sudo ovs-vsctl set Open_vSwitch . external_ids:hostname=$(hostname)

# give an ip to the bridge in the devstack vm
sudo ip link set up dev br-physnet0
sudo ip address add 10.0.0.2/24 dev br-physnet0

# create an image with serial console enabled, so we can later easily login and ping
openstack image create --disk-format qcow2 --public --file ~/ubuntu-20.04-server-cloudimg-amd64-disk-kvm-root-password.img u2004

openstack address scope create scope0
openstack subnet pool create --address-scope scope0 --pool-prefix 10.0.0.0/8 --default-prefix-length 22 pool0

# external net
openstack network create net-physnet0 --external --provider-network-type flat --provider-physical-network physnet0
openstack subnet create subnet-physnet0 --network net-physnet0 --subnet-pool pool0 --subnet-range 10.0.0.0/24 --gateway 10.0.0.1 --no-dhcp

# internal net in the same address scope
openstack network create net0 --provider-network-type vlan --provider-physical-network physnet0 --provider-segment 100
openstack subnet create subnet0 --network net0 --subnet-pool pool0 --subnet-range 10.0.1.0/24 --gateway 10.0.1.1

# router in disable-snat mode
openstack router create router0
openstack router set --external-gateway net-physnet0 --disable-snat router0
openstack router add subnet router0 subnet0

# boot, login over serial console
openstack server create --flavor ds1G --image u2004 --nic net-id=net0 --wait vm0
sudo virsh console "$( openstack server show vm0 -f value -c OS-EXT-SRV-ATTR:instance_name )"

# ping 10.0.0.2 responds

# change router to enable-snat mode
openstack router set --external-gateway net-physnet0 --enable-snat router0

# ping 10.0.0.2 still responds

[James Page (james-page)]

Hi Bence

On Mon, Apr 19, 2021 at 12:25 PM Bence Romsics <email address hidden>
wrote:

> Could you please provide a set of commands leading to this error? Also
> what behavior you expected and what happened instead?
>
> I'm asking this because there are many moving parts here. If you meant
> the enable_snat bit in the API, I'm afraid it's impossible to
> automatically set that, since we can't predict if the user will later
> attach a subnet from a different address scope.
>
> If you meant the SNAT-ting behavior between an internal subnet and the
> external gw of the same address scope then this may very well be a valid
> bug.
>

That's what I think I have seen in my setup.

>
> However I'm not able to reproduce it yet. This is what I tried (in an
> all-in-one ovn master devstack):
>
> # set ovs bridge mappings and hostname
> sudo ovs-vsctl add-br br-physnet0
> sudo ovs-vsctl set Open_vSwitch .
> external_ids:ovn-bridge-mappings=public:br-ex,physnet0:br-physnet0
> sudo ovs-vsctl set Open_vSwitch . external_ids:hostname=$(hostname)
>
> # give an ip to the bridge in the devstack vm
> sudo ip link set up dev br-physnet0
> sudo ip address add 10.0.0.2/24 dev br-physnet0
>
> # create an image with serial console enabled, so we can later easily
> login and ping
> openstack image create --disk-format qcow2 --public --file
> ~/ubuntu-20.04-server-cloudimg-amd64-disk-kvm-root-password.img u2004
>
> openstack address scope create scope0
> openstack subnet pool create --address-scope scope0 --pool-prefix
> 10.0.0.0/8 --default-prefix-length 22 pool0
>
> # external net
> openstack network create net-physnet0 --external --provider-network-type
> flat --provider-physical-network physnet0
> openstack subnet create subnet-physnet0 --network net-physnet0
> --subnet-pool pool0 --subnet-range 10.0.0.0/24 --gateway 10.0.0.1
> --no-dhcp
>
> # internal net in the same address scope
> openstack network create net0 --provider-network-type vlan
> --provider-physical-network physnet0 --provider-segment 100
> openstack subnet create subnet0 --network net0 --subnet-pool pool0
> --subnet-range 10.0.1.0/24 --gateway 10.0.1.1
>
> # router in disable-snat mode
> openstack router create router0
> openstack router set --external-gateway net-physnet0 --disable-snat router0
>

In my test I skipped this step and the router was created with SNAT enabled

I expected traffic between networks from the same address scope to transit
the router without any NAT.

> openstack router add subnet router0 subnet0
>

> # boot, login over serial console
> openstack server create --flavor ds1G --image u2004 --nic net-id=net0
> --wait vm0
> sudo virsh console "$( openstack server show vm0 -f value -c
> OS-EXT-SRV-ATTR:instance_name )"
>
> # ping 10.0.0.2 responds
>
> # change router to enable-snat mode
> openstack router set --external-gateway net-physnet0 --enable-snat router0
>
> # ping 10.0.0.2 still responds
>

I think that actually points to another bug (where disable/enabling snat on
a router once its in use does not work reliably).

>
> ** Changed in: neutron
> Status: New => Incomplete
>
> ** Tags added: ovn
>
> --
> You received this bug notification because you are subs...