network_device_mtu is not applied to VMs, only to agents

Fix proposed to branch: master
Review: https://review.openstack.org/111748

Change abandoned by Elena Ezhova (<email address hidden>) on branch: master
Review: https://review.openstack.org/111748
Reason: Due to Ian's comments and the spec he provided I abandon this change for now.

There is a BP [1] which targets MTU selection and advertisement and when implemented the problem, described in this bug report, will disappear.
[1] https://review.openstack.org/#/c/105989/

Er, yes, I know, I wrote both this bug and the blueprint. That doesn't make this bug incomplete, it makes it confirmed.

To clarify the situation, network_device_mtu in neutron.conf only affects MTU of interfaces which neutron agent creates.
Regarding VM tap device (on the hypervisor side), it should be controlled by network_device_mtu option in nova.conf (nova-compute).

In addition, I believe MTU advertised by DHCP server (usuaslly dnsmasq invoked by dhcp-agent) should be controlled by another config option. Even though your infrastructure allows larger MTU (like 9000 bytes), there is a case where traffic to external network still need to be 1500 bytes. Users can increase MTU on their VMs to 9000 bytes by their own risk to improve traffic throughput inside a data center.

[Some addition to my previous comment.]
At now if we want to control MTU advertised by DHCP server (dnsmasq), we need to prepare dnsmasq configuration file and specify this config file in dhcp_agent.ini. It is not a convenient way.
I think it would be nice if we have an option to control MTU size advertised by dnsmasq.
(This option will help environments where MTU needs to be set to some short value (<1500 bytes.))

https://blueprints.launchpad.net/neutron/+spec/mtu-selection-and-advertisement (though the selectable MTU part is low priority)

The kilo implementation of bp/mtu-selection-and-advertisement adds a mtu attribute to the network resource in the API and the db. The ML2 type drivers calc the MTU value (subtract encap) for each segment of the network and the type manager sets the mtu DB attrib for the network to the lowest of the calc'd segment values. This value is available in the DB (and API) and could be used by the linuxbridge mech driver to do something like setting the tap-interfaces' MTUs as described in this bug.

https://blueprints.launchpad.net/neutron/+spec/mtu-selection-and-advertisement
https://review.openstack.org/#/q/status:merged+project:openstack/neutron+branch:master+topic:bp/mtu-selection-and-advertisement,n,z
https://review.openstack.org/#/c/156318
https://review.openstack.org/#/c/169406 -- https://bugs.launchpad.net/neutron/+bug/1434671 (API extension)

Testing this I've found the following with a ml2-LB-vxlan config.

It looks like all the interfaces in the namespaces and without except for the VM's tap interface on the nova host have their MTU set correctly. I'm not sure if I'm missing something, but that's it.

Per Matthew's comment, it appears that the MTU change actually fixed this? Can someone confirm it's fixed?

With the addition of the MTU selection & advertisement parameters and the fix of [1] in Kilo, I don't see any remaining issues fitting this bug description--allowing jumbo frames.

The fix for [1] addressed a Linuxbridge issue where the VM's tap interface would not pick up the MTU of the physical interface attached to the same bridge due to the ordering of adding the interfaces to the bridge.

Could we mark this as a Dup of [1]? or otherwise what is the process to close this out?

[1] https://bugs.launchpad.net/neutron/+bug/1443607