ECMP Design: Load Sharing ohne Flow Imbalance

ECMP Design ist im Telco- und Provider-Umfeld eine der wichtigsten Grundlagen, um Backbone-, Metro- und Data-Center-Topologien effizient auszunutzen. Equal-Cost Multi-Path (ECMP) verteilt Verkehr über mehrere gleichwertige Pfade und erhöht so Kapazität, Resilienz und Wartbarkeit. In der Praxis ist ECMP jedoch nicht automatisch „gleichmäßig“. Häufig sehen Betriebsteams das gleiche Muster: Alle Links sind redundant, aber ein einzelner Pfad ist dauerhaft heiß, während andere Pfade Headroom haben. Oder es kommt zu sporadischen Paketverlusten und Jitter, obwohl die durchschnittliche Auslastung niedrig ist. Der Grund liegt fast immer in Flow Imbalance: ECMP verteilt nicht Pakete, sondern Flows – und Flows sind selten gleich groß. Ein einzelner „Elephant Flow“ kann einen Link überlasten, während viele kleine „Mice Flows“ auf anderen Links kaum Last verursachen. Hinzu kommen Hashing-Details, ungleiche Linkkapazitäten, asymmetrische Topologien, unklare Metrikmodelle und wechselnde Pfadsets bei Konvergenz oder Wartung. Ein professionelles ECMP-Design behandelt Load Sharing daher als Engineering-Aufgabe: Topologie, Hash-Strategie, Link-Bundling, Traffic Engineering, Telemetry und Betriebsprozesse müssen zusammenpassen. Dieser Artikel zeigt praxisnah, wie Sie ECMP so gestalten, dass Load Sharing stabil funktioniert – ohne Flow Imbalance, ohne Überraschungen im Failover und ohne OPEX-Explosion.

ECMP richtig verstehen: Warum „gleich teuer“ nicht „gleich genutzt“ bedeutet

ECMP basiert auf der Idee, dass mehrere Pfade die gleichen Routingkosten haben. Router können dann mehrere Next-Hops installieren und Verkehr über diese Pfade verteilen. Wichtig ist: Die Verteilung erfolgt in der Regel nicht per Round-Robin pro Paket (das würde Reordering erzeugen), sondern per Hash pro Flow. Ein Flow ist typischerweise durch Felder wie Quell-/Ziel-IP, Ports und Protokoll definiert. Das ist gut für Reihenfolge, aber schlecht für Gleichverteilung, wenn Flowgrößen stark variieren.

• Per-Flow Hashing: Stabil für Paket-Reihenfolge, aber anfällig für ungleich große Flows.
• Elephant vs. Mice: Wenige große Flows können einzelne Links dominieren.
• Hash-Entropie: Wenn zu wenige Header-Felder in den Hash eingehen, entstehen „Kollisionen“.
• Pfadset-Dynamik: Bei Failover oder Maintenance ändert sich das ECMP-Set und damit die Hash-Verteilung.

Ein Merksatz für den Betrieb

ECMP ist kein Lastverteiler im klassischen Sinn, sondern ein deterministischer Flow-Zuordner. Wenn Sie Gleichverteilung wollen, müssen Sie die Bedingungen schaffen, unter denen der Hash auch wirklich streut.

Ursachen von Flow Imbalance: Die typischen Muster im Provider-Netz

Flow Imbalance hat selten nur eine Ursache. Oft ist es eine Kombination aus Traffic-Profil, Hashing-Parametern und Topologie. Provider-Netze haben besondere Traffic-Eigenschaften: große Content-Flows, DCI-Last, Aggregation von vielen Kunden über wenige Ports, und häufige Peak-Phasen. Dadurch treten Elephant Flows häufiger auf als in kleineren Enterprise-Netzen.

• Große Einzelströme: DCI-Replikation, Backup, Video-Distribution, Cloud-Transfers.
• Aggregationseffekte: Viele Kunden/Services bündeln sich an wenigen Service-Edges oder PoP-Uplinks.
• Ungleiche Pfadkapazitäten: 100G/400G gemischt oder unterschiedliche Overhead/MTU-Effekte.
• Asymmetrische Topologie: Pfade sind „gleich teuer“, aber nicht gleich robust oder gleich kurz.
• Hash-Kollisionen: Zu wenig Entropie (z. B. nur 5-Tuple bei NAT/Proxy-Szenarien).

