ECMP im Backbone: Warum nur einige Kunden betroffen sind

ECMP im Backbone (Equal-Cost Multipath) ist ein zentraler Baustein moderner ISP-Architekturen: Mehrere gleichwertige Pfade werden gleichzeitig genutzt, um Kapazität zu bündeln, Ausfallsicherheit zu erhöhen und Traffic gleichmäßiger zu verteilen. Operativ führt ECMP jedoch zu einem typischen, frustrierenden Fehlerbild: Bei einem Incident sind „nur einige Kunden betroffen“, während andere scheinbar problemlos weiterarbeiten. Genau das ist kein Zufall, sondern eine direkte Folge davon, wie ECMP Traffic auf Pfade verteilt, wie Hashing funktioniert, wie Links und LAGs (Link Aggregation) zusammenspielen und wie Partial Failures oder Congestion auf einzelnen Pfaden wirken. In der Praxis eskalieren solche Fälle häufig als schwer erklärbare Tickets: „Bei uns ist alles grün, aber Kunde A hat Packet Loss und Kunde B nicht.“ Wer ECMP im Backbone betreibt, muss deshalb verstehen, wie Flows auf Pfade gemappt werden, welche Failure Modes ECMP besonders verstärkt (Mikrobursts, MTU-Mismatches, einseitige Drops, fehlerhafte LAG-Member, asymmetrische Pfade) und welche Monitoring- und Debug-Methoden zuverlässig belegen, warum nur ein Teil der Nutzer Impact hat. Dieser Artikel erklärt ECMP im Backbone praxisnah: vom Hashing-Modell über typische Symptome bis zur Evidence-Pack-Checkliste, mit der NOC-Teams in Minuten die richtige Fault Domain finden.

ECMP-Grundprinzip: Warum mehrere Pfade gleichzeitig genutzt werden

In Link-State-Backbones (OSPF/IS-IS) berechnet SPF (Dijkstra) die kürzesten Pfade. Wenn mehrere Pfade exakt gleiche Kosten haben, können Router mehrere Next Hops in die FIB programmieren. Das nennt man ECMP. Der Vorteil ist offensichtlich: Statt einen Link zu überlasten, kann Traffic über mehrere Links oder mehrere Spine-Pfade laufen. In großen Netzen ist ECMP zudem ein Robustheitsmechanismus: Fällt ein Pfad aus, bleibt ein anderer sofort verfügbar, ohne dass zwingend ein kompletter Pfadwechsel für alle Flows nötig ist.

• Skalierung: Kapazität wird besser genutzt, besonders bei vielen unabhängigen Flows.
• Resilienz: Pfadausfälle können abgefangen werden, oft mit minimalem Impact.
• Operative Nebenwirkung: Nicht „der Traffic“ nutzt mehrere Pfade, sondern einzelne Flows werden auf Pfade aufgeteilt.

Für Hintergrund zu Multipath-Routing und den damit verbundenen Problemen sind RFC 2991 und RFC 2992 hilfreiche Referenzen.

Der Kern des „nur einige Kunden“-Problems: ECMP verteilt per Hash, nicht per Kunde

ECMP teilt Traffic nicht gleichmäßig pro Kunde, pro VLAN oder pro Standort auf, sondern in der Regel pro Flow. Ein „Flow“ wird typischerweise als 5-Tuple definiert: Quell-IP, Ziel-IP, Quell-Port, Ziel-Port und Protokoll. Aus diesen Feldern wird ein Hash berechnet, und dieser Hash entscheidet, welcher Next Hop genutzt wird. Dadurch entsteht das typische Phänomen:

• Ein Kunde kann betroffen sein, weil seine dominanten Flows zufällig auf einem defekten Pfad landen.
• Ein anderer Kunde bleibt unbetroffen, weil seine Flows auf andere Pfade gehasht werden.
• Innerhalb eines Kunden können einzelne Anwendungen betroffen sein (z. B. nur bestimmte TCP-Verbindungen), andere nicht.

Vereinfachte Hash-Zuordnung (MathML)

$\mathrm{path}=\mathrm{hash}(\mathrm{srcIP},\mathrm{dstIP},\mathrm{srcPort},\mathrm{dstPort},\mathrm{proto})modN$

Das ist eine stark vereinfachte Darstellung, aber sie erklärt die Praxis: Bei N gleichwertigen Pfaden landen Flows deterministisch auf einem Pfad. „Deterministisch“ heißt: Derselbe Flow bleibt auf demselben Pfad, solange sich die Hash-Eingaben und die ECMP-Gruppe nicht ändern.

