Zusammenfassung

  • RFC 5185 bildet eine zusätzliche OSPFv3-Adjazenz als Router-LSA-Link ab, kündigt dafür aber keine Präfixe in der intra-area-prefix-LSA an und sollte keine Link-LSA erzeugen.
  • Eine Topologiekante darf deshalb weder eine Adresse noch physische Kapazität erfinden. Jede Adjazenz braucht eine belegte Zuordnung zu Interface, Schaltung und gemeinsamem Risiko.

Das Topologiesystem sah eine neue OSPFv3-Kante und verlangte automatisch ein neues Link-Präfix. Als keines erschien, meldete es einen Datenfehler. Ein Reparaturprozess schlug vor, aus der Kante einen Adressdatensatz abzuleiten.

Doch das Fehlen war beabsichtigt. RFC 5185 trennt die topologische Beziehung von der Adresssemantik. Der Fehler lag im Datenmodell, das jede Kante zu einem vollständigen physischen Linkobjekt aufblasen wollte.

Eine Kante löst ein Routingproblem

Die Standards-Track-RFC von Mai 2008 betrachtet zwei ABRs mit schnellem Backbone-Link und langsameren internen Wegen in einem anderen Bereich. OSPF bevorzugt Intra-Area gegenüber Inter-Area. Der schnelle Link kann deshalb ungenutzt bleiben.

Eine zusätzliche Bereichsadjazenz über das gemeinsame Interface macht ihn dort zum Intra-Area-Pfad. Virtual Link, Secondary Addressing oder dieselbe Subnetzzuordnung in mehreren Areas haben jeweils unerwünschte oder unzulässige Folgen. Die Erweiterung schafft daher Kontext, keinen zweiten Träger.

Mehrere FSMs auf einem Interface

Für jede Multi-Area-Adjazenz entsteht eine eigene OSPF-Interface-Struktur, stets point-to-point. Neighbor-Struktur und FSM bleiben normal; die primäre Adjazenz läuft nach RFC 2328 weiter. Auf nicht-punktförmigen Medien wird die Neighbor-Adresse konfiguriert oder außerhalb von OSPF gelernt, und Pakete werden unicast gesendet. Die Area ID demultiplexiert den Empfang.

Bei FULL erscheint ein Type-1-Link in der Router-LSA. Link ID ist die entfernte Router ID; Link Data ist Neighbor-IP oder IfIndex bei unnumbered. Ein Type-3-Link wird nicht erzeugt.

FULL ist damit ein präziser Protokollbeleg. Es ist kein Beleg für zweite Faser, Leitung, Linecard oder Bandbreite.

OSPFv3 macht die Datengrenze sichtbar

OSPFv3-Router-LSAs beschreiben Links unabhängig von Adressen. Für die Multi-Area-Adjazenz werden keine passenden Präfixe in einer intra-area-prefix-LSA angekündigt; eine Link-LSA sollte nicht angekündigt werden. Die IPv6-Link-Local-Adresse des Nachbarn kann aus Hello-Headern gelernt werden.

Ein Inventar braucht deshalb getrennte, verknüpfte Modelle: OSPF-Topologie, beobachtete Adressierung und physische Ressource. Ein fehlendes Präfix darf nicht automatisch ergänzt werden. Sonst verwandelt eine gewünschte Abwesenheit sich in erfundene Infrastruktur.

Kapazität wird am physischen Elternobjekt gezählt

RFC 3630 kann TE-Metrik, maximale und reservierbare Bandbreite, freie Bandbreite je Priorität und Administrative Group beschreiben. Diese Eigenschaften gehören zum Link-Ressourcenobjekt. Drei Area-Kanten eines 100-Gbit/s-Circuits ergeben nicht 300 Gbit/s.

Interface, Linecard, LAG-Mitglied, Provider-Circuit, Trasse und Shared-Risk-Gruppe erhalten eine stabile ID. Primäre und zusätzliche Adjazenzen referenzieren sie. Logische Zustände bleiben einzeln sichtbar, während Kapazität und Ausfallrisiko einmal gezählt werden.

