<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 4 August 2014 07:03, Elena Ezhova <span dir="ltr"><<a href="mailto:eezhova@mirantis.com" target="_blank">eezhova@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">Hi!</span></p>
<br><p dir="ltr" style="line-height:1.5;margin-top:0pt;margin-bottom:14pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">I feel I need a piece of advice regarding this bug [1].</span></p>
<p dir="ltr" style="line-height:1.5;margin-top:0pt;margin-bottom:14pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">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. </span></p>
</span></div></blockquote><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span><p dir="ltr" style="line-height:1.5;margin-top:0pt;margin-bottom:14pt">
<span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">MTU can be specified by the dhcp agent by adding the option to dnsmasq_config_file like it’s done here [2].</span></p>
</span></div></blockquote><div>Also correct, although only useful if you're using IPv4 <i>and</i> you have a DHCPv4 agent running in the guest <i>and</i> you have a DHCP agent that asks for the MTU option - none of which is necessarily true.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span><p dir="ltr" style="line-height:1.5;margin-top:0pt;margin-bottom:14pt">
<span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent"> 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.</span></p>
</span></div></blockquote><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span>
<p dir="ltr" style="line-height:1.5;margin-top:0pt;margin-bottom:14pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">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.</span></p>
</span></div></blockquote><div>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.<br>
<br></div><div>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.<br>
<br>I put together the spec
<a href="https://blueprints.launchpad.net/neutron/+spec/mtu-selection-and-advertisement">https://blueprints.launchpad.net/neutron/+spec/mtu-selection-and-advertisement</a>
which tries to cover the options more universally.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span>
<p dir="ltr" style="line-height:1.5;margin-top:0pt;margin-bottom:14pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">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]</span></p>
</span></div></blockquote><div>Nor do certain sorts of Windows.<br></div><div><br>-- <br></div><div>Ian.<br></div></div><br></div></div>