Maximum Transmission Unit (MTU) und Fragmentierung

Die maximale Größe eines Pakets zur Übertragung ist in einem paketvermittelten Netzwerk beschränkt. Allerdings gibt es hier keinen allgemeinen Wert, sondern je nach Konfiguration und vor allem Übertragungsmedium sind die Werte unterschiedliche und wirken sich auf Performance und Erreichbarkeit aus.

Fragmentierung findet bei IPv6 nicht statt. Hier müssen sich die beiden Endpunkte auf die Paketgröße abstimmen, die auf der engsten Stelle möglich ist. Siehe dazu auch DS-Lite

Wo gibt es die MTU?

Damit der TCP-Stack erkennen kann, wie groß ein Paket maximal werden darf, befragt er die Schnittstelle, über die das Paket versendet werden soll bzw. die Einstellungen im Betriebssystem. Unter Windows können Sie die Information einfach per NETSH ermitteln.

Netsh interface ipv4 show interfaces

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          75  4294967295  connected     Loopback Pseudo-Interface 1
 38          35        1500  connected     WLAN
 32          25        1500  disconnected  Mobilfunk
 43           5        1500  disconnected  Ethernet
 47          25        1500  connected     LAN-Verbindung* 1
 42          65        1500  disconnected  Bluetooth-Netzwerkverbindung
 21          25        1500  disconnected  LAN-Verbindung* 3
 62        5000        1500  connected     vEthernet (Default Switch)
 23          25        1500  connected     Npcap Loopback Adapter
 39          15        1500  connected     vEthernet (Intern Switch)

In meinem Beispiel haben alle Netzwerkkarten eine MTA-Size von 1500 Bytes. Sie können mit NetSH auf die MTU-Size manuell ändern, z.B. unter Angabe des Index oder Namens

netsh interface ipv4 set subinterface "WLAN" mtu=1458 store=persistent

Allerdings sollten Sie die Auswirkungen gut kennen. Damit zwingen Sie ihren Client keine Paket größer als dieser Wert zu senden. Auf bestimmten Verbindungen (z.B. ISCSI mit Jumbo-Frames) verlieren Sie damit Bandbreite. Es obliegt eigentlich dem Netzwerktreiber die MTU-Größe passend zur Physik zu zu setzen. Übliche Werte sind:

Medium MTU in Bytes Quelle

Offizielles Maximum

65535

RFC 791

Token Ring 16Mbit

17914

 

Gigabit mit Jumboframes

9000

 

Token Ring 4Mbit (802.5)

4464

RFC 1042

FDDI

4352

RFC 1188

WiFi

2304

 

Ethernet

1500

RFC 894

802.3

1492

RFC 1042

DSL (wegen PPPoE Framing)

max. 1492

 

DSLite (1&1)

1424

 

ISDN X.25

576

 

Netbios

512

