Open Stack

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 <blak111 at 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" <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
>>
>>
> __________________________________________________________________________
> 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/60567d9d/attachment.html>