ECMP-Troubleshooting: Warum haben nur manche User Errors?

ECMP-Troubleshooting wird meist dann akut, wenn ein Incident „unfair“ wirkt: Nur manche User sehen Errors, nur bestimmte Sessions timeouten, oder Probleme treten scheinbar zufällig auf – obwohl Monitoring grün ist und ein einfacher Ping funktioniert. Genau dieses Muster ist typisch für Equal-Cost Multi-Path (ECMP): Traffic wird über mehrere gleichwertige Pfade verteilt, meist per Hashing über Flow-Merkmale (z. B. Quell-/Ziel-IP, Ports, Protokoll). Wenn nun nur ein Teil dieser Pfade fehlerhaft, überlastet oder falsch konfiguriert ist, betrifft das nicht alle Nutzer, sondern nur die Flows, die auf den „schlechten“ Pfad gehasht werden. Das Ergebnis sind selektive Ausfälle: Ein Nutzer lädt die Seite, ein anderer erhält 502/504; ein API-Client funktioniert, der nächste hat Retries; ein Standort ist betroffen, ein anderer nicht – selbst bei identischer Anwendung. Dieser Artikel zeigt Ihnen, wie Sie ECMP-Probleme systematisch erkennen und eingrenzen: Welche Symptome wirklich auf ECMP hindeuten, wie Hashing und Flow-Pinning die Beobachtung erklären, welche Ursachen in Produktion am häufigsten sind (Dead/Degraded Member, asymmetrisches Routing, MTU/PMTUD-Blackholes, Policy-Drift, Mikrobursts), und welche Checks Sie im NOC in Minuten durchführen können – inklusive klarer Dokumentationspunkte, damit Eskalationen an Backbone-, DC- oder Plattformteams ohne langes Hin und Her funktionieren.

Warum ECMP selektive Errors erzeugt

ECMP verteilt Traffic nicht „pro Paket“, sondern in der Regel pro Flow. Das ist wichtig, damit Pakete eines TCP-Flows nicht in unterschiedlicher Reihenfolge ankommen (Out-of-Order), was Performance massiv verschlechtert. Die Kehrseite: Jeder Flow bleibt an „seinem“ Pfad kleben (Flow-Pinning). Wenn also einer von vier Pfaden Probleme macht, betrifft das nicht 25% „aller User“, sondern 25% der Flows – und je nach Traffic-Mix sogar deutlich mehr oder weniger.

• Flow-basiertes Hashing: Ein bestimmtes 5-Tuple wird deterministisch einem Next Hop zugeordnet.
• „Bad Apple“-Pfad: Ein einzelner Link/Next Hop verursacht Drops, MTU-Probleme oder Timeouts.
• Selektive Betroffenheit: Nur die Flows, die auf diesen Pfad fallen, sehen Errors.
• Intermittierend: Neue Flows können auf andere Pfade hashen; derselbe User kann mal betroffen, mal nicht betroffen sein.

ECMP-Grundlagen für die Praxis: Was genau wird gehasht?

Welche Felder in den Hash eingehen, hängt von Plattform, ASIC, Betriebssystem und Konfiguration ab. Häufig wird ein 5-Tuple verwendet: Quell-IP, Ziel-IP, Quellport, Zielport, Protokoll. Manche Umgebungen ergänzen VLAN/VRF, DSCP oder – bei Overlays – Inner/Outer Header. Genau hier entstehen viele „nur manche User“-Effekte: Wenn etwa nur die äußeren Header gehasht werden, kann ein großer Kundentraffic auf wenige Pfade klumpen; wenn nur die inneren Header gehasht werden, kann ein einzelnes NAT-Gateway viele Flows auf denselben Hash-Wert bringen.

• L3 ECMP: Hash über IP-Header (und oft Ports, wenn L4 bekannt ist).
• L4-aware Hash: Hash berücksichtigt TCP/UDP-Ports, erhöht Entropie.
• Overlay-ECMP: Hashing kann Outer (Tunnel) oder Inner (Tenant) nutzen – entscheidend für Lastverteilung.
• Symmetric Hash: Hash-Logik, die Hin- und Rückrichtung konsistent behandelt, um Asymmetrien zu reduzieren.

