No. However, we ought to determine what happens when both DHCP and RA advertise it.
On Tue, Jan 19, 2016 at 12:36 AM, Kevin Benton <blak...@gmail.com> wrote: > >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 > >
__________________________________________________________________________ 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