Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Einführung in OSPF

OSPF – Überblick

OSPF ist ein Interior Gateway Protocol (IGP), das Pakete innerhalb eines einzigen autonomen Systems (AS) leitet. OSPF verwendet Link-State-Informationen, um Routing-Entscheidungen zu treffen und Routenberechnungen mit dem SPF-Algorithmus (auch als Dijkstra-Algorithmus bezeichnet) durchzuführen. Jeder Router, auf dem OSPF ausgeführt wird, überflutet Link-Status-Ankündigungen im gesamten AS oder Bereich, die Informationen über die angeschlossenen Schnittstellen und Routing-Metriken dieses Routers enthalten. Jeder Router verwendet die Informationen in diesen Link-State-Ankündigungen, um den kostengünstigsten Pfad zu jedem Netzwerk zu berechnen und eine Routing-Tabelle für das Protokoll zu erstellen.

Junos OS unterstützt OSPF-Version 2 (OSPFv2) und OSPF-Version 3 (OSPFv3), einschließlich virtueller Verbindungen, Stubbereiche und für OSPFv2, Authentifizierung. Junos OS unterstützt kein Typ-of-Service-Routing (ToS).

OSPF wurde für die TCP/IP-Umgebung (Transmission Control Protocol/Internet Protocol) entwickelt und unterstützt daher explizit IP-Subnetting und das Tagging von extern abgeleiteten Routing-Informationen. OSPF bietet auch die Authentifizierung von Routing-Updates.

OSPF leitet IP-Pakete ausschließlich auf der Grundlage der im IP-Paket-Header enthaltenen Ziel-IP-Adresse weiter. OSPF erkennt schnell topologische Änderungen, z. B. wenn Routerschnittstellen nicht mehr verfügbar sind, und berechnet neue schleifenfreie Routen schnell und mit einem Minimum an Routing-Overhead-Datenverkehr.

Hinweis:

Wenn auf Firewalls der SRX-Serie nur ein Link-Schutz unter der OSPF-Schnittstelle konfiguriert ist, installiert das Gerät keine alternative Route in der Weiterleitungstabelle. Wenn das Load Balancing pro Paket als Problemumgehung aktiviert ist, beobachtet das Gerät weder die OSPF-Metrik noch sendet den Datenverkehr über die Schnittstellen.

Ein OSPF AS kann aus einem einzigen Bereich bestehen oder in mehrere Bereiche unterteilt werden. In einer OSPF-Netzwerktopologie mit einem einzigen Bereich verwaltet jeder Router eine Datenbank, die die Topologie des AS beschreibt. Die Verbindungsstatusinformationen für jeden Router werden im gesamten AS überflutet. In einer OSPF-Topologie mit mehreren Bereichen verwaltet jeder Router eine Datenbank, die die Topologie seines Bereichs beschreibt, und die Verbindungsstatusinformationen für jeden Router werden in diesem Bereich überflutet. Alle Router pflegen zusammengefasste Topologien anderer Bereiche innerhalb eines AS. In jedem Bereich verfügen OSPF-Router über identische topologische Datenbanken. Wenn sich die AS- oder Bereichstopologie ändert, stellt OSPF sicher, dass die Inhalte der topologischen Datenbanken aller Router schnell zusammenlaufen.

Alle OSPFv2-Protokollaustausche können authentifiziert werden. OSPFv3 setzt auf IPsec, um diese Funktionalität bereitzustellen. Das bedeutet, dass nur vertrauenswürdige Router am Routing des AS teilnehmen können. Es kann eine Vielzahl von Authentifizierungsschemata verwendet werden. Für jeden Bereich wird ein einziges Authentifizierungsschema konfiguriert, wodurch in einigen Bereichen strengere Authentifizierungen verwendet werden können als in anderen.

Extern abgeleitete Routing-Daten (z. B. aus BGP gelernte Routen) werden transparent durch den AS weitergeleitet. Diese extern abgeleiteten Daten werden getrennt von den OSPF Link-State-Daten aufbewahrt. Jede externe Route kann vom Werberouter getaggt werden, sodass zusätzliche Informationen zwischen Routern an den Grenzen des AS weitergeleitet werden können.

Hinweis:

