Site icon bintorosoft.com

ECMP im Backbone: Warum nur einige Kunden betroffen sind

Red Snapper

Data center with server racks in a corridor room. 3D render of digital data and cloud technology

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.

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:

Vereinfachte Hash-Zuordnung (MathML)

path = hash ( srcIP,dstIP,srcPort,dstPort,proto ) mod N

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.

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.

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.

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.

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.

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:

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

„Nur einige Flows“ als einfache Wahrscheinlichkeitsintuition (MathML)

P(flow_on_bad_path) = 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

Schritt: Pfadkandidaten identifizieren

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

Schritt: Beweis über gezielte Probes

Schritt: Mitigation auswählen

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

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.

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

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

Best Practice 3: Konsistentes Hashing und dokumentierte Hash-Inputs

Best Practice 4: MTU-Standards und PMTUD nicht sabotieren

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

Outbound-Ressourcen

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