<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 11, 2016 at 4:39 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On 07/11/2016 07:45 AM, Sam  Yaple wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Hello,<br>
<br>
There was alot of work to get MTU advertisement working well in Mitaka.<br>
With the work that was done we can finally have 1500 mtu networks for<br>
tunneled networks if the underlying infrastructure supports jumbo frames.<br>
<br>
Its fantastic for people who have 1500 mtu networks and want to use<br>
vxlan, no more hacks to get the instance to use 1450 mtu. Its fantastic<br>
for people who want to use 1500+ networks and get the instances setup<br>
with 9000 mtu interfaces. Its is not good for people who want consistent<br>
mtu no matter the network type. But thats fine, since mtu advertisement<br>
_could_ be disabled. Its a fantastic default to have it turned on.<br>
<br>
With a recent patchset [1] the ability to turn off MTU advertisements<br>
was deprecated in Newton. In the review it was stated there is no valid<br>
use case for it. I disagree.<br>
<br>
The scenario is the infrastructure has jumbo frames enabled, but I do<br>
not want the instances to be using jumbo frames, but I want them to be<br>
using the default 1500 mtu that the rest of the world operates on. This<br>
would still setup all of the virtual switching infrastructure to the<br>
correct MTUs, but not try to adjust the instances MTUs. In this way the<br>
instances are only communicating at 1500 mtu, but never having to<br>
fragment/drop inside of the SDN when communicating with other networks<br>
even if it is a VXLAN or other tunneled network.<br>
<br>
Without the option to disable mtu advertisement, inside the same<br>
environment flat/vlan and gre/vxlan network will always have different<br>
mtu, even if the backend supports jumbo frames.<br>
<br>
My ask is we keep the advertise_mtu option, and keep it enabled by<br>
default. This would allow for the default, common 1500 mtu across<br>
networks of different types.<br>
<br>
This scenario would be very similiar to having a computer with 1500 mtu<br>
attached to a switch which supports jumbo frames. Just because the<br>
switch will accept and process a 9000 mtu frame, doesnt mean the<br>
computer has to send a 9000 mtu frame. A very common scenario in the<br>
real world.<br>
<br>
[1] <a href="https://review.openstack.org/#/c/310448/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/310448/</a><br>
</blockquote>
<br></div></div>
Hi Sam,<br>
<br>
Out of curiosity, in what scenarios is it better to limit the instance's MTU to a value lower than that of the maximum path MTU of the infrastructure? In other words, if the infrastructure supports jumbo frames, why artificially limit an instance's MTU to 1500 if that instance could theoretically communicate with other instances in the same infrastructure via a higher MTU?<br>
<br></blockquote><div>Hey Jay,</div><div><br></div><div>A not-so-uncommon way to setup networks in neutron involves the use of 1:1 NATs. You have a firewall device that holds real, valid public addresses that map to private addresses (RFC-1918). So to OpenStack the network appears as a private network, but some of those address map to public addresses outside of OpenStack's sphere of knowledge. This works really, really well when you have multiple separate ranges of public ip addresses and separate gateways for each and you want to use them without creating multiple subnets on an external network with OpenStack. This has been written about in blog posts [1] and used in enterprise environments (it is what Rackspace does for their private cloud [2]).</div><div><br></div><div>In this situation, since you are mapping real-ips and the real world runs on 1500 mtu, you want to make sure your MTUs match in ways that cannot be auto-discovered. A good way to do this is to just use the default 1500 mtu for every instance and ensure that that never fragments (which means at least 1550 mtu networks for vxlan). So in this case you would have setup your network in such a way that a 1500 mtu frame from the internet can arrive at your instance without ever being fragment, and outgoing traffic isn't trying to send >1500mtu packets into the real internet.</div><div><br></div><div>Additionally, there may be other services using the interface (it is not dedicated to just neutron traffic) such as ceph which loves high MTUs. I mention this as a secondary point because neutron doesn't affect this at all, but it is related to your question.</div><div><br></div><div>[1] <a href="http://dachary.org/?p=2466">http://dachary.org/?p=2466</a></div><div>[2] <a href="https://developer.rackspace.com/blog/neutron-networking-l3-agent/">https://developer.rackspace.com/blog/neutron-networking-l3-agent/</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Sorry if my question is poorly worded. I'm no networking expert and am genuinely curious here. :)<br>
<br>
Best,<br>
-jay<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>