Zusammenfassung

  • RFC 6860 bewahrt die für SPF erforderliche OSPF-Topologie und verhindert zugleich, dass das Präfix eines reinen Transitnetzes als erreichbares Ziel in RIB und FIB installiert wird.
  • „Versteckt“ ist kein Geheimhaltungsversprechen: OSPFv2 kann Adressdaten in LSAs behalten, Altsoftware kann eine /32 installieren, und Management, Forwarding Address oder Virtual Link können die unterdrückte Adresse benötigen.

Zwei Zustände auf demselben Link

Nach einer Änderung ist eine kleinere Routenzahl allein wertlos. Sie kann die beabsichtigte Präfixunterdrückung zeigen oder den Verlust einer Nachbarschaft. Die Abnahme wird erst verständlich, wenn zugleich feststeht, dass die Topologiekante und der erwartete Paketpfad erhalten blieben.

Ein nummerierter OSPFv2-Punkt-zu-Punkt-Link erscheint in der Router-LSA gewöhnlich in zwei Rollen. Ein Type-1-Link beschreibt den Nachbarrouter und fließt in SPF ein. Ein Type-3-Stub-Link beschreibt das zugewiesene Netz und erzeugt dessen Route. RFC 6860 lässt Type 3 weg und behält Type 1.

Der Router weiß weiter, dass Ziele hinter dem Nachbarn über diese Kante erreichbar sind. Er verteilt aber nicht mehr die Behauptung, das Interface-Netz selbst müsse überall ein Ziel sein. Weder Interface noch Adresse verschwinden; nur die Projektion des Präfixes in entfernte RIBs wird beendet.

Warum der DR die Network-LSA nicht löschen darf

In Broadcast-Netzen nennt die Network-LSA des Designated Routers die angeschlossenen Router. Würde sie vollständig entfernt, ginge mit dem Präfix auch die Topologie verloren.

RFC 6860 erhält deshalb die LSA und setzt die besondere Maske 255.255.255.255. Ein aktualisierter Empfänger berechnet die Topologie normal, installiert die Netzroute jedoch nicht. Für NBMA im Broadcast-Modell gilt das Gleiche.

Bei gemischten Versionen entsteht bewusst keine identische RIB. Ein alter Router kann die Maske als gewöhnliche /32 lesen und eine Hostroute zur Interface-Adresse des DR installieren. Ein aktualisierter Router installiert keine Route. Der Standard bewertet eine einzelne exponierte Adresse als begrenzter als das ganze Transitnetz, verschweigt die Asymmetrie aber nicht.

Damit ist eine LSDB-Aufnahme kein Abschlussbeleg. Der Prüfer muss Empfänger, Softwarestand und resultierende RIB nennen. Ein gemeinsamer Kontrollzustand kann unterschiedliche Weiterleitungszustände erzeugen.

OSPFv3 trennt Adressen vom Kern

In OSPFv3 tragen die zentralen Router-LSAs und Network-LSAs Topologie, aber keine Netzadressen. Link-LSAs verknüpfen Adressen lokal mit dem Link; Intra-Area-Prefix-LSAs ordnen Präfixe Routern oder Netzen zu.

Prefix Suppression lässt die Topologieobjekte bestehen und nimmt die Transitpräfixe aus der Bildung der betreffenden Intra-Area-Prefix-LSAs. Die Address-Family-Unterstützung aus RFC 5838 verwendet dieselbe Trennung pro Instanz.

Das ist sauberer, nicht unsichtbar. Link-LSA, Router ID, Interfacezustand und Konfiguration bleiben beobachtbar. Eine Adresse kann zugewiesen sein und dennoch aus dem OSPF-Gebiet nicht erreichbar werden. Belastbar ist nur die konkrete Aussage, dass ein bestimmter Empfänger das Präfix aus einer bestimmten Instanz nicht installierte.

Bekannt heißt nicht routbar

Der Sicherheitszweck besteht darin, weniger Kernnetze aus der Ferne adressierbar zu machen. Auch eine bekannte Adresse lässt sich über das OSPF-Gebiet nicht erreichen, wenn den Routern die Weiterleitungsinformation fehlt.

