Bug 1371582

Summary:	dnsmasq-neutron.conf is left unmanaged after installation
Product:	[Community] RDO	Reporter:	Phil Sutter <psutter>
Component:	openstack-packstack	Assignee:	Martin Magr <mmagr>
Status:	CLOSED UPSTREAM	QA Contact:	Shai Revivo <srevivo>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	Mitaka	CC:	aortega, chris.brown, chrisw, derekh, psutter, srevivo
Target Milestone:	---
Target Release:	trunk
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-07-21 12:57:54 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Phil Sutter 2016-08-30 14:19:54 UTC

During an installation of OpenStack using packstack, the file /etc/neutron/dnsmasq-neutron.conf is being created. It's sole purpose seems to be announcing the correct MTU via DHCP option 26 to instances. This makes sense in order to avoid unnecessary fragmentation, though it is not adjusted as configuration changes are made.

As a practical example, in my setup I changed the default MTU used for tenant networks as explained in [1] by reconfiguring Neutron like so:

openstack-config --set /etc/neutron/neutron.conf DEFAULT global_physnet_mtu 9000
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2 path_mtu 9000

and after restarting neutron-server I recreated the existing tenant network
including subnet and router.

To my surprise, contrary to what the documentation in [1] claims, newly
created instances still have an MTU of 1400 configured in their interfaces.
This is especially severe since the Neutron facing side of the VM interface
already uses 8950 MTU size, therefore tends to send oversized packets to the
VM.

The problem's solution lies in adjusting the advertised MTU in
dnsmasq-neutron.conf, and this really should be done automatically. Moreover,
the file is completely ignored: removing it and rebooting the box doesn't
restore it, which is an issue on it's own.

I'm not sure whether Neutron or Nova should take over control of this config,
probably whichever instance also controls the running dnsmasq instance.
Neutron at least knows which MTU should be advertised.

[1] http://docs.openstack.org/mitaka/networking-guide/config-mtu.html

Comment 1 Christopher Brown 2017-06-18 13:27:20 UTC

Hi Phil,

There have been some changes to the way MTU is calculated and implemented since you filed this.

Can you confirm if this is still an issue?

Comment 2 Phil Sutter 2017-07-21 11:25:56 UTC

Hi Christopher,

(In reply to Christopher Brown from comment #1)
> There have been some changes to the way MTU is calculated and implemented
> since you filed this.
> 
> Can you confirm if this is still an issue?

Sorry, but I don't have the environment available anymore. Is /etc/neutron/dnsmasq-neutron.conf still used to propagate MTU values to instances? If so, is there any code which updates the file during startup of neutron-server?

Comment 3 Christopher Brown 2017-07-21 12:57:54 UTC

Hi Phil,

Thanks for the response.

Here is the latest info:

https://docs.openstack.org/ocata/networking-guide/config-mtu.html

So I think your original issue should be resolved or at least, there is a way to fix MTU for VMs to the manner you require.

I'll close this but I guess re-open if still a problem in the future?