MTU für fastd an Unitymedia anpassen bzw. kontrollieren

uci set fastd.mesh_vpn.mtu=1312
uci commit fastd
/etc/init.d/fastd restart
4 „Gefällt mir“

THX!

werde ich mal auf die UM-Client-Nodes übertragen.

Jo cool, mit MTU=1312 haben wir gerade einen „usselig“ laufenden Router in Stabilität gebracht.
(Langzeittest steht aber noch aus)

@thomasDOTwtf @Lars Was spricht denn theoretisch dagegen, dass wir die kleinere MTU fest in die site.conf nehmen?

Hoffe auch das „meine UM Schäfchen“ nun RUHE geben :wink:

Ist meine Meinung nach auf jeden Fall was für die FAQ.

Für die Snapshots hatte ich am 13/4 für die snapshots „MTU=1312“
bereits mal angefragt…

Dagegen spricht, dass 90% der Router einen wahnsinnigen Performance-Verlust von unter 5% erleiden.

Wo Freifunk doch immer daran gemessen wird, wie schnell es ist… Nicht umsonst geht gefühlt 50% unseres „Nutztraffics“ (also nach Abzug von OGM und Heimrouter-Verkabelungs-Unfällen an den „gelben Ports“) auf speedtest.net

Das hilft leider nicht. Die Fastd-Konfiguration muss auf beiden Seiten angepasst werden. Stimmt die MTU nicht bei fastd <= v16 nicht, gibt es Netzwerkprobleme, daher ist bei fastd v17 keine Verbindung möglich wenn beide Seiten nicht die selbe MTU eingestellt haben.

LG Ruben

Dafür läuft’s aber ganz schön viel besser, als vorher.

Dafür spricht, dass man sich sonst wohl alle UM-Internet-Spender mit DS-Kack-Lite vergrault
und die dürften in nächster Zeit eher mehr als weniger werden.

1 „Gefällt mir“

Da oute ich mich mal als einer der OOKLA/speedtest.net user.
Preisfrage: Warum mache ich das?

Weil der Durchsatz bei mir unter Freifunk bislang leider oft „Grütze“
ist wenn die VPN-Verbindung rum zickt.
Sollte das an den MTU-Settings für UM liegen hätte ich
künftig keine/wenig(er) Veranlassung OOKLA zu nutzen…
…somit könnte dann auch wieder Traffic gespart werden :wink:

MAL IM ERNST:

Stabilität geht VOR Tempo: denke ich das 5% Verlust für die „NICHT-UMs“
zumutbar wären wenn die UMs (zumindest in meiner Gegend hab ich weit Über 50%)
im Gegenzug „stabil & performat“ laufen.
Da die UMs in der Regel ja „unlimited“ einspeisen, würde - so meine Vermutung - die
gesamt Performance nicht leiden.

Kann bitte jemand ein UMFRAGE „Über welchen Provider wird eingespeist“ erstellen?

Wenn wir ein brauchbares Monitoring hätten ("Performance-Status IP-Anbindung, Auslastung und Verfübbarkeit Supernodes, Mail-Alerts für Downtime der ‚eigenen‘ Router -gemäß Kriterien-), dann könnten sich vermutlich viele von uns die Hausmeisterei sparen.

Technisch ist das nicht schwierig aufzusetzen. Es müsste halt nur wer machen.

Habt ihr nur die Clients oder auch die Supernodes auf MTU 1312 umgestellt?

Bei uns laufen sowohl Clients als auch unsere Gateways („Supernodes“) mit MTU 1312, da wir auf fastd v17 setzen.
Bei fastd v17 stirbt die fastd Instanz gleich nach dem Start wenn Client und Gateway eine unterschiedliche MTU haben (siehe auch ChangeLog für fastd v17 fastd v17 — fastd 17 documentation).

Gut, wir haben in der Domäne Möhne v16 laufen.
Die Frage ist jetzt nur noch, ob es denn was bringt Node-seitig die MTU herunterzufahren als Workaround, oder ob man sich die Mühe sparen kann, weil die Supernodes das auch brauchen.

Ich sehe nämlich eine deutliche Verbesserung, wenn man nur Node-seitig ändert.

Tante Edith sagt:

MTU mismatch is fatal
fastd will now refuse to perform a handshake instead of just printing a warning when its configured MTU
doesn’t match the peer’s one. Such a configuration is always broken and will lead to issues with
big packets.

Ich lese daraus: Das „Sterben der Fastd-Instanz“ in v17 ist die Konsequenz daraus, dass es total scheiße ist, die MTU des Nodes ungleich des Supernodes zu setzen. Man zieht dann also die Reißleine, damit nichts schlimmeres passiert.

@dgoersch Wie ist den die MTU Einstellung in der Niersufer Communty? Ich speise auch über UM (ipv4 only) ein.

Bei IPv4 juckt dat nich.

danke, das reicht mir ja schon :slight_smile:

Hi,

wie schlägt sich der Router nach der Umstellung im „langzeit Test“?
Hab bei mir wieder die Defaults eingetragen weil mal wieder NIX mehr ging…

Was hat sich den Unitymedia jetzt noch einfallen lassen, dass die mtu unter 1406 muss?
Ich habe in Aachen auch zwei Anschlüsse die wieder Probleme machen.

Es war ja eh schon von mtu=1312 die Rede. :frowning:

Ja genau, also unter 1406 das nachweislich für normale IPv6 Anschlüsse reicht.

Mich interessiert sehr ob jemand weiß was bei Unitymedia die maximale Paketgröße noch weiter verringert.