Warum „gute Entropie“ wichtig ist (MathML)

$P(\mathrm{Flow}\to \mathrm{Pfad})=\frac{1}{N}$

In der Idealvorstellung wird jeder neue Flow mit gleicher Wahrscheinlichkeit auf einen von N Pfaden gelegt. In der Realität weichen Hashing, geringe Entropie (z. B. viele Flows mit gleichen 5-Tuple-Mustern) oder ungleiche Pfadkapazitäten davon ab. Diese Abweichungen erklären, warum manchmal „nur ein Kunde“ betroffen ist, obwohl eigentlich „nur ein Pfad“ schlecht ist.

Typische Symptome: Woran Sie ECMP als Ursache erkennen

ECMP-Probleme zeigen sich selten als „alles ist down“. Stattdessen sind es Muster, die zwischen NOC und Applikationsteams oft zu Missverständnissen führen. Der Schlüssel ist, auf Selektivität und Reproduzierbarkeit pro Flow zu achten.

• Nur bestimmte Clients betroffen: z. B. ein Standort, ein NAT-Pool, eine Mobilfunk-AS, während andere ok sind.
• Nur bestimmte Ziele/Ports betroffen: HTTP ok, HTTPS nicht, oder nur ein Backend-Subnetz ist fehlerhaft.
• Intermittierende Timeouts: Retries helfen, weil ein neuer Flow neu gehasht wird.
• Traceroute wirkt „inkonsistent“: unterschiedliche Hops pro Run (ECMP), aber nur manche Runs brechen ab.
• Fehler korrelieren mit Flow-Neuaufbau: nach TLS-Handshake, nach Connection-Reuse, nach Load-Balancer-Rehash.

Die häufigsten Root Causes bei ECMP: „Warum ist nur ein Pfad schlecht?“

ECMP selbst ist selten „kaputt“. Meist ist ein einzelnes Mitglied im ECMP-Set fehlerhaft oder uneinheitlich konfiguriert. Im Betrieb haben sich die folgenden Ursachen als besonders häufig erwiesen.

• Degraded Link: CRC/Interface-Errors, Optical Power drift, Mikrobursts → Drops nur auf diesem Link.
• Next Hop ist logisch up, aber faktisch kaputt: z. B. ARP/ND-Probleme, fehlerhafte Linecard, FIB programmiert, aber Forwarding gestört.
• Ungleiche MTU: nur ein Pfad hat geringere MTU (Tunnel, VLAN, Provider-Handover) → große Pakete blackholen.
• Asymmetrisches Routing: Hinweg ECMP über mehrere Pfade, Rückweg geht über anderen Pfad/Stateful Firewall → selektive Drops.
• Policy-Drift: ACL/QoS/CoPP auf einem Pfad anders ausgerollt → nur dort werden Ports oder Protokolle geblockt.
• Unequal Capacity: ECMP verteilt „gleich“, aber Pfade sind nicht gleich schnell/kapazitiv → ein Pfad überlastet zuerst.
• Overlay/Underlay-Mismatch: Outer-Hash führt zu Klumpen; ein Tunnel-Endpunkt ist instabil → nur bestimmte VXLAN/GRE-Flows betroffen.

NOC-Playbook: ECMP-Troubleshooting in 10 Minuten

Das Ziel ist eine schnelle, belastbare Hypothese: „Es gibt ein defektes ECMP-Mitglied“ oder „Hash/Entropie erzeugt Hotspot“. Dafür braucht es eine feste Reihenfolge. So vermeiden Sie, dass Sie sich in Anwendungssymptomen verlieren.

