Zusammenfassung

  • RFC 3277 empfiehlt, nach jeder neuen IS-IS-Adjazenz sofort ein eigenes LSP mit Overload zu fluten, damit neue Nachbar-LSPs nicht den alten Routerzustand aus der vorigen Inkarnation für Transit reaktivieren.
  • RFC 8706 ergänzt mit dem SA-Bit eine ausdrückliche Sperre: Nachbarn unterdrücken die Adjazenz und verwenden sie nicht in SPF, bis der startende Router seine neue Generation ausreichend verbreitet hat.

RtrB fällt aus, und RtrA schickt Verkehr über RtrC zu einem externen Ziel hinter RtrD. RtrC besitzt eine vollständige FIB und die benötigten BGP-Routen. Nach dem Neustart von RtrB entstehen IS-IS-Adjazenzen schnell; der kostengünstigere Pfad über RtrB wird wieder attraktiv. BGP ist langsamer. RtrB kennt das externe Ziel noch nicht und verwirft die Pakete.

RFC 3277, im April 2002 als Informational RFC veröffentlicht, nutzt dagegen das vorhandene LSP Overload bit. Der Router bleibt für direkt angeschlossene Netze erreichbar, wird aber vorerst nicht als Transitknoten berechnet. Nach BGP-Synchronisierung oder einem anderen lokalen Trigger kann er Overload löschen.

Die Maßnahme klingt nach einem Zustandsbit. Der eigentliche Fehler liegt jedoch in der Reihenfolge, in der der Rest des Netzes den zurückkehrenden Knoten wieder zusammensetzt.

Die neue Kante macht den alten Knoten wirksam

Ein früheres LSP von RtrB kann nach seinem Verschwinden in den Link-State-Datenbanken verbleiben. Sobald RtrB mit RtrA und RtrD neue Adjazenzen bildet, erzeugen die Nachbarn neue LSPs, die diese Verbindungen bekannt machen. RtrB selbst synchronisiert vielleicht noch und hat sein neues Overload-LSP nicht gesendet.

SPF erhält damit neue Kanten und einen alten Knoteneintrag. Beide Objekte können protokollgemäß und von legitimen Urhebern stammen. Zusammen beschreiben sie trotzdem keinen kohärenten Zeitpunkt: Die Kanten gehören zur aktuellen Prozessinkarnation, die Selbstbeschreibung zur vorherigen, obwohl das Ergebnis bereits angewendet werden kann.

RFC 3277 empfiehlt deshalb, bei jeder Adjazenzbildung das eigene LSP sofort zu aktualisieren und noch vor der Datenbanksynchronisierung zu fluten. Overload soll im Domain View eintreffen, bevor die Nachbaranzeige das alte LSP wieder transitfähig macht.

Die Publikationsreihenfolge verteilt Autorität. Das Nachbar-LSP sagt, dass eine Kante existiert. Das aktuelle self-LSP begrenzt, welche Rolle der Knoten über diese Kante übernehmen darf. Kommt nur die erste Aussage rechtzeitig an, erbt die neue Verbindung Rechte aus einem alten Zustand.

Ein Audit muss Boot-Identität, self-LSP-Ursprung und Sequence, Reihenfolge der Adjazenzen, Flooding-Empfang, SPF-Datenbankgeneration und Route verbinden. Ein altes Objekt wird nicht aktuell, weil ein heutiger Prozess es liest.

Warum ein leeres LSP keine Lösung ist

Provider betreiben iBGP häufig über Loopback-Adressen. Ein leeres LSP würde auch die Erreichbarkeit der eigenen Loopback entfernen und damit den Wiederaufbau von BGP behindern.

Overload schafft einen Zwischenzustand: als Ziel erreichbar, als Transitkorridor noch nicht zugelassen. Das Bit bescheinigt weder die Ursache noch BGP-Vollständigkeit oder erhaltene FIB. Es erteilt eine schmale Anweisung an SPF.

Das Löschen des Bits ist ebenso schmal. Der Router darf wieder in Transitpfade aufgenommen werden; daraus folgt noch kein Hardware- oder Servicebeleg.

RFC 3137 behandelt für OSPF ein verwandtes Prinzip. Ein vorhandener BTW-Artikel besitzt bereits die MaxLinkMetric-These, die eigene Erreichbarkeit und den Sonderfall des einzigen Pfades. Dieser Text wiederholt das nicht. Sein Gegenstand ist die Generationstrennung in IS-IS und die spätere SA-Sperre gegen eine zu frühe Kantenanzeige.

Vom Wettlauf zur expliziten Unterdrückung

RFC 5306 standardisierte 2008 Restart Signaling für IS-IS. RFC 8706 ersetzte ihn 2020 und trennt restart mit erhaltener Forwarding Plane von start ohne erhaltenen Forwarding-Zustand.

Bei einem start können LSP-Kopien aus der vorherigen Inkarnation im Netz liegen. Weil der neue Prozess Sequence Numbers neu initialisiert, können die alten Kopien sogar neuer erscheinen als seine ersten Ausgaben. Die monotone Ordnung gilt nicht automatisch über Prozessleben hinweg.

Das SA-Bit im Restart TLV erlaubt dem startenden Router, seine Nachbarn zur Unterdrückung der Adjazenzanzeige aufzufordern. Bis ein IIH mit gelöschtem SA eintrifft, dürfen sie die Adjazenz nicht in ihren LSPs veröffentlichen. Sie dürfen sie auch nicht in die eigene SPF-Berechnung aufnehmen.

