Open Stack

On 4 August 2014 07:03, Elena Ezhova <eezhova at mirantis.com> wrote:

> Hi!
>
> I feel I need a piece of advice regarding this bug [1].
>
> The gist of the problem is that although there is an option
> network_device_mtu that can be specified in neutron.conf VMs are not
> getting that mtu on their interfaces.
>
Correct.  This (and veth_mtu if you're using OVS with the usual plugging
mechanism - don't ask me why it's independent, it probably shouldn't be) is
the equivalent of setting, on your switch, the MTU size.  It doesn't affect
the VM's perception of MTU size, in much the same way as reconfiguring a
physical switch would not automatically update the servers on a network
with the correct MTU.


> MTU can be specified by the dhcp agent by adding the option to
> dnsmasq_config_file like it’s done here [2].
>
Also correct, although only useful if you're using IPv4 *and* you have a
DHCPv4 agent running in the guest *and* you have a DHCP agent that asks for
the MTU option - none of which is necessarily true.


>  So one of the solutions might be to check whether the network_device_mtu
> is specified during spawning of Dnsmasq process and if it is add an option
> to Dnsmasq options file.
>
To generalise, the right solution is to tell the host using whatever
mechanisms are available (that would include Openstack DHCP, IPv6 RAs and
config drive data) what the MTU of the network was, if the MTU was set.  Of
course, the problem is that the network_device_mtu is not always set, and
it's not easy to automatically deduce, per the comment I put on that bug.


> But I am not sure whether this is something worth being fixed and if the
> above-described option is the right way to fix the bug.
>
The fix is worth doing but that's only a part of it.  Another part of it is
that the network_device_mtu is typically not universal - I might set up a
cloud with 9000 MTU tenant networks but still want my provider networks to
have an MTU of 1500 because that's what non-cloud devices have set.

The fix you propose is also a behavioural change, and very technically it
would be a break in backward compatibility to start advertising MTUs when
we didn't before.  I'm not sure I care too much about that but it's a point
to consider.

I put together the spec
https://blueprints.launchpad.net/neutron/+spec/mtu-selection-and-advertisement
which tries to cover the options more universally.


> By the way, as I found out, MTU cannot currently be set for instances that
> are running cirros, because cirros does not handle dhcp options like it’s
> said in the following bug. [3]
>
Nor do certain sorts of Windows.

-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140805/231a71e7/attachment.html>