>Yup. We mostly attempt to do that now. Right, but not by default. Can you think of a scenario where advertising it would be harmful? On Jan 18, 2016 23:57, "Matt Kassawara" <mkassaw...@gmail.com> wrote:
> > > 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 > >
__________________________________________________________________________ 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