Open Stack

>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" <mkassawara at gmail.com> wrote:

>
>
> On Mon, Jan 18, 2016 at 4:14 PM, Kevin Benton <blak111 at 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 <sean at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160119/06f9a6d0/attachment.html>