Weblog

MTU bei vDSL der Telekom

14.05.2025 · 5 Min. Lesezeit

Warum 1492 nicht immer reicht

Einleitung

Wer im Telekom Magenta Zuhause-Tarif mit vDSL unterwegs ist, denkt selten über die Maximum Transmission Unit (MTU) nach, allgemein dürfte das Thema MTU eher unbekannt unter DSL-Nutzern sein - bis plötzlich Webseiten nicht mehr laden, VPNs zicken oder Downloads abbrechen. Genau das ist mir passiert. Ich will nun beschreiben, wie ich ein MTU-Problem systematisch eingegrenzt, analysiert und trotzdem nicht gelöst habe - und warum MTU 1492 nicht immer die richtige Antwort ist.

Was ist die MTU überhaupt?

Die MTU ist die maximale Größe eines IP-Pakets (in Bytes), das ohne Fragmentierung über ein Interface gesendet werden kann. Ist ein Paket zu groß, so muß es in mehrere kleinere Pakete gesplittet werden - ein Aufwand der vermieden werden sollte und nicht selten administrativ unterbunden ist. Für Ethernet liegt die MTU klassisch bei 1500 Bytes. Doch bei PPPoE-Verbindungen - wie sie bei vDSL der Telekom üblich sind - wird ein Teil davon für das Protokoll selbst benötigt.

Beispiel:

Ethernet MTU: 1500 Bytes
PPPoE-Overhead: 8 Bytes
Effektive MTU: 1492 Bytes

Symptome eines MTU-Problems

MTU-Probleme äußern sich oft subtil:

Manche Webseiten laden nicht oder nur teilweise (z. B. mit vielen Bildern oder viel Werbung - Grüße an eBay an dieser Stelle), Downloads brechen ab, VPN-Verbindungen (IPSec, OpenVPN) sind instabil, ping funktioniert, aber curl oder wget scheitern, traceroute sieht normal aus, aber mtr zeigt Paketverlust.

In meinem Fall: Teams Calls brachen konsequent fast sofort nach dem Start ab, während augenscheinlich alles andere problemlos funktionierte. Ich will nicht vorweggreifen, aber natürlich funktionierte nicht alles andere problemlos - es ist mir nur nicht aufgefallen.

Leider konnte mir Marvis nicht weiterhelfen, da ich als reiner Nutzer des Corporate Teams Account keinen Token in meiner Mist Organisation hinterlegt habe.

… und ab diesem Moment funktionierte fast gar nichts mehr; klar - things can never be unseen.

Nach Monaten mit unveränderter Konfiguration (zumindest auf meiner Seite) hatte ich aus heiterem Himmel MTU Probleme.

MTU messen - methodisch und reproduzierbar

Methode 1: ping mit „Don’t Fragment“-Flag