Warum ECMP bewusst deterministisch ist

Deterministisches Hashing ist nicht nur ein Design-Detail, sondern eine Notwendigkeit. Würden Pakete eines Flows ständig unterschiedliche Pfade nehmen, entstünden Reordering und damit Performanceprobleme, besonders bei TCP. Deshalb versuchen Router, innerhalb eines Flows konsistent zu bleiben. Das erhöht Stabilität pro Flow, führt aber zu selektiven Auswirkungen bei Pfadproblemen.

Typische Failure Modes: Wenn ECMP selektiven Impact erzeugt

Viele Backbone-Störungen sind keine „harten“ Link-Downs. ECMP macht solche Partial Failures besonders sichtbar, weil nur ein Teil der Flows über den betroffenen Teilpfad läuft.

Failure Mode 1: Ein ECMP-Pfad ist congested, die anderen nicht

Congestion kann pfadspezifisch sein: ein bestimmter Interconnect, ein bestimmter Spine-Link oder ein einzelnes LAG-Mitglied hat hohe Queue Drops. Dann sind nur Flows betroffen, die auf genau diesen Pfad gemappt werden.

• Symptom: Packet Loss steigt für einige Flows/Kunden, während andere Flows sauber laufen.
• Hinweis: Loss korreliert mit Auslastung und Queue Drops, aber nur auf einem Teilpfad.
• Beweis: per-interface/per-queue Telemetrie zeigt Drops auf einem Next Hop oder einem Member.

Failure Mode 2: Ein LAG/Port-Channel hat ein defektes Member

Ein Klassiker: Der Port-Channel ist „up“, aber ein Mitgliedslink hat CRCs, FEC-Korrekturen oder intermittierende Errors. Je nach Hashing kann ein Teil der Flows auf genau dieses Member laufen und droppen, während andere Member sauber sind.

• Symptom: selektiver Loss, häufig in Bursts; Interface insgesamt wirkt ok.
• Hinweis: per-member Counters (Errors/Drops) zeigen Ausreißer nur auf einem Member.
• Beweis: Korrelation zwischen Member-Drops und betroffenen Flow-IDs.

Failure Mode 3: MTU- oder Fragmentation-Probleme nur auf einem Pfad

MTU ist häufig nicht überall identisch. Ein einzelner Pfad mit kleinerer MTU oder blockiertem PMTUD kann dazu führen, dass nur größere Pakete droppen – und nur für Flows, die über diesen Pfad laufen.

• Symptom: kleine Pakete funktionieren, große brechen; selektiv nach Flow und Pfad.
• Hinweis: TCP Retransmissions steigen bei bestimmten Verbindungen; ICMP „Packet Too Big“ fehlt oder kommt nicht an.
• Beweis: „large vs. small“-Probes zeigen pfadspezifische Failure; Drops erscheinen auf einem Next Hop.

Failure Mode 4: Asymmetrische Pfade (Hinweg anders als Rückweg)

ECMP kann Hin- und Rückweg unterschiedlich verteilen, insbesondere wenn Routing-Policies, unterschiedliche Cost-Modelle oder externe Peerings ins Spiel kommen. Dann kann ein Kunde „nur in eine Richtung“ Probleme sehen. Das ist besonders kritisch bei stateful Services (Firewall/NAT), aber auch bei simplen TCP-Flows, wenn ACK-Pakete über einen schlechten Pfad gehen.

• Symptom: Upload ok, Download schlecht (oder umgekehrt); Retransmissions ohne klare Single-Link-Congestion.
• Beweis: getrennte Messungen je Richtung, plus pfadspezifische Drops/Queueing.

Failure Mode 5: Hashing-Salz/Seed oder ECMP-Gruppe ändert sich (Rehashing)

Wenn sich die ECMP-Gruppe verändert (z. B. ein Pfad fällt weg oder kommt zurück), müssen Flows neu verteilt werden. Das nennt man Rehashing. Je nach Implementierung kann das zu kurzfristigen Traffic-Spikes, Mikrobursts und transienten Drops führen, weil viele Flows gleichzeitig den Pfad wechseln.

• Symptom: kurzer, heftiger Impact nach Link-Down/Up, dann Stabilisierung.
• Hinweis: Queue Drops steigen unmittelbar nach ECMP-Change; danach normalisiert es sich.
• Beweis: Timeline zeigt ECMP-Group-Change → Drops → Recovery.

Warum ausgerechnet „nur einige Kunden“ Tickets schreiben

