Open Stack

Thanks!

But those examples are for same MTU for client and server. If we have

Client: 1500
router in the middle 1500
OVS/GRE: 1458
server: 1458

For tcp this is ok. But can it hurt somehow other protocols? UDP, RST, etc?

On 03/14/2015 08:52 PM, Joseph Bajin wrote:
> 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 <mailto: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
>     <mailto: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/20150318/a0b15ca3/attachment.html>