-M do: Setzt das DF-Flag (Don't Fragment)
-s 1472: 1472 Bytes Payload + 28 Bytes IP/ICMP-Header = 1500 Bytes Gesamtpaket

Wenn das Paket durchgeht, ist die MTU mindestens 1500. Wenn nicht, tastet man sich schrittweise nach unten: 1498, 1496, 1494 - you get the idea.

Mein erstes zuverlässiges Ergebnis erreichte ich mit einer Payload von 628 Bytes. Das kann nicht stimmen. Also weiter.

Methode 2: tracepath

Tracepath zeigt automatisch die MTU des Pfads an, leider war mein Ergebnis auch hiermit eher seltsam als aufschlußreich: 912 Bytes Pfad-MTU soll mein DSL angeblich fahren.

Irgendwas läut hier gewaltig falsch.

Als Alternative für Windows wurde mir MTUpath empfohlen; diese Empfehlung gebe ich hier ungeprüft weiter.

Zurück zum Anfang.

PPPoE + VLAN + DSLAM

Die Telekom nutzt bei vDSL folgende Struktur:

PPPoE-Tunnel (8 Bytes Overhead)
VLAN-Tagging (4 Bytes)
Teilweise zusätzliche DSLAM- oder BNG-Overheads

Das bedeutet: Die effektive MTU kann unter 1492 Bytes liegen, insbesondere wenn:

• der eigene Router das VLAN-Tagging übernimmt
• ein VPN oder Tunnelprotokoll zusätzlichen Overhead erzeugt
• der Zielserver ICMP-Fragmentation-Needed blockiert (und damit die Path MTU Discovery bricht) - um das auszuschließen testete ich mit unterschiedlichen Zielen unter unterschiedlicher administrativer Hoheit und in mehreren ASNs.

Mein Router ist ein Juniper SSR, Tunnelverbindungen nutze ich aktuell keine. Mein DSL wird allerdings mit einem VLAN-Tag angeliefert.

Rechnerisch sollte ich also bei 1500-8-4=1488 herauskommen.

Exkurs

Auswirkungen einer zu großen MTU

Wenn ein Paket größer ist als die MTU eines Zwischenhops und das DF-Flag gesetzt, wir das Paket verworfen.

Der Router sollte ein ICMP „Fragmentation Needed“ senden, viele Router senden diese jedoch nicht ab bzw. manche Firewalls blockieren diese ICMP Nachrichten, was zu einem sogenannten ‘Silent Drop’ führt. Pakete verschwinden im Nichts.

Ergebnis: Verbindungsabbrüche, Hänger, Timeouts

Auswirkungen einer zu kleinen MTU

• Performanceverlust durch unnötige Fragmentierung
• Erhöhter Overhead (mehr Pakete für dieselbe Datenmenge)
• Probleme mit Path MTU Discovery, wenn der Client eine zu kleine MTU annimmt

Ein möglicher Indikator ist unnatürlich hohe CPU Last auf dem Router, da deutlich mehr Pakete/Sekunde transportiert werden als notwendig bzw. üblich.

Allerdings ist mein Problem sicherlich keine zu kleine MTU.

Mein Troubleshooting-Weg

Mein Test mit ping -M do zeigt Paketverlust. Ein langsames Herantasten bis ein stabiler Wert erreicht ist funktioniert nahezu immer und ist auf jeden Fall einen Versuch wert.

Ausnahmen bestätigen die Regel.

Hat man einen stabilen Wert, die MTU auf dem WAN-Interface manuell auf diesen Wert setzen, vermutlich ist das Problem nun dauerhaft gelöst.

Fazit

MTU-Probleme sind tückisch, weil sie sich nicht wie klassische Netzwerkfehler verhalten. Sie sind leise, selektiv und schwer zu debuggen. Wer Telekom-vDSL nutzt und auf seltsame Verbindungsprobleme stößt, sollte die MTU unbedingt prüfen - und nicht blind auf 1492 vertrauen.

„Wenn’s hakt und keiner weiß warum - prüf die MTU, sei nicht dumm.“

Ja, aber ..?!

Stimmt - ich habe bisher nur Wege aufgezeigt, die mein Problem nicht eingrenzen konnten. Die Wahrheit ist, ich weiß bis heute nicht was los ist (bzw. war).

Einige Troubleshooting Sessions mit Kollegen aus dem Access-Milieu, einen wirklich fähigen und bemühten Telekom Techniker am Telefon - wir konnten nicht ermitteln was falsch lief. Zwischenzeitlich war keine MTU größer 604 Bytes (!) mehr möglich, meist aber war die MTU im Bereich von ~900 Bytes durch Ausprobieren zu ermitteln und dann auch über Tage stabil.

Mit 904 Bytes MTU läuft mein DSL wieder seit einigen Wochen stabil. Auch das Monitoring über Marvis Minis zeigt keine Ausreißer.

Für den Moment lebe ich damit - ich nutze diesen Anschluß nur noch für wenige Wochen, mein innerer Monk läßt es zu das Problem nicht zu debuggen - wenn auch nur widerwillig.

Eins noch

Generell lohnt sich ein Blick in die Router-Logs, eventuell läßt sich Dein Problem mit dem Wissen aus den Logs zielgerichteter Eingrenzen. Wenn nichts mehr weiterführt, paste die Meldungen 1:1 in eine Suchmaschine Deiner Wahl - eventuell findest Du auf diese Weise einen ähnlichen Fall und mit etwas Glück steht ein Lösungsansatz dabei.

Hat mir aber auch nicht geholfen.