Hallo,
an welcher stelle kann ich den MTU-Wert fastd anpassen bzw. kontrollieren?
Kannst du nicht selber machen. Viel interessanter ist aber welcher MTU-Wert bei Unitymedia mit IPv4 und 6 funktioniert.
Wir haben hier 1312 im fastd und fahren damit bei Unitymedia inzwischen ganz gut mit. Vorher haben sich die Nodes dann sporadisch aus dem Netz gekegelt und nie wirklich davon erholt. Da half dann häufig nur ein Neustart.
Einen Performance Unterschied zwischen 1312 und 1426 bzw. 1406 ist nicht wirklich messbar bei den kleinen 841ern.
1 „Gefällt mir“
Wenn ich es nicht ändern kann ist er also auf 1426 fest vorkompiliert - oder?
Würde gerne mal mit den von „wem auch immer“ vorgeschlagenen MTU 1312 testen
@thomasDOTwtf
kannst du mal eine TESTFIRMARE auf http://moehne-vis.freifunk-rheinland.net/images/experimental/
erstellen und veröffentlichen?
Please note that the MTU of 1426 used by many communities for VPN over IPv4 is too big for IPv6 as the IPv6 header is 20 bytes longer (fastd over IPv4 has an overhead of 66 bytes, fastd over IPv6 has an overhead of 86 bytes).
----------------8<----------------------
Gluon fastd IPv4, IPv6 Unitymedia Problem
Aber ich kann 1406 für IPv4 und IPv6 nehmen oder? eth0 Link encap:Ethernet Hardware Adresse bc:ae:c5:36:83:28 inet Adresse:10.188.252.66 Bcast:10.188.255.255 Maske:255.255.0.0 inet6-Adresse: fe80::beae:c5ff:fe36:8328/64 Gültigkeitsbereich:Verbindung inet6-Adresse: fda0:747e:ab29:7405:beae:c5ff:fe36:8328/64 Gültigkeitsbereich:Global inet6-Adresse: fda0:747e:ab29:7405:788f:20a5:2278:afa7/64 Gültigkeitsbereich:Global UP BROADCAST RUNNING…
---------8< ---------------
Im IRC wurde eine MTU 1312 empfohlen um maximal kompatibel zu sein, bei so wenig wie möglich Performanceeinbuße.
GENAU da ist MEIN PROBLEM!!!
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 
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
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.