Multi MTU script

Moin,
in einer abendlichen Mumblerunde stellte sich uns die Frage wie viel mehr Performance wir denn aus unseren Routern bekommen könnten wenn wir zumindest dort wo es geht mit einer höheren MTU arbeiten.

Ein kurzer Test mit einem 1043er von TPlink mit Fichtenfirmware:
MTU 1280: 12 Mbit
MTU 1450: 20 Mbit

Nun die Idee:
wir fahren auf den Servern eine weitere Fastd Instanz mit der höheren MTU auf einem anderen Port und legen in der Site.conf je eine peergroup für die 1280er und die 1450er MTU an.

Auf den Routern läuft folgendes Script beim Start, testet die höhere MTU und bei Erfolg wird die 1280er group deaktiviert, die 1450er aktiviert und fastd einmal neugestartet. Ins flash schreiben wir nicht, denn es wird bei jedem Start die MTU erneut besttimmt.

#!/bin/ash 
log="/tmp/automtu.log"
echo "$(date) Prüfe Internetverbindung" >> $log
if ping -I $(uci get network.mesh_wan.ifname) -W 60 185.66.195.242 | grep -q "time";
then echo "$(date) Internetverbindung vorhanden" >> $log && if uci get gluon-setup-mode.@setup_mode[0].enabled | grep -q "0";
then echo "$(date) Config Mode=off" >> $log && if uci show fastd.mesh_vpn.enabled | grep -q "1";
then echo "$(date) Fastd=on" >> $log && if traceroute -s $(ip -f inet address show $(uci get network.mesh_wan.ifname)| grep inet|cut -f 6 -d " "|cut -f 0 -d "/") -F -w 1 -m 20 -q 1 185.66.195.242 1450 | grep -q "forum.freifunk.net";
then echo "$(date) Setze MTU hoch" >> $log && uci set fastd.mesh_vpn.mtu=1450 && uci set fastd.mesh_vpn_backbone_1450.enabled=1 && uci set fastd.mesh_vpn_backbone_1280.enabled=0 &&  /etc/init.d/fastd restart;
fi;
fi;
fi;
fi
echo "$(date) Fertig" >> $log

Wir setzen das ganze an einer Hand voll Router in der Fichte testweise ein ohne große Probleme.

Anmerkungen:

  • Die URL/IP vom Forum sind nur Platzhalter
  • Nehmt nicht 8.8.8.8 bzw. google für den test denn die begrenzen die MTU bei 1406
4 Likes

Wie sieht das serverseitig aus?
Einfach die beiden Fastd auf die gleiche bridge? Oder erst als eigene Interfaces per Batman zusammengeschaltet?

Die Liegen auf der gleichen Bridge.

Hallo,

bei mir funktioniert das Multi MTU Skript irgendwie nicht wie erwartet.

Mein Setup:
Mein WR841N hängt an einer Fritzbox 3370 mit 16Mbit Telekom-VDSL.

Wenn ich jetzt per SSH auf meine 841 gehe und folgenden Traceroute absetzte:

traceroute -s $(ip -f inet address show $(uci get network.mesh_wan.ifname)| grep inet|cut -f 6 -d " "|cut -f 0 -d "/") -F -w 1 -m 20 -q 1 185.66.195.242 1450

dann kann ich als Packetsize eintragen was ich will. Trotz „-F“ (Set the don’t fragment bit) geht da alles durch.

Output für Packetsize von z.B. 2345 Byte:

~# traceroute -s $(ip -f inet address show $(uci get network.mesh_wan.ifname)| grep inet|cut -f 6 -d " "|cut -f 0 -d "/") -F -w 1 -m 20 -q 1 185.66.195.242 2345
traceroute to 185.66.195.242 (185.66.195.242) from 192.168.179.32, 20 hops max, 2345 byte packets
1  192.168.179.1 (192.168.179.1)  24.594 ms
2  217.0.118.65 (217.0.118.65)  25.735 ms
3  87.186.232.170 (87.186.232.170)  31.496 ms
4  f-ed3-i.F.DE.NET.DTAG.DE (62.154.14.142)  24.312 ms
5  xe-3-0-1.atuin.as6724.net (62.157.249.198)  27.500 ms
6  ae0.0.morla.as6724.net (81.169.144.33)  24.511 ms
7  xe-0-0-1.core-b30.as6724.net (85.214.0.64)  33.529 ms
8  freifunk-rheinland.bcix.de (193.178.185.74)  50.608 ms
9  forum.freifunk.net (185.66.195.242)  55.770 ms

Liegt das an meiner Fritzbox, die MSS Clamping macht (siehe AVR MTU Hinweiss ) oder mache ich da was falsch?

