Zusammenfassung

  • BGP PIC lässt viele Präfixe hierarchische Next-Hop-Objekte gemeinsam nutzen. Bei einem abgedeckten Fehler ersetzt die Änderung weniger Pathlists oder Zeiger eine FIB-Neuprogrammierung pro Präfix.
  • Schnelles Umschalten setzt voraus, dass eine brauchbare Alternative vor dem Vorfall gelernt, ausgewählt und installiert wurde. Eine zweite Route oder ein anderer BGP Next Hop beweist weder physische Trennung noch Kapazität oder tatsächlichen Hardwarezustand.
  • Führung muss die gesamte Vorabvollmacht beherrschen: Kandidatensichtbarkeit, Eignung, gemeinsames Schicksal, Detektor, Hardwarehierarchie, beobachtete Pakete und Rückkehr zum stabilen Zustand.

Um 02:14 Uhr verliert ein Ingress-PE seinen bevorzugten Ausgang. BGP verarbeitet noch VPN-Routen, die Route Reflectors haben den neuen Zustand noch nicht vollständig verteilt. Trotzdem verlässt der Verkehr für Hunderttausende Präfixe bereits einen anderen PE.

Die übliche Frage lautet, wie das Netz so schnell konvergierte. Die wichtigere lautet, wer diesen Weg ausgewählt hat. Möglicherweise geschah die Auswahl nicht während des Ausfalls, sondern Stunden zuvor.

Der Router hatte eine Alternative empfangen, nach Policy zugelassen, ihren Next Hop aufgelöst und sie mit gemeinsamen Forwarding-Objekten verbunden. Als ein Detektor die primäre Abhängigkeit für unbrauchbar erklärte, änderte die Forwarding Plane wenige Zeiger. Sie schrieb nicht jedes Ziel neu.

Das ist die genaue Reichweite von BGP Prefix Independent Convergence. Der Name verspricht nicht, dass jede Konvergenz von der Netzgröße unabhängig wird. Er beschreibt eine lokale Phase: Nach Erkennung eines abgedeckten Fehlers kann die Aktivierung eines vorbereiteten Ersatzes unabhängig von der Zahl betroffener BGP-Präfixe erfolgen.

Zum Veröffentlichungszeitpunkt ist draft-ietf-rtgwg-bgp-pic-23 die zentrale IETF-Beschreibung. Es handelt sich um einen aktiven Internet-Draft mit beabsichtigtem Status Informational, also um laufende Arbeit, nicht um einen RFC und nicht um ein neues Protokoll zwischen Routern. Beschrieben wird eine interne Architektur aus hierarchischer FIB, rekursiver Auflösung und vorberechneten Backups.

In einer flachen FIB kann jedes Prefix Leaf eine Kopie sämtlicher Weiterleitungsdaten enthalten. Wenn 500.000 Routen über denselben Egress aufgelöst werden, kann dessen Änderung 500.000 Updates auslösen. In einer Hierarchie zeigen diese Blätter auf eine gemeinsame BGP Pathlist, danach auf ein aufgelöstes IGP-Objekt und schließlich auf Adjacency, Interface oder Label Stack.

Eine Änderung des gemeinsamen Astes gilt für alle abhängigen Blätter. Das ist der Unterschied zwischen dem Neuadressieren einer halben Million Sendungen und dem Umstellen einer einzigen Weiche auf ihrem gemeinsamen Förderband. Die zweite Operation ist nicht kostenlos, wird aber nicht pro Sendung wiederholt.

„Prefix independent“ ist somit eine Skalierungsaussage mit Grenzen. Fehlererkennung kostet Zeit. Ein Reflector kann die Alternative verbergen. Die Control Plane muss weiterhin zurückziehen, auswählen und ankündigen. Entfernte Router konvergieren separat. Der Rückweg kann ausfallen, das Backup überlastet sein. PIC entfernt die Präfixzahl aus einer lokalen Phase, nicht aus dem ganzen Ereignis.

Geschwindigkeit wird durch Vorberechnung erkauft. Solange der Primärweg gesund ist, benötigt der schützende Router eine nach Policy gültige, erreichbare, für die betreffende Fehlerklasse hinreichend andere und in Hardware installierte Alternative. Die Notfallentscheidung ist teilweise eine historische Entscheidung.

Damit ändert sich die Prüfung. Nach einem normalen Fehler lassen sich UPDATE, Attribute und FIB-Eintrag beobachten. Bei PIC muss eine ruhende Absicht geprüft werden. Der Ersatz kann wochenlang unbenutzt bleiben und beim Start von einer alten Topologie-, Policy- und Ressourcenentscheidung abhängen.