Standardmäßig ist Junos OS mit RFC 1583, OSPF-Version 2 kompatibel. In Junos OS Version 8.5 und höher können Sie die Kompatibilität mit RFC 1583 deaktivieren, indem Sie die no-rfc-1583 Anweisung angeben. Weitere Informationen finden Sie im Beispiel: Deaktivieren der OSPFv2-Kompatibilität mit RFC 1583.

In diesem Thema werden die folgenden Informationen beschrieben:

OSPF-Standardroutenpräferenzwerte

Der Junos OS-Routingprotokollprozess weist jeder Route, die die Routingtabelle empfängt, einen Standardeinstellungswert zu. Der Standardwert hängt von der Quelle der Route ab. Der Präferenzwert liegt von 0 bis 4.294.967.295 (232 – 1), wobei ein niedrigerer Wert eine bevorzugte Route anzeigt. Tabelle 1 listet die Standardwerte für OSPF auf.

Tabelle 1: Standard-Routenpräferenzwerte für OSPF

So lernt man die Route

Standardeinstellung

Anweisung zum Ändern der Standardeinstellung

OSPF-interne Route

10

OSPF-Präferenz

EXTERNE OSPF AS-Routen

150

OSPF externe Präferenz

OSPF-Routing-Algorithmus

OSPF verwendet den SPF-Algorithmus (Shortest Path First), auch als Dijkstra-Algorithmus bezeichnet, um die Route zu jedem Ziel zu bestimmen. Alle Routing-Geräte in einem Bereich führen diesen Algorithmus parallel aus und speichern die Ergebnisse in ihren individuellen topologischen Datenbanken. Routing-Geräte mit Schnittstellen zu mehreren Bereichen führen mehrere Kopien des Algorithmus aus. Dieser Abschnitt bietet eine kurze Zusammenfassung der Funktionsweise des SPF-Algorithmus.

Wenn ein Routinggerät gestartet wird, initialisiert es OSPF und wartet auf Hinweise von niedrigeren Protokollen, dass die Routerschnittstellen funktionsfähig sind. Das Routinggerät verwendet dann das OSPF hello-Protokoll, um Nachbarn zu erfassen, indem es Hallo-Pakete an seine Nachbarn sendet und deren Hallo-Pakete empfängt.

In Broadcast- oder Non-Broadcast-Multiaccess-Netzwerken (physische Netzwerke, die die Anbindung von mehr als zwei Routing-Geräten unterstützen) wählt das OSPF hello-Protokoll einen speziellen Router für das Netzwerk. Dieses Routing-Gerät ist für das Senden von Link-State-Ankündigungen (LSAs) verantwortlich, die das Netzwerk beschreiben, wodurch der Netzwerkverkehr und die Größe der topologischen Datenbanken der Routing-Geräte reduziert werden.

Das Routinggerät versucht dann, Mit einigen seiner neu erworbenen Nachbarn Nachbarschaften zu bilden. (In Multiaccess-Netzwerken bilden nur der designierte Router und der Backup-Router Zusammenführungen mit anderen Routing-Geräten.) Adjacencies bestimmen die Verteilung von Routing-Protokollpaketen. Routing-Protokollpakete werden nur bei Adjacencies gesendet und empfangen, und topologische Datenbankaktualisierungen werden nur über Adjacencies gesendet. Wenn Adjacencies eingerichtet sind, synchronisieren Paare benachbarter Router ihre topologischen Datenbanken.

Ein Routinggerät sendet LSA-Pakete, um seinen Status in regelmäßigen Abständen ankündigen zu können und wenn sich sein Zustand ändert. Diese Pakete enthalten Informationen über die Adjacencies des Routing-Geräts, die die Erkennung von nichtbetrieblichen Routing-Geräten ermöglichen.

Mit einem zuverlässigen Algorithmus überflutet das Routing-Gerät LSAs im gesamten Bereich, wodurch sichergestellt wird, dass alle Routing-Geräte in einem Bereich genau die gleiche topologische Datenbank haben. Jedes Routing-Gerät verwendet die Informationen in seiner topologischen Datenbank, um einen Baum für den kürzesten Pfad zu berechnen, der sich selbst als Wurzel dient. Das Routing-Gerät verwendet diese Struktur dann, um den Netzwerkverkehr zu routen.

