Frage zu MTU bei Routern und Clients

Das war ne Feststellung, keine Beleidigung. Wenn du das so auffasst, bitteschön.

2 „Gefällt mir“

Es fehlt einfach anscheinend jegliches technisches Verständnis, oder es ist einfach mal wieder zu viel Langeweile vorhanden und diese muss in einer der unendlichen und sinnlosen @Pinky Diskussion enden.

3 „Gefällt mir“

Du verquicks schon wieder die Argumente und ihre Bezüge

der nicht den hauptsächlichen Sinn von Freifunk darstellt.

darauf habe ich geantwortet.

Entweder es gibt Gleichwertigkeit ohne Gewichtung - das ist
Netzneutralität - oder es gibt Gewichtungen - das ist keine
Netzneutralität sondern Zensur.

Du weichst aus, indem Du das auf MTU beziehst. Also sinnverdrehend. Für diejenigen,die nur lesen, was ihnen gefällt und umschiffen, was sie nicht beantworten wollen.

um das mal wieder auf die sachliche Ebene zu hieven:

es ergibt Sinn die MTU so weit abzusenken, bis die Nutzer keine Probleme haben, einen fastd-Tunnel aufzubauen. Batman kompensiert dies und klebt Pakete wieder zusammen.

und genau darauf zielte meine ursprüngliche Frage ab und ist eigentlich immer noch unbeantworet:

Wenn ich vom Client via FF-Routing an einem Node hänge und der dann weiter an einem uplink (also Tunnel) einen Max MTU mit 1400 angegeben erhalte, aber mit 1500 sende, gibt es fragmentierte Pakete, auch wenn der Router vor mir 1500 hat.

Sende ich 1400, sind die 1500 des Routers kein Problem.

