RFE: detect obvious MTU mismatches for tunnelling and print a warning

[Jim Minter]

Hi,

It was non-obvious to me (and I suspect it will be non-obvious to a lot of others) that it really is absolutely necessary to increase the MTU when using VXLAN encapsulation (and presumably GRE and other tunnelling as well). The principal difficulty in diagnosis is that resulting VM behaviour is just so strange: depending on the guest and hypervisor kernel used and whether GSO is disabled on each using ethtool, network traffic may almost not flow at all, or be almost normal.

Very belatedly I spotted the doc note referenced in openstack-manuals commit c3ba506e97d59969ee2ad9476e8d1dfa55001641 , and this is a good start.

However, I think more is needed. This RFE is for neutron to sanity check for obvious MTU mismatches at startup (it may not be possible to catch all of them, but surely the obvious ones would be better than nothing) and print out a big warning.

For example, I'd say if VXLAN is configured + the MTU on the default gateway is 1500 + the MTU on the VXLAN network is <= 1554 (or whatever), then print a warning. Ditto for GRE, etc., etc.

It would be good if the warning said something like "MTU settings *may* be wrong: consult <OpenStack documentation link> for more details."

[Eugene Nikanorov (enikanorov)]

Not sure what exactly is suggested to be fixed.

[John Schwarz (jschwarz)]

The solution should be a warning log somewhere in neutron which will alert the user if the MTUs are not synced properly.
For example, if vxlan is configured but eth0's MTU is 1500 (and not ~1550) then a warning should be printed to the user that the VM's MTUs should be lowered to ~1450.

A proper proposal is being figured out and I will respond when we have more detail on how we want to fix this.

[OpenStack Infra (hudson-openstack)]

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

[Edgar Magana (emagana)]

I hate to be the bad guy for this commit but I disagree in two things, first that this is a real bug and second that Neutron should provide a mechanism to validate MTU configuration.

For the first one, you should propose a spec instead of a bug and therefore you will have a sub-set of the Neutron core reviewers checking whether the proposal is needed or not. Then, if you spec is approved then I will be reviewing the solution with more details.

[Assaf Muller (amuller)]

I don't think that a change of this magnitude needs a spec. We're not trying to solve the general issue (That's what Ian Well's approved spec is for). The proposed change is a sanity check, that cannot fail, but can emit a *warning*, nothing more. It doesn't actually *validate* the configuration. It can be used by support for example to help if they suspect that fragmentation may be at fault.

> The solution here propose may potentially break production deployment that handles network interfaces configuration different.

The proposed change cannot break anything.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Kyle Mestery (<email address hidden>) on branch: master
Review: https://review.openstack.org/129852
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[Ihar Hrachyshka (ihar-hrachyshka)]

This issue should be solved by latest MTU fixes in Mitaka.

[Ihar Hrachyshka (ihar-hrachyshka)]

Should be covered by:

bug 1542475
bug 1542108