Zusammenfassung

  • Der OSPFv2 Link-ID-Sub-TLV sollte in OSPFv3 nicht gesendet und muss beim Empfang ignoriert werden. Die Linkidentifikation verwendet den obligatorischen Neighbor ID aus Interface ID und Router ID.
  • Ein unbekannter Intra-Area-TE-LSA wird dank U-Bit weitergeflutet. Vollständige Verteilung ist daher kein Beleg für semantische Unterstützung oder TE-Nutzung.

Erhalten heißt nicht autorisiert

Ein Konverter übernimmt einen OSPFv2-Datensatz. Der Link ID ist wohlgeformt, die Zahl findet sich im Inventar, und die Benutzeroberfläche bietet sie als Gegenstelle an. Die Migration wirkt verlustfrei.

OSPFv3 identifiziert Nachbarn anders. Die frühere Abhängigkeit von IPv4-Interfaceadressen lässt sich nicht unverändert übertragen. RFC 5329 verlangt Neighbor ID und schreibt vor, den alten Link ID beim Empfang zu ignorieren.

Der Rohdatensatz sollte dennoch erhalten bleiben. Seine Anwesenheit kann einen Interoperabilitätsfehler belegen. Die Verarbeitung muss daneben festhalten, dass er keine Autorität hatte. Löschen und Befolgen wären zwei verschiedene Arten, die Evidenzgrenze zu verletzen.

Die neue Identität ist bewusst zusammengesetzt

Neighbor ID tritt genau einmal in einem Link TLV auf und enthält Neighbor Interface ID sowie Neighbor Router ID. Router ID benennt den Protokollnachbarn; Interface ID hält den Linkkontext fest.

Bei parallelen Verbindungen ist das keine Redundanz. Derselbe Router ID gehört zu mehreren Links, deren Interface IDs verschieden sind. Ein Schema mit nur einem Nachbarfeld verschmilzt sie und deutet wechselnde Attribute als Flattern.

Lokale und entfernte IPv6-Adressmengen unterstützen die Unterscheidung. Sie dürfen keine Link-Local-Adressen enthalten. Die entfernte Menge kann fehlen oder bei Multi-Access :: sein. Fehlende Zusatzinformation ist keine Widerlegung des Links.

Link State ID ist eine Verpackungsentscheidung

Der Link State ID des Intra-Area-TE-LSA ist beliebig und verwaltet mehrere TE-LSAs. Laut RFC 5329 besitzt er keine topologische Bedeutung. Wer ihn zum Asset-Schlüssel macht, erzählt bei jeder Neuaufteilung der TLVs eine Geschichte von Abbau und Neubau.

Er gehört in den LSA-Schlüssel und in den Verlauf der Verteilung. Er gehört nicht ohne weitere Beweise in die Identität einer Leitung. Protokollumschlag und bezeichnete Sache bleiben getrennt.

Ein grüner Flood beweist nur den Transport

Der LSA-Typ hat Area Scope und gesetztes U-Bit. Selbst ein Router, der den Typ nicht kennt, muss ihn im Scope fluten. Diese Regel bewahrt Erweiterbarkeit über ältere Knoten.

Ein Empfänger kann den Typ kennen und unbekannte verschachtelte TLVs ignorieren. Die Area-Policy kann TE-Werbung deaktiviert lassen. Eine vorhandene TE-Datenbank kann von keinem Pfadprozess genutzt werden.

Deshalb braucht es getrennte Belege für Flooding, Erkennung, TLV-Parsing, Identität, Policy und Konsum. Der LSDB-Eintrag ist nur der Anfang dieser Kette.

Die erste Instanz gewinnt

Neighbor ID ist einmalig. Andere RFC-5329-Sub-TLVs sollten nicht wiederholt werden; spätere Instanzen werden ignoriert. Ein gewöhnliches Last-write-wins-Objekt kehrt diese Regel um.

Bewahren Sie Reihenfolge, Längenfeld, Padding, Position und Parserurteil. Padding richtet auf vier Oktette aus, zählt aber nicht zur Länge. Ohne Rohgrenzen ist ein Parsingfehler später nicht von einem Inhaltskonflikt zu unterscheiden.

Auch ignorierte Duplikate bleiben relevant. Sie können Fehler, Versionswechsel oder bewusst mehrdeutige Eingaben zeigen. Bereinigung vor der Analyse zerstört Ursache.

Stabil adressiert ist nicht lebend gemessen

Der Router IPv6 Address TLV wirbt eine stabile routbare Adresse, die bei Konnektivität zum Router erreichbar sein sollte. Das ist eine Soll-Eigenschaft, kein Ping-Beleg. LSDB, Route, Messung, Managementsitzung und Anwendungsergebnis sind getrennte Quittungen.

Quellen und Evidenzgrenze

Die Quellen belegen Standardregeln, Historie und Registrierungen, nicht aktuelle Implementierung, Konfiguration, Adjazenz, TE-Datenbank, berechneten Pfad, Reservierung, Weiterleitung oder Nutzerwirkung.