Die bis zu diesem Zeitpunkt beschriebene Beschreibung des SPF-Algorithmus hat erklärt, wie der Algorithmus innerhalb eines einzelnen Bereichs funktioniert (Intra-Area-Routing). Damit interne Router zu Zielen außerhalb des Bereichs (Interarea-Routing) routen können, müssen die Bereichsrand-Router zusätzliche Routing-Informationen in den Bereich einschleusen. Da die Area Border Router mit dem Backbone verbunden sind, haben sie Zugriff auf vollständige topologische Daten über das Backbone. Die Router an der Bereichsgrenze verwenden diese Informationen, um Pfade zu allen Zielen außerhalb ihres Bereichs zu berechnen und diese Pfade dann an die internen Router der Region anzukündigen.

Autonome System-Router (AS) überfluten Informationen über externe autonome Systeme im gesamten AS, mit Ausnahme von Stubbereichen. Area Border Router sind für die Werbung der Pfade zu allen AS-Boundary-Routern verantwortlich.

OSPF-Drei-Wege-Handshake

OSPF erstellt eine Topologiekarte, indem LSAs über OSPF-fähige Verbindungen überflutet werden. LSAs kündigen das Vorhandensein von OSPF-fähigen Schnittstellen zu angrenzenden OSPF-Schnittstellen an. Der Austausch von LSAs stellt die bidirektionale Konnektivität zwischen allen benachbarten OSPF-Schnittstellen (Nachbarn) mithilfe eines Drei-Wege-Handshake her, wie in Abbildung 1 dargestellt.

Abbildung 1: OSPF-Drei-Wege-Handshake OSPF Three-Way Handshake

In Abbildung 1 sendet Router A pakete aller OSPF-fähigen Schnittstellen, wenn er online ist. Router B empfängt das Paket, das feststellt, dass Router B Datenverkehr von Router A empfangen kann. Router B generiert eine Antwort auf Router A, um den Erhalt des Hallo-Pakets zu bestätigen. Wenn Router A die Antwort erhält, stellt er fest, dass Router B Datenverkehr von Router A empfangen kann. Router A generiert dann ein endgültiges Antwortpaket, um Router B darüber zu informieren, dass Router A Datenverkehr von Router B empfangen kann. Dieser Drei-Wege-Handshake sorgt für bidirektionale Konnektivität.

Wenn dem Netzwerk neue Nachbarn hinzugefügt werden oder bestehende Nachbarn die Konnektivität verlieren, werden die Nachbarschaften in der Topologiekarte durch den Austausch (oder das Fehlen) von LSAs entsprechend geändert. Diese LSAs veröffentlichen nur die inkrementellen Änderungen im Netzwerk, wodurch die Menge des OSPF-Datenverkehrs im Netzwerk minimiert wird. Die Adjacencies werden gemeinsam genutzt und zum Erstellen der Netzwerktopologie in der topologischen Datenbank verwendet.

OSPF-Version 3

OSPFv3 ist eine modifizierte Version von OSPF, die IPv6-Adressierung (IP-Version 6) unterstützt. OSPFv3 unterscheidet sich auf folgende Weise von OSPFv2:

  • Alle Nachbarn-ID-Informationen basieren auf einer 32-Bit-Router-ID.

  • Das Protokoll wird pro Verbindung und nicht pro Subnetz ausgeführt.

  • Router- und Network Link-State-Ankündigungen (LSAs) übertragen keine Präfixinformationen.

  • Zwei neue LSA-Typen sind enthalten: Link-LSA und Intra-Area-Prefix-LSA.

  • Die Flooding-Bereiche sind wie folgt:

    • Link-lokal

    • Bereich

    • ALS

  • Link-lokale Adressen werden für alle Nachbarn mit Ausnahme virtueller Verbindungen verwendet.

  • Die Authentifizierung wird entfernt. Der IPv6-Authentifizierungs-Header basiert auf der IP-Ebene.

  • Das Paketformat hat sich wie folgt geändert:

    • VersionSnummer 2 ist jetzt Version Nummer 3.

    • Das Db-Optionsfeld wurde auf 24 Bits erweitert.

    • Authentifizierungsinformationen wurden entfernt.

    • Hallo Nachrichten haben keine Adressinformationen.

    • Zwei neue Optionsbits sind enthalten: R und V6.

  • Zusammenfassungs-LSAs des Typs 3 wurden in Inter-Area-Prefix-LSAs umbenannt.

  • Typ 4 Summary LSAs wurden in Inter-Area-Router-LSAs umbenannt.

OSPF-Pakete – Übersicht

Es gibt mehrere Arten von Link-State-Ankündigungspaketen (LSA).

In diesem Thema werden die folgenden Informationen beschrieben:

OSPF-Paket-Header

Alle OSPFv2-Pakete haben einen gemeinsamen 24-Byte-Header und OSPFv3-Pakete haben einen gemeinsamen 16-Byte-Header, der alle Informationen enthält, die erforderlich sind, um zu bestimmen, ob OSPF das Paket akzeptieren soll. Der Header besteht aus den folgenden Feldern:

  • Versionsnummer– Die aktuelle OSPF-Versionsnummer. Dies kann entweder 2 oder 3 sein.

  • Typ – Typ des OSPF-Pakets.

  • Paketlänge: Länge des Pakets, in Bytes, einschließlich des Headers.

  • Router-ID: IP-Adresse des Routers, von dem das Paket stammt.

  • Bereichs-ID – Kennung des Bereichs, in dem das Paket unterwegs ist. Jedes OSPF-Paket ist mit einem einzigen Bereich verknüpft. Pakete, die über einen virtuellen Link übertragen werden, werden mit der Backbone-Bereichs-ID 0.0.0 gekennzeichnet. .

  • Prüfsumme – Fletcher-Prüfsumme.

  • Authentifizierung – (nur OSPFv2) Authentifizierungsschema und Authentifizierungsinformationen.

  • Instanz-ID– (nur OSPFv3) Kennung, die verwendet wird, wenn mehrere OSPFv3-Realms auf einer Verbindung konfiguriert sind.

Hallo Pakete

Router senden regelmäßig Hallo-Pakete auf allen Schnittstellen, einschließlich virtueller Verbindungen, um Nachbarschaftsbeziehungen aufzubauen und aufrechtzuerhalten. Hallo Pakete sind Multicast in physischen Netzwerken, die eine Multicast- oder Broadcast-Funktion haben, die eine dynamische Erkennung benachbarter Router ermöglicht. (In Nicht-Broadcast-Netzwerken ist die dynamische Nachbarnerkennung nicht möglich. Sie müssen also alle Nachbarn statisch konfigurieren, wie in Beispiel beschrieben: Konfigurieren einer OSPFv2-Schnittstelle in einem Nonbroadcast Multiaccess-Netzwerk.)

Hallo Pakete bestehen aus dem OSPF-Header plus den folgenden Feldern:

  • Netzwerkmaske – (nur OSPFv2) Netzwerkmaske, die mit der Schnittstelle verknüpft ist.

  • Hallo Intervall: Wie oft sendet der Router Hallo-Pakete. Alle Router in einem gemeinsam genutzten Netzwerk müssen das gleiche Hallo-Intervall verwenden.

  • Optionen: Optionale Funktionen des Routers.

  • Routerpriorität: Die Priorität des Routers, die zum designierten Router wird.

  • Router-Dead-Intervall: Wie lange wartet der Router, ohne OSPF-Pakete von einem Router zu empfangen, bevor er den Ausfall des Routers erklärt. Alle Router in einem gemeinsam genutzten Netzwerk müssen dasselbe Router-Dead-Intervall verwenden.

  • Designated Router – IP-Adresse des angegebenen Routers.

  • Backup designated Router – IP-Adresse des Backup-Routers.

  • Neighbor: IP-Adressen der Router, von denen gültige Hallo-Pakete innerhalb der vom Toten Intervall des Routers angegebenen Zeit empfangen wurden.

Datenbankbeschreibungspakete

Bei der Initialisierung einer Adjacency tauscht OSPF Datenbankbeschreibungspakete aus, die den Inhalt der topologischen Datenbank beschreiben. Diese Pakete bestehen aus dem OSPF-Header, der Paketsequenznummer und dem Header der Link-State-Ankündigung.

Anfragepakete für Verbindungsstatus

Wenn ein Router feststellt, dass Teile seiner topologischen Datenbank veraltet sind, sendet er ein Verbindungsstatus-Anforderungspaket an einen Nachbarn, der eine präzise Instanz der Datenbank anfordert. Diese Pakete bestehen aus dem OSPF-Header plus Feldern, die die Vom Router gesuchten Datenbankinformationen eindeutig identifizieren.

Aktualisierungspakete für Verbindungsstatus