Heng Lus Realitätsschichten helfen: Router-LSA und SPF sind eine ausführbare symbolische Sicht; Optik, Counter und tatsächlicher Paketpfad bilden die operative Begrenzung. Die Verknüpfung ist Beweis, nicht Namensähnlichkeit.

Route und Ausfallradius ändern sich gemeinsam

Die neue Intra-Area-Route kann Verkehr vom langsameren Bereichspfad auf den gemeinsamen Backbone-Link ziehen. Deshalb gehören LSDB, SPF, RIB, FIB, Auslastung, Verlust, Queue und Alternativkapazität vor und nach der Änderung in den Nachweis.

Stub-Router-Metriken aus RFC 6987 oder Reverse Metric aus RFC 9355 können Verkehr beeinflussen, ändern aber die Leitung nicht. Nach einem Drain muss beobachtetes Forwarding beweisen, dass der Shared Link frei ist.

Kompatible Asymmetrie braucht Dokumentation

Die Gegenstelle muss die Adjazenz nur als point-to-point modellieren. Identische Multi-Area-Konfiguration ist nicht zwingend, Symmetrie wird jedoch für Darstellung und Fehlersuche empfohlen. Das erlaubt freiwillige Einführung, erzeugt aber unterschiedliche lokale Namen.

Darum speichert der Nachweis beide Router IDs, ABR-Rollen, Softwarestände, Interfaces, Neighbor-Provenienz, Area IDs, Konfigurationssichten und die gemeinsame physische ID.

Mehrdeutigkeit ist eine Konfigurationsstörung

Ein Backbone-Paket kann einem Virtual Link oder einer Multi-Area-Adjazenz entsprechen. Passt es zu beiden, verlangt RFC 5185 Behandlung als Konfigurationsfehler. Die Laufzeit soll nicht zufällig entscheiden.

Auch ein Planungssystem muss stoppen, wenn es nicht klären kann, ob zwei Kanten denselben Circuit verwenden. Unbekannte gemeinsame Abhängigkeit ist keine bewiesene Diversität.

Der vollständige Beleg

Er umfasst Change-ID und Snapshot; Router IDs, Rollen, Builds; Interface, Neighbor und Quelle; Circuit, Karte, Provider und Risiko; primäre und zusätzliche Adjazenzen; Area IDs und Netzwerktyp; FSM-Zeiten; Link ID, Link Data, Metrik und fehlenden Type 3; OSPFv3-Präfix- und Link-LSA-Verhalten; LSDB, SPF, RIB, FIB und Traffic; einmalige Kapazität; Endpunktasymmetrie; Virtual-Link-Prüfung; Drain, Rollback und Ergebnis.

RFC 5185 gibt Betreibern eine minimale gemeinsame Funktion für lokale Entscheidungen. Sie bleibt klar, wenn eine neue Topologiekante genau das bleibt: eine neue Sicht auf Routing, nicht die automatische Geburt von Adresse, Bandbreite oder physischer Unabhängigkeit.

Quellen

  1. RFC 5185 HTML
  2. RFC 5185 Text
  3. RFC-Editor-Information
  4. IETF Datatracker
  5. Dokumenthistorie
  6. Referenzen
  7. RFC-5185-Errata
  8. RFC 2328 OSPFv2
  9. RFC-2328-Information
  10. RFC 5340 OSPFv3
  11. RFC-5340-Information
  12. RFC 3630 Traffic Engineering
  13. RFC 6987 Stub Router
  14. RFC 7770 optionale Fähigkeiten
  15. RFC 8665 Segment Routing
  16. RFC 9355 Reverse Metric
  17. RFC 3137 Stub Router
  18. Heng Lu — Realitätsschichten
  19. Heng Lu — minimale Spezifikation und freiwillige Einführung
  20. Heng Lu — laufender Code zuerst