Warum NAT, Proxies und Tunnels Hashing erschweren können

Wenn viele Flows hinter denselben Quelladressen oder Ports „versteckt“ sind (z. B. durch NAT, Carrier-Grade NAT, Proxies oder bestimmte Tunnelmechanismen), reduziert sich die Entropie. Dann kann der Hash viele Sessions als ähnlich betrachten und sie auf denselben Next-Hop legen. Das ist ein klassischer Grund für „mystische“ Hotspots.

Topologie-Design für ECMP: Gleichwertige Pfade sind eine Designentscheidung

ECMP funktioniert am besten, wenn die Topologie echte Symmetrie bietet: gleiche Kosten, ähnliche Hopanzahl, ähnliche Kapazität und ähnliche Failure-Risiken. In Backbones sind partielle Meshes und Spine-Leaf-Fabrics dafür prädestiniert. In Metro- oder Ring-Umgebungen ist ECMP schwieriger, weil Pfade oft nicht wirklich gleichwertig sind oder weil ein Ring im Fehlerfall zwangsläufig asymmetrisch wird.

• Spine-Leaf: Sehr gut geeignet, weil Pfade meist gleich lang und gleich kapazitiv sind.
• Backbone Partial Mesh: Gut geeignet, wenn Linkkosten konsistent und Kapazitäten vergleichbar sind.
• Ringe: ECMP ist begrenzt, weil viele Szenarien nur einen „guten“ Pfad haben; im Fehlerfall starke Asymmetrie.
• Hub-and-Spoke: ECMP oft nur begrenzt sinnvoll, weil der Hub sowieso zentraler Engpass ist.

Designregel: ECMP-Pfade müssen auch im Störfall brauchbar sein

Viele Netze sehen im Normalbetrieb gut aus, kippen aber im Failover: Das ECMP-Set schrumpft, Hash-Verteilung ändert sich, und der verbleibende Pfad läuft in Überlast. Ein gutes ECMP-Design plant Störfallreserve und testet Failoverpfade unter realistischer Last.

Metrikmodell und Pfadgleichheit: ECMP beginnt im IGP

IGP-Metriken bestimmen, welche Pfade als gleichwertig gelten. Ein inkonsistentes Metrikmodell kann dazu führen, dass eigentlich vorhandene Pfadvielfalt nicht genutzt wird oder dass ein „falscher“ Pfad gleichwertig wird. Für Provider-Backbones gilt: Metriken sollten einfach, konsistent und nachvollziehbar sein. Zu kreative Metriken erhöhen den Zustandsraum und machen Hash-Verhalten schwer erklärbar.

• Konsistenz: Gleiche Linkklassen sollten gleiche Kosten haben.
• Kapazitätsbewusstsein: Wenn Linkkapazitäten stark variieren, müssen Kostenmodelle das berücksichtigen oder ECMP wird unfair.
• Regionale Leitplanken: Metriken können regionale Pfadpräferenzen unterstützen, sollten aber standardisiert bleiben.
• Domänengrenzen: Summarization und Hierarchie dürfen ECMP nicht ungewollt „verstecken“.

Equal-Cost ist eine bewusste Entscheidung, kein Zufallsprodukt

Wenn Sie „gleichwertige“ Pfade wollen, müssen Sie Kosten und Topologie so gestalten, dass diese Gleichwertigkeit stabil ist – auch nach Erweiterungen und Wartungen. Das ist ein Blueprint-Thema, nicht nur ein Konfigurationsdetail.

Hashing-Strategien: Entropie erhöhen, Reordering vermeiden

Der Hebel gegen Flow Imbalance ist in vielen Fällen Hash-Entropie: Je mehr unterscheidende Informationen in die Hash-Berechnung einfließen, desto gleichmäßiger verteilt sich die Last. Gleichzeitig darf die Verteilung nicht pro Paket erfolgen, weil das Reordering und damit TCP-Performance-Probleme erzeugen kann. Ziel ist: stabile, per-Flow deterministische Verteilung mit möglichst hoher Streuung.

• 5-Tuple-Hashing: Standard, oft ausreichend, aber bei NAT/Proxy-Last manchmal zu wenig.
• Zusätzliche Felder: Wo möglich, zusätzliche Header-Informationen für mehr Entropie nutzen.
• Symmetrie: Hashing sollte in Hin- und Rückrichtung konsistent sein, wenn State/Asymmetrie kritisch ist.
• Reordering vermeiden: Per-Packet Load Balancing ist im Backbone meist kontraproduktiv.

Elephant Flows bleiben ein Problem – auch mit gutem Hash

Selbst perfekte Entropie kann nicht verhindern, dass ein einzelner sehr großer Flow einen Link dominieren kann, wenn er als Einheit gehasht wird. Deshalb braucht ECMP-Design zusätzliche Mechanismen, wenn Elephant Flows regelmäßig auftreten: Splitting, Traffic Engineering oder Kapazitätsplanung.

Ungleiche Linkkapazitäten: ECMP ist dann nicht „fair“

In vielen Netzen sind ECMP-Pfade nicht gleich kapazitiv: 100G und 400G Links, unterschiedliche optische Systeme oder unterschiedliche Overhead-Effekte (Encapsulation). Wenn Router Traffic gleichmäßig auf alle Next-Hops verteilen, kann ein kleiner Link überlasten, obwohl die Summe der Kapazität ausreichen würde. Für Provider ist das ein häufiger Grund für Flow Imbalance und Drops.

• Kapazitätsklassen trennen: Pfade gleicher Kapazität in ECMP-Gruppen halten, gemischte Gruppen vermeiden.
• Cost-Modelle anpassen: Metriken so setzen, dass ungleiche Links nicht gleichwertig werden.
• Link-Bundling: LAG/Bundle kann helfen, Kapazität pro Pfad zu erhöhen und Hashing zu verbessern.
• Störfallanalyse: Im Failover kann die Kapazitätsasymmetrie drastisch werden.

Ein einfaches Ziel: ECMP-Pfade sollten ähnlich „stark“ sein

Wenn das nicht möglich ist, sollte das Design bewusst steuern, welche Traffic-Klassen welche Pfade nutzen dürfen. Andernfalls entstehen sporadische Drops, die schwer zu erklären sind.

Elephant Flow Management: Wenn ein Flow größer ist als ein Pfad

In Provider-Backbones gibt es Traffic, der nicht gut in das klassische ECMP-Modell passt: einzelne sehr große Transfers oder wenige sehr große Streams. Wenn diese Elephant Flows regelmäßig auftreten, reicht klassisches ECMP nicht aus, um Hotspots zu vermeiden. Dann wird ECMP zum Baustein, aber nicht zur alleinigen Lösung.

• Traffic Engineering: SR-TE oder MPLS-TE nutzen, um große Flows gezielt auf bestimmte Pfade zu legen.
• Serviceklassen: Bulk-Traffic in eigene Klassen/Queues lenken und über „Kapazitätspfade“ führen.
• Lastprofilierung: Identifizieren, welche Anwendungen Elephant Flows erzeugen, und diese gezielt steuern.
• Kapazitätsstrategie: Headroom so planen, dass einzelne Flows nicht sofort Drops erzeugen.

ECMP und TE gehören zusammen

In großen Netzen ist ECMP der Default für allgemeine Lastverteilung. Traffic Engineering ist die Ergänzung für die 10–20 % der Flows, die den Großteil der Probleme verursachen. Ein gutes Design nutzt beides: ECMP für Breite, TE für Ausreißer.

Failover, Churn und Hash-Remapping: Was bei Störungen wirklich passiert

Wenn ein Link ausfällt oder gewartet wird, ändert sich das ECMP-Set. Viele Router remappen dann Flows auf neue Next-Hops. Das kann kurzfristig zu Reordering, Burst-Drops oder plötzlich verschobenen Hotspots führen. Deshalb ist es wichtig, ECMP nicht nur im Normalbetrieb zu betrachten, sondern als dynamisches System, das in Störfällen neue Gleichgewichte erzeugt.

• ECMP-Set-Änderung: Weniger Pfade bedeutet größere Last pro verbleibendem Pfad.
• Remapping: Viele Flows bekommen einen neuen Next-Hop, was kurzfristig zu Lastspitzen führt.
• FRR/TI-LFA Interaktion: Schutzpfade können das ECMP-Set temporär verändern.
• Maintenance-Drain: Kontrolliertes Entfernen eines Pfads ist oft stabiler als „hartes Link-Down“.

Störfallkapazität ist Pflicht, sonst ist ECMP nur „online Degradation“

Ein Netz kann erreichbar bleiben und dennoch massiv degradieren. Ein professionelles ECMP-Design plant N-1-Headroom und testet Failover unter Last, damit Umschaltungen nicht zu Kundenimpact führen.

Telemetry und Troubleshooting: Flow Imbalance sichtbar machen

Flow Imbalance ist ohne Telemetry schwer zu beweisen. Durchschnittswerte (z. B. 5-Minuten-Auslastung) verschleiern Microbursts und kurzfristige Überlast. Provider brauchen daher eine Observability-Strategie, die sowohl Link- als auch Flowverteilung sichtbar macht: Auslastung pro Member-Link, Queue-Drops, Burst-Indikatoren und – wo möglich – Hinweise auf Hash-Distribution.

• Member-Link-Sicht: Bei LAG/Bundle Auslastung und Drops pro Mitglied, nicht nur aggregiert.
• Queue/Drops: Drops pro Klasse, Queue-Tiefe, Microburst-Indikatoren.
• Pfadtransparenz: Welche ECMP-Pfade sind aktiv, wie hat sich das Set geändert?
• Hotspot-Korrelation: Linkauslastung mit Events (Failover, Maintenance, Policy-Änderungen) verknüpfen.

Evidence-by-Design: ECMP muss erklärbar werden

Wenn Sie Load Sharing als Produktmerkmal betrachten, brauchen Sie Nachweise: welche Links tragen wie viel Last, wie verhalten sich Störfälle, wie hoch ist die Reordering-/Loss-Spitze bei Failover. Diese Daten reduzieren Diskussionen, beschleunigen Entstörung und unterstützen SLA-Nachweise.

Praktische Designprinzipien: Load Sharing ohne Flow Imbalance

• Topologie für Symmetrie bauen: Wo möglich, gleich lange und gleich kapazitive Pfade schaffen (Spine-Leaf, partielles Mesh).
• Metrikmodell standardisieren: Linkkosten konsistent halten, ungleiche Kapazitäten nicht als gleichwertig behandeln.
• Entropie erhöhen: Hashing so gestalten, dass genug unterscheidende Informationen genutzt werden, ohne Reordering zu erzeugen.
• Elephant Flows gezielt behandeln: TE-Policies oder Serviceklassen für Bulk-Traffic einführen.
• Störfallreserve planen: N-1 Headroom, Failoverpfade unter Last testen, Upgrade-Trigger definieren.
• Maintenance drainen: Pfade kontrolliert aus dem ECMP-Set nehmen, statt abrupt abzuschalten.
• Telemetry verpflichtend: Member-Link-Auslastung, Drops, Microbursts, Pfadwechsel sichtbar machen.
• Varianten begrenzen: Wenige, wiederholbare Blueprints senken OPEX und vermeiden Sonderfälle.

Ein einfaches Denkmodell für Imbalance

$\mathrm{Imbalance}\approx \frac{\mathrm{Elephant\_Flow\_Anteil}}{\mathrm{Hash\_Entropie}}$

Je größer der Anteil großer Flows und je geringer die Hash-Entropie, desto wahrscheinlicher sind Hotspots. Das Modell ist bewusst vereinfacht, hilft aber bei der Priorisierung: Erst Entropie und Symmetrie prüfen, dann Elephant-Flows und TE-/QoS-Strategien ergänzen.