global_physnet_mtu is set to 1400 instead of ethernet standard 1500

[Sai Sindhur Malleni]

In /etc/neutron/neutron.conf, global_physnet_mtu is set to 1400 instead of the ethernet standard 1500, causing all virtual networking component on the cloud to be configured at 1350 MTU(1400-50 for VXLAN headers). This leads to significant performance drop in throughput.

The mtu of the external network on the controller has been shown as an example:
 neutron net-show public
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | True |
| availability_zone_hints | |
| availability_zones | nova |
| created_at | 2016-06-07T12:44:29 |
| description | |
| id | 9e07b576-dbc0-4cc1-801f-8dd16be3283e |
| ipv4_address_scope | |
| ipv6_address_scope | |
| is_default | False |
| mtu | 1350 |
| name | public |
| port_security_enabled | True |
| provider:network_type | vxlan |
| provider:physical_network | |
| provider:segmentation_id | 44 |
| qos_policy_id | |
| router:external | True |
| shared | False |
| status | ACTIVE |
| subnets | 6ec8fdc1-6c54-4097-ba6a-7dd54ca3cba8 |
| tags | |
| tenant_id | bed81c5587c54f358a88247bd09f9ddd |
| updated_at | 2016-06-07T12:44:29 |
+---------------------------+--------------------------------------+

[Ben Nemec (bnemec)]

I believe this probably has to do with https://github.com/openstack/puppet-neutron/commit/d301833c2c379db706a52a582f502bb14cd4d34f

It means that the config opt we were setting in Neutron before has been deprecated and I suspect the behavior of the new opt is not exactly the same. I know there was a proposal to just stop setting tenant mtu since Neutron now does that itself, so that's probably the solution here. Needs some testing to ensure everything still gets set sanely though.

[Brent Eagles (beagles)]

Yes, the NetworkTenantMtu config and how it is propagated is pretty broken really. It's impact also exceeds what could be construed as a "tenant" MTU. If were only mapped to the neutron configuration we could alter the default. Unfortunately, it isn't. It looks as though it would be better if it just goes away.

FWIW, there is a related bug https://bugs.launchpad.net/tripleo/+bug/1590100.

[Brent Eagles (beagles)]

Proposed patch for mitaka:

https://review.openstack.org/#/c/333333/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/333333
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=ecc4e4113671e2197efe908f0fd77da894fb5fef
Submitter: Jenkins
Branch: stable/mitaka

commit ecc4e4113671e2197efe908f0fd77da894fb5fef
Author: Brent Eagles <email address hidden>
Date: Wed Jun 22 14:46:25 2016 -0230

    Properly direct MTU parameters and allow service defaults

    This patch wires NeutronTenantMtu to path_mtu instead of the deprecated
    network_device_mtu. This maintains similar behavior but allows
    global_physnet_mtu to be set independently. The default for this
    parameter has also been changed to an empty string, allowing proper
    service defaults that enable Neutron's MTU logic to be used.

    This patch also sets the default for NeutronDnsmasqOptions to an empty
    string and introduces handling of empty values when creating the dnsmasq
    configuration file.

    Note that is a Mitaka only patch. The properties were completely removed
    in Newton in change I540ba5dc69d0506f71b59746efcce94c73f9317f.

    Closes-Bug: 1590100
    Closes-Bug: 1590101

    Change-Id: I6d12a2b741b4a81bf60f47fd553b7f71cd25b1c1

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/tripleo-heat-templates 2.1.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/tripleo-heat-templates 2.1.0 release.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/liberty
Review: https://review.openstack.org/404355

[OpenStack Infra (hudson-openstack)]

Change abandoned by Joshua Hesketh (<email address hidden>) on branch: stable/liberty
Review: https://review.openstack.org/404355
Reason: This branch (stable/liberty) is at End Of Life