Zusammenfassung
- RFC 5283 erlaubt ein Label für eine spezifische FEC, wenn die RIB einen umfassenden Präfix besitzt und der ankündigende LSR der Next Hop ist. Weitergegeben wird die ursprüngliche FEC, nicht das Aggregat der Suche.
- Der Zustand belegt eine lokale Zuordnung. Unterstützung über den ganzen Weg, aktuelles Leben des Egress-LER, Abschluss des Withdraw, LFIB-Programmierung, Pakettransport und Dienstwirkung bleiben getrennte Aussagen.
Die Hostroute verschwand, die FEC nicht
Klassisches LDP bevorzugt die exakte Übereinstimmung von Prefix FEC und IP-RIB. Für inter-area LSPs mussten Betreiber deshalb jede PE-Loopback in alle Areas leaken. MPLS funktionierte, doch LSDB, RIB und FIB verloren einen Teil der Skalierung, die die IGP-Hierarchie schaffen sollte.
RFC 5283 ändert die Suche. Eine /32-FEC darf eine /24 verwenden, die sie enthält, sofern der Label-Nachbar zugleich der gewählte Next Hop ist. Eine FEC, die breiter als der RIB-Eintrag ist, gilt nicht als Treffer.
Der LSR kündigt weiterhin die /32 an. Labelidentität und Routingbegründung besitzen unterschiedliche Auflösung. Wer sie in einen Reachability-Status zusammenfasst, überschätzt den Beleg.
Ein Aggregat zählt seine Mitglieder nicht
Eine /24 kann gültig bleiben, wenn ein einzelner /32-Egress ausfällt. Sie beschreibt die Richtung für die Menge, nicht die Verfügbarkeit jedes Mitglieds.
Longest Match liest lokale RIB und LDP-Nachbarschaft. Es prüft weder den fernen LER noch Hardwarezustand oder Kundendatenverkehr.
Die FEC wirkt präzise, während ihr Routingbeleg bewusst breiter ist. Anzeigen sollten deshalb FEC, überdeckenden Präfix, Generation, Next Hop und Beobachter gemeinsam darstellen. Der genaue Name darf die Aussage nicht vergrößern.
Rückwärtskompatibel kann trotzdem unvollständig sein
Das Verfahren ist optional, konfigurierbar, standardmäßig deaktiviert und kann pro Präfix aktiviert werden. Ein alter LSR bleibt sicher, verlängert aber eine FEC ohne exakte Route nicht.
In jeder aggregierenden Area müssen die relevanten LSR das Verfahren unterstützen. Am ersten nicht konformen Knoten endet der vom Egress gestartete LSP. Keine Nebenwirkung ist nicht dasselbe wie Ende-zu-Ende-Kontinuität.
Ein Label am Ingress beweist nur, dass die Kette ihn erreichte. Fähigkeiten gehören zu Knoten, Area, Präfix und tatsächlichem Pfad, einschließlich Ausweichpfaden.
Der Cutover braucht überlappende Beweise
Upgrades dürfen schrittweise erfolgen. Bis alle LSR einer Area nachweislich aktualisiert sind, soll der ABR die spezifischen Routen weiter ankündigen. Erst danach bleiben nur die Aggregate.
Vor dem Cutover haben alte Knoten einen Exact Match und neue zusätzlich Longest Match. Danach verliert jeder vergessene Knoten seine RIB-Grundlage. Zu frühes Aufräumen macht aus einem Inventarfehler einen LSP-Abbruch.
Der Cutover-Beleg nennt Area, Knoten, Versionen, Feature-Status, Aktivierung je Präfix, letzte Generation mit spezifischen Routen, erste reine Aggregatgeneration, FEC-Mappings, NHLFE/LFIB und Paketprüfung. Ein abgeschlossenes Ticket genügt nicht.
Ein RIB-Ereignis verändert viele FECs
Viele spezifische FECs können von einem Aggregat abhängen. Erscheint oder verschwindet es oder wechselt der Next Hop, muss jede enthaltene FEC neu bewertet werden.
Eine neue spezifischere Route kann nur einen Teil der FECs übernehmen. Ihre Namen bleiben, ihre NHLFEs ändern sich. Zähler für Label-Erstellung und -Löschung sehen diese Umbindung nicht.
Nachweise verbinden RIB-Generation, Präfix, abhängige FEC-Menge, Nachbar, empfangenes und lokales Label, NHLFE und Hardwarequittung. Nur so ist ein Pfadwechsel ohne Identitätswechsel sichtbar.
Weniger FIB ist nicht weniger LFIB
RFC 5283 reduziert Link-State- und IP-FIB-Einträge. Die Zahl der LFIB-Einträge für spezifische LSPs sinkt nicht. „Weniger Zustand“ ist ohne Tabellenname keine belastbare Aussage.
SPF, RIB, FIB, LIB und LFIB haben verschiedene Ressourcen und Aktualisierungszeiten. IP-Aggregation kann Labelspeicher und Fehler-Fan-out unverändert lassen.
Auch Konvergenz besteht aus Schritten: Berechnung, Neubewertung der FECs, LFIB-Programmierung, Paketwiederkehr. Kein Schritt bezeugt automatisch den nächsten.
Der Egress-Ausfall hat eine eigene Uhr
Link-, Transit- und ABR-Ausfälle behalten ihr übliches Verhalten. Ein Egress-LER-Ausfall ist besonders: Das IGP-Aggregat kann fortbestehen, obwohl dieses Mitglied weg ist.
LDP Ordered Control trägt Label Withdraw hopweise zurück. RFC 5283 erwartet eine IGP-ähnliche Zeit, weist aber auf Implementierungsabhängigkeit hin. Wie MP-BGP, L3VPN oder Anwendungen reagieren, bleibt außerhalb des Dokuments.
In diesem Fenster können Aggregat grün, Upstream-Label sichtbar und Egress dunkel sein. Das sind Beobachtungen verschiedener Objekte und Zeiten. Der breite Status darf den spezifischen Alarm nicht aufheben.
Kontrollspezifische Reachability, Ordered Withdraw und BFD am Rand ergänzen den Beleg. Sie sind keine Eigenschaft des Aggregats.
Der Dienst beginnt hinter dem Kontrollzustand
Nach vollständigem LSP bleiben LFIB, richtiges NHLFE, Paket, VPN-Kontext, Egress, Rückweg und Anwendung zu prüfen. Ein Label ist keine Kundenquittung.
Ein Probe-Ergebnis gilt für den nachgebildeten Fluss. Ein Infrastruktur-Ping beweist keine andere VRF, Serviceklasse oder Rückroute.
Der Beleg darf Zwischenstände nennen: Aggregat da, lokale FEC da, Remote-Fähigkeit unbekannt, Withdraw unterwegs, Hardware unbestätigt, kein Rückpaket. Jeder Zustand hat einen anderen Eigentümer.
Beide Granularitäten protokollieren
- FEC, Adressfamilie und Egress-LER
- RIB-Kandidaten und gewählter Longest Match
- Generation, Metrik, Next Hop und Label-Nachbar
- Fähigkeit und Aktivierung pro Knoten/Präfix
- empfangene, lokale und angekündigte Labels
- abhängige FECs je Aggregat
- NHLFE, LFIB und Hardwarebestätigung
- Areas und ABRs des Pfads
- Migrationsphase spezifisch zu aggregiert
- Ursprung und Fortschritt von Label Withdraw
- BFD oder kontrollspezifische Reachability
- Reaktion der übergeordneten Anwendung
- bidirektionaler Verkehr
- behauptetes Dienstergebnis
RFC 5283 koordiniert zwei Maßstäbe. Gute Betriebsführung hält sie unterscheidbar und lässt das Aggregat nicht für jedes einzelne Ziel sprechen.
Sources
- https://www.rfc-editor.org/rfc/rfc5283.html
- https://www.rfc-editor.org/rfc/rfc5283.txt
- https://www.rfc-editor.org/info/rfc5283/
- https://datatracker.ietf.org/doc/rfc5283/
- https://datatracker.ietf.org/doc/rfc5283/history/
- https://datatracker.ietf.org/doc/rfc5283/references/
- https://datatracker.ietf.org/doc/rfc5283/referencedby/
- https://www.rfc-editor.org/errata/rfc5283
- https://www.rfc-editor.org/rfc/rfc5036.html
- https://www.rfc-editor.org/rfc/rfc2966.html
- https://www.rfc-editor.org/rfc/rfc4364.html
- https://www.rfc-editor.org/rfc/rfc4760.html
- https://www.rfc-editor.org/rfc/rfc8277.html
- https://www.rfc-editor.org/rfc/rfc4761.html
- https://www.rfc-editor.org/rfc/rfc4762.html
- https://www.rfc-editor.org/rfc/rfc5151.html
- https://www.rfc-editor.org/rfc/rfc5880.html
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-the-agency-problem-at-the-core-of-internet-governance/
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