Zuerst ist die Kandidatenzufuhr zu belegen. Der Draft nennt ADD-PATH, Best External, Diverse-Path-Verteilung und verschiedene Route Distinguisher in VPNs. Das sind mögliche Zufuhrwege, keine gleichwertigen Garantien.

Route Reflection kann eine Alternative entfernen, bevor sie den PE erreicht. Auch eine ADD-PATH-Capability genügt nicht: Richtung, AFI/SAFI, Sendepolicy, Zahl der Pfade, Importpolicy und tatsächliche Adj-RIB-In entscheiden. Der Kandidat muss am Umschaltpunkt nachgewiesen werden.

Danach folgt die Eignung. Die aktuelle Nokia-SR-Linux-Dokumentation verlangt für Edge PIC einen gültigen, erreichbaren Kandidaten mit einem anderen BGP Next Hop als der Primärweg und wählt den besten nach dem normalen BGP-Entscheidungsverfahren. Das ist eine klare Produktregel, aber kein Unabhängigkeitszertifikat.

Zwei Next Hops können über dieselbe Faser, Line Card, denselben Tunnel, Stromraum oder Provider auflösen. Zwei PEs können denselben Service Node benötigen. Logische Verschiedenheit verhindert kein gemeinsames physisches Schicksal.

Diversität muss für die geschützte Failure Class definiert werden. Ein zweites Interface schützt vielleicht vor einem Portfehler, nicht vor dem Ausfall der ganzen Karte. Ein weiterer Pfad über denselben PE schützt nicht vor dessen Verlust. Zwei Sessions zum selben Provider belegen keine kommerzielle oder geografische Trennung.

Core PIC und Edge PIC ordnen die Reparaturebene. Core PIC ändert den inneren Weg zu einem weiterhin erreichbaren BGP Next Hop; IGP oder Transport bewegen sich darunter. Edge PIC aktiviert bei Verlust des Egress einen anderen vorberechneten BGP Next Hop und kann VPN Label, Tunnel oder Service Path mitwechseln.

Produkte verwenden Begriffe und Umfang nicht einheitlich. Address Family, Service, Software, ASIC und Line Card sind einzeln zu prüfen. Der Draft betont selbst, dass der Nutzen vom Design der Forwarding Plane abhängt, nicht von einer Änderung des BGP-Protokolls.

Der Detektor besitzt den Aktivierungsschlüssel. Physischer Zustand, Interface, IGP-Adjazenz, BGP-Session und BFD sehen unterschiedliche Fehler. RFC 5880 berechnet die BFD Detection Time je Richtung aus ausgehandelten Intervallen und Multiplikator. Beide Richtungen können voneinander abweichen.

Eine Anzeige „BFD 50 ms“ kann diese Asymmetrie verdecken. Aggressive Timer schaffen zusätzliches Risiko. Überlastung, Control-Plane-Starvation, Filter oder Angriffe können gültige BFD-Pakete verschwinden lassen. Ein falsches Down oder Up kann Denial of Service verursachen. Schnelligkeit gibt wenigen fehlenden Beobachtungen die Macht über einen großen Verkehrssatz.

Das Signal muss die tatsächliche Abhängigkeit abdecken. Local Carrier erkennt den direkten Faserriss schnell, nicht aber ein entferntes Black Hole. Single-Hop BFD prüft eine Adjazenz, nicht den gesamten Service. Der Weg einer Multi-Hop-Probe muss mit dem geschützten Datenverkehr verglichen werden.

Auch IGP-Summarisation kann einen Fehler verbergen. RFC 9929 definiert Unreachable Prefix Announcement, weil ein von einem Summary abgedecktes Präfix unerreichbar werden kann, ohne dass das Summary verschwindet; BGP PIC wird als Fast-Convergence-Anwendung genannt. Das macht UPA nicht überall verpflichtend. Es zeigt, dass ein Entscheidungspunkt keine unsichtbare Abhängigkeit reparieren kann.

Die Hardwarehierarchie bildet eine weitere Grenze. Der Draft setzt mehrere Indirection-Ebenen voraus. Begrenzte Plattformen können die Kette bei der Programmierung abflachen, Zustand duplizieren und das Sharing verringern. Das kostet FIB-Speicher und kann pro-Präfix-Arbeit in bestimmte Fehlerfälle zurückbringen.

Zwei Router mit derselben RIB können deshalb verschieden reagieren. Einer ändert eine gemeinsame Pathlist, der andere viele flache Einträge. Zusagen müssen pro Plattform, Karte, Release, Route Family und Encapsulation gemessen werden.

In L3VPNs kann das Backup ein anderes VPN Label sowie einen anderen LDP- oder Segment-Routing-Stack benötigen. Ein korrekter Next-Hop-Wechsel mit altem Label führt besonders schnell in die falsche Richtung. Die Prüfung muss bis zur tatsächlichen Adjacency und Kapselung reichen.

