Cannot delete a neutron network, if the currently configured MTU is lower than the network's MTU

Bug #1713499 reported by Claudiu Belu on 2017-08-28
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Slawek Kaplonski

Bug Description

Currently, the neutron API returns an error [1] when trying to delete a neutron network which has a higher MTU than the configured MTU[2][3].

This issue has been noticed in Pike.

[1] Error:
[2] neutron.conf:
[3] ml2_conf.ini:

Claudiu Belu (cbelu) on 2017-08-28
description: updated
Reedip (reedip-banerjee) wrote :

Would really appreciate if you can show the logs ( /var/log/neutron/neutron-server.log ) , or run the "openstack --debug network delete" to get more information.

Changed in neutron:
status: New → Incomplete
status: Incomplete → New
Reedip (reedip-banerjee) wrote :

Sorry, got the information in [1]

Changed in neutron:
assignee: nobody → Reedip (reedip-banerjee)
Reedip (reedip-banerjee) wrote :

I just checked out and found that I cannot create a network with MTU higher than a specified MTU.

I am interested in knowing how the network in you case was created in the first place. The steps of creation/updation and any other modifications done before the deletion operation was performed would be greatly appreciated to rule out any uneven conditions.


Changed in neutron:
status: New → Incomplete
Claudiu Belu (cbelu) wrote :


1. Have global_physnet_mtu to something like 1500.
2. Create a neutron network with the said MTU.
3. Change the global_physnet_mtu to a lesser value.
4. Restart the neutron services.
5. Try to delete the neutron network.

Jakub Libosvar (libosvar) wrote :

Confirming the bug using reproduction steps from comment 4

Changed in neutron:
status: Incomplete → Confirmed
Kevin Benton (kevinbenton) wrote :


I think the appropriate fix for this is to just not try to validate the MTU during segment deletion.

In the call to _get_network_mtu at [1] you can pass a validate=False flag. This will stop the existing network from being undeletable.


Changed in neutron:
importance: Undecided → High

Fix proposed to branch: master

Changed in neutron:
status: Confirmed → In Progress
Miguel Lavalle (minsel) on 2018-01-26
Changed in neutron:
milestone: none → queens-rc1
tags: added: queens-backport-potential
Miguel Lavalle (minsel) wrote :

Haven't heard back from Reedip. Since we want to fix this bug early in Rocky and backport it to Queens, taking it over

Changed in neutron:
assignee: Reedip (reedip-banerjee) → Miguel Lavalle (minsel)
Changed in neutron:
assignee: Miguel Lavalle (minsel) → Brian Haley (brian-haley)
Changed in neutron:
assignee: Brian Haley (brian-haley) → Reedip (reedip-banerjee)
Changed in neutron:
assignee: Reedip (reedip-banerjee) → Brian Haley (brian-haley)
Changed in neutron:
assignee: Brian Haley (brian-haley) → Slawek Kaplonski (slaweq)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers