[Openstack-operators] MTU on router interface (neutron & GRE) without jumbo
Joseph Bajin
josephbajin at gmail.com
Sat Mar 14 18:52:37 UTC 2015
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 <george.shuklin at gmail.com>
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
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150314/c67dd3d5/attachment.html>
More information about the OpenStack-operators
mailing list