RFC 1088
ICE (https://www.bahn.de/service/zug/wlan-im-zug)

1440

 

Sie sehen also schon, dass die MTU-Größe auch von der Geschwindigkeit des Mediums abhängig ist. Allerdings ist das ja nur die Einstellung meines Clients, der Pakete sendet. Auf dem Weg zum Ziel gibt es ja noch mindestens zwei weitere Schnittstellen, die eine MTU-Size begrenzen könnten, z.B.:

  • MTU auf dem Adapter der Router
    Wenn ein Router ein Paket auf einem Interface empfängt und auf einem anderen Interface weitersendet muss unterschiedliche Übertragungstechniken berücksichtigen.
  • MTU auf dem Zielsystem
    Wenn das Paket am Ziel angekommen ist, dann erwarten wir natürlich auch eine Rückantwort. Damit wird der Empfänger zum Sender und das Spiel beginnt von vorne.

Mein Paket läuft ja über mehrere Stationen zum Ziel und insbesondere mit DSL-Verbindungen der VPNs oder auch IPv6 und Tunnel ist es sehr wahrscheinlich, dass mein Paket größer wird oder schon vom Anfang an zu groß war.

Welche Größe ist gemeint?

MTU bedeutet zwar "Maximum Transmission Unit" aber was ist die Unit? So ein Ethernet-Paket hat ja mehrere Schichten und jede hat eine Größe, wie sie hier an einem "PING -F-L 1472" sehen:

Die Größe beim Ping bezieht sich auf die Payload der Daten und nicht die Größe des Pakets auf dem Kabel. Für die MTU-Size ist die Größe des IP-Pakets maßgeblich. Beachten Sie, dass Wireshark aber auch Netzwerkkarten mit Offloading-Funktionen mehrere Pakete automatisch zu größeren Paketen zusammen setzen und die Anzeige verfälschen können.

Fragmentierung

Das System, welches auf einer Seite ein großes Paket empfängt und dieses nicht über die nächste Teilstrecke übertragen kann, hat drei Optionen damit umzugehen:

  • Paket einfach verwerfen
    Wenn der Absender eine Flusskontrolle wie z.B. bei TCP nutzt, dann wird der Verlust erkannt. Meist sendet der Absender das Paket aber erneut und eine Lösung ist das nicht. Dieser Weg ist also eine Sackgasse.
  • Paket fragmentieren
    Die Zwischenstation kann das Paket natürlich eigenständig in kleinere Pakete aufteilen und die Gegenseite muss diese Pakete dann wieder zusammensetzen und weiter leiten. Die Funktion ist möglich und wird von verschiedenen Routern auch unterstützt. Sie ist aber ineffektiv. Stellen Sie sich vor, sie senden ein 1500 Byte Paket und der Router mit einer MTU-Size von 1492 Bytes (DSL) muss jedes Paket  in eine 1492-Bytes und 8 Byte-Paket zzgl. Overhead umpacken.
  • ICMP "Size Exceeded" Message"
    Da ist es wohl besser, wenn der Router dem Absender einen Hinweis gibt, dass sein Paket zu groß ist. Das ist per ICMP-Steuermeldung standardisiert. Der Sender kann dann schon auf seiner Seite die Pakte kleiner machen und passend senden. Ganz problemlos ist das aber auch nicht, da zum einen die "kleinste" Teilstecke die Paketgröße über alle Teilstecken bestimmt. Zudem gibt es zwischen zwei Systemen im Internet oft mehrere Wege. Wenn diese dann eine unterschiedliche MTU-Size haben, verschenken Sie entweder Bandbreite oder bekommen erst im Laufe der Verbindung ein "ICMP Size Exceeded"

Die aktuelle maximale Größe für ein Paket zu einem Ziel können Sie per PING sehr einfach ermitteln. Sie senden ein ICMP-Ping an die Gegenstelle und geben sowohl die Größe vor un setzen das "Don't Fragment (DF)"-Flag.

ping www.msxfaq.de -f -l 1500

In den meisten Fällen sollte dieser Ping nicht durchgehen und sie folgende Ausgabe sehen:

Wenn Sie mit Wireshark die Pakete anschauen, dann sehen Sie in dem Beispiel aber gar kein Paket. Wenn ich ein 1,5kByte "Nutzdaten" über meinem PC senden möchte, der eine 1500byte MTU auf der Netzwerkkarte hat, dann passt das schon deshalb nicht, weil der Header noch dazu gerechnet werden muss. Ich muss ein etwas kleineres Paket senden. Bei mir gelingt es mit

ping www.msxfaq.de -f -l 1465

1465 Bytes ist so groß, dass das Ethernet-Paket auf dem Kabel dann 1507 Bytes groß ist. Die 8 Bytes der Ziel-MAC-Adresse können Sie hier abziehen.

Das Paket wird von meinem Client als zum "Next Hop" gesendet, der aber, DSL sei Dank, ein kleineres Paket benötigt. Hier ist es der Router mit der IP-Adresse 46.91.217.151, der mit eine MaxMTU von 1492-Bytes  vorschlägt.

Mein Client, bzw. dessen IP-Stack muss dafür sorgen, dass das IP-Paket also nicht größer wird, um erfolgreich diesen Weg zu nehmen. Mit folgendem Wireshark-Capture-Filter können Sie gezielt diese Antworten einfangen

icmp[icmptype]==3

Wenn Sie nun mit Wireshark aber länger solche ICMP-Antworten suchen, dann werden sie kaum Pakete finden. Das kann daran liegen, dass Sie keine Teilstecke in der Übertragung haben, die eine kleinere MTU nutzt. Es kann aber auch einfach daran liegen, dass die Zwischenstationen mittels Fragmentierung das Paket weiter übertragen.

MSS Clamping

IP-Router sollten laut OSI-Schichtenmodell sich nur um die IP-Pakete kümmern. Wenn ein Router aber nun mit einer unterschiedlichen MTU-Size auf zwei Schnittstellen agieren muss, dann sollte er zu große Pakete selbst fragmentieren und übertragen. Das kostet natürlich Rechenleistung und ist der Performance auch nicht gerade förderlich, wenn das zweite Paket sehr klein ist. Wenn ein Router nun statt der Fragmentierung ein "ICMP Size Exceeded" an den Absender sendet. dann wird der Absender dazu gezwungen, die Pakete selbst kleiner zu machen. Technisch funktioniert dies und wird auch genutzt:

Die Fritz!Box bietet keine Möglichkeit, die MTU-Size manuell anzupassen. Dies ist auch nicht erforderlich, da die Fritz!Box das MSS Clamping-Verfahren (Maximum Segment Size) unterstützt, über das die Größe der Datenpakete automatisch an die jeweils kleinere MTU der miteinander verbundenen Netzwerke angepasst wird. Somit kommt es zu keinen Performance-Einbußen durch das Fragmentieren oder Verwerfen von Datenpaketen.
Quelle: https://avm.de/service/fritzbox/fritzbox-7590/wissensdatenbank/publication/show/432_MTU-Size-fur-DSL-Verbindungen-manuell-anpassen/

Allerdings verletzt dieses vorgehen natürlich das OSI Modell. Ein Router auf OSI-Schicht 3 sollte nicht in die OSI-Schicht 2 (Ethernet) eingreifen und dort an den ausgehandelten Paketgrößen Einfluss nehmen.

Fehlerbilder

Ein typisches Fehlerszenario bei MTU Problemen sind Verbindungen mit großen Datenmenge. So kann die Anmeldung an einen Service noch funktionieren aber der Betrieb bricht dann. Klassisches Beispiel sind hier TELNET oder SMTP. Am Anfang (rot) sind die Pakete alle noch sehr klein und unkritisch für Verbindungen mit MTU-Beschränkungen.

Sobald aber Daten übertragen werden müssen, wird die MTU-Size (hier 1514 Bytes), auch ausgenutzt. hier ist es nun eine Verbindung im "LAN" er Ethernet, wo eine MTU-Size von 1500 problemlos möglich ist. Wenn die Verbindung über WAN oder VPN geht, und ein System in der Mitte kein "ICMP Size Exceeded" sendet aber auch nicht fragmentiert, dann kommt die Verbindung einfach nicht zustande.

Der Sender hat ja keine Idee, warum die Pakete nicht ankommen und von sich aus versucht er nicht eine geeignete MTU heraus zu finden.

Diese Probleme tauchen oft auf, wenn Firewall-Administratoren z.B. ICMP komplett blockieren, weil Sie von einem PING und TRACEROUTE eine Gefahr sehen. ICMP ist aber mehr als nur PING sondern auch ein wichtiges Steuerungsprotokoll, welches zumindest im internen Netzwerk erlaubt sein sollte und selbst eingehende ICMP-Steuerungsmeldungen sollten nicht pauschal verworfen werden.

MTU Discovery

Die Fragmentierung durch einen Router auf dem Übertragungsweg macht die Übertragung aufgrund mehrerer Pakete langsam und es kostet vor allem Speicher und CPU auf den Routern. Heute sollten Sie davon ausgehen, dass kein Provider mehr Fragmentation durchführt. Sie müssen also sicherstellen, dass die Endpunkte die Funktion "MTU Discovery" unterstützen. Dazu sendet der Absender ein Paket in der gewünschten Größe aber ein Router, der das nicht mehr übertragen kann, sendet ihnen dann ein ICMP Exceeded zurück. Dieses Paket enthält nicht nur den Fehlercode, dass ihr Paket zu groß war sondern auch die Größe, die dieser Router maximal weiter leiten kann.

Ihr Client sendet nun also ein "kleineres Paket" und hofft, dass dieses durch geht. Es wird den Router passieren, der eben die Übertragung gestoppt hat aber auf dem weiteren Weg kann es noch weitere Router geben, die vielleicht noch kleinere Frame-Größen benötigen. Dann wiederholt sich das Spiel bis Sie letztlich ein Paket zum Ziel bekommen. Das Ziel antwortet dann und auch in die Richtung können unterschiedliche Paketgrößen die Übertragung behindern. Das Spiel beginnt von vorne.

Damit nicht genug. Auch nach der erfolgreichen Aushandlung einer möglichen Paketgröße ist nicht sichergestellt, dass ihr IP-Paket immer den gleichen Weg geht. Einmal einen Umweg über einen anderen Kanal mit kleinerer Frame-Size ergibt wieder ein ICMP-Paket.

Das ganze System funktioniert nur, wenn Sie ICMP auch zulassen. Immer wieder höre ich, dass aus "Sicherheitsgründen" das Protokoll ICMP geblockt wird, weil damit Hacker ihr Subnetz per PING durchgehen können und so eine Liste der Rechner ermitteln könnten. Das kann ich aber auch mit anderen "gängigen Ports" die mir dann sogar gleich die Antwort liefern, welcher Service dort läuft.

Bitte hören sie auf, die Basisfunktion von MTU Discovery aber auch Traceroute und Ping durch das Blocken von ICMP zu stören. Sie können die lokale MTU-Größe beschränken, um dem Client zu verbieten größere Pakete zu senden. Dies kann für einen Fehlersuche nützlich sein aber ist natürlich keine dauerhafte Lösung.

REM Anzeige der aktuellen MTU Size
netsh interface ipv4 show interfaces

REM MTU eines Interface ueber Name setzen
netsh interface ipv4 set subinterface "Local Area Connection" mtu=1400 store=persistent

REM MTU eines Interface ueber Nummer setzen
netsh interface ipv4 set subinterface "2" mtu=1400 store=persistent

Die Einstellungen sind damit aber permanent. Vergessen Sie also nicht, diese nach der Fehlersuche wieder zurückzustellen.

Ursache ICMP und Firewall

Das Protokoll ICMP wird landläufig mit "PING" gleichgesetzt, obwohl ICMP viel mehr ist. Es ist ein "Internet Control Message Protocol", welches noch viele andere Informationen an den Absender zurück melden kann. Im ICMP Header gibt es einen 8-Bit Wert, der unterschiedliche Bedeutungen hat. Hier ein Auszug:

Typ Code Bedeutung

0

0

Antwort auf Ping, (Echo Reply)

3

0

ICMP not Reachable: Netzwerk nicht erreichbar

1

ICMP not Reachable: Host nicht erreichbar

2

ICMP not Reachable: Protokoll nicht erreichbar

3

ICMP not Reachable: Port nicht erreichbar

4

ICMP not Reachable: Fragmentierung nötig aber nicht erlaubt (DF Header)

5

ICMP not Reachable: Route nicht möglich

13

ICMP not Reachable: Durch Admin (Firewall) geblockt

8

0

PING Anfrage. Echo Request

11

0

Zeitüberschreitung bei der Übertragung, TTL Abgelaufen

1

Zeitüberschreitung während der Defragmentierung überschritten

Für MTU ist hier der Code 3 ("Not Reachable") interessant, da es dann noch einen Untercode gibt und hier ist z.B. Code 4 ("Fragmentierung nötig aber nicht erlaubt (DF Header)" interessant. Sie sehen aber auch die Gruppierung, dass die PING und Traceroute-Anfrage andere Typ-Codes verwenden. Der Versand von ICMP-Paketen vom Typ=3 an entfernte Stellen als Fehlermeldung ist genauso sinnvoll wie auch der Empfang von diesen Meldungen bei ausgehenden Verbindungen.

Natürlich können solche Meldungen auch gefälscht sein, das es bei ICMP ja keinen Handshake wie bei TCP gibt. Aber da auf eine ICMP-Antwort in der Regel keine weitere Reaktion des Zielsystems erfolgt, ist das Risiko eher überschaubar. Das Unterdrücken von "Unerreichbar-Meldungen" hilft kaum gegen Angreifer, da diese meist genug Ressourcen haben, um einfach Ports und Adressen durchzuprobieren und nicht auf eine "nicht erreichbar" Antwort warten. Verbindungsprobleme bei guten Prozessen können Sie aber so viel einfacher analysieren, wenn der ICMP-Code ihnen verrät, warum die Verbindung nicht zustande gekommen ist.

In der Windows Firewall ist auch zu sehen, dass die Regeln solche ICMP Pakete erlauben.

Messen mit PING -f -l nnnn

Welche MTU zwischen zwei Endgeräten maximal möglich ist, können Sie am einfachsten mit einem ICMP-PING ausmessen. Sie können hier die Größe des Pakets vorgeben aber insbesondere das Flag "Don't Fragment" setzen. Allerdings benötigen sie dann schon einige Versuche, da Sie sich dem Wert nähern müssen.

C:\>ping www.google.de -f -l 1400

Ping wird ausgeführt für www.google.de [172.217.18.99] mit 1400 Bytes Daten:
Antwort von 172.217.18.99: Bytes=68 (gesendet 1400) Zeit=11ms TTL=57

Ping-Statistik für 172.217.18.99:
    Pakete: Gesendet = 1, Empfangen = 1, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 11ms, Maximum = 11ms, Mittelwert = 11ms
STRG-C
^C
C:\>ping www.google.de -f -l 1500

Ping wird ausgeführt für www.google.de [172.217.18.99] mit 1500 Bytes Daten:
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.

Ping-Statistik für 172.217.18.99:
    Pakete: Gesendet = 1, Empfangen = 0, Verloren = 1
    (100% Verlust),

Hier habe ich einmal ein paar meiner Messungen ausgeführt:

Standort Gegenstelle Gemessener MTA

DSL 100.000 Hövelhof

www.google.de
www.netatwork.de www.msxfaq.de

1464

Net at Work DSL (Telekom DSL) (PPPoE)

www.google.de
www.netatwork.de
www.msxfaq.de

1464

Kundennetz

www.google.de
www.netatwork.de
www.msxfaq.de

1448

Kabelnetz (Unity Media) (mit IPv4)

www.google.de
www.netatwork.de
www.msxfaq.de

1472

VPN-Verbindung via Net at Work

192.168.x.x (Internes System(

1372

Freifunk über WLAN und Router mit VPN

www.google.de
www.netatwork.de
www.msxfaq.de

1372

Eine MTU von 1500bytes, wie diese von der Schnittstelle angeboten wird, wird nie erreicht, was aber auch nicht zu erwarten war. Bei DSL scheint deine Obergrenze von 1464 Bytes erreichbar zu sein, während Firewalls bei einem Kunden schon bei 1448 Bytes abriegelt. Bei Internet über Kabelfernsehen hingegen ist die gemessene MTU-Size 1472 sogar etwas größer als bei DSL. Der Kabelanschluss hatte aber IPv4. Die neueren Anschlüsse mit IPv6 und DS-Lite werden vermutlich eine kleinere MTU haben.

Wenn ich aber ein VPN über DSL aufbaue, dann sehen Sie den "Verlust" durch die VPN-Ummantelung. Das übertragene Paket ist zwar weiter 1464 Bytes groß aber bei meinem VPN sind 92 Bytes als "VPN Overhead" zu verzeichnen. Der VPN-Overhead ist aber auch bei Freifunk zu sehen. Hier verbinde ich mich per WLAN mit einem Freifunk-Router, der dann die Daten über einen VPN-Tunnel sendet und beim Ausgang ins Internet angeblich nichts protokoliert wird.

Da es also nicht genau eine optimale MTU gibt, macht es auch wenig Sinn auf dem Client eine MTU vorzugeben. Wenn Sie diese manuell zu groß wählen, dann wird weiter fragmentiert oder die Verbindung kommt nicht an. Wenn Sie dies zur Sicherheit aber gleich oder kleiner der minimalen MTU all ihrer Verbindungen wählen, dann lassen Sie Bandbreite liegen. Die MTU beschränkt sich bei ihnen eh nur auf die Senderichtung. Beim Empfang können Sie nicht direkt eingreifen.

Also vergessen Sie erst einmal die meisten Tricks zur "Optimierung" der MTU.

Automatisiert messen

Eine zu kleine MTU-Size hat mir schon häufiger Probleme bereitet, z.B. bei der Replikation zwischen zwei Domain Controllern. Natürlich kann ich einfach per "PING" mit Angabe der Option "-f" für nicht fragmentieren und einer Paketgröße den Weg prüfen. Technisch würde ein XXL-großes Paket reichen, um den ersten Router zu finden, der dagegen ist und ein ICMP Size Exceeded sendet. Genau das habe erst erst einmal per PowerShell versucht aber ich kann zwar per PING und Test-Connection ein Ping mit bestimmter Größe und ohne Fragmentierung senden aber die ICMP-Antwort mit der blockierenden Gegenstelle und der gemeldeten MTZ-Größe konnte ich nicht erhalten. Auch in direktes lesen mit RAW-Sockets scheint nicht mehr möglich zu sein

Erst die genauer Betrachtung der Parameter von "Test-Connection" und insbesondere des Bereichs "Output" sagt, dass normalerweise nur ein "True/False" zurück kommt, wenn keine anderen Parameter etwas anderes vorgeben:

Über den Parameter "-MTUSizeDetect" kommen Sie ganz schnell zum Ergebnis. Ich habe zuerst einmal meine interne Fritz!Box ausgemessen. Da sollte jeder auf 1514 Bytes auf dem Kabel kommen, auch wenn Test-Connection hier irrtümlich 1472 ausliefert. Das ist aber die ICMP-Payload-Size. Das IP-Paket ist 1500 Bytes und die 14 Bytes kommen für das Ethernet-Frame dazu, die aber nicht zu MTU dazu zählen.

PS C:\> Test-Connection 192.168.178.1 -MTUSizeDetect

Source        : FC-T480S
Destination   : www.msxfaq.de
MTUSize       : 1472
Status        : Success
Address       : 217.160.0.234
RoundtripTime : 17
Options       : System.Net.NetworkInformation.PingOptions
Buffer        : {97, 98, 99, 100_}

Dabei ist schön zu sehen, wie Test-Connection sich von kleineren Paketen zu größeren Paketen hocharbeitet:

Das PowerShell Commandlet startet mit 770 Bytes und geht dann über 1121, 1297, 1385, 1429, 1451,1462 auf 1464. Anscheinend sind das gängige Sprünge. Das Skript nutzt also nicht die "ICMP Size Exceeded" Meldung, um die MTU-Size zu ermitteln.

IPv6 und MTU

Bei IPv6 ist es nicht mehr erlaubt, dass ein System auf dem Übertragungsweg die Pakete fragmentiert. Das, was bei IPv4 noch als Verletzung des OSI-Modells geschimpft wurde, wenn ein IP-Router (OSI-Schicht 3) in den Übertragungsweg (OSI Schicht 2) eingreift, ist bei IPv6 nun empfohlen.

IPv6 defines a mechanism that allows large payloads to be divided into fragments, with each fragment sent in a separate packet (see [IPv6-SPEC] section "Fragment Header"). However, packetization layers are encouraged to avoid sending messages that will require fragmentation
Quelle: RFC 1981 – Path MTU Discovery for IP version 6 - https://tools.ietf.org/html/rfc1981

The Fragment header is used by an IPv6 source to send packets larger than would fit in the path MTU to their destinations. (Note: unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path

IPv6 requires that every link in the internet have an MTU of 576 octets or greater. On any link that cannot convey a 576-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6.

Links that have a configurable MTU (for example, PPP links) must be configured to have an MTU of at least 576 octets; it is recommended that a larger MTU be configured, to accommodate possible encapsulations (i.e., tunneling) without incurring fragmentation.

Quelle: RFC 1883  Internet Protocol, Version 6 (IPv6) Specification" - https://tools.ietf.org/html/rfc1883

Auch ohne Fragmentierung gibt es dennoch die MTU ermitteln. Daher ist das Blockieren von "ICMP Fragmentation needed" einfach nicht mehr supportet und damit fällt auch das "Do not fragment" weg.

C:> ping fritz.box -6 -f

Die Option "-f" wird nur für IPv4 unterstützt.

Weitere Links