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.ubu...@cack.org.uk> wrote:
> On 23 January 2016 at 11:27, Adam Lawson <alaw...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
