Zusammenfassung
- RFC 3612 warnt ausdrücklich, dass Zustandserhaltung falschen Zustand fortschreiben kann; im Extremfall war gerade dieser Zustand Ursache des Ausfalls.
- Fähigkeiten, ACKs und Ablaufmarker belegen einzelne Kontrollschritte. Erst die Zuordnung von Sitzung, Labelraum, FEC, Frist und unabhängiger Paketbeobachtung trägt eine Kontinuitätsaussage.
Erfolg nach der falschen Kennzahl
Nach einem Steuerungsneustart steht die MPLS-Tabelle noch da. Kein Eintrag ging verloren, alle Bits überlebten. Genau darin kann der Fehler liegen: Ein falscher Next Hop, eine überholte FEC-Zuordnung oder ein bereits anderweitig vergebenes Label wurde ebenso zuverlässig bewahrt wie ein richtiger Eintrag.
RFC 3612 wurde im September 2003 als informatorisches IETF-Dokument veröffentlicht. Es vergleicht Graceful Restart aus RFC 3478 und Fault Tolerance aus RFC 3479. Es ist kein Einsatzbericht und garantiert kein Ergebnis. Das damals referenzierte LDP-Dokument RFC 3036 wurde später durch RFC 5036 abgelöst.
Im Grundverhalten führte der Verlust der TCP-Sitzung zum Abbau zugehöriger LSPs und zur Freigabe von Labels. Die Erweiterungen lassen ausgewählten Zustand über das Ende der Sitzung hinaus leben. Damit entsteht Zeit für Wiederabgleich, aber auch eine vorläufige Autorität ohne aktive Ursprungssitzung.
Steuerung und Weiterleitung sind getrennte Zeugen
RFC 3612 trennt Session Failure und Node Failure. Beim ersten bleiben beide LSR aktiv; nur ihre LDP-Sitzung fällt aus. Das bedeutet selbst bei In-Band-Steuerung nicht automatisch, dass der Datenkanal ausfällt. Beim zweiten startet der Knoten oder seine LDP-Komponente neu, während Weiterleitungshardware Zustand behalten kann oder nicht.
Eine Capability sagt daher nur, welches Verfahren verstanden wird. Sie beweist nicht, was im konkreten Ausfall erhalten blieb. Für unbeeinträchtigten Verkehr müssen beide Sitzungsenden mindestens Weiterleitungszustand bewahren. Hält nur eine Seite ihn, kann RFC 3478 die spätere Rekonstruktion erleichtern, nicht aber die Unterbrechungsfreiheit bezeugen.
Schutzpfade und Fast Reroute liegen außerhalb des Anwendungsbereichs. Neustart, Schutzumschaltung und Paketlieferung brauchen getrennte Nachweise.
Der Timer begrenzt Ungewissheit
RFC 3478 übermittelt FT Reconnect Timeout und Recovery Time. Der erste Wert bittet den Nachbarn, bestehenden Zustand nach Kommunikationsverlust zu halten; der zweite benennt die Restzeit des geretteten Zustands am neu startenden Knoten. Null bedeutet: nicht erhalten oder nicht mehr verfügbar.
Gerettete Einträge werden stale. Neue Mappings bestätigen sie, andernfalls werden sie nach Fristablauf entfernt. Eine lange Frist schafft Raum für große Tabellen und verlängert den Fehler. Eine kurze Frist begrenzt Altzustand und kann die Synchronisierung abschneiden. LSP-Zahl, Steuerungsdurchsatz, Rechenleistung und Änderungsrate bestimmen die reale Dauer.
RFC 5919 fügte End-of-LIB hinzu. Die Meldung kann fehlen; ein lokaler Timer darf ihren Effekt ersetzen. Sie schließt eine Anzeigenphase, nicht Hardwareinstallation, globale Konvergenz oder Paketzustellung ab.
Ein ACK kann vor der Verarbeitung kommen
RFC 3479 versieht geschützte Operationen mit Sequenzen, ACKs und Checkpoints und kann vor geplanter Wartung Änderungen anhalten. Beide Peers müssen teilnehmen; rekonstruierter Steuerungszustand ist gegen den Weiterleitungszustand zu prüfen.
Ein ACK darf gesendet werden, sobald eine Nachricht ausfallsicher aufgezeichnet ist, noch bevor sie vollständig verarbeitet wurde. Gespeicherte Anfrage ist keine erzeugte Zuordnung; verarbeitete Zuordnung ist keine installierte Hardwareaktion; Installation ist keine beobachtete Lieferung. Ein Dashboardfeld „angewendet“ würde diese Kette verfälschen.
Häufige ACKs verkleinern den ungesicherten Rest und erhöhen den Betriebsaufwand. Seltene Checkpoints vereinfachen und vergrößern die Wiederaufbau-Lücke. Ein sauberer Checkpoint korrigiert keinen bereits falschen Inhalt.
Zwei Bedeutungen für dasselbe Label
Während der Resynchronisierung kann ein Upstream ein altes Label für eine FEC weiterverwenden, während der Downstream dieselbe Nummer einer anderen FEC zuteilt. Beide lokalen Tabellen können plausibel sein; zusammen leiten sie falsch weiter.
Statische Konfiguration, eine zweite LDP-Instanz oder ein anderes Verteilprotokoll können denselben Raum beanspruchen. Gemeinsame Vergabeautorität oder segmentierte Räume müssen verhindern, dass ein zur Wiederherstellung gehaltenes Label neu vergeben wird.
Die Sicherheitsfolge ist ausdrücklich: Nutzung über die autorisierende Sitzung hinaus kann Daten fehlleiten. RFC 3479 nennt bei vorzeitiger Wiedervergabe auch unberechtigte Dienste oder Dienstverweigerung als denkbare Folgen. Das sind Protokollrisiken, keine Behauptung eines realen Angriffs.
Ein prüfbarer Wiederanlaufbeleg
Der Beleg nennt Peer, Sitzungsepoche, Fehlerart, Capabilities und Fristen. Für jeden Eintrag hält er Vergabestelle, Labelraum, FEC, Next Hop, stale-Status und Ausgang fest: bestätigt, ersetzt, zurückgezogen oder abgelaufen.
Er trennt empfangen, dauerhaft gespeichert, verarbeitet, installiert und beobachtet. Checkpoint, Wiederholungen, echtes oder zeitlich angenommenes End-of-LIB und Vergabekonflikte bleiben sichtbar.
Erst danach folgen bidirektionale Probes, Zähler beider Enden und Stichproben relevanter FECs. Fehlt diese Ebene, lautet das Ergebnis unbeobachtet. Eine perfekte Sicherung ist nur dann Erfolg, wenn sie anschließend den richtigen Zustand und die richtige Paketwirkung belegen kann.
Quellen
- https://www.rfc-editor.org/rfc/rfc3612.html
- https://www.rfc-editor.org/rfc/rfc3612.txt
- https://www.rfc-editor.org/errata_search.php?rec_status=0&rfc=3612
- https://www.rfc-editor.org/info/rfc3612/
- https://datatracker.ietf.org/doc/rfc3612/
- https://www.rfc-editor.org/rfc/rfc3478.html
- https://www.rfc-editor.org/rfc/rfc3479.html
- https://www.rfc-editor.org/rfc/rfc3036.html
- https://www.rfc-editor.org/rfc/rfc5036.html
- https://www.rfc-editor.org/rfc/rfc3212.html
- https://www.rfc-editor.org/rfc/rfc3469.html
- https://www.rfc-editor.org/rfc/rfc3623.html
- https://www.rfc-editor.org/rfc/rfc4724.html
- https://www.rfc-editor.org/rfc/rfc5561.html
- https://www.rfc-editor.org/rfc/rfc5919.html
- https://www.rfc-editor.org/rfc/rfc7552.html
- https://www.iana.org/assignments/ldp-namespaces/ldp-namespaces.xhtml
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