In ISP-Realität melden sich nicht alle Betroffenen gleich schnell. ECMP verstärkt diese selektive Wahrnehmung aus drei Gründen:

• Traffic-Profil: Kunden mit wenigen großen Flows (Elephants) werden stärker getroffen, wenn genau diese Flows auf einem schlechten Pfad landen.
• Anwendungslogik: Echtzeitdienste (VoIP, Gaming) reagieren empfindlicher auf Loss/Jitter als Bulk-Transfer.
• Timing: Manche Kunden merken es nur zu Peak-Zeiten, wenn Congestion den schlechten Pfad erst sichtbar macht.

ECMP vs. Per-Packet Load Balancing: Warum letzteres selten sinnvoll ist

Manche fragen: „Warum verteilt ihr nicht einfach jedes Paket auf alle Pfade?“ Per-Packet-Load-Balancing reduziert zwar das „nur einige Flows“-Problem, erzeugt aber häufig Paket-Reordering. Das verschlechtert TCP-Performance und kann insbesondere bei langen RTTs und hohen Bandbreiten deutlich spürbar sein. In Backbones ist deshalb Flow-basiertes ECMP der Standard.

Monitoring, das ECMP-Probleme sichtbar macht

Das größte Problem bei ECMP-Incidents ist nicht die Ursache, sondern die Sichtbarkeit. Wenn Sie nur Gesamtwerte pro Bundle oder pro Router betrachten, übersehen Sie pfadspezifische Ausreißer. Monitoring muss daher ECMP- und LAG-Strukturen explizit abbilden.

Pflichtmetriken für ECMP im Backbone

• Per-Next-Hop / Per-Interface Drops: Discards, Queue Drops, Tail Drops, WRED/ECN (falls genutzt).
• Per-LAG-Member Telemetrie: Utilization, Errors, FEC/CRC, Drops je Member, nicht nur aggregiert.
• Microburst-Indikatoren: wenn möglich High-Resolution (sub-second) Counters, da Average-Werte oft „zu schön“ sind.
• Flow-Sicht: NetFlow/IPFIX (Top-Talker), um zu erkennen, welche Kunden/Services gerade den Hotspot erzeugen.
• End-to-End Probes: synthetische Probes aus mehreren PoPs, um selektive Pfadfehler zu erkennen.

„Nur einige Flows“ als einfache Wahrscheinlichkeitsintuition (MathML)

$P\left(\mathrm{flow\_on\_bad\_path}\right)=\frac{1}{N}$

Wenn es N gleichwertige Pfade gibt und genau ein Pfad ist „schlecht“, dann liegt ein einzelner Flow mit Wahrscheinlichkeit 1/N auf dem schlechten Pfad. Bei vielen Flows verteilt sich das statistisch, aber einzelne Kunden mit wenigen dominanten Flows können sehr stark betroffen sein – oder gar nicht.

Troubleshooting-Runbook: ECMP-Incident in Minuten einordnen

Ein praxistaugliches Runbook vermeidet, dass Teams in allgemeinen „Netz ist langsam“-Debatten landen. Ziel ist, schnell zu beweisen, ob der Impact pfadspezifisch ist und welcher Pfad betroffen ist.

Schritt: Scope und Signatur klären

• Ist es flow-spezifisch? nur bestimmte Ziele/Ports/Anwendungen?
• Ist es zeitabhängig? nur Peak-Zeiten (Congestion) oder konstant (Defekt/MTU)?
• Ist es richtungsabhängig? Upload vs. Download, v4 vs. v6?

Schritt: Pfadkandidaten identifizieren

• Welche ECMP-Gruppe trägt den Traffic? (nächstgelegener Core-Knoten, relevante Next Hops)
• Welche LAGs/Links sind involviert? insbesondere Member-Links und Spine-Uplinks.

Schritt: Per-Member/Per-Next-Hop Counter prüfen

• Queue Drops: gibt es einen klaren Ausreißer?
• Errors/FEC/CRC: gibt es einen „halb kaputten“ Link?
• Utilization: ist ein Pfad deutlich höher ausgelastet als andere (ungleiche Hash-Verteilung oder Hotspot)?

Schritt: Beweis über gezielte Probes

• Multi-Flow Probing: mehrere 5-Tuple-Varianten (z. B. unterschiedliche Source Ports), um verschiedene Hash-Buckets zu treffen.
• Large vs. Small: MTU-Indizien aufdecken (große Payloads brechen, kleine nicht).
• Bidirektional: beide Richtungen testen, um Asymmetrie zu erkennen.