• 1) Betroffenheit klassifizieren: Welche Clients/Ziele sind betroffen? Gibt es Muster nach Standort, ASN, NAT-Pool, Backend-Subnetz?
• 2) ECMP-Pfad-Set identifizieren: Welche Next Hops sind für das Zielpräfix im FIB aktiv? Wie viele Pfade?
• 3) Pro-Next-Hop Health prüfen: Interface-Errors, Drops, Queue-Discards, Optik (DOM/DDM), Link-Flaps.
• 4) MTU/PMTUD prüfen: Unterschiede pro Pfad, besonders bei Tunneln/Overlays oder Provider-Edges.
• 5) Asymmetrie prüfen: Rückweg über gleiche Geräte/Firewalls? uRPF/Stateful Policies relevant?
• 6) Reproduzierbarkeit pro Flow testen: Gleicher Client + gleiche 5-Tuple → gleicher Fehler? Neuer Flow → anderer Pfad → evtl. ok?
• 7) Mitigation vorbereiten: „Bad Member“ aus ECMP nehmen, Gewichte anpassen, temporär Single-Path erzwingen.

Reproduzierbarkeit richtig testen: Warum „einfach nochmal probieren“ nicht reicht

Viele Teams testen mit „nochmal laden“. Das ist häufig ein schlechter Test, weil moderne Clients Connection Reuse, HTTP/2, QUIC, Keep-Alive und Load-Balancer-Retries nutzen. Sie sehen dann wechselnde Ergebnisse, ohne zu wissen, ob es am ECMP oder am Client-Verhalten liegt. Für ECMP ist entscheidend, kontrolliert zu variieren: einmal denselben Flow erzwingen, einmal bewusst einen neuen Flow erzeugen.

• Gleicher Flow: gleiche Quell-IP, gleiche Ziel-IP, gleicher Zielport, gleicher Quellport (so weit steuerbar) → sollte denselben Pfad nutzen.
• Neuer Flow: nur Quellport ändern (oder neue TCP-Verbindung) → Hash kann auf anderen Pfad fallen.
• Konstantes Ziel: DNS-Rotation ausschließen (sonst testen Sie verschiedene Backends statt Pfade).

Flow-Pinning als Erklärung für „nur manche User“

Wenn ein Nutzer hinter einem NAT sitzt, teilen sich viele Clients eine öffentliche Quell-IP. Je nach NAT-Verhalten können Quellports in Mustern vergeben werden. Das kann dazu führen, dass ein großer Teil der Nutzer „zufällig“ auf denselben Hash-Bucket fällt. Das erklärt, warum manchmal ganze Firmenstandorte betroffen sind, während andere Standorte (mit anderer NAT-Gateway-IP) keine Probleme sehen.

ECMP und MTU: Der klassische „nur große Antworten brechen“ Fall

Ein besonders tückisches Fehlerbild: Kleine Requests funktionieren, Ping ist stabil, aber Downloads, API-Responses oder TLS-Handshakes brechen bei bestimmten Nutzern ab. Wenn nur ein ECMP-Pfad eine niedrigere MTU hat oder PMTUD nicht korrekt funktioniert, dann betrifft das nur die Flows, die auf diesen Pfad fallen. Der Rest wirkt gesund, was die Diagnose verzögert.

• Indikator: Fehler treten eher bei großen Payloads auf (Uploads, große JSON-Antworten, Zertifikatsketten, gRPC/HTTP2 Frames).
• ECMP-Signatur: nur ein Teil der User betroffen, weil nur ein Pfad MTU-problematisch ist.
• Prüfpunkte: Tunnel-Overhead, VLAN/Provider-Handover-MTU, ICMP „Fragmentation Needed“ Filter.

Für Path MTU Discovery ist RFC 1191 eine passende Referenz.

Asymmetrisches Routing im ECMP-Kontext: Wenn Statefulness den Fehler erzeugt

ECMP erhöht die Chance auf Asymmetrien: Hinweg nimmt Pfad A, Rückweg Pfad B. In vielen Netzen ist das funktional, solange beide Richtungen geroutet werden. Problematisch wird es mit stateful Komponenten: Firewalls, NAT-Gateways, Load Balancer mit Connection Tracking oder uRPF-Checks. Dann kann ein legitimer Rückverkehr als „unerwartet“ verworfen werden – selektiv und flowabhängig.

• Symptom: TCP SYN geht raus, SYN-ACK kommt nicht zurück (oder wird gedroppt), Timeouts entstehen.
• Typische Ursache: Firewall-State existiert nur auf einem Cluster-Mitglied, Rückweg landet auf anderem.
• NOC-Check: Ist Session-Pinning am LB/Firewall korrekt? Gibt es ECMP über Stateful-Boundaries?

