QoS bei ECMP ist ein Thema, das in Provider- und Backbone-Netzen zunehmend wichtig wird, weil Equal-Cost Multi-Path (ECMP) eine der effektivsten Methoden ist, um Last über mehrere gleichwertige Pfade zu verteilen. Gleichzeitig ist ECMP eine typische Quelle für Jitter-Probleme, wenn Echtzeitverkehr (Voice, interaktives Video, WebRTC) nicht bewusst eingeordnet wird. Der Grund ist kein „Bug“ in ECMP, sondern Physik und Statistik: ECMP verteilt Flows anhand von Hashing. Wenn Pfade unterschiedliche Queueing-Charakteristiken, leicht unterschiedliche Latenzen oder asymmetrische Engpässe haben, kann schon eine kleine Hash-Verlagerung, ein Link-Event oder ein Rebalancing zu Delay-Spitzen, Reordering und damit zu hörbaren Aussetzern führen. Besonders tückisch wird es bei Microbursts und bei großen Aggregationspunkten: Die Last ist im Durchschnitt gut verteilt, aber kurze Spitzen treffen zufällig einen Pfad stärker, während ein anderer frei bleibt – und genau diese Sekundenereignisse zerstören MOS und QoE. Ein professionelles QoS-Design bei ECMP hat deshalb zwei Ziele: Erstens muss die Service-Semantik (DSCP/CoS/MPLS-TC) auf allen ECMP-Pfaden identisch umgesetzt sein, damit Voice überall die gleiche Behandlung erhält. Zweitens muss die Lastverteilung so gestaltet sein, dass Echtzeitflows stabil bleiben und nicht durch Reordering, Pfadwechsel oder ungleiches Queueing degradiert werden. Dieser Artikel zeigt, wie ECMP technisch arbeitet, wo Jitter in ECMP-Topologien entsteht und welche Designregeln Voice und Video stabil halten – ohne die Vorteile der Lastverteilung zu verlieren.
ECMP kurz erklärt: Was wird verteilt – Pakete oder Flows?
ECMP verteilt Verkehr über mehrere Pfade mit gleichen Routingkosten. In den meisten Produktionsnetzen erfolgt das nicht paketweise, sondern flowbasiert: Ein Hash über Headerfelder (z. B. 5-Tuple) entscheidet, welcher Flow auf welchem Next Hop landet. Dadurch bleibt die Reihenfolge innerhalb eines Flows in der Regel stabil.
- Flowbasiertes ECMP: ein Flow bleibt auf einem Pfad, Reordering ist gering, ideal für TCP und viele UDP-Flows.
- Paketbasiertes ECMP: jedes Paket kann einen anderen Pfad nehmen; Reordering-Risiko ist hoch und für Echtzeit meist ungeeignet.
- Unequal Cost/Weighted ECMP: Pfade sind nicht gleich, oder werden gewichtet; kann Lastverteilung verbessern, erhöht aber Komplexität.
Für QoS ist entscheidend: Echtzeitverkehr profitiert von stabilen Pfaden. Alles, was Pfadstabilität oder Reihenfolge gefährdet, kann Jitter erhöhen.
Warum ECMP Jitter erzeugen kann, obwohl die Pfade „gleich“ sind
„Equal cost“ heißt nicht „gleiches Delay“. Zwei Pfade können im Routing gleichwertig sein, aber in der Realität unterschiedliche Eigenschaften haben:
- Unterschiedliche Latenz: mehr Hops, andere Optikstrecken, andere Transporttechnologien.
- Unterschiedliche Engpässe: einer der Pfade hat ein rate-limitiertes Segment oder eine stärker überbuchte Aggregation.
- Unterschiedliche Queueing-Implementierung: andere Plattformen, andere Buffer, andere WRED/Queue-Limits.
- Unterschiedliche Auslastung: Hashing verteilt nicht perfekt, Hotspots sind normal.
Wenn Voice auf Pfad A im Durchschnitt 8 ms One-Way Delay hat und auf Pfad B 18 ms, ist das zunächst nicht tragisch – solange der Flow nicht wechselt. Wird der Flow jedoch durch Rehashing, Link-Events oder ECMP-Änderungen umgehängt, entstehen Delay-Sprünge. Diese Sprünge erscheinen als Jitter und können den Jitter-Buffer destabilisieren.
Der Hauptfeind in ECMP-Topologien: Rehashing und Flow-Migration
ECMP ist stabil, solange die Hash-Buckets stabil sind. Probleme entstehen, wenn sich die Menge der verfügbaren Pfade ändert oder wenn das Gerät aktiv rebalanciert:
- Link Down/Up: Pfadanzahl ändert sich, Hashing wird neu verteilt, viele Flows migrieren gleichzeitig.
- IGP-Event: neue ECMP-Nexthops, geänderte Kosten, neu berechnete Pfade.
- ECMP Rebalancing: manche Plattformen verteilen Flows dynamisch um, um Last auszugleichen.
- Uneinheitliche Hash-Algorithmen: unterschiedliche Router im Pfad nutzen unterschiedliche Hash-Inputs, was zu asymmetrischen Pfaden führt.
Für Echtzeit bedeutet das: Große, synchrone Flow-Migrationen sind Gift, weil sie Microbursts, Queue-Spitzen und kurzzeitige Reordering-Effekte auslösen können.
Reordering: Warum selbst flowbasiertes ECMP nicht immer „reorder-frei“ ist
Auch bei flowbasiertem ECMP kann Reordering auftreten:
- Flowdefinition ist nicht echtzeitgerecht: Wenn Hashing nur auf 2-Tuple (IP/Proto) basiert, können mehrere Medienströme in einen Hash fallen und mit NAT/Portänderungen wandern.
- Per-Packet Load Balancing in einem Segment: ein einzelner Switch/Router im Pfad verteilt paketweise.
- Asymmetrische Queueing Delays: wenn Pakete eines Flows (durch Fehler oder Encapsulation) auf zwei Pfade geraten, kommen sie mit unterschiedlichen Delays an.
- Hash-Seed Änderungen: Rehashing kann kurzfristig zu „Mischzuständen“ führen, wenn FIB/ECMP-States aktualisiert werden.
Für VoIP ist Reordering praktisch Jitter: Der Receiver sieht schwankende Interarrival-Zeiten. Bei größeren Sprüngen entsteht Late Loss, weil Pakete zu spät kommen und verworfen werden.
QoS-Grundforderung bei ECMP: Identische Service-Semantik auf allen Pfaden
Die wichtigste Regel für QoS bei ECMP ist einfach, aber oft verletzt: Alle ECMP-Pfade müssen die gleichen Klassen und Mappings besitzen. Wenn Pfad A DSCP EF korrekt in eine Voice-LLQ mappt, Pfad B aber EF als Best Effort behandelt, ist die Qualität zufällig und driftet mit dem Hash.
- DSCP→Queue Mapping: auf allen ECMP-Links identisch.
- DSCP↔CoS↔MPLS-TC: konsistente Mappingtabellen über Access, Metro und Core.
- LLQ-Limits: gleich dimensioniert, damit Voice nicht auf einem Pfad dropt und auf dem anderen nicht.
- Shaping/Policing: gleiche Profile an vergleichbaren Engpässen; keine „zufälligen“ Policers nur auf einem Pfad.
Diese Pfadgleichwertigkeit ist die Grundlage. Ohne sie ist jedes ECMP-Design für Echtzeit ein Glücksspiel.
LLQ und ECMP: Wie Sie Voice stabil halten, ohne das Netz zu gefährden
Voice benötigt Low Latency. Im ECMP-Kontext gilt besonders: Voice muss klein bleiben. Wenn EF/LLQ inflationiert, verschärft ECMP die Risiken, weil mehrere Pfade jeweils Premiumqueues füllen können und bei Rehashing große Mengen an Premiumtraffic umspringen.
- Voice in LLQ: strict priority für Audio, aber immer mit Bandbreitenlimit.
- Trust Boundary: EF nur aus kontrollierten Quellen akzeptieren, sonst Premium-Inflation.
- Keine LLQ für Video: Video ist zu groß und zu burstig, es gehört in gewichtete Klassen.
- Queue-Limits klein: Voice darf nicht gepuffert werden; große Puffer erhöhen Jitter.
Im ECMP-Betrieb ist die LLQ-Limitierung auch ein Stabilitätsmechanismus: Sie verhindert, dass eine Flow-Migration Premiumklassen überproportional belastet.
Video und ECMP: Stabilität durch Gewichte und Throughput-Fenster
Interaktives Video läuft häufig über UDP (WebRTC) oder über optimierte Transportmechanismen. Es ist bandbreitenstärker als Voice, toleriert etwas mehr Delay, reagiert aber empfindlich auf Drop-Cluster und Throughput-Wellen. ECMP kann diese Wellen verstärken, wenn Hashing Hotspots erzeugt.
- Video in AF-Klasse: gewichtete Queue mit garantierten Anteilen statt strict priority.
- Shaping an Engpässen: glättet Bursts und reduziert Drop-Cluster bei ECMP-Rebalancing.
- Congestion Avoidance: in Video/BE-Klassen können Mechanismen gegen Tail Drop helfen, Throughput-Wellen zu glätten.
Ein gut gewähltes Klassenbudget sorgt dafür, dass Video nicht die Voice-LLQ indirekt gefährdet und dass Video bei Pfadänderungen nicht sofort einfriert.
ECMP-Hashing richtig wählen: Der unterschätzte QoS-Hebel
Wie der Hash gebildet wird, entscheidet über Lastverteilung und Flow-Stabilität. Für Echtzeit sind zwei Ziele wichtig: stabile Zuordnung pro Flow und ausreichende Verteilung über viele Flows.
- 5-Tuple Hashing: Quell-/Ziel-IP, Ports, Protokoll – in vielen Netzen der beste Kompromiss.
- L4-Port-Visibility: bei Encapsulation (GRE, VXLAN, IPsec) sind Ports ggf. nicht sichtbar; dann wird Hashing gröber und Hotspots werden wahrscheinlicher.
- Entropy-Quellen: manche Technologien fügen Entropy ein, um Lastverteilung zu verbessern; ohne Entropy landen viele Flows im gleichen Bucket.
Wenn Hashing zu grob ist, kann ein einziger großer Flow (z. B. Video-Stream) einen ECMP-Pfad füllen, während andere frei bleiben. Dann entstehen Queueing Delay-Spitzen und Jitter – obwohl die Gesamtbandbreite ausreichend wäre.
Encapsulation und ECMP: Warum Tunnel ECMP-Probleme verschärfen können
Overlays und VPNs verändern, welche Headerfelder sichtbar sind. Das beeinflusst Hashing und QoS gleichzeitig:
- Hashing wird „blind“: wenn nur Outer-IP sichtbar ist, werden viele Flows gemeinsam gehasht, Hotspots entstehen.
- Outer-DSCP entscheidet: Underlay queued nach Outer-Header; fehlendes DSCP-Copy führt zu QoS-Loch.
- MTU/Fragmentierung: Tunnel-Overhead kann Fragmentierung erzeugen; Fragmentverlust wirkt wie Loss und ruiniert Echtzeit.
Best Practice: Outer-DSCP kontrolliert mappen, MTU-Headroom sicherstellen und – wenn möglich – Entropy/Flow-Labels nutzen, damit ECMP trotz Encapsulation gut verteilt.
Microbursts an Aggregationspunkten: ECMP verteilt Durchschnitt, nicht Spitzen
ECMP ist stark bei mittleren Lasten über viele Flows. Bei Microbursts ist die Realität anders: Viele Flows können gleichzeitig „spiken“ und zufällig denselben Pfad treffen. Das ist besonders an Aggregationspunkten relevant (Metro, PE, Spine/Leaf).
- Symptom: Queueing Delay-Perzentile steigen, obwohl Interface-Auslastung im Durchschnitt moderat ist.
- Folge: Voice sieht Jitter, Video sieht Freeze/Quality-Pendeln.
- Gegenmittel: Shaping an Engpässen, kontrollierte Queue-Limits, Monitoring in Sekundenauflösung, ggf. mehr ECMP-Pfade oder bessere Hash-Entropy.
Im Betrieb sollten Sie deshalb nicht nur „Link utilization“ betrachten, sondern Queueing Delay und Drops pro Klasse – genau dort zeigt ECMP-bedingter Jitter zuerst.
Monitoring und Verifikation: So beweisen Sie, dass ECMP QoS stabil bleibt
QoS bei ECMP ist nur dann vertrauenswürdig, wenn Sie Verifikation und Telemetrie klassen- und pfadbewusst betreiben.
- Traffic pro Klasse pro Pfad: erkennen, ob ein Pfad überproportional viel EF/AF trägt.
- Queueing Delay/Drops pro Klasse: Perzentile und Peaks, nicht nur Mittelwerte.
- Active Probes pro Klasse: EF/AF/BE Probes zwischen Messpunkten, um Pfadqualität sichtbar zu machen.
- Hash/ECMP-Events: Link-Events, Rehashing, ECMP-Nexthop-Änderungen korrelieren mit QoE-Einbrüchen.
Ein operativer Leitsatz bleibt: EF-Drops sind ein Incident. Wenn EF auf einem ECMP-Pfad dropt, ist entweder Kapazität, Mapping oder Premium-Governance falsch.
Designregeln: Lastverteilung ohne Jitter-Probleme
- Pfade qualitativ angleichen: ähnliche Latenz, ähnliche Engpässe, identische QoS-Policies auf allen ECMP-Pfaden.
- Hashing optimieren: 5-Tuple, Entropy, Flow-Labels nutzen; Tunnel so gestalten, dass Hashing nicht blind wird.
- Voice strikt und limitiert: LLQ für Audio mit Limit und Trust Boundary gegen Premium-Inflation.
- Video gewichtet: AF-Klasse mit garantierten Anteilen, keine LLQ.
- Shaping an Engpässen: besonders bei rate-limitierten Links und an Aggregationsübergängen, um Microbursts zu glätten.
- MTU sauber planen: keine Fragmentierung durch alternative Pfade/Encapsulation; PMTUD ermöglichen.
- Failover-Tests: ECMP-Hash-Neuverteilung und Link-Events testen, weil sie die größten QoE-Spitzen erzeugen.
Typische Fehlersignaturen bei ECMP-bedingten QoS-Problemen
- Voice knackt nur sporadisch: Microbursts und Queueing Delay Peaks auf einem ECMP-Pfad; Perzentile zeigen es.
- Video pendelt in der Qualität: Hotspot-Pfad, Throughput-Wellen, Tail Drop in Video/BE; Hashing/Entropy prüfen.
- Probleme nach Link-Event: Rehashing migriert Flows, erzeugt Bursts; Shaping/Queue-Limits prüfen.
- Nur über VPN betroffen: Outer-DSCP fehlt oder Hashing ist blind; Tunnel-Mapping und Entropy prüfen.
- EF-Drops auf einem Pfad: Pfadgleichwertigkeit fehlt oder LLQ-Limit zu eng; Premium-Inflation möglich.
Praxis-Blueprint: ECMP und QoS in 8 Schritten stabilisieren
- Schritt 1: Serviceklassen definieren (Voice/EF, Video/AF, Control, BE) und End-to-End Mapping dokumentieren.
- Schritt 2: ECMP-Pfade inventarisieren und qualitative Unterschiede messen (Delay, Engpässe, Queue-Implementierung).
- Schritt 3: QoS-Policies auf allen Pfaden vereinheitlichen (Queues, Limits, Weights, WRED, Shaping).
- Schritt 4: Hashing-Parameter prüfen (5-Tuple, Entropy, Tunnel-Visibility) und Hotspot-Risiko reduzieren.
- Schritt 5: Voice strikt und limitiert behandeln, Trust Boundary setzen.
- Schritt 6: Shaping an Engpässen einführen/anpassen, um Microbursts und Rehash-Spitzen zu glätten.
- Schritt 7: Monitoring in Sekundenauflösung aufbauen (Queueing Delay/Drops pro Klasse, Traffic pro Pfad).
- Schritt 8: Link-Events und Rehashing testen, QoE-KPIs (MOS, Freeze) mit ECMP-Events korrelieren.
Häufige Fragen zu QoS bei ECMP
Ist ECMP grundsätzlich schlecht für Voice?
Nein. Flowbasiertes ECMP kann sehr gut mit Voice funktionieren, wenn Pfade qualitativ ähnlich sind, QoS-Mappings konsistent sind und Voice in einer strikt limitierten Low-Latency-Klasse läuft. Probleme entstehen vor allem durch Pfadunterschiede, Rehashing-Events und fehlendes Burst-Handling.
Warum treten Jitter-Probleme oft erst nach einem Link-Event auf?
Weil sich die Menge der ECMP-Pfade ändert und Flows neu verteilt werden. Diese Flow-Migration erzeugt Microbursts und Queueing Delay Peaks. Wenn Shaping fehlt oder Queue-Limits knapp sind, werden diese Peaks hörbar als Knacken oder sichtbar als Video-Freezes.
Was ist der wichtigste „Quick Win“ gegen ECMP-bedingten Jitter?
Shaping an den Engpässen und konsequente Pfadgleichwertigkeit der QoS-Policies. Shaping glättet Umschalt- und Rehash-Spitzen, und identische DSCP/CoS/TC-Mappings verhindern, dass Voice zufällig in eine schlechtere Behandlung fällt.