MTU und Fragmentierung gehören zu den unscheinbaren Netzwerkthemen, die in VoIP-Projekten erstaunlich häufig die Sprachqualität ruinieren – und zwar genau dann, wenn „eigentlich alles stimmt“: DSCP ist korrekt, QoS-Queues sind sauber, Bandbreite ist ausreichend, und trotzdem knackt Voice, Gespräche brechen sporadisch ab oder Audio wird einseitig. Der Grund ist, dass Echtzeit-Audio zwar geringe Bitraten hat, aber äußerst empfindlich auf Paketverlustmuster reagiert. Fragmentierung macht aus einem Paket mehrere Fragmente – und sobald ein Fragment fehlt oder verspätet ist, ist das gesamte Originalpaket unbrauchbar. Das führt zu Drop-Clustern und hörbaren Aussetzern, obwohl die eigentliche Linkauslastung völlig unauffällig sein kann. Besonders tückisch wird es durch kleine MTU-Fehler an Übergängen: VLAN-Tagging, PPPoE/DSL, IPsec/VPN-Tunnel, GRE, VXLAN, MPLS oder Provider-Access-Profile verändern effektiv die maximale Paketgröße. Wenn dann Path MTU Discovery (PMTUD) nicht sauber funktioniert oder ICMP-Meldungen gefiltert werden, entsteht ein MTU-Blackhole – und Voice leidet ohne klare Fehlermeldung. Dieser Artikel erklärt praxisnah, warum MTU und Fragmentierung so kritisch für Voice sind, welche typischen Fehler in Telco- und Enterprise-Netzen auftreten und wie Sie MTU-Probleme gezielt vermeiden, messen und beheben.
MTU kurz erklärt: Die maximale Paketgröße auf einem Pfad
Die MTU (Maximum Transmission Unit) beschreibt die größte Nutzlast, die ein Link in einem Frame/Paket transportieren kann, ohne dass eine Aufteilung nötig ist. In klassischen Ethernet-Netzen ist 1500 Byte als Standard-MTU sehr verbreitet, aber in der Praxis ist das nur ein Ausgangspunkt. Schon kleine Änderungen an der Kapselung können die effektive MTU reduzieren.
- Layer-2-MTU: maximale Frame-Nutzlast auf Ethernet-Ebene (z. B. 1500 Byte IP-Payload bei Standard-Ethernet).
- IP-MTU: maximale Größe des IP-Pakets, das ohne Fragmentierung übertragen werden kann.
- Path MTU: die kleinste MTU entlang des gesamten Pfads – sie bestimmt, was Ende-zu-Ende möglich ist.
Für Voice ist nicht die „größte mögliche MTU“ entscheidend, sondern die kleinste Stelle im Pfad. Eine einzige zu kleine MTU an einem Segment reicht aus, um Probleme auszulösen.
Warum Voice so empfindlich ist: Fragmentverlust ist Paketverlust
VoIP-Medienverkehr (RTP/SRTP) läuft typischerweise über UDP. UDP kennt keine Retransmits wie TCP. Wenn ein Paket verloren geht, ist es weg. Fragmentierung verschärft das Problem:
- Ein Paket wird in mehrere Fragmente geteilt: aus 1 wird 2 oder mehr.
- Verlust eines Fragments bedeutet Verlust des gesamten Pakets: der Empfänger kann es nicht zusammensetzen.
- Loss-Muster wird clusteriger: statt vereinzelter Drops entstehen hörbare Aussetzer.
Das ist der zentrale Grund, warum „kleine MTU-Fehler“ Voice ruinieren: Sie verwandeln wenige, schwer sichtbare Fragmentverluste in hörbare Audioaussetzer. Und weil RTP-Pakete in festen Intervallen kommen, wirken diese Aussetzer als Knacken oder Stottern.
IPv4 vs. IPv6: Fragmentierung funktioniert unterschiedlich
Für die Praxis ist wichtig zu wissen, dass Fragmentierung bei IPv4 und IPv6 anders gehandhabt wird:
- IPv4: Fragmentierung kann unterwegs durch Router erfolgen (wenn DF nicht gesetzt), oder bereits am Sender.
- IPv6: Router fragmentieren nicht; Fragmentierung passiert nur am Sender, basierend auf Path MTU.
Damit wird PMTUD bei IPv6 noch wichtiger. Wenn PMTUD scheitert, werden zu große Pakete nicht fragmentiert, sondern verworfen – und Voice-/Signaling-Flows können plötzlich „schwarz“ werden.
PMTUD: Der Mechanismus, der MTU-Fehler sichtbar machen soll
Path MTU Discovery (PMTUD) ist das Verfahren, mit dem ein Sender herausfindet, wie groß Pakete maximal sein dürfen. Vereinfacht läuft es so:
- Sender sendet ein großes Paket (oder nutzt eine Standard-MTU).
- Unterwegs gibt es eine Engstelle mit kleinerer MTU.
- Netz sendet eine Meldung zurück („Fragmentation needed“ / „Packet too big“), damit der Sender die Paketgröße reduziert.
In vielen realen Netzen scheitert PMTUD aus einem simplen Grund: ICMP wird gefiltert oder rate-limitiert. Dann entsteht ein MTU-Blackhole: Pakete sind zu groß, werden verworfen, und der Sender erfährt nie, warum.
Warum MTU-Blackholes besonders tückisch sind
Ein MTU-Blackhole wirkt oft wie ein „sporadisches Qualitätsproblem“, obwohl es strukturell ist. Typische Symptome:
- Einweg-Audio: Signaling klappt, aber Medienrichtung bricht; oder umgekehrt.
- Calls brechen beim Aufbau ab: SIP/SDP oder TLS/DTLS handshakes scheitern, wenn Pakete größer werden.
- Probleme nur über VPN: ohne Tunnel läuft es, mit IPsec nicht.
- Nur bestimmte Ziele betroffen: weil nur bestimmte Pfade eine kleinere MTU haben.
Gerade bei VoIP wirkt das „unlogisch“, weil Audio klein ist. Der Punkt ist: Nicht nur RTP zählt. Auch Signaling, ICE/STUN/TURN, TLS, Zertifikate oder SIP/SDP können größere Pakete erzeugen. Wenn dort MTU bricht, kommt es zu Setup-Problemen, die wie „QoS“ aussehen, aber tatsächlich MTU sind.
Wo MTU-Probleme typischerweise entstehen
In Telco- und Enterprise-Netzen gibt es wiederkehrende Hotspots, an denen sich MTU „heimlich“ verändert:
- PPPoE/DSL: reduziert die nutzbare MTU häufig unter 1500, wenn nicht gegengeplant.
- IPsec/VPN: ESP/UDP/Outer-IP-Header addieren Overhead; effektive MTU sinkt.
- GRE/Overlay: zusätzliche Header, oft ohne ausreichend angepasste MTU/MSS.
- VXLAN/EVPN: Encapsulation benötigt Headroom; ohne Jumbo-Frames entstehen Drops oder Fragmentierung.
- Carrier Ethernet/Q-in-Q: zusätzliche VLAN-Tags, ggf. reduzierte effektive MTU oder falsch konfigurierte L2-MTU.
- MPLS/SR: Label-Stack fügt Overhead hinzu; MTU muss im Core ausreichend dimensioniert sein.
- Firewalls: ICMP wird gefiltert; PMTUD scheitert, obwohl die MTU an sich korrekt wäre.
Die häufigste Ursache ist nicht „zu kleine MTU überall“, sondern „ein Segment hat weniger Headroom als erwartet“ – oft durch Encapsulation.
Warum Fragmentierung und QoS sich gegenseitig verschlechtern können
QoS priorisiert Pakete nach Klassen. Fragmentierung verändert diese Pakete:
- Mehr Pakete: aus einem Paket werden mehrere Fragmente; die Paketanzahl steigt, PPS steigt.
- Queue-Interaktion: Fragmente können in unterschiedlichen Queues landen, wenn Klassifizierung falsch ist.
- Drop-Risiko steigt: mehr Pakete erhöhen die Wahrscheinlichkeit, dass etwas gedroppt wird, besonders bei Microbursts.
Selbst wenn Sie EF/LLQ für Voice sauber betreiben, ist Fragmentierung ein Risiko, weil sie das Loss- und Jitter-Verhalten verschlechtert. Die beste QoS-Strategie für Voice ist daher: Fragmentierung möglichst vermeiden, statt sie „zu priorisieren“.
MTU-Designregel für Echtzeit: Headroom einplanen statt „gerade so“
Ein robustes Design stellt sicher, dass der Pfad genug MTU-Headroom für die größte erwartete Kapselung hat. Praktische Leitlinien:
- Tunnel-Overhead berücksichtigen: IPsec/GRE/VXLAN/MPLS – jedes zusätzliche Headerbyte zählt.
- Jumbo-Frames im Underlay, wo nötig: besonders bei VXLAN/EVPN ist ausreichende MTU im Fabric-Underlay entscheidend.
- Einheitliche MTU-Standards: im Core/Metro konsistent konfigurieren; „Misch-MTUs“ sind Fehlerquellen.
- PMTUD ermöglichen: ICMP für PMTUD nicht blind blocken, sondern gezielt erlauben und rate-limiting sinnvoll konfigurieren.
Der wichtigste Gedanke: MTU ist ein End-to-End-Thema. Es reicht nicht, einzelne Links zu prüfen. Sie brauchen ein Pfadmodell.
Warum kleine MTU-Fehler oft zuerst in Voice auffallen
Voice hat zwei Eigenschaften, die MTU-Fehler schnell sichtbar machen:
- Hohe Wahrnehmungssensibilität: Menschen hören kurze Aussetzer sofort, selbst wenn es nur Millisekunden sind.
- Keine Retransmits: RTP über UDP „heilt“ Verlust nicht; Probleme bleiben hörbar.
Datenverkehr kann dieselben MTU-Probleme haben, wirkt aber oft „nur langsam“ oder erholt sich durch Retransmits. Deshalb ist VoIP häufig das erste System, das MTU-Fehler entlarvt.
Praktische Diagnose: Wie Sie MTU-Probleme zuverlässig finden
MTU-Fehler lassen sich mit einem klaren Vorgehen meist schnell eingrenzen:
- Pfad identifizieren: welcher Weg wird genutzt (VPN, MPLS, Internet, Dual-Stack)?
- ICMP/PMTUD prüfen: werden „Packet too big“ / „Fragmentation needed“ Meldungen blockiert?
- MTU entlang der Segmente prüfen: LAN, WAN, Tunnel-Interfaces, Provider-Übergaben, Underlay.
- Symptom-Trigger suchen: tritt der Fehler bei bestimmten Aktionen auf (Call Setup, Screen Share, SRTP-Keying)?
In vielen Fällen hilft es, gezielt zu testen, ob große Pakete den Pfad passieren. Wenn große Pakete scheitern, aber kleine funktionieren, ist MTU/PMTUD der wahrscheinlichste Kandidat.
Konfigurationsthemen, die Voice indirekt durch MTU brechen
In der Praxis sind es oft nicht die RTP-Pakete selbst, sondern Nebeneffekte:
- SRTP/DTLS: Handshakes können größere Pakete erzeugen; MTU-Blackhole führt zu Verbindungsproblemen.
- SIP over TLS: Zertifikatsketten und TLS-Records können MTU-problematisch sein, wenn PMTUD nicht funktioniert.
- TURN-Relays: bei NAT-Traversal entstehen zusätzliche Kapselungen; effektive MTU sinkt.
- Recording/Analytics: zusätzliche Flows verändern Traffic-Muster, MTU-Probleme treten plötzlich „unter Last“ auf.
Wenn Voice „nur in bestimmten Szenarien“ bricht, ist MTU häufig der Grund, weil die Paketgrößen in diesen Szenarien steigen.
Best Practices: MTU und Fragmentierung so planen, dass Voice stabil bleibt
- Fragmentierung vermeiden: insbesondere für Echtzeit (RTP/SRTP) und für sicherheitsrelevante Handshakes.
- Headroom für Encapsulation: Tunnel und Overlays brauchen zusätzliche MTU; Underlay entsprechend anheben oder MSS/MTU sauber anpassen.
- PMTUD ermöglichen: ICMP für PMTUD gezielt erlauben; nicht pauschal blocken.
- Einheitliche MTU-Standards: Core/Metro/Access so konsistent wie möglich halten; Abweichungen dokumentieren.
- QoS nicht als Pflaster nutzen: Priorisierung behebt MTU-Blackholes nicht; zuerst MTU stabilisieren, dann QoS optimieren.
- Monitoring ergänzen: Fehlerraten, Fragment-Counter, Drops auf Tunnel-Interfaces und Anomalien bei Call Setup Times beobachten.
Typische Fehler, die „klein“ wirken, aber große Auswirkungen haben
- VPN aktiviert, MTU nicht angepasst: plötzlich knackt Voice oder Calls brechen, obwohl QoS unverändert ist.
- ICMP wird blockiert: PMTUD kann nicht funktionieren, MTU-Blackhole entsteht.
- VXLAN ohne Jumbo-Frames: Overlays droppen oder fragmentieren, Echtzeit wird instabil.
- Misch-MTU im Core: einzelne Links kleiner, nur bestimmte Pfade betroffen, schwer zu reproduzieren.
- Falsche Klassifizierung von Fragmenten: Fragmente landen nicht in der Voice-Klasse, Drops werden wahrscheinlicher.
Praxis-Blueprint: Vorgehen für MTU-sichere Voice-Services
- Pfadmodell erstellen: alle Kapselungen und Übergänge (VLAN, PPPoE, VPN, MPLS, VXLAN) erfassen.
- Worst-Case-Overhead berechnen: wie viel Headroom brauchen Sie für Tunnel/Overlay?
- MTU-Standards festlegen: Underlay-MTU so wählen, dass Overlays ohne Fragmentierung laufen.
- PMTUD sicherstellen: ICMP-Meldungen für „Packet too big“/„Fragmentation needed“ gezielt zulassen.
- Voice-QoS danach stabilisieren: EF/LLQ mit Limit, Shaping an Engpässen, keine harten Policer auf Voice.
- Validieren: Tests mit realen Szenarien (SRTP, VPN, Roaming, Busy Hour), Monitoring auf Drops und Setup-Zeiten.
Häufige Fragen zu MTU, Fragmentierung und Voice
Warum kann Voice schlecht sein, obwohl RTP-Pakete doch klein sind?
Weil nicht nur RTP zählt. Signaling, Verschlüsselungshandshakes, TURN/Relay-Kapselungen und Tunnel-Overhead können größere Pakete erzeugen. Wenn diese an einer zu kleinen MTU scheitern oder fragmentiert werden und Fragmente verloren gehen, entstehen hörbare Aussetzer oder Setup-Probleme.
Ist Fragmentierung immer schlecht?
Für Echtzeit-Audio ist Fragmentierung in der Praxis fast immer unerwünscht, weil sie die Verlustwahrscheinlichkeit pro Originalpaket erhöht und Drop-Cluster begünstigt. Für Voice ist das Ziel daher: Fragmentierung vermeiden, statt sie zu „tolerieren“.
Was ist der wichtigste Fix bei MTU-Problemen?
End-to-End Headroom schaffen und PMTUD ermöglichen. Wenn Overlays/VPNs genutzt werden, muss die effektive MTU angepasst werden, und ICMP für „Packet too big“ darf nicht pauschal blockiert werden. Danach können QoS-Mechanismen ihre Wirkung entfalten, ohne dass MTU-Blackholes die Sprachqualität sabotieren.