The size of MTU only really matters for the server and client. The between connections need to be larger than the packets that are being sent.
Scenario 1: Server - 1400 MTU Client - 1400 MTU Switches - 9216 MTU OVS - 1500 MTU Result: Successful - Traffic passes without any issue Scenario 2: Server - 1520 MTU Client - 1520 MTU Switches - 1516 MTU OVS - 1500 MTU Result: Failure - Traffic will have issues passing through. So just make sure everything in-between is higher than your server and client. --Joe On Fri, Mar 13, 2015 at 9:28 AM, George Shuklin <[email protected]> wrote: > Hello. > > We've hit badly changes in behaviour of OVS when we switched from 3.08 to > 3.13 kernel. When runs on 3.11 or above, OVS starts to use kernel GRE > services. And they copy DNF (do not fragment) flag from encapsulated packet > to GRE packet. And this mess up all things, because ICMP messages about > dropped GRE never reach neither source nor destination of underlying TCP. > > We've fixed problems with MTU by using option for DHCP for dnsmasq. This > lower MTU inside instances. But there are routers (router namespaces) and > they are still using 1500 bytes MTU. > > I feel like this can cause problems with some types of traffic, when > client (outside of openstack) sending DNF packets to instance (via > floating) and that packet is silently dropped. > > 1) Is those concerns have any real life implication? TCP should take in > account MTU on server and works smoothly, but other protocols? > 2) Is there any way to lower MTU inside router namespace? > > Thanks. > > P.S. Jumbo frames is not an option due reasons outside of our reach. > > _______________________________________________ > OpenStack-operators mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