EDIT:
Ganz, aber wirklich ganz selten erhalte ich folgendes:

 1  192.168.179.1 (192.168.179.1)  9.951 ms
 2  p4FDA4AF9.dip0.t-ipconnect.de (79.218.74.249)  0.647 ms !F-1492

EDIT 2:
Firmware: Aktuelles Gluon Master vom 7.11.2015

1 Like

Wenn ich mit meinem Rechner (OS X) direkt über meine Fritzbox in’s Internet gehen dann erhalte ich die erwartete Rückmeldung:

$ traceroute -F forum.freifunk.net 2345
traceroute to forum.freifunk.net (185.66.195.242), 64 hops max, 2345 byte packets
traceroute: sendto: Message too long
1 traceroute: wrote forum.freifunk.net 2345 chars, ret=-1

??

2 posts were merged into an existing topic: Auf der Suche nach der besten MTU

Das Problem des Scriptes ist, dass der serienmäßige Ping der Busybox kein „dont fragment“ setzen kann.
Das kann nur das Traceroute. Daher der faktische Hack mit dem Traceroute (der ziemlich viel Laufzeit kostet)

Man könnte natürlich auch ein besseres Ping als Paket ins Gluon-Image mit hineinwerfen. Aber da der Platz cronisch knapp ist, möchte man das vielleicht vermeiden.
Und wenn schon was „externes“, dann vielleicht doch was natives, was den ganzen Job der MaxMTU-Ermittlung.
Gibt’s da was „fertiges“ für OpenWRT?

Ja, das mit dem BusyBox Ping ist mir auch schon aufgestossen.

Merkwürdig ist nur, dass es selbst mit einem „-F“ im Traceroute bei mir mit meinem Telekom-DSL irgendwie nicht so funktioniert wie es sollte.
Soll heissen:
Bei mir würde das Skript immer auf MTU=1450 umstellen.
In meinem Fall (Telekom-DSL) kein Problem. Aber was ist wenn ich kein Telekom-DSL hätte?

Könnte das evtl. mal jemand mit einem Cabel-Modem / einer Cabel-Fritzbox o.ä. versuchen?

traceroute -s $(ip -f inet address show $(uci get network.mesh_wan.ifname)| grep inet|cut -f 6 -d " "|cut -f 0 -d "/") -F -w 1 -m 20 -q 1 185.66.195.242 2345

(Achtung lange Zeile. Bitte bis ganz nach rechts scrollen)

Also,
das Script ist nur für die Tools auf dem Gluon gedacht und getestet. Wir habe keine probleme mit Batman, aber wir ändern ja auch nur die Fastd MTU.

Unity Media:
traceroute -s $(ip -f inet address show $(uci get network.mesh_wan.ifname)| grep inet|cut -f 6 -d " "|cut -f 0 -d „/“) -F -w 1 -m 20 -q 1 185.66.195.242 2345

traceroute to 185.66.195.242 (185.66.195.242) from 192.168.168.25, 20 hops max, 2345 byte packets
1 192.168.168.253 (192.168.168.253) 0.864 ms
2 10.128.128.1 (10.128.128.1) 7.173 ms
3 1313a-mx960-01-ae13-1030.aah.unity-media.net (81.210.130.25) 6.512 ms
4 84.116.196.174 (84.116.196.174) 16.779 ms
5 84.116.196.178 (84.116.196.178) 20.263 ms
6 de-fra03b-ri1-ae5-0.aorta.net (84.116.133.118) 14.536 ms
7 ge0-0-3-br2.frankfurt1.iphh.net (80.81.192.27) 14.722 ms
8 te5-12-br1.hamburg2.iphh.net (213.128.159.217) 27.069 ms
9 te4-4-cr1.hamburg2.iphh.net (213.128.158.38) 26.113 ms
10 wende0.hamburg.freifunk.net (213.128.138.162) 24.815 ms
11 vlan3405.eth4.bb-a.ak.ber.de.ffrl.de (185.66.192.146) 31.070 ms
12 forum.freifunk.net (185.66.195.242) 27.087 ms

1 Like

kannst Du mal in einem openwrt ein „richtiges“ Ping installieren und damit testen?

Eventuell bekäme man ja durchaus einen dreckigen Hack für die Busybox als Patch hin, ohne gleich das ganze Ping-Paket zu nehmen.

Hast Du evtl. einen Namen des zu installierenden Packages?
Ach ja, Speicherprobleme habe ich auch noch → WR841N.

Ich nutze Gluon auf einem WR841N.

