[Bug 1924776] Re: [ovn] use of address scopes does not automatically disable router snat

[James Page]

Hi Bence

On Mon, Apr 19, 2021 at 12:25 PM Bence Romsics <1924776 at bugs.launchpad.net>
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 subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1924776
>
> Title:
>   [ovn] use of address scopes does not automatically disable router snat
>
> Status in neutron:
>   Incomplete
> Status in neutron package in Ubuntu:
>   New
>
> Bug description:
>   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.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/neutron/+bug/1924776/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: product=neutron; status=Incomplete; importance=Undecided;
> assignee=None;
> Launchpad-Bug: distribution=ubuntu; sourcepackage=neutron; component=main;
> status=New; importance=Undecided; assignee=None;
> Launchpad-Bug-Tags: ovn
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: bence-romsics james-page
> Launchpad-Bug-Reporter: James Page (james-page)
> Launchpad-Bug-Modifier: Bence Romsics (bence-romsics)
> Launchpad-Message-Rationale: Subscriber
> Launchpad-Message-For: james-page
>


** Changed in: neutron
       Status: Incomplete => New

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to neutron in Ubuntu.
https://bugs.launchpad.net/bugs/1924776

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

Status in neutron:
  New
Status in neutron package in Ubuntu:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1924776/+subscriptions