Aber was ist mit den Paketen, die der Router selbst sendet? Wie gross sind die? Müsste somit nicht der Router selbst auch auf 1400 (bzw. auf den Wert, den der Tunnel als max MTU hat) gesenkt werden, damit auch diese Pakete nicht gesplittet werden müssen (= cpu load und Bremse)? Oder sind die Pakete sowieso immer kleiner?
(Wenn ich mich an das Setup vom Offloader erinnere, wird da ein Wert von 1532 genannt, also muss in jedem Fall fragmentiert werden, aber bedeutet das dann nicht 2x Fragmentieren oder Umpacken?

mach Dir um die Fragmentierung im Freifunk keine Sorgen. Mach Dir Sorgen um Nutzer, die aufgrund von IPv6 oder neumodischer Einwahlmöglichkeiten, eine kleinere MTU als 1492 angeboten bekommen. Batman erledigt den Rest.

Es ist höhere Batman-Magie dafür zu sorgen, dass es für den Nutzer transparent ist. Ist zwar nicht schön, aber es war nie vorhergesehen Batman durch Tunnel zu leiten (obwohl Fledermäuse eigentlich Tunnel mögen). Wenn Freifunk flächendeckend aufgebaut wird und es einen mehrere lokale Gateways gibt, erübrigt es sich. Bis dahin ist die Batman-Magie eine Brückentechnologie, die wirklich gut arbeitet. Hier noch mehr Lektüre dazu

Du sorgst doch selber dafür das du so schreibst das möglichst keiner es verstehst was du willst und drehst es hinterher so das alle anderen doof sind weil dich keiner versteht.

Der Hauptsächliche Sinn von Freifunk ist ein freies Netzwerk.

Wie erreichen wir das? Durch Mesh Technologie.

Wer das bestimmt hat? Es ist eine technische Lösung damit sich Netzwerkhardware autonom, mit so wenig menschlichen Eingriff wie möglich selbst organisiert, damit Daten von einer Quelle bis zur einer Senke weitergeleitet werden. Trotzdem müssen im gewissen Rahmen vorher einige Parameter definiert werden, damit Daten so reibungslos wie möglich weiter geleitet werden. Und wenn dafür nun mal ein VPN Tunnel notwendig ist dann sind dessen technischen Parameter der Spielraum.

Wer hat die Entscheidungshoheit? Diejenigen welche die die Grundlagen verstanden haben und die in der Lage sind sie auf die Geräte welche das Netz bilden auszubringen und anzuwenden.

Genau so groß wie die aktuelle Strecke zwischen Router und Ziel maximal an MTU zulässt. Das bekommt der Router entweder mit über den Mechanismus PathMTUDiscovery, oder seine Pakete werden von einem anderen Router fragmentiert. BATMAN_adv macht das sehr effizient und transparent. So das das höher gelegene IP Protokoll davon nix mitbekommt. Damit BATMAN_adv aber z.B. nicht jedes Paket was zwischen Client und Internet welches durch FastD und GRE oder FastD und OpenVPN (Schweden) Tunnel fragmentieren muss, wurde und wird die MTU schon vorher so klein gemacht das eben gar nicht erst fragmentiert werden muss und dem Client mitgeteilt wird, schicke keine Pakete größer als MTU X.

Die Fragestellung des Threadstarters bezieht sich aber gar nicht auf die MTU des fastd, sondern die MTU innerhalb des Layer2-Netzes und des Gateways „von dort ins Internet“ (zumindest ist es das, was er gemessen hat.)

(Welchen Sinn diese Frage ergibt: Keinen. Aber dann auf eine interessantere Fragestellung umzuschwenken, den Threadstarter das nicht bemerken zu lassen und dann Stundenlang aneinander vorbeizureden, das treibt mir die Sorgenfalten auf die Stirn.)

Wobei die, wenn nicht ohnehin bereits per DHCP relativ niedrig announced, spätestens von den Tunneln ins Internet geclamped wird.

2 „Gefällt mir“

?? nochmal, zum mitschreiben:

client - FF-router - FF-uplink - irgendwo Interent
max MTU = 1400
FF-Router hat 1500
Frage war: ob Das nachteilig ist, wenn FF-Router nicht den selben Wert, also 1400 hat

Warum muss jede simple Frage immer so zerflückt werden?

Weil Du eben keine simple Frage gestellt hast, sondern unproblematisches Szenario als Problem darstellst.
Und aus den Antworten, dass es kein Problem darstellt konkretisierst, wo es ein Problem sein soll.
Da das aber nicht nachvollziehbar ist und Du dann Seitenbedingungen nachschiebst, die zwar immer noch kein Problem verursache, sondern lediglich weiteren Performance-Verlust.
Aber keine Bange, du wirst schon etwas finden, was Du als Verstoß gegen das PPA interpretieren können wirst.

Weil genau diese Frage kein simples 0 oder 1 als Antwort erlaubt, sondern einer tieferen Betrachtung würdig ist.

Eigentlich müsste die Antwort sein, dass das auf den Haupteinsatzzweck ankommt.

Grundsätzlich ist es positiv, wenn so wenig wie möglich fragmentiert wird, was die 1500er MTU rechtfertigen würde, wenn die Clients ebenfalls eine hoch ausgelegte MTU auf dem Interface aktiv haben.

Wenn der Hauptnutzen jedoch in der Nutzung des Internet besteht dann wäre es positiv sofort eine niedrige MTU aktiv zu haben.

Eine hohe MTU auf dem Freifunk Router schadet hierbei aber nicht, egal welchen der oberen Fälle man als Hauptnutzen sieht, selbst wenn die Clients sofort per DHCP eine 1280er MTU announced bekämen.

Weil es egal ist wie groß die MTU eines Interfaces ist für Pakete die es selbst aussendet. Der Empfänger oder ein Gerät dazwischen mit niedriger MTU wird schon die Meldung zurück geben, Paket zu groß, verwende bitte nur MTU X für die Kommunikation mit mir. So dann ist das eine große Paket zwar verloren, aber alle folgenden kommen mit der richtigen Größe an.

ohne Polemik gehts nicht bei einer sachlichen Frage?

Mal einfach sagen, dass das kein Problem ist und kurz begründen ist wohl nicht angesagt?

Mal einfach selbst recherchieren und andere Freifunker nicht auf die Nerven gehen mit dummen Fragen ist wohl nicht angesagt?

Du hast mein erstes Posting (Tipp: Ganz oben im Thread) nicht gelesen? Oder nur nicht verstanden?

Da mir inzwischen (siehe anderer Thread) klar ist, was Du mit Deiner Frage bezweckst:
Bitte unterscheide die MTU mit der der Fastd seine MeshVPN-Verbindungen aufbaut.
Und die MTU, die die Router auf der br-client anbieten und die MTU, die das batman-gateway („Richtung Internet“) anbietet.

fastd-MTU wird -so prophezeihe ich- über kurz oder lang auf 1280 stehen.
Und nächstes Jahr dann auf „auto“ (kann fastd noch nicht, soll aber kommen)

die batman-mtu sollte 1500 sein und wird meines Wissens bei keiner Community angefasst.
Ob man die Plasterouter auf 9k-Jumboframes bringen kann: Müsste man mal ausprobieren.

Kann man schon ändern…für die Map Server werden z.B. MTU reduzierte Interfaces angelegt…

Wäre es nicht gerade da spannend, mit großen Paketen zu arbeiten, damit möglich wenig Splits von den gezipten(!) UDP-Datagrammen zu erleiden? Klar, müsste natürlich auch der Sender schon so können.

Es geht dabei vielmehr darum, dass die Pakete die vom bspw. Alfred auf den Supernodes an den Alfred Master auf dem Map Server gehen sofort mit einem definiert kleinen Paket auf die Reise gehen, da dies der Stabilität der UDP Übertragung sehr dienlich ist. Aber das war nur ein kurzer OT Schlenker, sorry… :wink:

Die Frage nach der „minimalen MTU auf dem Pfad“ ist schon nicht präzise genug. Je nachdem wer fragmentiert, läuft es zusätzlich gegebenenfalls schneller oder nicht.

Beispiel: Auf einem DSL-Anschluss hatten Pakete bis vor kurzem eine Größe von 48 Bytes Payload + 5 Bytes Header (90% Effizienz), das bedeutet, das mal eben alles fragmentiert wird, wenn man Ethernet mit 1500 Bytes MTU da drauf setzt. Niemand käme auf die Idee alle IP-Pakete nun nur noch 48 Bytes groß zu machen (was ja bei v6 auch gar nicht geht, und selbst mit Ethernet ist der Header vermutlich schon größer :smiley: ). Das fragmentiert wird merkt man aber sowieso nicht, weil das eben vom DSL-Modem vermutlich in spezieller Hardware gemacht wird und ruckizucki ohne Overhead geht.

Wenn man dann überlegt ob man lieber Batman oder IP oder fastd fragmentieren lässt, dann muss man sich auch anschauen, ob das vielleicht Overhead im Kernel erzeugt der aufgrund der CPU-Last viel relevanter ist als irgendein paar Bytes Protokolloverhead. Wenn ich früh im Userspace fragmentiere und dann je zwei Kontextwechsel mit zwei Paketen auslöse statt nur einen, um die Pakete dann durch ihre Odyssee durch mein tun/tap oder so zu schicken, dann hat das wahrscheinlich einen wesentlich größeren Impact als wenn ich später fragmentiere und ein bisschen Verschnitt habe, dafür aber alles im Kernel abläuft. Das kann ich aber auch nicht beziffern, nichtmal qualitativ, da könnte mal jemand nachschauen, ob das auch tatsächlich so abläuft wie ich das grade geraten habe.

(Ich meld mich aber nicht freiwillig. Facebook beschäftigt einen grade mit nem sechsstelligen Gehalt um im Linux-IP-Stack rumzupopeln. Wenn wir genau so ein cleveres Bürschchen haben um den Flaschenhals auszumerzen, dann gerne, sonst hat das außer akademischer Neugierde eher weniger Sinn)

1 „Gefällt mir“