Site icon bintorosoft.com

ECMP-Troubleshooting: Warum nur ein Teil des Traffics kaputt ist

Red Snapper

ECMP-Troubleshooting ist in modernen Netzwerken ein Pflichtprogramm, weil Equal-Cost Multi-Path (ECMP) heute in Rechenzentren, Campus-Core-Designs, WAN-Backbones und Spine-Leaf-Fabrics als Standard gilt. Das Prinzip ist simpel: Wenn mehrere gleichwertige Pfade zum Ziel existieren, verteilt ein Router oder Switch den Traffic über mehrere Next-Hops, um Bandbreite besser zu nutzen und Redundanz zu erhöhen. In der Praxis führt genau diese Verteilung aber zu einem typischen, schwer zu greifenden Fehlerbild: Nur ein Teil des Traffics ist kaputt. Einige Nutzer oder Applikationsflüsse funktionieren, andere brechen sporadisch ab, wirken langsam oder zeigen Paketverlust – obwohl „Routing stimmt“ und Links scheinbar stabil sind. Der Grund liegt fast immer in der Kombination aus Hashing-Mechanismus, Flow-Eigenschaften und einem oder mehreren fehlerhaften Teilpfaden. Wer ECMP-Troubleshooting strukturiert angeht, kann dieses „Teilausfall“-Phänomen schnell beweisen, den betroffenen Next-Hop identifizieren und die eigentliche Ursache (z. B. MTU-Mismatch, fehlerhafte Adjacency, defektes LAG-Mitglied, asymmetrisches Forwarding oder FIB-Programmierung) zielgerichtet beheben.

Was ist ECMP und warum verteilt es nicht „Paket für Paket“?

ECMP steht für Equal-Cost Multi-Path und bedeutet, dass ein Gerät mehrere Next-Hops mit identischer Metrik (z. B. gleicher OSPF Cost oder gleicher BGP-Pfadpräferenz) gleichzeitig in seine Forwarding-Tabelle aufnimmt. Damit ECMP praktikabel ist, erfolgt die Verteilung in der Regel flussbasiert und nicht pro Paket. Der Hintergrund ist Stabilität: Würde ein Flow (z. B. eine TCP-Verbindung) Paket für Paket über wechselnde Pfade laufen, würden unterschiedliche Latenzen und Reordering entstehen, was TCP massiv ausbremst. Daher nutzen Geräte Hash-Funktionen, die anhand bestimmter Header-Felder einen Flow eindeutig einem Pfad zuordnen.

Typische Hash-Schlüssel (Five-Tuple und Varianten)

Viele Implementierungen nutzen das sogenannte Five-Tuple, also Quell-IP, Ziel-IP, Quell-Port, Ziel-Port und Protokoll. Je nach Plattform und Konfiguration können weitere Felder einfließen, etwa VLAN, DSCP, IPv6 Flow Label, GRE-Key, VXLAN VNI oder innere Header bei Tunneln. Das Ziel bleibt gleich: Ein Flow bleibt stabil auf einem Pfad.

Warum „nur ein Teil des Traffics“ kaputt ist: Die häufigsten Ursachenklassen

Bei partiellen Störungen unter ECMP ist das Grundmuster fast immer: ECMP ist aktiv, mehrere Next-Hops sind in der FIB, aber mindestens ein Next-Hop ist fehlerhaft oder verhält sich anders als die übrigen. Daraus folgen selektive Drops, Timeouts oder Performanceprobleme.

Teilpfad ist physisch oder logisch degradiert

Adjacency-/Neighbor-Probleme (ARP/ND) nur auf einem Pfad

Ein ECMP-Next-Hop kann in der FIB stehen, aber die Layer-2-Auflösung (ARP bei IPv4, Neighbor Discovery bei IPv6) ist instabil oder falsch. Das Gerät versucht zu forwarden, scheitert jedoch an einer unzuverlässigen Adjacency. Da nur bestimmte Flows auf diesen Next-Hop gehen, wirkt das Problem zufällig.

Unterschiedliche Behandlung durch Stateful Komponenten

ECMP ist in erster Linie ein Routing-/Forwarding-Mechanismus. Wenn aber auf einem der Pfade eine stateful Firewall, ein Load Balancer oder NAT beteiligt ist, kann asymmetrisches Forwarding fatal sein: Hinweg und Rückweg eines Flows laufen über unterschiedliche Pfade, die Session wird nicht erkannt und Pakete werden verworfen. Das Ergebnis ist nicht immer ein Totalausfall, sondern selektive Störungen, abhängig vom Hash und von Session-Timeouts.

