[openstack-dev] [Neutron] MTU configuration pain

Kevin Benton blak111 at gmail.com
Mon Jan 25 04:18:33 UTC 2016

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

More information about the OpenStack-dev mailing list