Hallo,
habe etwas rumgebastelt und ein ordentliches ‚ping‘ installieren können.
Das OpenWrt Package dazu heisst ‚iputils-ping‘.
‚iputils-tracepath‘ wäre nochbesser, weil es die MTU-Frame-Size selbstständig ermittelt, es ist aber ein ‚nicht terminierendes‘ Programm. Die Verwendung war mir mit Shell-Scripten zu kompliziert.

Zur Zeit testen wir in ffm gerade ein Auto-MTU Lua-Skript.
Wir haben hier zwei fastd-Instanzen pro Supernode.

  • Port 10001 mit einer fastd-MTU von 1280 (default)
  • Port 10002 mit einer fastd-MTU von 1426

Das Skript wird jedesmal beim Booten über /etc/rc.d aufgerufen.
Es überprüft ganz stumpf am Ende des Boot-Prozesses, ob der UpLink ein Telekom-artiger DSL-Anschluss ist und damit eine MTU-Frame-Size von 1492 Byte hat. Wenn ja, dann wird hier eine fastd-MTU-Frame-Size von 1426 verwendet und ggf. fastd neu gestartet.
Fallback ist immer die kleinere, aber sichere fastd-MTU-Frame-Size von 1280 Byte.
Das ganze ist per uci abschaltbar.

Zu finden gibt es es als Gluon-Package hier:
Gesamt-Package → https://github.com/freifunk-ffm/packages/tree/master/ffffm/ffffm-fastd-auto-mtu
Skript → https://github.com/freifunk-ffm/packages/blob/master/ffffm/ffffm-fastd-auto-mtu/files/lib/gluon/fastd-auto-mtu/automtu.lua

ToDo:

  • Angepasst werden könnte noch der optimale rc.d Aufrufzeitpunkt (z.Z. S99)
  • Ebenfalls sind die variablen MTU-Grössen noch hartcodiert, also nicht einfach parametrisierbar ( z.B. über die site.conf).
  • Auch wenn der Konfig-Mod aktiv ist, wird versucht die UpLink-MTU-Frame-Size zu ermitteln.
5 Likes

Die Entwicklung des Packages fastd-auto-mtu ist noch nicht ganz abgeschlossen!

ToDo:

  • Heute habe ich festgestellt, dass mit meinem Futro-HW-Setup das
    Auto-MTU-Skript beim Booten immer die kleinere Frame-Grösse
    detektiert. Starte ich das Skript jedoch zur Laufzeit per SSH, so
    wird eine große MTU immer sicher erkannt und auch auf diese
    umgeschaltet.
    Edit: Erledigt

  • Es fehlt noch der optimale rc.d Boot-Ausführungszeitpunkt (z.Z. S99) Edit: S99 ist gut

  • Das Logging funktioniert m.M.n. auch noch nicht richtig. Edit: Funktioniert mit 'logread'

  • „Schön machen“ ist noch angesagt Edit: Erledigt

Code Reviews are welcome!

2 Likes

Like für die deutsche Readme!

Ich würde es mal nach dem Lan-Start machen. Also „nach 20, vor 50“… für fqdn-Auflösung wird aber vermutlich der dnsmasq gebraucht, also nach S60.

Habe gerade mal etwas getestet.

Wenn das Skript beim Booten aufgerufen wird, dann hat das Interface „br-wan“ beim meinem Futro (x86-generic Image) noch keine IPv4 Adresse per DHCP bezogen. Daher geht der Ping in’s Leere und die sichere kleine MTU-Grösse wird verwendet. Das Fallback funktioniert also auch hier :o)

Baue ich eine Verzögerung von 5 Sekunden ein, dann klappt alles.
Das ist wohl den x86-Treibern geschuldet und unterscheidet sich damit zu den von mir bisher getesteten Plaste-Routern.

Lösung:
→ Werde mal eine schöne 10-Sekunden-IPv4-Abfrageschleife erstellen.

1 Like

Du könntest auch mit dem Start warten, bis Du überhaupt irgendwen auf dem WAN-Interface anpingen kannst (wenn kein Ping durchgeht auf dem fastd-server, dann nochmal 5s warten)

1 Like

Da ich ein /etc/init.d/fastd restart in dem Skript verwende, sollte ich mindestens bis S95 warten. Dann ist alles für fastd vorbereitet und fastd wird erstmalig aufgerufen. (Obwohl auch dann br-wan noch garnicht fertig ist :o) )

Damit ich aber auf jeden Fall auf der sicheren Seite bin und nix verwurschtelt wird, bleibe ich erstmal bei S99.

P.S.
Einen zeitlichen Einfluss, auf die Benutzbarkeit des Routers, wird dieses sowieso nur max. einmal haben. Bleibt die MTU wie sie ist, wird ja auch fastd nicht neu gestartet.