<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 11 July 2016 at 11:12, Chris Friesen <span dir="ltr"><<a href="mailto:chris.friesen@windriver.com" target="_blank">chris.friesen@windriver.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"><span class="">On 07/11/2016 10:39 AM, Jay Pipes wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Out of curiosity, in what scenarios is it better to limit the instance's MTU to<br>
a value lower than that of the maximum path MTU of the infrastructure? In other<br>
words, if the infrastructure supports jumbo frames, why artificially limit an<br>
instance's MTU to 1500 if that instance could theoretically communicate with<br>
other instances in the same infrastructure via a higher MTU?<br>
</blockquote>
<br></span>
It is my understanding that using the max path MTU is ideal, but that not all software does path MTU discovery.  Also, some badly-designed security devices can mess up PMTUD.<span class=""><font color="#888888"></font></span></blockquote><div><br></div><div>Ignoring PMTUD cases, which are routed (the original question was L2 transit), there are several use cases for specific networks having MTUs other than 9000.  Maybe you're talking to a device on a provider network that has a 1500 MTU not under your control, for instance.  It's also reasonable to have a cloud with a high internal MTU and a
 low external network MTU - maybe you have control over your own domain 
but not the whole network in which you're situated.<br><br>That is *not*, in fact, the same as having no MTU advertisement (but it seems to address the use case originally mentioned; if you could be selective about the MTU you used and the advertisements were corrected accordingly you could simply choose 1500).  There are also ports that need an MTU - router ports, DHCP ports - that are not receiving it via MTU advertisement, so  turning advertisement off and letting nature take its course doesn't work for everything.<br><br>The original MTU spec [1] - which never got fully implemented - detailed the intent, which was that OpenStack would choose a sensible default MTU value and advertise it, and that you could override that value for your own purposes.  I still think we need to implement the missing bits.<br>-- <br></div><div>Ian.<br><br></div><div>[1] <a href="https://specs.openstack.org/openstack/neutron-specs/specs/kilo/mtu-selection-and-advertisement.html">https://specs.openstack.org/openstack/neutron-specs/specs/kilo/mtu-selection-and-advertisement.html</a> - the bit that wasn't completed was 'the tenant can request a specific MTU on a network' - which, incidentally, is not 'the network will not pass packets bigger than X', but simply 'OpenStack and the tenant will agree that X is the MTU that ports shall use on that network; packets that size or less are guaranteed to pass over the L2 domain unmolested, and where an MTU is set on a port or advertised to it that will be the one'.  If you want a lecture on cloud MTUs I can give one.  But you really, really don't.<br></div></div></div></div>