On 22 January 2014 10:01, Ian Wells <ijw.ubu...@cack.org.uk> wrote: > On 21 January 2014 21:23, Robert Collins <robe...@robertcollins.net> wrote: >> >> In OpenStack we've got documentation[1] that advises setting a low MTU >> for tenants to workaround this issue (but the issue itself is >> unsolved) - this is a problem because PMTU is fairly important :) >> Lowering *every* tenant when one tenant somewhere hits a new tunnel >> with a lower physical packet size limit isn't an answer. > > > The right answer is probably that (a) GRE drops packets it can't take (it > used to return a spoofed PMTU exceeded, which was faintly naughty cos it's
In that it's an L2 device which doesn't necessarily have an L3 address to send a PMTU /from/ which is why it is problematic (and spoofed). > not a router, and it breaks non-IP protocols; sounds like it fragments now, > which is probably no better), I'm about 99% sure it fragments at the moment, GRO on the servers we're using hides that (at a cost) but if I turn that off I should be able to see the bad boy in action :). I think dropping frames that can't be forwarded is entirely sane - at a guess it's what a physical ethernet switch would do if you try to send a 1600 byte frame (on a non-jumbo-frame switched network) - but perhaps there is an actual standard for this we could follow? > (b) we use the DHCP option to advertise the > right MTU, and Yes; the current manual assignment in neutron is global (which can be wrong). For instance we have provider networks that can have jumbo frames on, so there is a big performance hit if we advertise the wrong MTU to all ports. > (c) we require Neutron plugins to work out the MTU, which for > any encap except VLAN is (host interface MTU - header size). do you mean tunnel wrap overheads? (What if a particular tunnel has a trailer.. crazy talk I know). > At this point we probably discover that nothing respects the MTU option in > DHCP, mind you (I'm not saying it doesn't work; I'm just saying, have you > ever tried it?) I haven't :/ > This solution is pedantically correct and I would actually like to see it > implemented, but there's probably something more pragmatic that can be done. I think pedantically correct matters here, as low level plumbing needs to be predictable and reliable. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev