Zusammenfassung

  • ECMP bedeutet, dass mehrere nächste Hops dieselben Routingkosten haben; es besagt nicht, dass MTU, Latenz, Paketfolge oder Multicast-Funktion der Wege gleich sind.
  • RFC 2991 vergleicht Regeln, die einen Fluss auf einem Pfad halten und beim Ändern der nächsten Hops möglichst wenige bestehende Flüsse neu zuweisen.

Ein Traceroute zeigt den Weg seiner eigenen Sonden. Es verrät nicht zwingend, welche anderen nächsten Hops der Router gleichzeitig zur Wahl hatte oder wie er übrige Flüsse verteilt hat. Genau hier wird „gleich“ leicht zu viel zugeschrieben: ECMP bezeichnet gleiche Kosten in der Routingentscheidung, keine physische Gleichheit der Pfade.

Dave Thaler und Christian Hopps veröffentlichten RFC 2991 im November 2000 als Informational-Dokument über Multipath-Weiterleitung. OSPF und IS-IS erlaubten Equal-Cost Multipath ausdrücklich; manche Implementierungen nutzten es auch mit RIP und anderen Protokollen. Sobald für ein Ziel mehrere nächste Hops gültig waren, musste die Weiterleitung trotzdem für jedes Paket eine Auswahl treffen.

Pakete reihum über verschiedene Ausgänge zu schicken, verteilt zwar Verkehr, kann aber eine einzelne Verbindung über Wege mit unterschiedlicher MTU und Laufzeit führen. Damit ändert sich die scheinbare Path-MTU von Paket zu Paket. Kommt ein Paket später als nachfolgende Sequenznummern an, kann TCP Verlust vermuten und eine schnelle Wiederholung auslösen. Das kostet zusätzliche Bandbreite und Puffer. Ping und Traceroute können zudem verschiedene Zweige sehen und ein falsches Bild des Pfads liefern.

Multicast setzt eine engere Grenze: Die in der RFC besprochenen Protokolle errichteten einen einzelnen Baum zur Quelle, zum Kern oder zum Rendezvous-Punkt. Ein Baum brauchte einen einzigen nächsten Hop zurück zur Wurzel, um Schleifen und Duplikate zu vermeiden. Paketweises Wechseln war daher mehr als eine Frage der Lastverteilung.

RFC 2991 nennt die Granularität, für die ein Router gegebenenfalls Zustand hält, einen „Flow“. Das muss nicht dem Fünf-Tupel-Mikroflow aus RFC 2474 entsprechen. Eine Implementierung kann allein die Zieladresse verwenden oder Quelle, Ziel und Protokollnummer zusammenfassen. Nicht-Initialfragmente enthalten möglicherweise keine Transportfelder; Ports als Auswahlmerkmale können außerdem verhindern, dass Pfadinformationen wie die MTU für weitere Verbindungen derselben Endpunkte wiederverwendet werden. Der Begriff blieb implementationsabhängig, die Folgen der Definition aber nicht.

Bleiben alle Pakete eines Flows zusammen, verschwindet das laufende Hin- und Herspringen. Ändert sich die Menge der nächsten Hops, kommt jedoch die nächste Frage: Wie viele aktive Flows müssen auf einen anderen Pfad? ECMP macht mehr Routeneinträge direkt wirksam; bei einem Flattern der Routen kann damit auch die mögliche Zone für Verluste und Umordnungen wachsen. RFC 2991 verlangt deshalb beides: möglichst geringe Störung bei Änderungen und einen kleinen Rechenaufwand bei der Weiterleitung.

Modulo-N-Hashing ist schnell. Der Router hasht den Flow und teilt das Ergebnis durch die Zahl der nächsten Hops. Ändert sich N, wechseln laut RFC (N-1)/N der Flows den Weg. Beim Hash-Threshold-Verfahren wird der Wertebereich des Hashes in Bereiche aufgeteilt; verschieben sich die Grenzen, ändern sich Zuordnungen nahe diesen Schwellen. Trotzdem können beim Hinzufügen oder Entfernen eines Mitglieds ein Viertel bis die Hälfte der Flows wechseln. RFC 2992 analysiert diese Störung. Highest Random Weight (HRW) hasht jeden Flow mit jedem möglichen nächsten Hop und nimmt den höchsten Wert. Bei einer Änderung eines Mitglieds betrifft das ungefähr 1/N der Flows, kostet aber etwa N-mal so viel Rechenarbeit wie Modulo N.

Das sind Werte aus algorithmischen Modellen, keine Messungen produktiver Router. Gezählt werden Flows, nicht Bytes, Kunden oder Auswirkungen auf einen Dienst. Wenige lange Flows können viel mehr Verkehr tragen als Tausende kurze.

Ob der Router Flow-Zustand speichert, bestimmt, wann die Berechnung anfällt. Mit vorhandenem Zustand lässt sich der nächste Hop beim Anlegen des Eintrags wählen, statt ihn für jedes Paket neu zu berechnen. RFC 2991 empfiehlt HRW für zustandsbehaftetes Unicast und für Multicast, bei dem Quell-/Gruppenzustand geführt wird. Ohne Flow-Zustand muss ein Unicast-Forwarder bei jedem eingehenden Paket rechnen; wenn CPU wichtiger ist als Pfadstabilität, empfiehlt die RFC Hash-Threshold. Das ist eine bedingte Empfehlung, kein universeller Sieger.

Auch RFC 6438 aus dem Jahr 2011 beschreibt den Zielkonflikt: Verkehr verteilen, Paketreihenfolge innerhalb eines Flows bewahren und Links auslasten kann nicht immer zugleich gelingen. Das belegt die Dauerhaftigkeit der Abwägung, aber nicht, dass jeder Router die Verfahren aus RFC 2991 übernahm.

Die historische Pointe ist eine saubere Trennung der Ebenen. Routingkosten ordnen Kandidaten; ein lokaler Selektor weist Flows zu; die physischen Pfade bestimmen tatsächliche MTU und Laufzeit; TCP reagiert auf das Empfangene. Stabilität kostet Rechenarbeit oder kann eine ungleiche Verteilung länger bestehen lassen. Umverteilung setzt bestehende Flows Änderungen aus. Das Label „gleiche Kosten“ entscheidet nicht, welche dieser Kosten ein Netz tragen sollte.

Quellen