Damit verändert sich die Schutzstrategie. RFC 3277 lässt das neue Overload-LSP gegen die Nachbar-LSPs antreten. RFC 8706 kann die Kante zurückhalten, die den alten Knoten erst nutzbar machen würde. Die Generation erhält einen protokollsichtbaren Gate.

Auch das neuere Verfahren ist kein universeller Erfolgsnachweis. Ein gemischtes Netz kann nicht unterstützende Systeme enthalten. Timer, LAN-Verhalten und Konfiguration müssen geprüft werden. Die Veröffentlichung des RFC beweist weder Implementierung noch Aktivierung.

Geplanter restart setzt tatsächlich erhaltenes Forwarding voraus. Wer das Signal ohne FIB-Custody nutzt, hält eine Topologie aufrecht, die der Datenpfad nicht erfüllen kann. RFC 8706 untersagt diese Kombination; ein Control-Plane-Flag ersetzt keinen laufenden Datenpfad.

Trigger dürfen ihre Beweisgrenze nicht überschreiten

RFC 3277 überlässt das Setzen und Löschen von Overload dem Implementierer. Genannt werden N Sekunden nach dem Boot oder N BGP-Präfixe in der Loc-RIB.

Der Timer beweist Zeit. Er erkennt keinen fehlenden Peer, keine fehlende Address Family, keine fehlerhafte Policy und keinen ungelösten Next Hop. Wachstum und Last können einen alten Wert entwerten.

Der Zähler beweist Kardinalität. Gleich große Mengen können andere Mitglieder besitzen. Ein Default oder Infrastrukturpräfix kann fehlen, während andere Routen den Zielwert füllen. Loc-RIB bedeutet nicht FIB.

Eine belastbare lokale Freigabe kann erwartete Peers, AFI/SAFI, Pflichtpräfixe, Set-Digest, Next-Hop-Auflösung, RIB/FIB-Abgleich und einen kontrollierten Probe kombinieren. Das ist keine versteckte Vorgabe des RFC, sondern eine saubere Begrenzung dessen, was ein einzelner Trigger aussagen kann.

Overload braucht einen tragfähigen Umweg

Mit gesetztem Overload werden keine Transitpfade durch den Router berechnet. Ist er der einzige Zugang zu nachgelagerten Knoten, kann die Schutzmaßnahme den letzten Pfad entfernen. In einer redundanten Topologie verhindert sie Blackholing; ohne Redundanz kann sie Erreichbarkeit beseitigen.

Eine Alternative im Graphen beweist noch keine Kapazität, Failure Independence, richtige Policy oder aktuelle FIB. Die Annahme über RtrC im RFC muss in der realen Umgebung gemessen werden.

RFC 3277 warnt zudem vor möglichen Loops, falls Systeme Overload nicht korrekt umsetzen. Authentizität des LSP und Gleichheit der Interpretation sind verschiedene Nachweise.

Die Freigabepolitik muss deshalb sowohl RtrBs aktuelle Bereitschaft als auch die Belastbarkeit der restlichen Topologie während seiner Sperre erfassen.

Graceful Mechanismen haben getrennte Quittungen

BGP Graceful Restart kann Forwarding-Information während einer Control-Plane-Unterbrechung erhalten. IP Fast Reroute kann lokal einen Reparaturpfad wählen. Ordered FIB convergence kann Updates in einer sichereren Reihenfolge installieren.

Keine dieser Funktionen ordnet eine neue Adjazenz automatisch dem aktuellen self-LSP zu. Keine macht aus einer Anzahl eine Routenidentität. Keine verwandelt Overload-clear in einen Beleg für Hardwareinstallation oder Paketlieferung.

Restart TLV, Overload, BGP stale state, SPF-Ergebnis, RIB, FIB-Readback und Probe beantworten unterschiedliche Fragen. Zusammengenommen können sie eine Kette bilden; in einem grünen Status zusammengepresst verlieren sie Erklärungskraft.

Die offengelegten Heng-Lu-Texte verlangen eine schmale gemeinsame Semantik und lokal überprüfbare Autorität. Das passt hier: Das Protokoll standardisiert eine Transit-Sperre und eine Kantenunterdrückung. Es entscheidet nicht, welche BGP-Menge betrieblich vollständig ist oder ob der Dienst funktioniert.

Die belastbare Kette lautet: Inkarnation, Forwarding-Custody, Adjazenz, aktuelles self-LSP, Flooding, Overload-Auswertung, IS-IS-Synchronisierung, erforderliche BGP-Menge, Auflösung, FIB, begrenzte Transitfreigabe, Paketbeobachtung, Ergebnis und Rollback.

Unsicherheit

Der Artikel analysiert Protokolltexte, keinen benannten Ausfall, Anbieter oder heutigen Deployment-Anteil. RFC 3277 erwähnt historische Nutzung in großen IS-IS-Netzen, nennt aber keine Netze und keine Messwerte. Unterstützung für RFC 8706, Mischbetrieb, Trigger, Hardware und Umwegkapazität sind lokal zu verifizieren. Eine Verlustmenge oder Leistungsverbesserung wird nicht behauptet.

Quellen