[openstack-dev] [Neutron] MTU configuration pain

Ian Wells ijw.ubuntu at cack.org.uk
Mon Jan 25 23:13:06 UTC 2016


On 25 January 2016 at 07:06, Matt Kassawara <mkassawara at gmail.com> wrote:
> Overthinking and corner cases led to the existing implementation which
doesn't solve the MTU problem and arguably makes the situation worse
because options in the configuration files give operators the impression
they can control it.

We are giving the impression we solved the problem because we tried to
comprehensively solve the problem (documentation aside, apparently).  It's
complex when you want to do complex things, but the right answer for basic
end users is adding these two lines to neutron.conf, which I don't think is
asking too much:

path_mtu = 1500 # for VXLAN and GRE; MTU is 1450 on ports on VXLAN networks
segment_mtu = 1500 # for VLAN; MTU is 1500 on ports on VLAN networks

(while leaving the floor open for the other 1% of cases, where the options
cover pretty much everything you'd want to do).

So.  I don't know what path_mtu and segment_mtu settings you used that
disappointed you; could you recap?  Can you tell me whether the two options
above help?

> For example, the segment_mtu does nothing in the in-tree drivers, the
network_device_mtu option only impacts parts of some in-tree drivers, and
path_mtu only provides a way to change the MTU for VMs for all in-tree
drivers.

I was reading what documentation I could find (I may have written the spec,
but I didn't write the code, so I have to check the docs like everyone
else) and it says it should work - so anything else is a bug, which we
should go out and fix.  What test cases did you try?

network_device_mtu is an old hack, this much I know, and path_mtu and
segment_mtu are intended to be the correct modern way of doing things.

path_mtu should not apply to all in tree drivers, specifically it should
only apply to L3 overlays (as segment_mtu should only apply to VLANs) (and
by the wording of your statement I have to ask - are you seeing VM MTU =
path MTU, because you shouldn't be).

I see there are plausible looking unit tests for segment_mtu, so if it's
not working then in what specific configuration is it not working?

>
> I ran my experiments without any of these options to provide a clean
slate for empirically analyzing the problem and finding a solution for the
majority of operators.

I'm afraid you've not been clear about what setups you've tested where
path_mtu and segment_mtu *are* set - you dismissed them so I presume you
tried.  When you say they don't do what you want, what do they do wrong?

>
>
> Matt
>
> On Mon, Jan 25, 2016 at 6:31 AM, Sean M. Collins <sean at coreitpro.com>
wrote:
>>
>> On Mon, Jan 25, 2016 at 01:37:55AM EST, Kevin Benton wrote:
>> > At a minimum I think we should pick a default in devstack and dump a
>> > warning in neutron if operators don't specify it.
>>
>> Here's the DevStack change that implements this.
>>
>> https://review.openstack.org/#/c/267604/
>>
>> Again this just fixes it for DevStack. Deployers still need to set the
>> MTUs by hand in their deployment tool of choice. I would hope that we
>> can still move forward with some sort of automatic discovery - and also
>> figure out a way to take it from 3 different config knobs down to like
>> one master knob, for the sake of sanity.
>>
>> --
>> Sean M. Collins
>>
>>
__________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160125/8c8d2bc1/attachment.html>


More information about the OpenStack-dev mailing list