Hashing trifft zufällig besonders „ungünstig“

Manchmal ist kein Pfad „kaputt“, aber das Hashing ist schlecht verteilt, etwa weil viele Flows ähnliche Header haben. Dann kann ein Teil der Nutzer eine überlastete Teilstrecke erwischen, während andere über freie Pfade laufen. Das ist besonders sichtbar bei:

Beweisführung: Wie Sie ECMP als Ursache schnell bestätigen

Ein strukturiertes ECMP-Troubleshooting beginnt nicht mit „wildem“ Paketmitschnitt, sondern mit einer nachvollziehbaren Beweiskette: ECMP ist aktiv, mehrere Next-Hops werden genutzt, und genau ein Teilpfad erzeugt Drops oder unerwünschte Behandlung.

Schritt 1: Prüfen, ob ECMP für das Zielpräfix wirklich aktiv ist

Wichtig ist die FIB-Perspektive: Nur weil die Control Plane mehrere Kandidaten kennt, heißt das nicht, dass sie auch in Hardware/Software-FIB genutzt werden.

Schritt 2: Flow-Konsistenz testen statt „einfach pingen“

Ein normaler Ping nutzt oft sehr ähnliche Pakete (gleiches Protokoll, ähnliche Header) und kann dadurch immer wieder auf demselben ECMP-Pfad landen. Für eine Aussage über „nur ein Teil kaputt“ brauchen Sie Variabilität in den Hash-Feldern. Praktisch bedeutet das: Tests mit unterschiedlichen Quellports (TCP/UDP), unterschiedlichen Quell-IPs (wenn möglich) oder Tools, die gezielt verschiedene Flows erzeugen.

Schritt 3: Per-Next-Hop-Indikatoren korrelieren

Viele Plattformen zeigen pro ECMP-Next-Hop Zähler, etwa genutzte Bytes/Packets oder Drops. Wenn ein Next-Hop deutlich weniger Traffic trägt oder auffällige Drop-Zähler hat, ist das ein starker Hinweis. Falls keine per-Next-Hop-Zähler verfügbar sind, helfen indirekte Methoden: Interface-Error-Counter, Queue-Drops, ARP/ND-Instabilität und logische Events (Link Flaps, LACP, STP).

Die Rolle des Hashing: Warum die Verteilung „gefühlt zufällig“ ist

Die Hash-Funktion ist deterministisch, aber sie wirkt für Menschen zufällig, weil kleine Unterschiede im Header zu einem anderen Ergebnis führen. Damit Sie das Verhalten besser einordnen können, hilft ein vereinfachtes Modell: Ein Gerät berechnet aus den Header-Feldern einen Hash-Wert und ordnet diesen einem der N Next-Hops zu.

Vereinfachtes Hash-Modell mit MathML

Wenn H der Hashwert eines Flows und N die Anzahl der ECMP-Pfade ist, kann die Pfadzuordnung vereinfacht so modelliert werden:

p = ( H mod N )

Hier steht p für den ausgewählten Pfadindex. In der Realität sind Hashing-Algorithmen komplexer (z. B. CRC-basierte Hashes, Toeplitz-Hashing, zusätzliche Salt-Werte), aber das Prinzip bleibt: Manche Flows landen auf Pfad 0, andere auf Pfad 1 usw. Ist Pfad 1 degradiert, sind genau die Flows betroffen, die dort landen.

Warum ein einzelner Flow oft „immer“ kaputt ist

Wenn ein Nutzer berichtet, dass eine bestimmte Anwendung konstant fehlschlägt, während andere normal funktionieren, passt das gut zu ECMP: Eine einzelne TCP-Session bleibt auf einem Pfad. Ist dieser Pfad defekt, ist genau diese Session dauerhaft betroffen. Erst wenn sich die 5-Tuple-Werte ändern (z. B. neuer Quellport nach Reconnect), kann der Flow auf einen anderen Pfad fallen und plötzlich funktionieren.

Typische ECMP-Fehlerbilder und wie Sie sie unterscheiden

Partielle Ausfälle sehen ähnlich aus, haben aber unterschiedliche Ursachen. Ein gutes Troubleshooting unterscheidet die Muster anhand von Symptomen und Messpunkten.

Fehlerbild: Paketverlust nur bei großen Paketen

Fehlerbild: UDP/Realtime (VoIP/Video) stottert, TCP wirkt „zäh“

Fehlerbild: Nur manche Clients sind betroffen, andere nie

Fehlerbild: Verbindungen brechen nach einigen Sekunden/Minuten ab

Methodik: ECMP-Pfad als Übeltäter identifizieren

