[Berlin-wireless] MTU verstehen...

[Loria]

> Am 20.04.2016 um 11:14 schrieb smilebef at gmail.com:
> 
> Am Tue, 19 Apr 2016 12:11:39 +0200
> schrieb Sven-Ola Tuecke <sven-ola at gmx.de>:
> 
>> Menno. Da will man man klugscheissen und schon gibt's 3 Antworten.
>> Dank an die anderen!
>> 
>> Am 19.04.2016 um 12:09 schrieb Sven-Ola Tuecke:
>>> Schön wär's. Ist aber nicht immer so.  
>> 
>> 
> 
> Besser einer mehr klug geschissen, als eine wichtige Information
> verloren gegangen.
> 
> 
> Was mir noch nicht klar ist:
> 
> 1. MTUs sollen laut L. gleich sein.
> Warum müssen die MTUs gleich sein, wenn doch alles mit MSS geregelt
> scheint? Hat L. hier übertrieben oder ist doch nicht alles in Butter?

da hast Du mich falsch Verstanden.
die MTU muss nicht gleich sein
(DU kannst zB am PPP Link eine MTU von 256 haben und am anderen Ende die gewohnte MTU von 1500 haben).

Damit die MSS Ermittlung funktionieren kann, müssen beide Partner die ICMP Fragmentation needed verarbeiten, sonst kann die nicht funktionieren
(dh, sendest Du zu große Pakete mit DF gesetzt und verarbeitest die ICMP Fragmentation needed nicht, dann geht nix).

Ebenso muss das Fragmentieren und Defragmentieren funktionieren. Sperrt zB eine Firewall fragmente von Paketen, geht auch nix durch … wenn Pakete fragmentiert worden sind.

Du kannst bequem damit leben, wenn dein IP Paket fragmentiert wird und alle Fragmende immr ankommen … besser wäre es natürlich immer, die Pakete maximal so groß zu machen, wie die kleinste MTU auf der Strecke.


> 2. Fakt ist es lief nix bei MTU=1450.

Dann wäre das Beste hier herauszufinden, was hier genau passiert … Dazu musst Du auf beide Enden Zugriff haben, so daß Du anschauen kannst, was auf biden Enden jeweils raus geht (und ggf auch auf die router auf der Strecke, damit man sieht, was da passiert).

> Ist letztlich also überhaupt nichts geregelt oder muss ich explizit beim
> Webbrowser, bei jeder SSH/Telnet/Mail-Verbindung die Anfrage mit einer
> Option MSS=1400 machen?

Wenn das zm Erfolg führt, dann deutet es schon darauf hin, daß einer der beiden TCP Partner auf Firewallebene falch konfiguriert ist.

Ich hatte allrdings auch schon Fälle zwischen den Fingern, wo zwar MSS und Co alles sauber ausgehandelt wurde … doch im Anschluss ab einem Moment 
keine Daten mehr transportiert worden sind (an einem Ende konnt man allerdings sehen, dass Pakete rausgehen, die kamen am anderen Ende aber nicht an). Es kann also auch sein, daß hier eine Fragmentierung / Defragmentierung nicht ordentlich durchgeführt wird. 
Unvollständig rekombiniertes IP Paket ist schlicht Paketverlusst. Das ist aber mühsam zu analysieren und dann auch den Beleg zu finden.

Es ist also einiges an Analyse nötig, um die Ursache für das zu erkennen, was Du beobachtest.


Grüße.