MTU

Last change on 2025-04-25 • Created on 2025-04-25 • ID: CL-F987E

Dieser Artikel geht davon aus, dass Sie die Bedeutung von Paketgrößen, MTU und MSS und die technischen Konzepte über das Routen durch mehrere Netzwerke kennen.

Um zu prüfen, ob Ihr Problem tatsächlich mit MTU zusammenhängt, können Sie testen, ob Path MTU Discovery funktioniert.

ℹ   Path MTU Discovery (PMTUD)
Wenn ein Paket verworfen wird, weil es zu groß ist und eine ICMP-Fehlermeldung mit der korrekten MTU auslöst, lernt PMTUD die MTU für dieses Ziel und verwendet diese für künftige Pakete.

Wenn das System keine ICMP-Meldung empfängt oder die Meldung keine MTU enthält, schlägt PMTUD fehl und große Pakete werden weiterhin verworfen.
Mehr erfahren

Mit ip addr können Sie alle Schnittstellen und deren MTU auf dem System listen.

Anfrage senden

Sender
—>
Zwischenstelle
—>
Zwischenstelle
—>
Empfänger

Wenn Sie eine Anfrage senden, nutzt das System die MTU seiner lokalen Schnittstelle. Wenn irgendeine Schnittstelle zwischen dem Sender und dem Empfänger eine kleinere MTU besitzt, wird das Paket verworfen. Im Idealfall sendet die Zwischenstelle mit der kleinen MTU-Anforderung eine anständige ICMP-Fehlermeldung, welche die MTU enthält.

Mit dem ping-Befehl können Sie prüfen, was die maximale MTU für den Pfads ist und ob Sie eine anständige ICMP-Fehlermeldung empfangen, wenn diese überschritten wird. Wir empfehlen sowohl den maximalen Wert zu testen, von dem Sie ausgehen, dass dieser funktionieren sollte, als auch einen höheren.

Innerhalb eines privaten Netzwerks mit einer MTU von 1450, ist die maximale Größe der ICMPv4-Payload 1422.
Über die öffentliche Schnittstelle sollten MTUs von bis zu 1500 funktionieren, wobei die maximale Größe der ICMPv4-Payload 1472 wäre.

# Ping mit der Anforderung `Don't fragment` testen.
# Erst mit dem maximalen Payload-Wert, der funktionieren sollte, z.B. 1422 Bytes für ein privates Netzwerk
ping -c 1 -M do -s 1422 <ip_address>
# Zusätzlich, ping mit einer etwas zu großen Payload von 1423 Bytes
ping -c 1 -M do -s 1423 <ip_address>
sudo tcpdump -i <interface_name> icmp

Output analysieren:

  • Wenn die Anfrage erfolgreich übermittelt wird und Sie die erwartete echo-Antwort erhalten, ist MTU nicht die Ursache Ihres Problems, da das Paket reibungslos durch die Netzwerke geleitet wird.

    # ping -c1 -M do -s 1422 203.0.113.1
    PING 203.0.113.1 (203.0.113.1) 1422(1450) bytes of data.
    1430 bytes from 203.0.113.1: icmp_seq=1 ttl=64 time=0.122 ms
    
    --- 203.0.113.1 ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 0.122/0.122/0.122/0.000 ms

  • Wenn Sie eine Fehlermeldung empfangen, die eine MTU enthält (z.B. ping: local error: message too long, mtu=1450), lernt Path MTU Discovery die richtige MTU für diesen Empfänger und passt es entsprechend an. Künftige Pakete sollten sich an die neue MTU halten und erfolgreich übermittelt werden.

    # ping -c1 -M do -s 1423 203.0.113.1
    PING 203.0.113.1 (203.0.113.1) 1423(1451) bytes of data.
    ping: local error: message too long, mtu=1450
    
    --- 203.0.113.1 ping statistics ---
    1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

    Beachten Sie, dass hiermit das Versenden von Paketen lediglich in eine Richtung gerichtet wird. Im Idealfall sollten Sie den Befehl in beide Richtungen ausführen, um sicherzustellen, dass für die Verbindung von beiden Seiten die richtige MTU verwendet wird. Im oberen Beispiel müssten Sie sowohl den Empfänger vom Sender aus pingen als auch den Sender vom Empfänger aus.


  • Wenn Sie eine Fehlermeldung empfangen, die keine MTU enthält, kann Path MTU Discovery die MTU für diesen Empfänger nicht korrigieren und künftige Pakete verwenden weiterhin die falsche MTU.

  • Wenn Sie keine Fehlermeldung empfangen, werden "ICMP (error)"-Pakete vermutlich herausgefiltert. Wenn das innerhalb eines privaten Netzwerks passiert, prüfen Sie am Besten iptables oder nftables Regeln, oder eine andere Firewall, die Sie gegebenenfalls auf Ihrem System eingerichtet haben.

    # ping -c1 -M do -s 1450 203.0.113.1
    PING 203.0.113.1 (203.0.113.1) 1450(1478) bytes of data.
    
    --- 203.0.113.1 ping statistics ---
    1 packets transmitted, 0 received, 100% packet loss, time 0ms

Antwort empfangen

Sender
<—
Zwischenstelle
<—
Zwischenstelle
<—
Empfänger

Wenn der Empfänger eine Antwort sendet, die größer ist als die kleinste erforderliche MTU für den gesamten Pfad zwischen dem Sender und dem Empfänger, wird die Antwort verworfen.

Im Idealfall sollte die Zwischenstelle mit der kleinen MTU-Anforderung eine anständige ICMP-Fehlermeldung an den Empfänger senden, welche die erforderliche MTU enthält und der Empfänger sollte die Antwort als kleineres Paket erneut versenden. Manche Empfänger sind allerdings falsch konfiguriert, wodurch sie den gesamten ICMP-Datenverkehr verwerfen und die ICMP-Fehlermeldung mit der korrekten MTU ignorieren.

Wenn Sie auf den Empfänger zugreifen können, verbinden Sie sich mit dem System und nutzen Sie den ping-Befehl, wie in dem Abschnitt "Anfrage senden" erklärt.

Wenn Sie auf den Empfänger keinen Zugriff haben, können Sie folgenden Befehl nutzen, um zu prüfen, ob Sie eine anständige ICMP-Fehlermeldung empfangen, nachdem das Paket gesendet wurde:

holu@source:~$ sudo tcpdump -i <interface_name> icmp
13:49:25.292748 IP static.1.113.0.203.clients.your-server.de > 1.100.51.198: ICMP static.1.113.0.203.clients.your-server.de unreachable - need to frag (mtu 1450), length 556

Output analysieren:

  • Wenn Ihnen eine anständige ICMP-Fehlermeldung angezeigt wird, ist der Empfänger vermutlich falsch konfiguriert, was bedeutet, dass er ICMP-Fehlermeldungen blockiert und die MTU nicht korrigiert.

  • Wenn Ihnen keine Fehlermeldung angezeigt wird oder diese keine MTU enthält, kann Path MTU Discovery die MTU nicht korrigieren und der Empfänger verwendet für künftige Pakete weiterhin die falsche MTU.

Lösung

  • Wenn Sie auf den Sender und den Empfänger Zugriff haben

    Setzen Sie die MTU sowohl auf dem Sender als auch auf dem Empfänger auf die kleinste erforderliche MTU für den gesamten Pfad. Für Hetzner Cloud Netzwerke ist der maximale MTU Wert 1450 Bytes.

    sudo ip link set <interface_name> mtu 1450  

    Wenn der Sender eine Umgebung mit isoliertem Netzwerk ist (z.B. Docker Container oder LXC), müssen Sie die MTU in der isolierten Umgebung selbst ändern, nicht auf dem Host.

    Bei Problemen mit Docker, nutzen Sie die offizielle Dokumentation bezüglich MTU-Einstellungen für das default bridge Netzwerk (EN) und die default MTU-Einstellung für neue Netzwerke (EN).


  • Wenn Sie auf den Empfänger oder auf eine Zwischenstelle Zugriff haben

    ℹ   MSS Clamping
    Wenn Sie MSS Clamping aktivieren, können Sie für MSS einen festen Wert bestimmen, der beim Initialisieren der TCP-Verbindung an den Server (Empfänger) übermittelt werden soll.
    Mehr erfahren

    Nur für TCP: Aktivieren Sie MSS Clamping und setzen Sie MSS auf die kleinste erforderliche MSS für den gesamten Pfad zwischen dem Sender und dem Empfänger (sehen Sie dazu diese Beispiel-nftables-Konfiguration unter Linux). Sie können MSS Clamping entweder auf dem Sender selbst oder auf einem Router aktivieren. Für Hetzner Cloud Netzwerke ist der maximale MSS-Wert 1410 Bytes.


    Wenn mehrere Sender dasselbe MSS-Limit und denselben Router besitzen, z. B. mehrere Docker Container auf demselben Host:

    Container A

    Container B
    Host
    Gateway
    Router
    Internet

    Können Sie MSS Clamping auf Router-Level aktivieren. In diesem Fall überschreibt der Router den MSS-Wert in dem TCP-SYN-Paket, bevor er dieses an den Empfänger weiterleitet. Über diese Methode muss MSS Clamping nicht auf jedem Sender einzeln aktiviert und eingerichtet werden.