Schritt: Mitigation auswählen

Die Mitigation hängt vom Failure Mode ab. Typische schnelle Maßnahmen im Backbone:

• Defektes Member isolieren: problematischen LAG-Member aus dem Bundle nehmen (kontrolliert), um selektiven Loss sofort zu eliminieren.
• Congestion entschärfen: Traffic Engineering, Kapazität zuschalten, Hotspot-Flow identifizieren, ggf. temporär umleiten.
• MTU/PMTUD fixen: einheitliche MTU erzwingen, ICMP „Packet Too Big“ zulassen, pfadspezifische MTU-Knicks entfernen.
• ECMP-Rehash kontrollieren: bei Restore/Recovery schrittweise arbeiten, um Bursts zu vermeiden (wenn möglich).

Warum „MTR zeigt Loss auf einem Hop“ bei ECMP oft verwirrt

Bei ECMP können klassische Tools wie Traceroute/MTR irritierende Ergebnisse liefern: Pfade variieren, ICMP wird gerate-limited, und einzelne Hops zeigen scheinbar Loss, obwohl der End-to-End-Traffic nicht im gleichen Maß betroffen ist. Zudem kann MTR unterschiedliche Flows erzeugen, die auf unterschiedliche ECMP-Pfade gehasht werden. Das ist als Hinweis nützlich, aber als Beweis unzuverlässig.

• Best Practice: MTR nur als Indiz, dann mit per-interface Drops und end-to-end Probes verifizieren.
• Best Practice: bei ECMP immer mehrere Probes/Flows betrachten, nicht einen einzelnen Traceroute.

Design-Best-Practices, damit ECMP seltener selektiven Impact erzeugt

Sie werden selektive Effekte nie komplett eliminieren, aber Sie können die Wahrscheinlichkeit und die Schwere deutlich senken.

Best Practice 1: Per-Member Observability als Standard

• Pflicht: Telemetrie und Alarme auf Member-Ebene (LAG) und Next-Hop-Ebene (ECMP).
• Ziel: Defekte werden als „ein Member dropt“ sichtbar, nicht als „Kunden melden Probleme“.

Best Practice 2: Headroom-Planung für N-1

• Pflicht: Links und Bundles so planen, dass ein Member-Ausfall nicht sofort Congestion erzeugt.
• Praxis: 95th-Percentile nicht als Dauergrenze verstehen; Failover-Headroom ist entscheidend.

Best Practice 3: Konsistentes Hashing und dokumentierte Hash-Inputs

• Pflicht: wissen, ob Hashing auf 2-Tuple, 5-Tuple oder inkl. L4-Ports basiert.
• Risiko: unterschiedliche Hash-Profile in der Fabric erzeugen ungleichmäßige Last und schwer erklärbare Hotspots.

Best Practice 4: MTU-Standards und PMTUD nicht sabotieren

• Pflicht: einheitliche MTU im Backbone, klare Regeln für Encapsulation/Overlays.
• Pflicht: ICMP-Fehlermeldungen für PMTUD korrekt erlauben, sonst entstehen „mysteriöse“ Drops.

Evidence Pack: Pflichtdaten, um „nur einige Kunden betroffen“ zu beweisen

• Zeitfenster (UTC): Start, Peak, Mitigation, Stabilitätsfenster.
• Betroffene Flows/Kundenbeispiele: 3–5 Flow-IDs (5-Tuple) und Symptome (Loss/Latency).
• ECMP-Gruppe: beteiligte Next Hops, Änderungen der Gruppe (Pfad raus/rein).
• Per-Next-Hop/Per-Interface Counter: Queue Drops, Discards, Errors, Utilization.
• Per-LAG-Member Counter: Errors/FEC/CRC, Drops, Utilization je Member.
• End-to-End Probes: multi-flow Probes (verschiedene Ports), bidirektional, large vs. small.
• Traffic Shift: NetFlow/IPFIX Top-Talker, um Hotspots oder Elephant-Flows zu identifizieren.

Outbound-Ressourcen

• RFC 2991 (Multipath Issues in Unicast and Multicast Next-Hop Selection)
• RFC 2992 (Analysis of an Equal-Cost Multi-Path Algorithm)
• RFC 2328 (OSPFv2: Link-State-Routing und ECMP-Kontext)
• RFC 1195 (Integrated IS-IS: Provider-IGP-Kontext)
• RFC 5880 (BFD: schnelle Failure Detection, relevant für ECMP-Failover)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.