subnet's gateway ip can be unset while attached to router

Bug #2036423 reported by Weronika Sikora

This bug report will be marked for expiration in 57 days if no further activity occurs. (find out why)

This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description


There's a weird issue with a subnet's gateway ip when it's attached to a router.

Normally, when you try to attach a subnet to a router, this subnet needs to have a gateway ip set. Otherwise the attachment will fail.

So we expect the subnet attached to a router to always have a gateway ip - this is used for creating the router interface after all.

However, when you attach a subnet with a gateway ip to a router and then attempt to unset this gateway ip... you can do that. There's no error, there's no connectivity lost, nothing is deleted. The router interface is still listed under "router show", the port exists, the connectivity is still working fine, as if nothing happened. But when you "subnet show", you can see the gateway ip is None.

This will result in error logs whenever the code tries to process certain things related to the router. Restarting the L3 agent will result in these errors, for example.

file: neutron/db/
method: get_subnet_for_dvr()
                LOG.error("Could not retrieve gateway port "
                          "for subnet %s", subnet_info)

file: neutron/plugins/ml2/drivers/openvswitch/agent/
method: _bind_centralized_snat_port_on_dvr_subnet()
                LOG.warning("DVR: Unable to retrieve subnet information "
                            "for subnet_id %s. The subnet or the gateway "
                            "may have already been deleted", subnet_uuid)

A user shouldn't be allowed to unset the gateway ip from a subnet that's already attached to a router. If they can't add a gateway-less subnet to a router, they shouldn't be allowed to unset it after the fact as well.

Tested on Stein and quickly checked if the behaviour still exists on Master.

To reproduce:

- Create a router
openstack router create r1
- Create a network with a subnet with gateway ip set (default behaviour)
openstack network create n1
openstack subnet create --subnet-range <blabla> --network n1 s1
- Add subnet to the router
openstack router add subnet r1 s1
- Unset the gateway ip from the subnet
openstack subnet set --gateway None s1

The gateway ip on the subnet will be listed as None, the router will still have the interface existing, the port will stil exist, all connectivity will remain intact, certain actions and agent restarts will trigger error logs.

tags: added: l3-dvr-backlog
removed: gateway gateway-ip router subnet unset
Revision history for this message
Brian Haley (brian-haley) wrote :

So there are a couple of things here.

1) Changing the gateway_ip of a subnet to None is valid as far as I know, it looks like the second sentence in the API doc is just a copy from the POST section, so should be removed.

"Gateway IP of this subnet. If the value is null that implies no gateway is associated with the subnet. If the gateway_ip is not specified, OpenStack Networking allocates an address from the CIDR for the gateway for the subnet by default."

And any instance booted that received DHCP info with that router as the gateway should continue to function.

2) Setting the gateway_ip to None won't remove the router interface, since in theory you could just be changing it to the interface of another router.

3) I didn't see the error/warning you mentioned in my quick testing when I restarted the l3-agent, so some more help would be required.

This isn't to say there's not a bug here, just that initial triage didn't reproduce it.

Changed in neutron:
status: New → Incomplete
Revision history for this message
Weronika Sikora (shushuda) wrote :

I did check again and while I couldn't see it on a singlenode Devstack, I did see it on multinode. The router needs to be DVR, in my case DVR-HA. The warning log prints on the snat node where the router is in backup mode, in the ovs agent. The error log prints then in the server.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for neutron because there has been no activity for 60 days.]

Changed in neutron:
status: Incomplete → Expired
Revision history for this message
Weronika Sikora (shushuda) wrote :

Hey, I see the ticket expired. I can still, however, reproduce this issue in the same way as described in my previous comment.

Changed in neutron:
status: Expired → Incomplete
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.