<p dir="ltr">>Yup. We mostly attempt to do that now.</p>
<p dir="ltr">Right, but not by default. Can you think of a scenario where advertising it would be harmful? </p>
<div class="gmail_quote">On Jan 18, 2016 23:57, "Matt Kassawara" <<a href="mailto:mkassawara@gmail.com">mkassawara@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 18, 2016 at 4:14 PM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thanks for the awesome writeup.</div><span><div><br></div>><span style="font-size:12.8px">5) A bridge or veth pair with an IP address can participate in path MTU discovery (PMTUD). However, these devices do not appear to understand namespaces and originate the ICMP message from the host instead of a namespace. Therefore, the message never reaches the destination... typically a host outside of the deployment.</span><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">I suspect this is because we don't put the bridges into namespaces. Even if we did do this, we would need to allocate IP addresses for every compute node to use to chat on the network...</span></div></div></blockquote><div><br></div><div>Yup. Moving the MTU disparity to the first layer-3 device a packet traverses inbound to a VM saves us from burning IPs too.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><span><div><span style="font-size:12.8px"><br></span></div><div><br></div><div>><span style="font-size:12.8px">At least for the Linux bridge agent, I think we can address ingress MTU disparity (to the VM) by moving it to the first device in the chain capable of layer-3 operations, particularly the neutron router namespace. We can address the egress MTU disparity (from the VM) by advertising the MTU of the overlay network to the VM via DHCP/RA or using manual interface configuration.</span></div><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">So when setting up DHCP for the subnet, would telling the DHCP agent to use an MTU we calculate based on (global MTU value - network encap overhead) achieve what you are suggesting here?</span></div></div></blockquote><div><br></div><div>Yup. We mostly attempt to do that now.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 15, 2016 at 10:41 AM, Sean M. Collins <span dir="ltr"><<a href="mailto:sean@coreitpro.com" target="_blank">sean@coreitpro.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">MTU has been an ongoing issue in Neutron for _years_.<br>
<br>
It's such a hassle, that most people just throw up their hands and set<br>
their physical infrastructure to jumbo frames. We even document it.<br>
<br>
<a href="http://docs.openstack.org/juno/install-guide/install/apt-debian/content/neutron-network-node.html" rel="noreferrer" target="_blank">http://docs.openstack.org/juno/install-guide/install/apt-debian/content/neutron-network-node.html</a><br>
<br>
> Ideally, you can prevent these problems by enabling jumbo frames on<br>
> the physical network that contains your tenant virtual networks. Jumbo<br>
> frames support MTUs up to approximately 9000 bytes which negates the<br>
> impact of GRE overhead on virtual networks.<br>
<br>
We've pushed this onto operators and deployers. There's a lot of<br>
code in provisioning projects to handle MTUs.<br>
<br>
<a href="http://codesearch.openstack.org/?q=MTU&i=nope&files=&repos=" rel="noreferrer" target="_blank">http://codesearch.openstack.org/?q=MTU&i=nope&files=&repos=</a><br>
<br>
We have mentions to it in our architecture design guide<br>
<br>
<a href="http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/arch-design/source/network-focus-architecture.rst#n150" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/arch-design/source/network-focus-architecture.rst#n150</a><br>
<br>
I want to get Neutron to the point where it starts discovering this<br>
information and automatically configuring, in the optimistic cases. I<br>
understand that it can be complex and have corner cases, but the issue<br>
we have today is that it is broken in some multinode jobs, even Neutron<br>
developers are configuring it correctly.<br>
<br>
I also had this discussion on the DevStack side in <a href="https://review.openstack.org/#/c/112523/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/112523/</a><br>
where basically, sure we can fix it in DevStack and at the gate, but it<br>
doesn't fix the problem for anyone who isn't using DevStack to deploy<br>
their cloud.<br>
<br>
Today we have a ton of MTU configuration options sprinkled throghout the<br>
L3 agent, dhcp agent, l2 agents, and at least one API extension to the<br>
REST API for handling MTUs.<br>
<br>
So yeah, a lot of knobs and not a lot of documentation on how to make<br>
this thing work correctly. I'd like to try and simplify.<br>
<br>
<br>
Further reading:<br>
<br>
<a href="http://techbackground.blogspot.co.uk/2013/06/path-mtu-discovery-and-gre.html" rel="noreferrer" target="_blank">http://techbackground.blogspot.co.uk/2013/06/path-mtu-discovery-and-gre.html</a><br>
<br>
<a href="http://lists.openstack.org/pipermail/openstack/2013-October/001778.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack/2013-October/001778.html</a><br>
<br>
<a href="https://ask.openstack.org/en/question/6140/quantum-neutron-gre-slow-performance/" rel="noreferrer" target="_blank">https://ask.openstack.org/en/question/6140/quantum-neutron-gre-slow-performance/</a><br>
<br>
<a href="https://ask.openstack.org/en/question/12499/forcing-mtu-to-1400-via-etcneutrondnsmasq-neutronconf-per-daniels/" rel="noreferrer" target="_blank">https://ask.openstack.org/en/question/12499/forcing-mtu-to-1400-via-etcneutrondnsmasq-neutronconf-per-daniels/</a><br>
<br>
<a href="http://blog.systemathic.ch/2015/03/05/openstack-mtu-pitfalls-with-tunnels/" rel="noreferrer" target="_blank">http://blog.systemathic.ch/2015/03/05/openstack-mtu-pitfalls-with-tunnels/</a><br>
<br>
<a href="https://twitter.com/search?q=openstack%20neutron%20MTU" rel="noreferrer" target="_blank">https://twitter.com/search?q=openstack%20neutron%20MTU</a><br>
<span><font color="#888888"><br>
--<br>
Sean M. Collins<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>
</font></span></blockquote></div><br></div>
</div></div><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>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div><div>Kevin Benton</div></div>
</font></span></div>
<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>
<br></blockquote></div><br></div></div>
<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>
<br></blockquote></div>