Link-State-Update-Pakete tragen einen oder mehrere Link-Status-Ankündigungen einen Hop weiter von ihrem Ursprung entfernt. Der Router multicasts (überflutet) diese Pakete in physischen Netzwerken, die Multicast- oder Broadcast-Modus unterstützen. Der Router erkennt alle Aktualisierungspakete des Verbindungszustands und sendet, wenn eine erneute Übertragung erforderlich ist, die erneut übertragenen Ankündigungen Unicast.

Aktualisierungspakete für den Verbindungsstatus bestehen aus dem OSPF-Header und den folgenden Feldern:

  • Anzahl der Ankündigungen – Anzahl der in diesem Paket enthaltenen Link-Status-Ankündigungen.

  • Link-State-Ankündigungen: Die Link-State-Ankündigungen selbst.

Verbindungsstatusbestätigungspakete

Der Router sendet Verbindungsstatusbestätigungspakete als Antwort auf Link-State-Aktualisierungspakete, um zu überprüfen, ob die Update-Pakete erfolgreich empfangen wurden. Ein einzelnes Bestätigungspaket kann Antworten auf mehrere Update-Pakete enthalten.

Verbindungsstatusbestätigungspakete bestehen aus dem OSPF-Header und dem Link-State-Ankündigungs-Header.

Pakettypen für Link-State-Ankündigung

Verbindungsstatusanfrage, Link-Status-Aktualisierung und Link-Status-Bestätigungspakete werden verwendet, um Verbindungsstatus-Ankündigungspakete zuverlässig zu überfluten. OSPF sendet die folgenden Arten von Link-Status-Ankündigungen:

  • Ankündigungen für Routerlinks: Werden von allen Routern gesendet, um den Zustand und die Kosten der Routerverbindungen zu diesem Bereich zu beschreiben. Diese Link-State-Ankündigungen werden nur in einem einzigen Bereich überflutet.

  • Ankündigungen von Netzwerklinks: Werden von bestimmten Routern gesendet, um alle router zu beschreiben, die an das Netzwerk angeschlossen sind. Diese Link-State-Ankündigungen werden nur in einem einzigen Bereich überflutet.

  • Ankündigungen von Zusammenfassungslinks: Werden von Routern an Bereichsgrenzen gesendet, um die Routen zu beschreiben, die sie in anderen Bereichen kennen. Es gibt zwei Arten von Ankündigungen für Zusammenfassungslinks: diejenigen, die verwendet werden, wenn das Ziel ein IP-Netzwerk ist, und diejenigen, die verwendet werden, wenn das Ziel ein AS-Boundary-Router ist. Zusammenfassende Link-Ankündigungen beschreiben interarea-Routen, das heißt Routen zu Zielen außerhalb des Bereichs, aber innerhalb des AS. Diese Link-State-Ankündigungen werden in den zugehörigen Bereichen der Werbung überflutet.

  • Ankündigung externer Links: Werden von AS-Boundary-Routern gesendet, um externe Routen zu beschreiben, die ihnen bekannt sind. Diese Link-State-Ankündigungen werden im gesamten AS überflutet (mit Ausnahme von Stub-Bereichen).

Jeder Verbindungsstatus-Ankündigungstyp beschreibt einen Teil der OSPF-Routingdomäne. Alle Link-State-Ankündigungen werden im gesamten AS überflutet.

Jedes Link-State-Ankündigungspaket beginnt mit einem gemeinsamen 20-Byte-Header.

Grundlegendes zu externen OSPF-Kennzahlen

Wenn OSPF Routeninformationen aus externen autonomen Systemen (ASs) exportiert, enthält es eine Kosten - oder externe Metrik in der Route. OSPF unterstützt zwei Arten von externen Metriken: Typ 1 und Typ 2. Der Unterschied zwischen den beiden Metriken besteht darin, wie OSPF die Kosten für die Route berechnet.

  • Externe Metriken des Typs 1 entsprechen der Link-State-Metrik, wobei die Kosten gleich der Summe der internen Kosten zuzüglich der externen Kosten sind. Das bedeutet, dass externe Metriken des Typs 1 die externen Kosten für das Ziel sowie die Kosten (Kennzahl) für das Erreichen des AS-Boundary-Routers umfassen.

  • Typ 2 externe Metriken sind höher als die Kosten für jeden Pfad, der zum AS intern ist. Externe Metriken typ 2 verwenden nur die externen Kosten für das Ziel und ignorieren die Kosten (Kennzahl), um den AS-Grenzen-Router zu erreichen.

