[openstack-dev] [Neutron] MTU configuration pain

Ian Wells ijw.ubuntu at cack.org.uk
Mon Jan 25 03:43:27 UTC 2016


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160124/58ef852f/attachment.html>


More information about the OpenStack-dev mailing list