Das Ziel ist, den konkreten Next-Hop oder das konkrete Teilsegment zu finden, das die Störung verursacht. Dafür braucht es eine Kombination aus gezielter Variation der Flows und Beobachtung auf dem Forwarding-Gerät.

Flow-Variation gezielt einsetzen

Wichtig ist, jeden Test als eigenständigen Flow zu betrachten. Ein einzelner Ping ist oft nicht repräsentativ.

Per-Next-Hop Beobachtung und Ausschlussprinzip

Wenn Sie mehrere Next-Hops haben, können Sie schrittweise prüfen, ob ein bestimmter Pfad „auffällig“ ist. In vielen Umgebungen ist das Ausschlussprinzip am schnellsten:

Warum Traceroute oft nicht reicht

Klassische Traceroute-Ausgaben können bei ECMP irreführend sein, weil unterschiedliche Probes unterschiedliche Pfade nehmen, Zwischenknoten ICMP unterschiedlich rate-limiten oder Return-Traffic anders geroutet wird. Ein Traceroute kann Hinweise geben, ersetzt aber nicht die FIB-/ECMP-Gruppenprüfung und die per-Pfad-Counter.

ECMP und LAG: Wenn zwei Lastverteilungsmechanismen zusammenkommen

In vielen Netzen liegen ECMP (Layer 3) und Link Aggregation (Layer 2/2.5) übereinander: Ein Router verteilt Traffic über mehrere Next-Hops (ECMP) und jeder Next-Hop kann wiederum über ein LAG angebunden sein. Dann kann „nur ein Teil kaputt“ aus zwei Richtungen kommen: Ein defektes ECMP-Mitglied oder ein defektes LAG-Mitglied.

Fehlerbild: Ein LAG-Mitglied droppt, aber das Bundle bleibt up

Wenn ein Port-Channel zwar als „up“ gilt, aber ein Mitgliedslink Paketverlust erzeugt (z. B. physische Fehler, Duplex/Speed-Probleme, fehlerhafte Optik), kann genau der Teil des Traffics ausfallen, der auf dieses Mitglied gehasht wird. In der Praxis wirkt es dann wie ECMP-Problem, obwohl es „darunter“ im LAG liegt. Deshalb gehört zu gutem ECMP-Troubleshooting immer die Prüfung der darunterliegenden Bündel.

Besondere Stolpersteine: Tunnels, Overlays und „innere“ Flows

In modernen Fabrics (VXLAN/EVPN, GRE, IPsec, MPLS) wird häufig getunnelt. Dann stellt sich die Frage: Hasht das Gerät auf den äußeren oder inneren Header? Wenn nur auf den äußeren Header gehasht wird, können viele innere Sessions „zusammenkleben“ und auf einen einzigen Pfad fallen. Das kann Überlast erzeugen oder einen defekten Pfad besonders sichtbar machen.

Prüfpunkte in Overlay-Umgebungen

RIB/FIB als harte Evidenz: Was Sie dokumentieren sollten

Damit Sie ECMP-Probleme nicht nur „fixen“, sondern auch sauber belegen können (z. B. im Postmortem oder gegenüber anderen Teams), lohnt sich eine klare Dokumentation der technischen Kette:

Diese Beweiskette macht das „nur ein Teil des Traffics kaputt“-Phänomen nachvollziehbar und verhindert Diskussionen, ob es ein Applikationsproblem oder ein echtes Netzwerkproblem ist.

Prävention: Wie Sie ECMP-Teilausfälle künftig schneller erkennen

ECMP ist stabil, wenn die Teilpfade wirklich gleichwertig sind und Monitoring auch die Teilpfade sichtbar macht. Viele Umgebungen überwachen nur Link-Up/Down und BGP/OSPF-Status. Für ECMP reicht das nicht.

Monitoring-Ansätze, die sich bewährt haben

Weiterführende Informationsquellen

Für die grundlegende Einordnung des ECMP-Prinzips und seiner Motivation ist die Übersicht zu Equal-cost multi-path routing hilfreich. Für die Lastverteilung über mehrere Links und die zugrunde liegenden Konzepte rund um Multipath-Weiterleitung und Hashing bietet RFC-Editor einen guten Einstieg in relevante Standards und Protokollbeschreibungen. Wer das Thema Longest Prefix Match als Basis der Forwarding-Entscheidung vertiefen möchte, findet in der Erklärung zu Longest Prefix Match eine kompakte Grundlage, um ECMP-Entscheidungen in der FIB besser einordnen zu können.

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:

Lieferumfang:

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.

 

Exit mobile version