MTU caveats

Bei nicht so richtig funktionierenden WAN Verbindungen kann man sich als Administrator gerne mal einen “Wolf” suchen. Ein Thema das hier immer wieder für Freude sorgt ist dabei dann, die MTU– Größe. Die Maximum Transmission Unit besagt nichts anderes, als die Größe der “Payload” in einem “Frame” des Layer 2 Übertraguns- Protokolls.

Typische Internetkommunikation – Layer 3 Kommunikation wird vom Konsumenten – dem PC – per Layer 2 an einen Router geschickt und dieser übersetzt dies dann in Layer 3. Je nach dem welchen Weg dieses Päckchen nimmt kommen jetzt weitere Informationen hinzu, die insbesondere auf IPSec verschlüsselten Verbindungen einen Teil der Payload benötigen um selbst funktionieren zu können. Daraus ergibt sich ein Verschnitt, bei dem mehr Bytes übertragen werden sollen, als in das Datenpaket hinein passen. Passt dies nicht zusammen, werden Korrekturprotokolle ausgelöst und alle möglichen Effekte summieren sich.

Wie so oft bei langen Ketten, bestimmt dann, das schwächste Glied das Tempo. Um das heraus zu finden bedient man sich am besten eines geeigneten Tools wie z.B. mturoute.

mturoute

Dieses liefert sehr kurzfristig den effektiven Payload – im gegebenen Beispiel 1472 Byte, statt der 1500 Bytes im Standard. Genau diesen Wert sollte man dann den kritischen Diensten mit auf den Weg geben um die Fehlerkorrekturen unterwegs zu vermeiden und die Verbindung auch optimal zu nutzen.

In diesem Fall bedeutet die für die beteiligten Server das Setzen der jeweiligen MTU Größe auf 1472 Bytes. Im Falle von Windows bedeutet das zunächst den Interface Index zu identifizieren. Das Kommando hierzu ist:

netsh interface ipv4 show interface

Und sollte dann in etwa ein Output wie folgt liefern:

netsh show interfaces

In diesem Beispiel wäre also die Ethernet Schnittstelle mit dem Index Idx 4 betroffen und man sieht die MTU auch auf der Standardisierten Größe von 1500 Bytes. Mit dem folgenden Befehl setzt man die MTU- Größe auf den gewünschten Wert und speichert diesen mit dem Parameter store=persistent auch dauerhaft:

netsh interface ipv4 set subinterface 4 mtu=1472 store=persistent

Anderenfalls geht diese Einstellung nach dem nächsten Neustart verloren, was insbesondere bei Server- Anwendungen zu nicht immer offensichtlichen Störungen führt.  Hat man dieses Kommando abgesetzt, sollte umgehend bei einer Kontrolle des Interface Status die angepasste MTU- Größe auch sichtbar werden,

netsh show interfaces 2

wie sich hier im Beispiel des Interface mit dem Index 4 gut ablesen lässt.

Spannend ist die MTU Anpassung dabei insbesondere für lange oder große Datenströme wie WAN Backup, Fileserversynchronisation, Abgleich von Datenbanken oder auch gegebenenfalls Sprachdienste. Allenthalben lohnt sich hier ein Blick auf die Situation, sobald Kommunikation eigentlich besser funktionieren sollte, als sie es eigentlich tut.

Kyp.F.

Leave a Reply