Ich habe heute mal wegen der Performance im Freifunk ein bisschen rumgespielt. Auf dem Freifunkknoten hatte ich via batctl mal das fragmentieren abgestellt, mit dem Ergebnis, dass ich nur noch Pakete der Größe 1398 durchbrachte.
Neben Batman fügt fügt dann auch noch der fastd einen Header vor das Paket, und weil ich über PPPoE ins Netz gehe, wird im Zweifel auch noch meine Fritzbox fragmentieren. Angenommen die Fragmentierung an verschiedenen Stellen steigert nicht die Performance: sollte die Clients nicht einfach eine kleinere MTU via DHCP genannt bekommen, damit es erst gar nicht zu einer Fragmentierung kommt?
mir ist das auch schon vor einer weile aufgefallen.
Der Batman meldet das auch per dmesg im Kernellog.
–cut–
[ 47.840000] batman_adv: bat0: Adding interface: wlan0-1
[ 47.850000] batman_adv: bat0: Interface activated: wlan0-1
[ 56.700000] batman_adv: bat0: Adding interface: mesh-vpn
[ 56.710000] batman_adv: bat0: The MTU of interface mesh-vpn is too small (1426) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1528 would solve the problem.
–cut–
Vermutlich wäre es gut, dieses per Bugreport an die Gluon Entwickler einzureichen.
Allerdings habe ich noch keine Zeit dafür gefunden.
Das ist völlig normal Die MTU vom Fastd Interface ist zu klein was sich leider nicht ändern lässt.
Allerdings fragmentiert Batman die Pakete damit sie trotztdem über die Leitung passen.
Daher bitte keine Bugreport öffnen das ist überall so
Gruß
Cyrus
P.s. Die MTU von Fastd (1426) ist so gewählt das sie über PPPoE unfragmentiert übertragen werden, lediglich die Batman-Frames werden fragmentiert.
Wie ich sagte ist es richtig so, die MTU kann nicht überall gleich sein da jedes Interface eine andere hat.
Das Wifi-Interface muss eine MTU von 1528 haben damit die Batman-Frames unfragmentiert durchpassen. Wir wollen eine Default-MTU von 1500 für die Clients da es auch die Default Ethernet MTU ist, daher müssen wir die Batman MTU auf 1528 legen da man die Clientseite auch nicht kontrollieren kann und somit Ethernet Frames mit eine MTU von 1500 durchpassen.
Fastd hingegen hat eine MTU von 1426. Man könnte die gesammte MTU auf sagen wir 1398 legen, aber dann wird Batman auch nicht optimal laufen denn das optimum ist nun mal die 1528 was mit dem Fastd Interface nicht machtbar ist.
Es ist also ein notwendiges Übel. Zusätzlich gibt es MTU-Clamping bei 1400 damit zumindest IP Verbindungen versuchen die Frames so klein zu senden das diese nicht fragmentieren.
Das ginge auch, ich weiß nicht ob es so schon getestet wurden. Allerdings findet die Fragmentieren auf Layer2 statt, daher ist es für die Clients transparent und MSS/MTU Clamping muss nachwievor verwendet werden da einige Gegenstellen ICMP so unglücklich Filtern das es Probleme bei manchen Verbindungen gibt.
Also wenn man die MTU per DHCP für alle möglichen Endgeräte zuverlässig verkleinern kann, fänd ich das Begrüßenswert. Allerdings habe ich das noch nie praktiziert.
Wie sieht es denn mit dem radvd aus, oder würde man einen DHCPv6 benötigen um in v6-only Netzen dann eine global definierte MTU zu setzen.
Hier liest man auch von diesem Ansatz, (MTU im Netz auf 1486 verringern etc…)
Ich denke man sollte auf diesen gesammten VPN Quatsch verzichten. Das schafft zu viel Zentralität und wie man sieht auch Fragmentierung. Lieber örtliche Zugangspunkte schaffen. Much more appealing !
Das schöne am Batman ist aber, das man pingend von Knoten zu Konten wandern kann … Auch die Dinger müssen nicht zentral stehen. Kann auch jede zusammenhängende Wolke ein VPN-Pärchen haben…
So wie im Mobilfunk. Du hast Google Maps offen und navigierst vom Marktplatz zum Museum XY. Du willst dich unterwegs nicht an drei verschiedenen Knoten neu anmelden müssen. Also müssen alle Knoten die gleiche SSID (dss gleiche Netz) ausstrahlen. Da dein „Navi" den Wechsel nicht bemerken kann, müssen Server den Wechsel regeln. Beim Freifunk erledigt das Batman. Wenn der Server nicht tut, tut dann leider nicht viel. Deswegen mindestens ein „Pärchen“.
Ja klar, das macht batman, allerdings seit dem Domänenkonzept über VPN.
Mein Vorschlag ist auf VPN >>komplett<< zu verzichten und für jede Wifi-Wolke „örtliche Zugangspunkte zu schaffen“.
Roaming würde dabei genau so funktionieren wie jetzt mit VPN, vermutlich eher noch besser.
Also komplett verzichten macht nicht viel Sinn, sonst müsste man sehr viele Uplink-Punkte schaffen.
VPN auf mehreren Nodes schafft ja auch mehr Bandbreite in der lokalen Wolke.
„Wifi“ Supernodes folgen noch, aber erst wenn wir dafür auch Standorte haben Und das sollte dann kein Mehrfamilienhaus sein sonder eher in Richtung Kirchturm, Fernsehturm usw.
Wieso denn sehr viele? Um auf die Bandbreite zu kommen, die wir aktuell über VPN erzielen können, würde für den Anfang 1 „Wifi Supernode“ genügen mit - sagen wir - 100 Mbit synchron.
Um solch ein Supernode würden sich auch sehr schnell mehr Knoten tummeln und ein enger vermaschtes Netz fördern.
Und dann könnte man sukzessive weitere Wifi supernodes hinzufügen. Wenn man dann noch nebem dem Funk viele Knoten per Kabel an diesen Wifi Supernode kaskadiert, würde ein „wunderhübsches“ Netz entstehen.
Allerdings ist Freifunk ja bislang vor allen Dingen in städtischen Gebieten erfolgreich, weil da ehe ein über-Angebot von Internet-Bandbreite ist. Das ist enorm schade, weil gerade im ländlichen Raum gibt es viel Potential, das momentan brach liegt.
Aktuell konzentriert man sich ja sehr auf VPN. Allerdings holt uns das ja jetzt schon ein… wir müssen händeringend Supernodes in Rechenzentren hinzufügen. Das halte ich - mit Verlaub - für einen Designfehler.
Das Problem ist dass in großen Wolken die durchschnittliche Bandbreite sinkt wenn Traffic erst vom einen Ende der Wolke zum nächsten transportiert werden muss wo sich der Gateway befindet.
Daher sind mehrere Gateways notwendig damit dieser Traffic eben nicht durchs halbe Mesh wandern muss um ins Internet zu gelangen.
Wir haben in Kiel jetzt die fastd verbundungen auf eine niedrigere MTU von 1280 gesetzt, damit wir die problematik der kaputten fragmentierung von Kabel Deutschland und Co umgehen.
Macht das jetzt ev. ein Problem mit dem „MTU-Clamping bei 1400“? Was ist das überhaupt?
Die MTU vom Fastd Interface ist zu klein was sich leider nicht ändern lässt.