Open Stack

I like both of those ideas.

On 24 January 2016 at 22:37, Kevin Benton <blak111 at gmail.com> wrote:

> At a minimum I think we should pick a default in devstack and dump a
> warning in neutron if operators don't specify it.
>
> I would still be preferable to changing the default even though it's a
> behavior change considering the current behavior is annoying. :)
> On Jan 24, 2016 23:31, "Ian Wells" <ijw.ubuntu at cack.org.uk> wrote:
>
>> On 24 January 2016 at 22:12, Kevin Benton <blak111 at gmail.com> wrote:
>>
>>> >The reason for that was in the other half of the thread - it's not
>>> possible to magically discover these things from within Openstack's own
>>> code because the relevant settings span more than just one server
>>>
>>> IMO it's better to have a default of 1500 rather than let VMs
>>> automatically default to 1500 because at least we will deduct the encap
>>> header length when necessary in the dhcp/ra advertised value so overlays
>>> work on standard 1500 MTU networks.
>>>
>>> In other words, our current empty default is realistically a terrible
>>> default of 1500 that doesn't account for network segmentation overhead.
>>>
>> It's pretty clear that, while the current setup is precisely the old
>> behaviour (backward compatibility, y'know?), it's not very useful.  Problem
>> is, anyone using the 1550+hacks and other methods of today will find their
>> system changes behaviour if we started setting that specific default.
>>
>> Regardless, we need to take that documentation and update it.  It was a
>> nasty hack back in the day and not remotely a good idea now.
>>
>>
>>
>>> On Jan 24, 2016 23:00, "Ian Wells" <ijw.ubuntu at cack.org.uk> wrote:
>>>
>>>> On 24 January 2016 at 20:18, Kevin Benton <blak111 at gmail.com> wrote:
>>>>
>>>>> I believe the issue is that the default is unspecified, which leads to
>>>>> nothing being advertised to VMs via dhcp/ra. So VMs end up using 1500,
>>>>> which leads to a catastrophe when running on an overlay on a 1500 underlay.
>>>>>
>>>> That's not quite the point I was making here, but to answer that: looks
>>>> to me like (for the LB or OVS drivers to appropriately set the network MTU
>>>> for the virtual network, at which point it will be advertised because
>>>> advertise_mtu defaults to True in the code) you *must* set one or more of
>>>> path_mtu (for L3 overlays), segment_mtu (for L2 overlays) or physnet_mtu
>>>> (for L2 overlays with differing MTUs on different physical networks).
>>>> That's a statement of faith - I suspect if we try it we'll find a few
>>>> niggling problems - but I can find the code, at least.
>>>>
>>>> The reason for that was in the other half of the thread - it's not
>>>> possible to magically discover these things from within Openstack's own
>>>> code because the relevant settings span more than just one server.  They
>>>> have to line up with both your MTU settings for the interfaces in use, and
>>>> the MTU settings for the other equipment within and neighbouring the cloud
>>>> - switches, routers, nexthops.  So they have to be provided by the operator
>>>> - then everything you want should kick in.
>>>>
>>>> If all of that is true, it really is just a documentation problem - we
>>>> have the idea in place, we're just not telling people how to make use of
>>>> it.  We can also include a checklist or a check script with that
>>>> documentation - you might not be able to deduce the MTU values, but you can
>>>> certainly run some checks to see if the values you have been given are
>>>> obviously wrong.
>>>>
>>>> In the meantime, Matt K, you said you hadn't set path_mtu in your
>>>> tests, but [1] says you have to ([1] is far from end-user consumable
>>>> documentation, which again illustrates our problem).
>>>>
>>>> Can you set both path_mtu and segment_mtu to whatever value your switch
>>>> MTU is (1500 or 9000), confirm your outbound interface MTU is the same
>>>> (1500 or 9000), and see if that changes things?  At this point, you should
>>>> find that your networks get appropriate 1500/9000 MTUs on VLAN based
>>>> networks and 1450/8950 MTUs on VXLAN networks, that they're advertised to
>>>> your VMs via DHCP and RA, and that your routers even know that different
>>>> interfaces have different MTUs in a mixed environment, at least if
>>>> everything is working as intended.
>>>> --
>>>> Ian.
>>>>
>>>> [1]
>>>> https://github.com/openstack/neutron/blob/544ff57bcac00720f54a75eb34916218cb248213/releasenotes/notes/advertise_mtu_by_default-d8b0b056a74517b8.yaml#L5
>>>>
>>>>
>>>>> On Jan 24, 2016 20:48, "Ian Wells" <ijw.ubuntu at cack.org.uk> wrote:
>>>>>
>>>>>> On 23 January 2016 at 11:27, Adam Lawson <alawson at aqorn.com> wrote:
>>>>>>
>>>>>>> For the sake of over-simplification, is there ever a reason to NOT
>>>>>>> enable jumbo frames in a cloud/SDN context where most of the traffic is
>>>>>>> between virtual elements that all support it? I understand that some
>>>>>>> switches do not support it and traffic form the web doesn't support it
>>>>>>> either but besides that, seems like a default "jumboframes = 1" concept
>>>>>>> would work just fine to me.
>>>>>>>
>>>>>>
>>>>>> Offhand:
>>>>>>
>>>>>> 1. you don't want the latency increase that comes with 9000 byte
>>>>>> packets, even if it's tiny (bearing in mind that in a link shared between
>>>>>> tenants it affects everyone when one packet holds the line for 6 times
>>>>>> longer)
>>>>>> 2. not every switch in the world is going to (a) be configurable or
>>>>>> (b) pass 9000 byte packets
>>>>>> 3. not every VM has a configurable MTU that you can set on boot, or
>>>>>> supports jumbo frames, and someone somewhere will try and run one of those
>>>>>> VMs
>>>>>> 4. when you're using provider networks, not every device attached to
>>>>>> the cloud has a 9000 MTU (and this one's interesting, in fact, because it
>>>>>> points to the other element the MTU spec was addressing, that *not all
>>>>>> networks, even in Neutron, will have the same MTU*).
>>>>>> 5. similarly, if you have an external network in Openstack, and
>>>>>> you're using VXLAN, the MTU of the external network is almost certainly 50
>>>>>> bytes bigger than that of the inside of the VXLAN overlays, so no one
>>>>>> number can ever be right for every network in Neutron.
>>>>>>
>>>>>> Also, I say 9000, but why is 9000 even the right number?  We need a
>>>>>> number... and 'jumbo' is not a number.  I know devices that will let you
>>>>>> transmit 9200 byte packets.  Conversely, if the native L2 is 9000 bytes,
>>>>>> then the MTU in a Neutron virtual network is less than 9000 - so what MTU
>>>>>> do you want to offer your applications?  If your apps don't care, why not
>>>>>> tell them what MTU they're getting (e.g. 1450) and be done with it?
>>>>>> (Memory says that the old problem with that was that github had problems
>>>>>> with PMTUD in that circumstance, but I don't know if that's still true, and
>>>>>> even if it is it's not technically our problem.)
>>>>>>
>>>>>> Per the spec, I would like to see us do the remaining fixes to make
>>>>>> that work as intended - largely 'tell the VMs what they're getting' - and
>>>>>> then, as others have said, lay out simple options for deployments, be they
>>>>>> jumbo frame or otherwise.
>>>>>>
>>>>>> If you're seeing MTU related problems at this point, can you file
>>>>>> bugs on them and/or report back the bugs here, so that we can see what
>>>>>> we're actually facing?
>>>>>> --
>>>>>> Ian.
>>>>>>
>>>>>>
>>>>>> __________________________________________________________________________
>>>>>> 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
>>>>
>>>>
>>>
>>> __________________________________________________________________________
>>> 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/20160124/713e4e6c/attachment.html>