Hashing-Strategien sind im Carrier- und Telco-Netz einer der unterschätztesten Stellhebel für Performance, Stabilität und Betriebskosten. In fast jedem Backbone, Metro-Netz oder Telco-Data-Center werden mehrere physische Links parallel betrieben – sei es als ECMP (Equal-Cost Multi-Path) über mehrere Next-Hops oder als Link Aggregation (LAG, Port-Channel, Bundle) über mehrere Member-Links. Auf dem Papier erhöht das Kapazität und Resilienz linear. In der Praxis sieht man jedoch häufig das Gegenteil: ein Member-Link läuft heiß, andere bleiben leer, es gibt sporadische Drops, Jitter-Spitzen oder vermeintlich „zufällige“ Hotspots, obwohl die Gesamtlast moderat ist. Die Ursache liegt selten in der Topologie allein, sondern sehr oft im Hashing: Wie Router und Switches Flows einem Pfad oder einem LAG-Mitglied zuordnen, entscheidet über Load Sharing – und darüber, ob sich einzelne „Elephant Flows“ auf wenigen Links konzentrieren. Im Carrier-Netz kommen zusätzliche Faktoren hinzu: NAT, CGNAT, Proxies, DCI-Traffic, Tunnel-Encapsulation und Multi-Tenant-Overlays können die Entropie des Hashes stark reduzieren. Wer Hashing-Strategien systematisch plant, kann bestehende Infrastruktur messbar besser ausnutzen, Incident-Risiken senken und Wartungen planbarer machen. Dieser Artikel zeigt, wie Sie ECMP- und LAG-Hashing im Provider-Umfeld optimieren – von Grundlagen über typische Stolpersteine bis hin zu praxisnahen Design-Blueprints.
Hashing-Grundlagen: Warum Carrier-Netze nicht „pro Paket“ verteilen
Damit parallele Links sinnvoll genutzt werden, muss Verkehr verteilt werden. Die naive Idee wäre, jedes Paket reihum auf einen anderen Link zu schicken. Das erzeugt jedoch Reordering: Pakete desselben Flows kommen in unterschiedlicher Reihenfolge an, was insbesondere TCP-Verbindungen massiv bremst und Anwendungen instabil macht. Deshalb nutzen Carrier-Router in der Regel per-Flow Hashing. Dabei wird für jeden Flow ein Hashwert berechnet und daraus ein Pfad ausgewählt. Solange die Flow-Definition stabil ist, bleibt auch die Pfadwahl stabil – und Reordering wird minimiert.
- Per-Packet Verteilung: hohe Gleichverteilung, aber starkes Reordering-Risiko.
- Per-Flow Verteilung: stabile Reihenfolge, aber anfällig für ungleiche Flowgrößen.
- Flow-Key: Menge an Header-Feldern, die in den Hash eingehen (z. B. 5-Tuple).
- Bucket/Member-Zuordnung: Mapping von Hashwerten auf ECMP-Next-Hops oder LAG-Member.
Der entscheidende Satz für die Praxis
Hashing verteilt nicht „Traffic“, sondern Flow-Identitäten. Wenn wenige Flows sehr groß sind, kann die Verteilung trotz sauberem Hash ungleich wirken.
ECMP vs. LAG: Zwei Mechanismen, ähnliche Hashing-Probleme
ECMP und Link Aggregation verfolgen unterschiedliche Ziele, wirken im Alltag aber ähnlich: Beide stellen mehrere parallele Pfade bereit, über die ein Gerät Last verteilt. ECMP verteilt auf mehrere Next-Hops im Routing (L3), LAG verteilt auf mehrere physische Ports, die als ein logischer Link erscheinen (L2/L3). In beiden Fällen gilt: Hashing-Qualität entscheidet, ob Sie die Summe der Kapazität wirklich nutzen.
- ECMP: mehrere gleichwertige Routingpfade; häufig im Core, Metro, Spine-Leaf und bei SR/MPLS.
- LAG: mehrere physische Links als ein logischer; häufig für Uplinks, Core-to-Core, Router-to-Switch, DCI.
- Gemeinsamer Engpass: unzureichende Entropie oder ungünstiges Mapping führt zu Member-Hotspots.
- Betriebsfolgen: Drops und Microbursts auf einzelnen Links, obwohl Gesamtlink „frei“ wirkt.
Warum LAG „sicher“ wirkt, aber trotzdem hotspottet
Viele Teams schauen nur auf den logischen Bundle-Traffic. Wenn ein einzelnes Mitglied überläuft, sieht man den Schaden oft erst über Queue-Drops oder Fehlerzähler – nicht über die aggregierte Auslastung. Deshalb gehört Member-Level-Telemetry in jedes Carrier-Blueprint.
Entropie: Der Schlüsselbegriff für gute Hashing-Strategien
Entropie beschreibt vereinfacht, wie gut sich Flows anhand der gewählten Hash-Felder unterscheiden lassen. Je mehr unterschiedliche Werte in den Hash eingehen, desto gleichmäßiger kann sich die Zuordnung verteilen. In Carrier-Netzen sinkt die Entropie oft durch Aggregations- und Encapsulation-Effekte: Viele Endkunden teilen sich wenige Quelladressen (NAT), viele Sessions laufen über denselben Proxy, oder Tunnel-Header verstecken innere Header-Felder.
- Hohe Entropie: viele unabhängige Quell-/Zielkombinationen und Ports; Hash streut gut.
- Niedrige Entropie: viele Flows sehen im äußeren Header ähnlich aus; Hash kollidiert häufiger.
- Elephant Flows: einzelne sehr große Flows können einen Pfad dominieren, selbst bei guter Entropie.
- Asymmetrie: wenn Hin- und Rückweg unterschiedlich gehasht werden, entstehen stateful Risiken.
Eine einfache Intuition
Wenn 10.000 Sessions nur aus 100 „sichtbaren“ Hash-Keys bestehen, kann die Verteilung niemals wirklich gleichmäßig sein – egal wie viele Links Sie parallel schalten.
Flow-Key-Design: Welche Header-Felder sollten in den Hash?
Im Carrier-Umfeld ist die häufigste Stellschraube die Wahl des Flow-Keys. Der Klassiker ist das 5-Tuple (Quell-IP, Ziel-IP, Quell-Port, Ziel-Port, Protokoll). In vielen Szenarien reicht das aus. Problematisch wird es, wenn diese Felder für große Teile des Traffics gleich oder wenig variabel sind, etwa bei NAT/CGNAT, bei bestimmten Streaming-Setups oder bei DCI-Replikation mit wenigen großen Verbindungen.
- 5-Tuple als Default: guter Kompromiss aus Stabilität und Entropie für klassische Internet- und Enterprise-Flows.
- 2-/3-Tuple Risiken: Hash nur über IPs oder nur über Ziel-IP führt schnell zu Hotspots.
- Port-Entropie: Quellports erzeugen oft viel Streuung – aber nur, wenn sie nicht durch NAT/Proxy „vereinheitlicht“ werden.
- IPv6 Besonderheit: gleiche Prinzipien, aber mehr Adressraum; Entropie kann steigen, wenn Endsysteme echte IPv6-Adressen nutzen.
Carrier-Realität: Nicht jedes Netz darf „alles“ hashen
In manchen Umgebungen sind bestimmte Header-Felder nicht zuverlässig sichtbar (z. B. wegen Encapsulation) oder es existieren Anforderungen an Symmetrie (z. B. stateful Firewalls, NAT-State, Lawful Intercept-Ketten). Hashing-Strategien müssen daher nicht nur technisch, sondern auch produkt- und compliancekonform sein.
Elephant Flows: Wenn ein einziger Flow einen Link überlastet
Selbst perfekte Entropie schützt nicht vor dem Elephant-Flow-Problem: Ein einzelner sehr großer Flow wird als Einheit gehasht und kann einen Link saturieren. Das ist im Provider-Netz häufig, z. B. bei DCI-Backups, Content-Distribution, großen Cloud-Transfers oder bestimmten Mobilfunk-Userplane-Workloads. Das Ziel ist dann nicht „perfekte Gleichverteilung“, sondern „keine Hotspots, die Drops erzeugen“.
- Traffic Engineering ergänzen: Große Flows oder Klassen gezielt auf kapazitive Pfade legen (SR-TE/MPLS-TE).
- Serviceklassen nutzen: Bulk-Traffic in eigene QoS-Klassen und ggf. eigene Pfadprofile führen.
- Kapazitätsreserve planen: Headroom so dimensionieren, dass einzelne Flows nicht sofort Drops auslösen.
- Flows identifizieren: Ohne Sichtbarkeit bleiben Elephant-Flows „mystische“ Hotspots.
Praktischer Leitgedanke
ECMP/LAG ist das Grundrauschen der Lastverteilung. Elephant-Flow-Handling ist die Spezialdisziplin für die wenigen Flows, die 80 % der Probleme verursachen.
Ungleiche Linkkapazitäten: Warum ECMP und LAG dann unfair werden
In modernisierten Netzen sind parallele Pfade oft nicht gleich stark: 100G neben 400G, unterschiedliche Optiken, unterschiedliche Overhead-Profile (Encapsulation), oder unterschiedliche Latenz/Queueing-Eigenschaften. Klassisches Hashing verteilt Flows häufig gleich auf alle Mitglieder, unabhängig von deren Kapazität. Ergebnis: kleinere Links überlaufen, obwohl die Summe der Kapazität ausreichen würde.
- Kapazitätsklassen trennen: Gleich starke Links in ein gemeinsames ECMP-Set oder Bundle; Mischsets vermeiden.
- Metrikmodell anpassen: IGP-Kosten so setzen, dass ungleiche Links nicht als gleichwertig erscheinen.
- Bundles bewusst bauen: LAG-Mitglieder sollten möglichst identisch sein (Speed, MTU, Buffering), sonst wird Betrieb komplex.
- Failover bedenken: Nach Ausfall eines großen Links kann das Set drastisch „kleiner“ werden.
Carrier-Blueprint-Regel
Wenn Links nicht gleichwertig sind, dürfen sie nicht gleich behandelt werden – weder im Metrikmodell noch im Hashing- und Capacity-Design.
Remapping und Churn: Was passiert bei Link-Ausfall oder Maintenance?
Wenn ein ECMP-Next-Hop oder ein LAG-Member wegfällt, ändert sich das Pfadset. Viele Implementierungen remappen dann Hash-Buckets auf die verbleibenden Pfade. Das kann kurzfristig zu Lastspitzen führen: Viele Flows springen gleichzeitig auf neue Links, Microbursts entstehen, Queue-Drops steigen. In Carrier-Netzen ist das besonders relevant, weil Wartung regelmäßig ist und Failover-Szenarien real passieren.
- ECMP-Set schrumpft: weniger Pfade, mehr Last pro Pfad, höheres Hotspot-Risiko.
- Mass Remap: viele Flows erhalten gleichzeitig neue Next-Hops; kurzfristige Spitzen möglich.
- Reordering-Effekte: Flow-Pfade ändern sich; manche Anwendungen reagieren empfindlich.
- Maintenance-Drain: kontrolliertes Herausnehmen eines Pfads ist oft stabiler als abruptes Link-Down.
Störfallreserve ist hier nicht optional
Wenn Sie im Normalbetrieb „auf Kante“ fahren, wird Remapping im Fehlerfall fast zwangsläufig Drops erzeugen. Hashing-Optimierung kann das mildern, aber nicht kompensieren.
Hashing bei Encapsulation: MPLS, SR, EVPN und Tunnels
Carrier-Netze kapseln Verkehr häufig: MPLS/SR-Labels, EVPN-Overlays, SRv6-Header, GRE/IPsec oder weitere Tunnel. Das beeinflusst Hashing, weil Geräte je nach Plattform entweder auf äußere oder innere Header-Felder hashen – oder beides. Wenn nur äußere Header-Felder verwendet werden, kann Entropie sinken. Wenn innere Felder einbezogen werden, steigt Entropie – aber nur, wenn diese Felder konsistent sichtbar sind.
- Outer-Hashing: stabil, aber bei wenigen äußeren Flows hohe Hotspot-Gefahr.
- Inner-Hashing: bessere Entropie, aber abhängig von Plattformfähigkeit und konsistenter Encapsulation.
- Label-Stack: kann Hashing beeinflussen, wenn Labels als Hash-Input genutzt werden oder nicht.
- MTU/Overhead: nicht direkt Hashing, aber eng gekoppelt: Drops auf einzelnen Pfaden wirken wie Imbalance.
Designregel: Hashing-Strategie ist Teil des Encapsulation-Blueprints
Wenn Sie EVPN, SR-MPLS oder SRv6 einführen, sollten Hashing- und Telemetry-Anforderungen explizit im Blueprint stehen: Welche Felder werden gehasht, welche Member-Metriken werden überwacht, welche Failover-Tests sind Pflicht?
Symmetrie und State: Wann Hashing „gleich“ sein muss
In vielen Backbones ist asymmetrisches Routing akzeptabel. Es gibt jedoch Fälle, in denen Symmetrie wichtig ist: stateful Firewalls, NAT-State, bestimmte Service-Chains, Lawful Intercept-Architekturen oder Monitoring-Ketten. Hashing-Optimierung darf hier nicht dazu führen, dass Hin- und Rückwege unkontrolliert auseinanderlaufen oder dass Flows bei Remapping stateful Systeme „verlassen“.
- Stateful Service Chains: Pfad muss stabil bleiben oder State muss repliziert sein.
- NAT/CGNAT: State kann bei Pfadwechseln kritisch sein; Placement und Hashing müssen zusammenpassen.
- Security/Inspection: Konsistente Pfade vereinfachen Audit und Incident-Response.
- Operational Guardrails: Änderungen am Hashing sind hochwirksam und müssen getestet/gerollt werden.
Praxis-Tipp für Carrier-Teams
Hashing nicht „global“ ändern, wenn nur ein Teil des Netzes stateful Einschränkungen hat. Besser: klare Rollenmodelle und Service-Zonen, die Anforderungen pro Bereich definieren.
Telemetry: Flow Imbalance erkennen, bevor Kunden es merken
Ohne Telemetry bleibt Hashing-Optimierung ein Ratespiel. Durchschnittliche Auslastung ist oft nutzlos, weil Microbursts und Member-Hotspots in kurzen Zeitfenstern auftreten. Carrier-Designs brauchen daher Messpunkte auf Member-Ebene und in den Queues.
- Member-Link-Stats: Auslastung, Drops, Errors pro LAG-Mitglied und pro ECMP-Interface.
- Queue-Telemetry: Queue-Tiefe, Drops pro Klasse, Burst-Indikatoren.
- Event-Korrelation: Link-Flaps, Maintenance, FRR/TI-LFA-Events mit Hotspots verknüpfen.
- Baseline vs. Störfall: Messen, wie sich Verteilung im Failover verändert.
Evidence-by-Design: Hashing als messbares Betriebsmerkmal
Wenn Sie Hashing-Strategien als Teil der Architektur behandeln, sollten Sie auch Belege erzeugen: „Vorher/Nachher“-Member-Auslastung, Drop-Reduktion, Failover-Verhalten. Das unterstützt SLA-Diskussionen und reduziert OPEX, weil Ursachen schneller gefunden werden.
Optimierungs-Blueprints: Bewährte Hashing-Strategien im Carrier-Netz
In der Praxis haben sich einige wiederholbare Muster bewährt. Wichtig ist, diese nicht als einmalige „Tuning-Aktion“, sondern als Blueprint pro Rolle zu definieren: Backbone-P, Metro-Edge, DC-Fabric, Service-Edge, DCI.
- Blueprint 1: Symmetrische Pfade schaffen – gleiche Linkklassen, konsistentes Metrikmodell, vermeiden gemischter ECMP-Sets.
- Blueprint 2: Entropie maximieren – Flow-Key so wählen, dass genügend Unterscheidung entsteht, ohne Reordering zu riskieren.
- Blueprint 3: Elephant-Flows separieren – TE-/QoS-Profile für Bulk-Traffic, nicht alles dem Hash überlassen.
- Blueprint 4: Maintenance kontrollieren – Drain-Prozesse, um Remapping-Spitzen zu minimieren.
- Blueprint 5: Observability verpflichtend – Member-, Queue- und Event-Telemetry als Standard.
Ein vereinfachtes Qualitätsmodell für Hashing
LoadSharing_Qualität=g(Entropie,Symmetrie,Headroom,Elephant_Anteil)
Die Funktion g steht für Ihr Netz: Hohe Entropie und Symmetrie verbessern die Verteilung, Headroom fängt Remapping-Spitzen ab, und ein hoher Elephant-Anteil verlangt zusätzliche TE-/QoS-Maßnahmen.
Typische Fallstricke und wie Sie sie vermeiden
- Nur auf Gesamtbundle schauen: Member-Hotspots bleiben unsichtbar – Lösung: Member-Telemetry verpflichtend.
- Gemischte Linkgeschwindigkeiten im gleichen ECMP-Set: kleine Links überlaufen – Lösung: Kapazitätsklassen trennen, Metriken anpassen.
- Zu wenig Hash-Entropie durch NAT/Proxies: Hash kollidiert – Lösung: Flow-Key prüfen, ggf. Service-Placement/Architektur anpassen.
- Elephant-Flows ignorieren: einzelne Flows saturieren Links – Lösung: TE/QoS für Bulk-Traffic.
- Failover nicht testen: Remapping erzeugt Drops – Lösung: Störfalltests unter Last, Drain-Playbooks.
- Hashing-Änderungen ohne Governance: großflächige Nebenwirkungen – Lösung: Policy-as-Code, Reviews, Wellen-Rollouts, Rollback.
Leitlinien für eine sichere Einführung von Hashing-Optimierungen
- Änderungen klein beginnen: Pilotregion oder definierte PoP-Klasse, Canary-Ansatz.
- Vorher/Nachher messen: Member-Verteilung, Drops, Latenz/Jitter, Failover-Effekte.
- Rollback bereit halten: Hashing-Änderungen sind hochwirksam; Rückweg muss klar sein.
- Dokumentieren und standardisieren: Sobald ein Pattern funktioniert, als Blueprint fixieren.