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 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
>
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.
> ids:ovn- bridge- mappings= public: br-ex,physnet0: br-physnet0 ids:hostname= $(hostname) 20.04-server- cloudimg- amd64-disk- kvm-root- password. img u2004 prefix- length 22 pool0 network- type physical- network physnet0 network- type vlan physical- network physnet0 --provider-segment 100
> 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_
> sudo ovs-vsctl set Open_vSwitch . external_
>
> # 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-
>
> openstack address scope create scope0
> openstack subnet pool create --address-scope scope0 --pool-prefix
> 10.0.0.0/8 --default-
>
> # external net
> openstack network create net-physnet0 --external --provider-
> flat --provider-
> 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-
> --provider-
> 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 SRV-ATTR: instance_ name )"
> 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-
>
> # 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).
> /bugs.launchpad .net/bugs/ 1924776 /bugs.launchpad .net/neutron/ +bug/1924776/ +subscriptions Notification- Type: bug Undecided; ubuntu; sourcepackage= neutron; component=main; Undecided; assignee=None; Bug-Information -Type: Public Bug-Private: no Bug-Security- Vulnerability: no Bug-Commenters: bence-romsics james-page Bug-Reporter: James Page (james-page) Bug-Modifier: Bence Romsics (bence-romsics) Message- Rationale: Subscriber Message- For: james-page
> ** Changed in: neutron
> Status: New => Incomplete
>
> ** Tags added: ovn
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> 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:/
>
> Launchpad-
> Launchpad-Bug: product=neutron; status=Incomplete; importance=
> assignee=None;
> Launchpad-Bug: distribution=
> status=New; importance=
> Launchpad-Bug-Tags: ovn
> Launchpad-
> Launchpad-
> Launchpad-
> Launchpad-
> Launchpad-
> Launchpad-
> Launchpad-
> Launchpad-
>