On Mon, Jan 18, 2016 at 4:14 PM, Kevin Benton <blak...@gmail.com> wrote:
> Thanks for the awesome writeup. > > >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. > > 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... > Yup. Moving the MTU disparity to the first layer-3 device a packet traverses inbound to a VM saves us from burning IPs too. > > > > >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. > > 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? > Yup. We mostly attempt to do that now. On Fri, Jan 15, 2016 at 10:41 AM, Sean M. Collins <s...@coreitpro.com> >> wrote: >> >>> MTU has been an ongoing issue in Neutron for _years_. >>> >>> It's such a hassle, that most people just throw up their hands and set >>> their physical infrastructure to jumbo frames. We even document it. >>> >>> >>> http://docs.openstack.org/juno/install-guide/install/apt-debian/content/neutron-network-node.html >>> >>> > Ideally, you can prevent these problems by enabling jumbo frames on >>> > the physical network that contains your tenant virtual networks. Jumbo >>> > frames support MTUs up to approximately 9000 bytes which negates the >>> > impact of GRE overhead on virtual networks. >>> >>> We've pushed this onto operators and deployers. There's a lot of >>> code in provisioning projects to handle MTUs. >>> >>> http://codesearch.openstack.org/?q=MTU&i=nope&files=&repos= >>> >>> We have mentions to it in our architecture design guide >>> >>> >>> http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/arch-design/source/network-focus-architecture.rst#n150 >>> >>> I want to get Neutron to the point where it starts discovering this >>> information and automatically configuring, in the optimistic cases. I >>> understand that it can be complex and have corner cases, but the issue >>> we have today is that it is broken in some multinode jobs, even Neutron >>> developers are configuring it correctly. >>> >>> I also had this discussion on the DevStack side in >>> https://review.openstack.org/#/c/112523/ >>> where basically, sure we can fix it in DevStack and at the gate, but it >>> doesn't fix the problem for anyone who isn't using DevStack to deploy >>> their cloud. >>> >>> Today we have a ton of MTU configuration options sprinkled throghout the >>> L3 agent, dhcp agent, l2 agents, and at least one API extension to the >>> REST API for handling MTUs. >>> >>> So yeah, a lot of knobs and not a lot of documentation on how to make >>> this thing work correctly. I'd like to try and simplify. >>> >>> >>> Further reading: >>> >>> >>> http://techbackground.blogspot.co.uk/2013/06/path-mtu-discovery-and-gre.html >>> >>> http://lists.openstack.org/pipermail/openstack/2013-October/001778.html >>> >>> >>> https://ask.openstack.org/en/question/6140/quantum-neutron-gre-slow-performance/ >>> >>> >>> https://ask.openstack.org/en/question/12499/forcing-mtu-to-1400-via-etcneutrondnsmasq-neutronconf-per-daniels/ >>> >>> >>> http://blog.systemathic.ch/2015/03/05/openstack-mtu-pitfalls-with-tunnels/ >>> >>> https://twitter.com/search?q=openstack%20neutron%20MTU >>> >>> -- >>> Sean M. Collins >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Kevin Benton > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev