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) weiterleitet. OSPF nutzt Link-State-Informationen, um Routing-Entscheidungen zu treffen, und nimmt Routenberechnungen mit dem SPF-Algorithmus (shortest-path-first) (auch als Dijkstra-Algorithmus bezeichnet) vor. Jeder Router, auf dem OSPF ausgeführt wird, überflutet im gesamten AS oder Bereich Link-State-Ankündigungen, die Informationen über die angeschlossenen Schnittstellen und Routing-Metriken des Routers enthalten. Jeder Router verwendet die Informationen in diesen Link-State-Ankündigungen, um den kostengünstigsten Pfad zu den einzelnen Netzwerken 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 Links, Stub-Bereiche und für OSPFv2 Authentifizierung. Junos OS unterstützt kein ToS-Routing (Type-of-Service).

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 ermöglicht auch die Authentifizierung von Routing-Updates.

OSPF routet IP-Pakete ausschließlich basierend auf der Ziel-IP-Adresse, die im IP-Paket-Header enthalten ist. OSPF erkennt schnell topologische Veränderungen, z. B. wenn Routerschnittstellen nicht mehr verfügbar sind, und berechnet neue schleifenfreie Routen schnell und mit minimalem Routing-Overhead-Datenverkehr.

Anmerkung:

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 der Lastenausgleich pro Paket als Problemumgehung aktiviert ist, berücksichtigt das Gerät nicht sowohl die OSPF-Metrik als auch das Senden des Datenverkehrs über beide Schnittstellen.

Ein OSPF AS kann aus einem einzelnen Bereich bestehen oder in mehrere Bereiche unterteilt werden. In einer Single-Area-OSPF-Netzwerktopologie 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. Innerhalb jedes Bereichs 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 konvergiert werden.

Alle OSPFv2-Protokollaustausche können authentifiziert werden. OSPFv3 verwendet 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 einzelnes Authentifizierungsschema konfiguriert, wodurch einige Bereiche eine strengere Authentifizierung verwenden können als andere.

Extern abgeleitete Routingdaten (z. B. von BGP gelernte Routen) werden transparent an den gesamten AS übergeben. Diese extern abgeleiteten Daten werden getrennt von den OSPF-Verbindungszustandsdaten aufbewahrt. Jede externe Route kann vom Werberouter mit Tags versehen werden, sodass zusätzliche Informationen zwischen Routern an den Grenzen des AS weitergegeben werden können.

Anmerkung:

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 einfügen. Weitere Informationen finden Sie unter Beispiel: Deaktivieren der OSPFv2-Kompatibilität mit RFC 1583.

In diesem Thema werden die folgenden Informationen beschrieben:

OSPF-Standard-Routenpräferenzwerte

Der Routingprotokollprozess von Junos OS weist jeder Route, die von der Routing-Tabelle empfangen wird, einen Standardpräferenzwert zu. Der Standardwert hängt von der Quelle der Route ab. Der Präferenzwert liegt zwischen 0 und 4.294.967.295 (232 – 1), wobei ein niedrigerer Wert eine bevorzugte Route angibt. In Tabelle 1 sind die Standardeinstellungswerte für OSPF aufgeführt.

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

Wie Route gelernt wird

Standardeinstellung

Anweisung zum Ändern der Standardeinstellung

Interne OSPF-Route

10

OSPF-Präferenz

Externe OSPF-AS-Routen

150

Externe OSPF-Präferenz

OSPF-Routing-Algorithmus

OSPF verwendet den SPF-Algorithmus (shortest-path-first), der auch als Dijkstra-Algorithmus bezeichnet wird, um die Route zu den einzelnen Zielen zu bestimmen. Alle Routing-Geräte in einem Gebiet führen diesen Algorithmus parallel aus und speichern die Ergebnisse in ihren jeweiligen topologischen Datenbanken. Auf dem Routing von Geräten mit Schnittstellen zu mehreren Bereichen werden mehrere Kopien des Algorithmus ausgeführt. Dieser Abschnitt enthält eine kurze Zusammenfassung der Funktionsweise des SPF-Algorithmus.

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

In Broadcast- oder Non-Broadcast-Multiaccess-Netzwerken (physische Netzwerke, die den Anschluss von mehr als zwei Routing-Geräten unterstützen) wählt das OSPF-Hello-Protokoll einen bestimmten Router für das Netzwerk aus. Dieses Routing-Gerät ist für das Senden von Link State Advertisements (LSAs) zuständig, die das Netzwerk beschreiben, wodurch die Menge des Netzwerkverkehrs und die Größe der topologischen Datenbanken der Routing-Geräte reduziert werden.

Das Routing-Gerät versucht dann, Nachbarschaften mit einigen seiner neu erworbenen Nachbarn zu bilden. (In Multiaccess-Netzwerken benachbarten sich nur der designierte Router und der designierte Backup-Router mit anderen Routing-Geräten.) Nachbarschaften bestimmen die Verteilung von Routing-Protokollpaketen. Routingprotokollpakete werden nur in benachbarten Umgebungen gesendet und empfangen, und Aktualisierungen topologischer Datenbanken werden nur in benachbarten Umgebungen gesendet. Wenn Nachbarschaften hergestellt wurden, synchronisieren Paare benachbarter Router ihre topologischen Datenbanken.

Ein Routinggerät sendet LSA-Pakete, um seinen Status regelmäßig und bei einer Statusänderung bekannt zu geben. Diese Pakete enthalten Informationen über die Nachbarschaft des Routing-Geräts, wodurch nicht betriebsfähige Routing-Geräte erkannt werden können.

Mithilfe eines zuverlässigen Algorithmus flutet das Routing-Gerät LSAs im gesamten Bereich, wodurch sichergestellt wird, dass alle Routing-Geräte in einem Bereich über genau dieselbe topologische Datenbank verfügen. Jedes Routing-Gerät verwendet die Informationen in seiner topologischen Datenbank, um einen Baum mit dem kürzesten Pfad zu berechnen, wobei es selbst als Stamm fungiert. Das Routing-Gerät verwendet dann diese Struktur, um Netzwerkdatenverkehr weiterzuleiten.

Die bisherige Beschreibung des SPF-Algorithmus hat erklärt, wie der Algorithmus innerhalb eines einzelnen Bereichs funktioniert (Intra-Area-Routing). Damit interne Router an Ziele außerhalb des Gebiets weiterleiten können (Interarea-Routing), müssen die Area Border-Router zusätzliche Routing-Informationen in den Bereich einspeisen. Da die Area Border Router mit dem Backbone verbunden sind, haben sie Zugriff auf vollständige topologische Daten über das Backbone. Die Area Border-Router verwenden diese Informationen, um Pfade zu allen Zielen außerhalb des Gebiets zu berechnen und diese Pfade dann den internen Routern des Gebiets bekannt zu geben.

Boundary Router für autonome Systeme (AS) überfluten Informationen über externe autonome Systeme im gesamten AS, mit Ausnahme von Stub-Bereichen. Area Border Router sind dafür verantwortlich, die Pfade zu allen AS Boundary Routern bekannt zu geben.

OSPF-Drei-Wege-Handschlag

OSPF erstellt eine Topologiekarte, indem LSAs über OSPF-fähige Links überflutet werden. LSAs kündigen das Vorhandensein von OSPF-fähigen Schnittstellen zu benachbarten OSPF-Schnittstellen an. Durch den Austausch von LSAs wird eine bidirektionale Konnektivität zwischen allen benachbarten OSPF-Schnittstellen (Nachbarn) mithilfe eines Drei-Wege-Handshakes hergestellt, wie in Abbildung 1 dargestellt.

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

In Abbildung 1 sendet Router A Hello-Pakete an alle seine OSPF-fähigen Schnittstellen, wenn er online geht. Router B empfängt das Paket, wodurch festgelegt wird, dass Router B Datenverkehr von Router A empfangen kann. Router B generiert eine Antwort an Router A, um den Empfang des Hello-Pakets zu bestätigen. Wenn Router A die Antwort erhält, wird festgestellt, dass Router B Datenverkehr von Router A empfangen kann. Router A generiert dann ein letztes Antwortpaket, um Router B darüber zu informieren, dass Router A Datenverkehr von Router B empfangen kann. Dieser Drei-Wege-Handshake gewährleistet eine bidirektionale Konnektivität.

Wenn dem Netzwerk neue Nachbarn hinzugefügt werden oder die Verbindung zwischen bestehenden Nachbarn unterbrochen wird, werden die benachbarten Nachbarn in der Topologiezuordnung durch den Austausch (oder das Fehlen) von LSAs entsprechend geändert. Diese LSAs kündigen nur die inkrementellen Änderungen im Netzwerk an, wodurch der OSPF-Datenverkehr im Netzwerk minimiert wird. Die angrenzenden Flächen werden freigegeben 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 von OSPFv2 in folgenden Punkten:

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

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

  • Router- und Netzwerk-Link-State-Advertisements (LSAs) enthalten keine Präfixinformationen.

  • Es gibt zwei neue LSA-Typen: Link-LSA und Intra-Area-Prefix-LSA.

  • Die Flooding-Bereiche lauten wie folgt:

    • Link-lokal

    • Fläche

    • WIE

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

  • Die Authentifizierung wird entfernt. Der IPv6-Authentifizierungsheader basiert auf der IP-Schicht.

  • Das Paketformat hat sich wie folgt geändert:

    • Die Versionsnummer 2 ist jetzt die Versionsnummer 3.

    • Das Optionsfeld db wurde auf 24 Bit erweitert.

    • Die Authentifizierungsinformationen wurden entfernt.

    • Hello-Nachrichten enthalten keine Adressinformationen.

    • Zwei neue Optionsbits sind enthalten: R und V6.

  • Zusammenfassungs-LSAs vom Typ 3 wurden in Inter-Area-Prefix-LSAs umbenannt.

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

Übersicht über OSPF-Pakete

Es gibt verschiedene Arten von LSA-Paketen (Link State Advertisement).

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 sich das Paket befindet. Jedes OSPF-Paket ist einem einzelnen Bereich zugeordnet. Pakete, die über eine virtuelle Verbindung übertragen werden, werden mit der Backbone-Bereichs-ID 0.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-Bereiche für einen Link konfiguriert sind.

Hallo Päckchen

Router senden regelmäßig Hello-Pakete an alle Schnittstellen, einschließlich virtueller Verbindungen, um nachbarschaftliche Beziehungen aufzubauen und zu pflegen. Hello-Pakete werden in physischen Netzwerken mit einer Multicast- oder Broadcast-Funktion übertragen, die eine dynamische Erkennung benachbarter Router ermöglicht. (In Nicht-Broadcast-Netzwerken ist die dynamische Nachbarerkennung nicht möglich, daher müssen Sie alle Nachbarn statisch konfigurieren, wie in Beispiel: Konfigurieren einer OSPFv2-Schnittstelle in einem Nicht-Broadcast-Netzwerk mit Mehrfachzugriff beschrieben.)

Hello-Pakete bestehen aus dem OSPF-Header und den folgenden Feldern:

  • Netzwerkmaske: (Nur OSPFv2) Netzwerkmaske, die mit der Schnittstelle verknüpft ist.

  • Hallo-Intervall: Gibt an, wie oft der Router Hallo-Pakete sendet. 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, der zum designierten Router wird.

  • Totes Intervall für Router: Wie lange der Router wartet, ohne OSPF-Pakete von einem Router zu erhalten, bevor der Router als ausgefallen deklariert wird. Alle Router in einem gemeinsam genutzten Netzwerk müssen das gleiche Totintervall des Routers verwenden.

  • Designierter Router: IP-Adresse des designierten Routers.

  • Designierter Backup-Router: IP-Adresse des designierten Backup-Routers.

  • Nachbar: IP-Adressen der Router, von denen innerhalb der durch das Totintervall des Routers angegebenen Zeit gültige Hello-Pakete empfangen wurden.

Datenbank Beschreibungspakete

Bei der Initialisierung einer Nachbarschaft 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.

Verbindungsstatus-Anforderungspakete

Wenn ein Router feststellt, dass Teile seiner topologischen Datenbank veraltet sind, sendet er ein Link-State-Anforderungspaket an einen Nachbarn, der eine genaue Instanz der Datenbank anfordert. Diese Pakete bestehen aus dem OSPF-Header und Feldern, die die vom Router gesuchten Datenbankinformationen eindeutig identifizieren.

Aktualisierungspakete für den Verbindungsstatus

Aktualisierungspakete für den Verbindungsstatus enthalten eine oder mehrere Ankündigungen für den Verbindungsstatus, die einen Hop weiter von ihrem Ursprung entfernt sind. Der Router multicastet (flutet) diese Pakete in physische Netzwerke, die den Multicast- oder Broadcast-Modus unterstützen. Der Router quittiert alle Aktualisierungspakete für den Verbindungsstatus und sendet die erneut übertragenen Ankündigungen an Unicast, falls eine erneute Übertragung erforderlich ist.

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

  • Anzahl der Ankündigungen: Anzahl der Link-State-Ankündigungen, die in diesem Paket enthalten sind.

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

Link-State-Bestätigungspakete

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

Link-State-Bestätigungspakete bestehen aus dem OSPF-Header und dem Link-State-Advertisement-Header.

Link-State-Ankündigung Pakettypen

Link-State-Anforderungs-, Link-State-Update- und Link-State-Bestätigungspakete werden verwendet, um Link-State-Ankündigungspakete zuverlässig zu fluten. OSPF sendet die folgenden Arten von Link-State-Ankündigungen:

  • Router-Link-Ankündigungen: Werden von allen Routern gesendet, um den Status und die Kosten der Verbindungen des Routers zu dem Gebiet zu beschreiben. Diese Link-State-Ankündigungen werden nur in einem einzigen Bereich überflutet.

  • Netzwerkverbindungsankündigungen: Werden von bestimmten Routern gesendet, um alle an das Netzwerk angeschlossenen Router zu beschreiben. Diese Link-State-Ankündigungen werden nur in einem einzigen Bereich überflutet.

  • Zusammenfassende Linkankündigungen: Werden von Area Border-Routern gesendet, um die Routen zu beschreiben, die ihnen in anderen Gebieten bekannt sind. Es gibt zwei Arten von zusammenfassenden Linkankündigungen: solche, die verwendet werden, wenn das Ziel ein IP-Netzwerk ist, und solche, die verwendet werden, wenn das Ziel ein AS-Grenzrouter ist. Zusammenfassende Linkankündigungen beschreiben gebietsübergreifende Routen, d. h. Routen zu Zielen außerhalb des Gebiets, aber innerhalb des AS. Diese Link-State-Ankündigungen werden in den zugehörigen Bereichen der Anzeige überflutet.

  • AS-Werbung für externe 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 Verbindungszustandsankü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.

Externe OSPF-Metriken verstehen

Wenn OSPF Routeninformationen von externen autonomen Systemen (ASs) exportiert, enthält dies einen Kostenfaktor oder eine 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 der Route berechnet.

  • Externe Metriken vom Typ 1 entsprechen der Link-State-Metrik, bei der die Kosten der Summe der internen Kosten zuzüglich der externen Kosten entsprechen. Das bedeutet, dass externe Metriken vom Typ 1 sowohl die externen Kosten bis zum Ziel als auch die Kosten (Metrik) zum Erreichen des AS-Boundary-Routers umfassen.

  • Externe Metriken vom Typ 2 sind höher als die Kosten für einen Pfad innerhalb des AS. Externe Metriken vom Typ 2 verwenden nur die externen Kosten für das Ziel und ignorieren die Kosten (Metrik), um den AS-Boundary-Router zu erreichen.

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

Externe Metriken vom Typ 1 und Typ 2 können gleichzeitig im AS vorhanden sein. In diesem Fall haben externe Metriken vom Typ 1 immer Vorrang.

Externe Pfade vom Typ 1 werden immer den externen Pfaden des Typs 2 vorgezogen. Wenn es sich bei allen Pfaden um externe Pfade des Typs 2 handelt, werden immer die Pfade mit der kleinsten beworbenen Metrik des Typs 2 bevorzugt.

Unterstützte OSPF- und OSPFv3-Standards

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

  • RFC 1583, OSPF Version 2

  • RFC 1765, OSPF-Datenbanküberlauf

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

  • RFC 1850, OSPF Version 2 Management Information Base

  • RFC 2154, OSPF mit digitalen Signaturen

  • RFC 2328, OSPF Version 2

  • RFC 2370, Die OSPF Opake LSA-Option

    Die Unterstützung erfolgt durch die update-threshold Konfigurationsanweisung auf der [edit protocols rsvp interface interface-name ] Hierarchieebene.

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

  • RFC 3623, Graceful-OSPF-Neustart

  • RFC 3630, Traffic Engineering (TE)-Erweiterungen zu 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 das Switching der Schnittstellen unterstützt.

  • RFC 4552, Authentifizierung/Vertraulichkeit für OSPFv3

  • RFC 4576, Verwenden eines Link State Advertisement (LSA)-Optionsbits zur Verhinderung von Schleifen 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-LSDB-Resynchronisierung (Link State Database)

  • RFC 4812, OSPF-Restart-Signalisierung

  • RFC 4813, OSPF Link-Local Signaling

  • RFC 4915, Multi-Topologie (MT)-Routing in OSPF

  • RFC 5185, OSPF – Nachbarschaft in mehreren Bereichen

  • RFC 5187, OSPFv3 Graceful-Restart

  • RFC 5250, Die OSPF Opake LSA-Option

    Anmerkung:

    RFC 4750, der in diesem RFC als "should"-Anforderung erwähnt wird, wird nicht unterstützt. RFC 1850, der Vorgänger von RFC 4750, wird jedoch unterstützt.

  • RFC 5286, Grundlegende Spezifikation für IP Fast Reroute: Schleifenfreie Alternativen

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

  • RFC 5709, OSPFv2 HMAC-SHA Kryptografische Authentifizierung

  • RFC 5838, Unterstützung von Adressfamilien in OSPFv3

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

  • Internet-Entwurf draft-katz-ward-bfd-02.txt, Bidirectional Forwarding Detection (Bidirektionale Weiterleitungserkennung)

    Die Übertragung von Echopaketen wird nicht unterstützt.

  • RFC 6549, OSPFv2 Multi-Instanz-Erweiterungen

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

  • Internet-Entwurf draft-ietf-lsr-flex-algo-07.txt, flexibler IGP-Algorithmus

Die folgenden RFCs definieren keine Standards, stellen aber Informationen zu OSPF und verwandten Technologien bereit. Die IETF stuft sie als "informativ" ein.

  • RFC 3137, OSPF-Stub-Router-Werbung

  • RFC 3509, Alternative Implementierungen von OSPF Area Border Routern

  • RFC 5309, Punkt-zu-Punkt-Betrieb über LAN in Link State Routing-Protokollen

  • RFC 8920, Anwendungsspezifische OSPF-Verbindungsattribute

  • RFC 8920, OSPFv2 Präfix/Linkattributankündigung