Vorberechneter Zustand altert. Importänderung, Withdrawal, neue Auflösung, Labelwechsel, teilweise Erreichbarkeit oder Hardwaredruck können ihn untauglich machen. Gefährlich ist nicht nur das fehlende Backup, sondern das veraltete, weiterhin als bereit markierte.

Zu protokollieren sind Empfangszeit, letzte Eignungsberechnung, FIB-Programmierung und begründende Policy-/Topologie-Epoche. Relevante Änderungen müssen die Standby-Kette neu validieren. Präsenz in der RIB ist kein Frischenachweis.

Kapazität gehört zur Vollmacht. Ein Pfad kann schleifenfrei und erreichbar, aber zu klein sein. Teilen viele Primärwege denselben Standby, konzentriert ein Fehler enorme Last. Bei Mehrfachfehlern können einzeln geeignete Backups kollidieren. Transit- oder Peeringverträge können technisch gültige Wege ebenfalls untersagen.

RFC 5714 trennt lokale Reparatur und verteilte Konvergenz. Fast Reroute trägt Pakete, während Routingprotokolle den Fehler verbreiten und den Endzustand bilden. Die Reparatur ist eine Brücke, nicht zwingend das Ziel.

Sechs Uhren sind getrennt zu messen: Erkennung, Ereignisübermittlung, FIB-Aktivierung, erstes erfolgreiches Paket, Control-Plane-Konvergenz und endgültige stabile FIB. Eine einzige „Konvergenzzeit“ verwischt Zuständigkeiten und belegt keine Zustellung.

Data-Plane-Probes sollen Interface, Next Hop und Label Stack vor, während und nach dem Wechsel erfassen. Der Rückweg braucht einen eigenen Test: Stateful Firewalls, NAT und Service Chains können Sessions verlieren, obwohl der Hinweg korrekt umschaltet.

Die Testmatrix muss lokalen Link, entfernten Transport, Egress-PE, BGP-Session, verzögertes oder falsches BFD, vorheriges Backup-Withdrawal, Policyänderung, FIB-Druck, Line-Card-Neustart und Rückkehr des Primärwegs enthalten. Für jedes Szenario sind Detektor, Objekt, Ersatzweg, Verlustbudget und Endzustand vorzugeben.

Ein False Positive lenkt sofort eine riesige Präfixmenge auf einen unbrauchbaren Weg. Ein False Negative lässt scheinbaren Schutz bestehen, obwohl Hardwareeintrag oder Trigger fehlen. Gemeinsamer Zustand ist Effizienzquelle und Fehlermultiplikator zugleich.

Auswahl und Zertifizierung sollten deshalb getrennt sein. Routing definiert Eignung, Transport belegt physische Trennung, Platform Engineering zeigt die echte FIB, der Service prüft Kapazität und beide Richtungen, ein unabhängiger Reviewer genehmigt die Ausweitung.

Das erste Betriebsartefakt ist eine Protection Matrix je Failure Class, Route Family, Plattform und Service mit Primärabhängigkeit, Kandidatenquelle, Backup, Diversitätsbeleg, Detektor, Timer, Hardwareobjekt, Kapazität und Owner.

Das zweite ist ein Dormant-State-Ledger, das RIB-Backup und Hardware-Backup unterscheidet. Das dritte ist eine Zeitspur, die Detektorereignis, Pathlist-Änderung und beobachtete Pakete einschließlich Übergang zum konvergierten Zustand verbindet.

Auch die Rückkehr zum Primärweg braucht Kontrolle. Sofortiges Zurückschalten kann Reordering, Oszillation oder einen zweiten Verlust erzeugen. Hold-down, Prüfzeit oder genehmigter Revert können sicherer sein. Rollback heißt nicht PIC abschalten, sondern einen belegten stabilen Zustand wiederherstellen.

Heng Lus Minimum Initial Specification passt dazu: Den gemeinsamen Mechanismus eng halten und Route Families, Plattformen, Failure Classes und Timer lokal wählen. Running-Code Primacy ordnet die Belege: Konfiguration, RIB und FIB sind Behauptungen; das Paket zeigt das Ergebnis.

Praktische Datensouveränität verlangt, die vorberechnete Entscheidung in proprietärer Hardware abfragen, testen, verfallen lassen und widerrufen zu können. Ein Config-Repository ohne Sicht auf den ruhenden Ersatz bietet nur symbolische Kontrolle.

BGP PIC verlagert Arbeit aus dem Notfall. Regierbar wird es nur, wenn auch der Beleg vorverlagert wird. Herkunft, Diversität, Trigger, Hardwarezustand, Kapazität und Ablaufdatum des Backups müssen vor dem Alarm bekannt sein.

Quellen