Standardmäßig verwendet OSPF die externe Metrik Typ 2.

Sowohl Typ 1 als auch Typ 2 externe Metriken können gleichzeitig im AS angezeigt werden. In diesem Fall haben externe Metriken Typ 1 immer Vorrang.

Externe Pfade des Typs 1 werden immer gegenüber externen Pfaden des Typs 2 bevorzugt. Wenn es sich bei allen Pfaden um externe Pfade des Typs 2 handelt, werden immer die Pfade mit der kleinsten angekündigten Typ-2-Metrik bevorzugt.

Unterstützte OSPF- und OSPFv3-Standards

Junos OS unterstützt im Wesentlichen die folgenden RFCs und Internet-Entwürfe, die Standards für OSPF und OSPF Version 3 (OSPFv3) definieren.

  • RFC 1583, OSPF-Version 2

  • RFC 1765, OSPF-Datenbanküberlauf

  • RFC 1793, Erweiterung von OSPF zur Unterstützung von Demand Circuits

  • RFC 1850, Management Information Base der OSPF-Version 2

  • RFC 2154, OSPF mit digitalen Signaturen

  • RFC 2328, OSPF-Version 2

  • RFC 2370, die OSPF Opaque LSA-Option

    Unterstützung wird durch die update-threshold Konfigurationsaussage auf [edit protocols rsvp interface interface-name ] Hierarchieebene bereitgestellt.

  • RFC 3101, The OSPF Not-So-Stubby Area (NSSA)-Option

  • RFC 3623, Graceful OSPF Restart

  • RFC 3630, Traffic Engineering (TE)-Erweiterungen für OSPF-Version 2

  • RFC 4136, OSPF-Aktualisierung und Flooding-Reduzierung in stabilen Topologien

  • RFC 4203, OSPF-Erweiterungen zur Unterstützung von Generalized Multi-Protocol Label Switching (GMPLS)

    Es wird nur Schnittstellen-Switching unterstützt.

  • RFC 4552, Authentifizierung/Vertraulichkeit für OSPFv3

  • RFC 4576, Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)

  • RFC 4577, OSPF als Provider/Customer Edge Protocol für BGP/MPLS IP Virtual Private Networks (VPNs)

  • RFC 4811, OSPF Out-of-Band Link State Database (LSDB)-Resynchronisation

  • RFC 4812, OSPF Restart Signaling

  • RFC 4813, OSPF Link-Local Signaling

  • RFC 4915, Multitopology (MT) Routing in OSPF

  • RFC 5185, OSPF Multi-Area Adjacency

  • RFC 5187, OSPFv3 Graceful Restart

  • RFC 5250, die OSPF Opaque LSA-Option

    Hinweis:

    RFC 4750, der in diesem RFC als "sollte"-Anforderung bezeichnet wird, wird nicht unterstützt. Rfc 1850, der Vorgänger von RFC 4750, wird jedoch unterstützt.

  • RFC 5286, Basic Specification for IP Fast Reroute: Loop-Free Alternates

  • RFC 5340, OSPF für IPv6 (RFC 2740 ist durch RFC 5340 veraltet)

  • RFC 5838, Unterstützung von Adressfamilien in OSPFv3

  • Internet Draft-ietf-ospf-af-alt-10.txt, Unterstützung von Adressfamilien in OSPFv3

  • Internet Draft-katz-ward-bfd-02.txt, Bidirektionale Weiterleitungserkennung

    Die Übertragung von Echo-Paketen wird nicht unterstützt.

  • RFC 8665, OSPF-Erweiterungen für Segment-Routing

  • Internet Draft-ietf-lsr-flex-algo-07.txt, IGP Flexibler Algorithmus

Die folgenden RFCs definieren keine Standards, liefern aber Informationen über OSPF und verwandte Technologien. Die IETF stuft sie als "Informational" ein.

  • RFC 3137, Ankündigung des OSPF-Stub-Routers

  • RFC 3509, Alternative Implementierungen von OSPF Area Border Routern

  • RFC 5309, Point-to-Point-Betrieb über LAN in Link State Routing-Protokollen

  • RFC 8920, anwendungsspezifische Linkattribute von OSPF

  • RFC 8920, Ankündigung von OSPFv2 Prefix/Link-Attribut