l2tp update and fix mtu

[Christoph süpke]

Hallo, wir haben uns mal bei anderen communities erkundigt, diese haben das
gleiche Problem mit der CPU last und durch ausschalten von pmtu discovery
behoben. Die kleinste MTU war afaik 1438. Das MTU discovery macht zu viel
last.

MFG Christoph Süpke

Am Samstag, 3. März 2018 schrieb Tim Niemeyer :

> Am Mittwoch, den 21.02.2018, 17:28 +0100 schrieb Robert Langhammer:
> > [PATCH 1/2] Update tunneldigger
> >
> > There are a few more patches left.
> >
> > [PATCH 2/2] fff-tunneldigger: set fix MTU for l2tp tunnel.
> >
> > Active pmtu is definitely preferable, but we have seen CPU load
> > issues when many tunnels are connected to a broker. This can be fixed
> > with a fixed mtu.
> Wo kommt da die hohe CPU Last her? Client und Server sollten am Anfang
> einmal die richtige MTU ausloten und dann wird das VPN auf ein Wert
> gestellt.
>
> Batman wird diesen Wert dann nutzen und größere Pakete fragmentieren.
> Wird ein 1500 Byte Paket übermittelt wird immer durch batman
> fragmentiert, ganz egal wie hoch die MTU vom Tunnel ist, so lange sie
> nicht >= 1500+Batman_Overhead hat.
>
> > When pmtu is disabled at the broker, the tunneldigger sets the mtu to
> > 1488, regardless of the broker's settings.
> > This mtu is too big. This results in a considerable (up to 80% I've
> > measured) break in the upload throughput.
> > A little too small mtu is irrelevant. Since only very few tunnels
> > have a mtu <1438, this value seems to me to be a good compromise.
> Was passiert denn, wenn jemand so ein Knoten an einer Leitung mit
> kleinerer MTU verwendet? Gehen die Pakete dann kaputt? Der Kompromiss
> könnte für ein paar wenige Leute das Netz kaputt machen, oder?
>
> > If pmtu is enabled, this patch has no effect.
> Wo wird denn pmtu aktiviert?
>
> Tim
> >
> > Robert
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20180303/4ef6c955/attachment.html>