Zusammenfassung

  • Multipath lässt mehrere qualifizierte Routen am lokalen Forwarding teilnehmen, garantiert aber weder doppelte Kapazität noch physische Vielfalt oder gleiche Byte-Mengen.
  • BGP entscheidet über Kandidaten, Rekursion und Hardware bauen die Gruppe, Hash und Flow-Population bestimmen die Nutzung.
  • Eine belastbare Prüfung verbindet Adj-RIB-In, RIB, FIB, Mitgliederzähler, Queues und Fehlerfälle. Ein Routing-Tabellenbild belegt nur eine Stufe.

Die Hälfte, die nie zugesagt wurde

Ein Mechanismusbeispiel, kein realer Vorfall: Zwei Routen zum selben Präfix erfüllen die Multipath-Kriterien eines Geräts und erscheinen als ECMP-Mitglieder. Im Änderungsplan steht „50/50“. Ein langlebiger großer Flow landet auf Mitglied A, füllt dessen Queue und lässt B vergleichsweise frei.

BGP-Sitzungen und Routen können dabei gesund sein. Auch die ECMP-Gruppe kann vertragsgemäß arbeiten. Falsch war die Folgerung, zwei Mitglieder müssten je die Hälfte der Bytes tragen. Ein Hash verteilt Flow-Kennungen; er normiert nicht die Größe der Flows.

RFC 4271 beschreibt die Bewertung geeigneter Routen, die Auswahl, die Aufnahme in die Loc-RIB und die Bestimmung des unmittelbaren Next Hops. Multipath-Implementierungen erweitern dieses lokale Ergebnis um weitere qualifizierte Pfade. Daraus entsteht kein domänenübergreifendes Versprechen, dass alle Peers dieselbe Menge ankündigen oder verwenden. RFC 4271, Abschnitt 9.1.2

Auch „gleich“ ist implementationsabhängig. Cisco dokumentiert bestimmte Vergleichsbedingungen und behält einen best path für die Ankündigung. FRRouting prüft Multipath nach früheren Auswahlkriterien und kann mit multipath-relax die exakte AS_PATH-Gleichheit lockern; Arista dokumentiert im zitierten EOS-Kontext ein anderes Standardverhalten für diese Lockerung. Das sind lokale Zulassungsregeln, keine Belege für gleiche Kapazität, Unabhängigkeit oder Risiken. Cisco-Dokumentation, FRRouting-Dokumentation, Arista-EOS-BGP-Dokumentation

Drei getrennte Entscheidungen

Zuerst kommt die Eignung: Welche Routen sind nutzbar, policy-konform und nach den Produktregeln hinreichend gleich? maximum-paths ist nur eine Obergrenze und beweist keine Programmierung im ASIC.

Danach wird die Gruppe gebaut. Jeder Next Hop muss rekursiv aufgelöst und in der FIB abgebildet werden. Zwei Adressen können durch denselben Tunnel, dieselbe Linecard oder dieselbe entfernte Leitung führen. Die Zahl der BGP-Pfade ist kein Nachweis getrennter Fehlerdomänen.

Zuletzt wählt der Hash für jeden Flow ein Mitglied. RFC 2991 begründet die Pfadstabilität innerhalb eines Flows und beschreibt Risiken bei Mitgliederänderungen. RFC 2992 analysiert hash-threshold ECMP. Eine gleichmäßige Verteilung des Hash-Raums kann Flows verteilen, nicht aber ihre Bytes angleichen. RFC 2991, RFC 2992

Darum brauchen drei Aussagen eigene Nachweise: Die Routen waren geeignet, die Mitglieder wurden programmiert und der Verkehr nutzte sie tatsächlich.

Entropie ist eine lokale Ressource

Das Gerät kann nur sichtbare und unterstützte Felder hashen. Bei IPv6 kann das Flow Label zusätzliche Entropie liefern, wenn Transportheader nicht verfügbar sind. RFC 6438 zeigt zugleich die Grenzen durch Tunnel, Fragmente und undurchsichtige Nutzlast. Viele innere Verbindungen mit demselben äußeren Tupel können wie ein einziger Flow wirken. RFC 6438

Die Aussage „Fünf-Tupel“ reicht daher nicht. Plattform, Adressfamilie, Kapselung, Felder, Seed und Granularität gehören ins Prüfprotokoll. Aristas Einstellungen zu Seeds, Polarisation und resilient ECMP zeigen eine implementationsspezifische Steuerfläche, keinen universellen Standard. Arista-Dokumentation

Ebenso wichtig ist der Verkehrsmix. RFC 7424 beschreibt die Viele-zu-eins-Abbildung von Flows auf Links und die Schieflage durch große Flows. Viele kurze Verbindungen können sich gut mitteln; ein Backup- oder Replikationsstrom kann ein Mitglied stundenlang dominieren. Pakete, Bytes, Queue, Drops und Latenz beantworten jeweils andere Fragen. RFC 7424

Bei ungleichen Linkkapazitäten kennt gewöhnliches ECMP das Verhältnis nicht automatisch. Gewichtetes ECMP oder adaptive Verfahren sind eigene Mechanismen mit eigenen Fehlerbildern.

Sichtbarkeit ist keine Nutzung

ADD-PATH erweitert die Sicht. RFC 7911 erlaubt mehrere Pfadankündigungen für ein Präfix ohne impliziten Ersatz, verpflichtet den Empfänger aber weder zur gemeinsamen Installation noch zu einer Verkehrsquote. Umgekehrt kann ein Router lokal Multipath nutzen und nur seinen best path ankündigen. RFC 7911

PIC bereitet schnelle Reparatur nach einem Ausfall vor; ein vorbereiteter Ersatz ist kein Beleg für gleichzeitigen Verkehr im Normalbetrieb. Junos dokumentiert BGP-Multipath-Auswahl und Forwarding-Load-Balancing als getrennte Schritte. Die historische Bezeichnung „per-packet“ meint dort häufig einen Flow-Hash und darf nicht als beliebiges Paket-Spraying gelesen werden. Junos-Dokumentation

Vom Kandidaten bis zum Paket

Vor der Änderung werden Präfixe, Familien, Peers, Obergrenze, Verantwortlicher und Rückfallbedingung festgelegt. Adj-RIB-In-Kandidaten und Gleichheitsprüfung werden gesichert; bei multipath-relax wird die genaue Lockerung benannt.

Danach folgen rekursive Auflösung, Fehlerdomänen und die tatsächlich programmierte ECMP-Gruppen-ID. Zeigt die RIB zwei Pfade und die FIB ein Mitglied, liegen Auflösung, Kapazität oder Programmierung vor dem Hash als Untersuchungsfeld.

Über ein repräsentatives Zeitfenster werden Pakete, Bytes, Drops und Queues je Mitglied erfasst, große Flows identifiziert und Tests mit vielen Schlüsseln von relevanten Eingängen gesendet. Ein Ping beweist nur seinen eigenen Pfad. Entfernung und Rückkehr eines Mitglieds gehören dazu; resilient hashing begrenzt Umsortierung, beseitigt sie aber nicht vollständig.

Auch ein Rollback endet erst, wenn Kandidatenmenge, RIB, FIB und Paketverhalten zurückgekehrt sind.