Das ist weder Verschlüsselung noch Authentisierung. In OSPFv2 kann die Interface-Adresse als Link Data sichtbar bleiben; die DR-Adresse kann Link State ID bleiben. Direkt angeschlossene Router besitzen Connected Routes. Statische Routen, andere Protokolle, Tunnel oder Managementnetze können alternative Wege liefern.

„Versteckt“ braucht deshalb einen Beobachtungspunkt: aus welcher RIB, auf welchem Router, zu welcher Zeit und für welche Routingquelle? Wurde auch die FIB geprüft? Existiert ein Ersatzweg? Wurde vom relevanten Eingang aus getestet?

Auch ein behaupteter Konvergenzgewinn benötigt Messung. Weniger Präfixe können Arbeit sparen; RFC 6860 ersetzt aber keine Vorher-nachher-Messung der konkreten Topologie.

Transit-only muss bewiesen werden

Linkadressen dienen oft Ping, Traceroute, direktem Management, Alarmzuordnung oder Automatisierung. Nutzverkehr kann ungestört weiterlaufen, während die Diagnosefähigkeit sinkt.

Eine von null verschiedene Forwarding Address in externen oder NSSA-LSAs benötigt einen passenden Routingtabelleneintrag. Eine unterdrückte Interface-Adresse darf diese Rolle nicht weiter tragen; externe Wege können dadurch weniger optimal werden.

Auch ein OSPF Virtual Link verlangt erreichbare Endpunkte über einen Intra-Area-Pfad. Die unterdrückte Adresse darf kein Endpunkt sein. Die erhaltene Topologiekante ersetzt keine ausdrücklich adressabhängige Kontrollfunktion.

Zum Inventar gehören außerdem BGP-Peerings, ACLs, Sammler, Skripte und Notfallpfade. Transit-only ist eine widerrufbare Betreiberklassifikation, keine Eigenschaft der Subnetzmaske.

Zwei Belege statt eines Feature-Hakens

Aktuelle Dokumentation von FRRouting und Cisco belegt Steuerungsmöglichkeiten in benannten Produktfamilien. Sie belegt weder Aktivierung noch Ergebnis eines Produktionsnetzes.

Der Kontinuitätsbeleg umfasst Nachbarschaft, Topologiekante, SPF-Ausgabe und Paket-Canaries. Der Unterdrückungsbeleg umfasst die ausgelassene Type-3- oder Präfixzuordnung, gegebenenfalls die Sondermaske, die fehlende Route in aktualisierten RIBs/FIBs und jede bewusst akzeptierte Legacy-/32.

Softwareversion, Konfigurationsumfang, Ausnahmen, Ersatz-Managementpfad, Forwarding-Address- und Virtual-Link-Prüfung, Verantwortlicher und Rollback verbinden beide Belege. Eine bloße Routenzahl kann gezielte Unterdrückung nicht von Kontrollverlust unterscheiden.

Álvaro Retanas begrenzte Zuordnung

RFC 6860 erschien 2013 mit Yi Yang, Álvaro Retana und Abhay Roy als Autoren und nennt weitere Erfinder und Reviewer. Retanas IETF-Profil dokumentiert eine viel breitere Laufbahn, begründet aber kein Eigentum an OSPF, Herstellercode oder fremden Netzen.

Die belegte Mitautorschaft trägt eine präzise Aussage: Retana wirkte an einer gemeinsamen Spezifikation mit, die Topologie und Adresserreichbarkeit nicht zu einem Zustand verdichtet. Der Standard definiert die kleinste gemeinsame Bedeutung; Implementierungen bieten die Fähigkeit; Betreiber wählen den Einsatz; Running Code liefert den Beleg.

Im Ledger bleiben fünf Aussagen getrennt: Der Link existiert. OSPF nutzt ihn. Das Interface hat eine Adresse. Entfernte Router installieren das Präfix nicht. Erforderliche Funktionen bestehen weiter. RFC 6860 erlaubt unterschiedliche Antworten. Gute Betriebsführung verhindert, dass daraus wieder nur ein grünes „hidden“ wird.

Quellen