Hash-Entropie und Traffic-Klumpen: Wenn ECMP „gleich“ verteilt, aber nicht fair wirkt

Auch ohne defekten Pfad können nur manche User Fehler sehen, wenn ein Pfad überlastet ist. Überlastung entsteht nicht nur durch zu wenig Kapazität, sondern auch durch schlechte Entropie: Viele Flows ähneln sich (z. B. viele Clients zu derselben Ziel-IP/Port), sodass Hashing nicht gut verteilt. Dann klumpen Flows auf einem Pfad, der überläuft, während andere Pfade frei sind.

• Typische Trigger: wenige Hot Destinations (CDN, API-Gateway), NAT mit begrenzter Quell-IP-Entropie, Overlays mit Outer-Hash.
• Indikator: Interface-Auslastung und Queue-Drops sind auf einem ECMP-Link deutlich höher als auf den anderen.
• Mitigation: Hash-Algorithmus/Fields prüfen, L4-aware Hash aktivieren, Flowlet/Adaptive Load Balancing (falls verfügbar), Kapazitäten angleichen.

Mitigation in Produktion: So stabilisieren Sie ohne großen Umbau

Wenn ECMP die Ursache ist, ist die pragmatischste Maßnahme oft, den „schlechten“ Pfad aus dem Set zu nehmen oder die Lastverteilung kurzfristig zu ändern. Wichtig: Mitigation sollte reversibel sein und den Blast Radius kontrollieren. In einem NOC-Runbook sind daher abgestufte Maßnahmen sinnvoll.

• Bad Member entfernen: Next Hop/Interface temporär aus ECMP, wenn Health-Indikatoren eindeutig sind.
• Gewichtung anpassen: Wenn Pfade ungleiche Kapazität haben, Gewichte/UCMP nutzen (falls unterstützt).
• Temporär Single-Path: Für kritische Ziele ECMP reduzieren, um selektive Errors zu eliminieren (auf Kosten von Redundanz).
• Policy konsolidieren: ACL/QoS/CoPP auf allen Pfaden angleichen, um Drift zu beseitigen.
• MTU vereinheitlichen: Konsistente MTU entlang aller Mitglieder, inklusive Tunnel-Overhead und Handover.

Was in ein gutes Ticket gehört: Evidence, die ECMP-Probleme beweist

ECMP-Incidents eskalieren oft zäh, weil „es geht doch bei mir“ ein valides Gegenargument ist. Deshalb braucht das Ticket eine strukturierte Beweisführung: Sie müssen zeigen, dass eine definierte Menge an Flows auf einem Pfad fehlschlägt und auf anderen Pfaden funktioniert.

• Scope: betroffene Nutzergruppen (Standort, ASN, NAT-IP, Client-Typ) und betroffene Ziele (IP/Port/Service).
• ECMP-Set: Anzahl und Identität der Next Hops für das Zielpräfix (FIB-Sicht).
• Per-Next-Hop Health: Errors, Drops, Discards, Flap-Historie, Optikwerte pro Link.
• Reproduzierbarkeit: Beispiele „Flow A failt“, „Flow B succeedet“ mit klaren Unterschieden (z. B. Quellport/Quell-IP).
• Asymmetrie-Hinweise: Pfadhinweise, Stateful-Boundaries, uRPF/Firewall Logs, wenn verfügbar.
• Mitigation und Ergebnis: Was wurde geändert (Bad Member removed, ECMP reduziert) und wie hat sich die Fehlerrate verändert?

Outbound-Links für Protokoll- und Betriebskontext

• RFC 2992 (Analysis of an Equal-Cost Multi-Path Algorithm) für Hintergründe zu ECMP-Hashing und Verteilung.
• RFC 2991 (Multipath Issues in Unicast and Multicast Next-Hop Selection) für praktische Problemklassen bei Multipath.
• RFC 1191 (Path MTU Discovery) für MTU/PMTUD-Fehlerbilder, die ECMP selektiv sichtbar machen.
• RFC 9293 (TCP) für Retransmits, Timeouts und warum selektiver Paketverlust so „zufällig“ wirkt.

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.