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 – Übersicht

OSPF ist ein Interior Gateway Protocol (IGP), das Pakete innerhalb eines einzigen autonomen Systems (AS) weitergibt. OSPF nutzt Link-State-Informationen, um Routing-Entscheidungen zu treffen, indem es Routenberechnungen mit dem Algorithmus "Shortest Path-First" (SPF) (auch als Dijkstra-Algorithmus bezeichnet) vornimmt. 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-Status-Anzeigen, 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 Links, Stubbereiche 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 ausdrücklich IP-Subnetze und das Tagging von extern abgeleiteten Routing-Informationen. OSPF bietet auch die Authentifizierung von Routing-Updates.

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

Hinweis:

Wenn auf Geräten der SRX-Serie nur ein Verbindungsschutz über die OSPF-Schnittstelle konfiguriert wird, installiert das Gerät keine alternative Route in der Weiterleitungstabelle. Wenn der Lastausgleich pro Paket als Problemumgehung aktiviert ist, beobachtet das Gerät nicht sowohl die OSPF-Metrik als auch das Senden des Datenverkehrs über beide Schnittstellen.

Ein OSPF-AS kann aus einem einzigen Bereich bestehen oder in mehrere Bereiche unterteilt werden. In einer OSPF-Netzwerktopologie mit einem Bereich verwaltet jeder Router eine Datenbank, die die Topologie des AS beschreibt. 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 Verbindungsstatusinformationen für jeden Router werden über diesen Bereich hinweg geflutet. 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 der Inhalt der topologischen Datenbanken aller Router schnell konvergiert.

Alle OSPFv2-Protokollaustausche können authentifiziert werden. OSPFv3 setzt zur Bereitstellung dieser Funktionalität auf IPsec. Das bedeutet, dass nur vertrauenswürdige Router am Routing des AS teilnehmen können. Es können verschiedene Authentifizierungsschemata verwendet werden. Für jeden Bereich wird ein einzelnes Authentifizierungsschema konfiguriert, das es einigen Bereichen ermöglicht, eine strengere Authentifizierung als andere zu verwenden.

Extern abgeleitete Routing-Daten (z. B. aus BGP gelernte Routen) werden transparent im gesamten AS übergeben. Diese extern abgeleiteten Daten werden getrennt von den OSPF Link-State-Daten aufbewahrt. Jede externe Route kann über den 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 einbeziehen. Weitere Informationen finden Sie unter Beispiel: Deaktivierung der OSPFv2-Kompatibilität mit RFC 1583.

In diesem Thema werden die folgenden Informationen beschrieben:

OSPF Standard-Routenprä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 zwischen 0 und 4.294.967.295 (232 – 1), wobei ein niedrigerer Wert für eine bevorzugtere Route angibt. Tabelle 1 listet die Standardpräferenzwerte für OSPF auf.

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

Wie Route erlernt wird

Standardeinstellung

Anweisung zur Änderung der Standardpräferenz

INTERNE OSPF-Route

10

OSPF-Präferenz

OSPF AS externe Routen

150

OSPF externe Präferenz

OSPF-Routing-Algorithmus

OSPF verwendet den Shortest Path-First (SPF)-Algorithmus, der auch als Dijkstra-Algorithmus bezeichnet wird, 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 beginnt, initialisiert es OSPF und wartet auf Hinweise von Protokollen auf niedrigerer Ebene, dass die Routerschnittstellen funktionsfähig sind. Das Routing-Gerät verwendet dann das OSPF hello-Protokoll, um Nachbarn zu erwerben, indem es Hello-Pakete an seine Nachbarn sendet und ihre Hello-Pakete empfängt.

Bei Broadcast- oder Nonbroadcast-Multiaccess-Netzwerken (physische Netzwerke, die das Anbringen von mehr als zwei Routing-Geräten unterstützen) wählt das OSPF Hello Protocol einen speziellen Router für das Netzwerk. Dieses Routing-Gerät ist verantwortlich für das Senden von Link State Advertisements (LSAs), die das Netzwerk beschreiben, wodurch die Menge des Netzwerkdatenverkehrs und die Größe der topologischen Datenbanken der Routinggeräte reduziert werden.

Das Routinggerät versucht dann, Nachbarschaften mit einigen seiner neu erworbenen Nachbarn zu bilden. (In Multiaccess-Netzwerken bilden nur der designierte Router und der backup-designated Router Nachbarschaften zu anderen Routing-Geräten.) Nachbarschaften bestimmen die Verteilung von Routingprotokollpaketen. Routingprotokollpakete werden nur in Nachbarschaften gesendet und empfangen, und topologische Datenbankaktualisierungen werden nur in Nachbarschaften gesendet. Wenn Nachbarschaften eingerichtet wurden, synchronisieren Paare benachbarter Router ihre topologischen Datenbanken.

Ein Routinggerät sendet LSA-Pakete, um den Status regelmäßig und bei Statusänderungen zu werben. Diese Pakete enthalten Informationen über die Nachbarschaften des Routinggeräts, die die Erkennung von nicht operativen Routinggeräten ermöglichen.

Mithilfe eines zuverlässigen Algorithmus überflutet das Routinggerät LSAs im gesamten Bereich, was sicherstellt, dass alle Routing-Geräte in einem Bereich genau die gleiche topologische Datenbank haben. Jedes Routinggerät verwendet die Informationen in seiner topologischen Datenbank, um einen Baum mit dem kürzesten Pfad zu berechnen, der sich selbst als Stammverzeichnis befindet. Das Routinggerät verwendet dann diesen Baum, um den Netzwerkdatenverkehr zu routen.

Die Beschreibung des SPF-Algorithmus bis zu diesem Punkt hat erklärt, wie der Algorithmus innerhalb eines einzigen Bereichs (Intra-Area Routing) funktioniert. Damit interne Router zu Zielen außerhalb des Bereichs routen 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 die Pfade zu allen Zielen außerhalb des Bereichs zu berechnen und diese Pfade dann für die internen Router des Bereichs zu werben.

Grenzrouter für autonome Systeme (AS) überfluten Informationen zu externen autonomen Systemen im gesamten AS, mit Ausnahme von Stubbereichen. Area Border Router sind für die Werbung für die Pfade zu allen AS-Grenzroutern 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 benachbarten OSPF-Schnittstellen an. Der Austausch von LSAs schafft bidirektionale Konnektivität zwischen allen benachbarten OSPF-Schnittstellen (Nachbarn) mithilfe eines Drei-Wege-Handshakes, 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 OSPF-fähigen Schnittstellen, wenn sie online verfügbar sind. Router B empfängt das Paket, wodurch festgestellt wird, dass Router B Datenverkehr von Router A empfangen kann. Router B generiert eine Antwort auf Router A, um den Empfang des Hello-Pakets zu bestätigen. Wenn Router A die Antwort empfängt, 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 vorhandene Nachbarn die Konnektivität verlieren, werden die Nachbarschaften in der Topologiekarte entsprechend durch den Austausch (oder das Fehlen) von LSAs geändert. Diese LSAs werben nur für inkrementelle Änderungen im Netzwerk, was dazu beiträgt, die Menge des OSPF-Datenverkehrs im Netzwerk zu minimieren. Die Nachbarschaften werden gemeinsam genutzt und zur Erstellung der Netzwerktopologie in der topologischen Datenbank verwendet.

OSPF Version 3

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

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

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

  • Router- und Network Link State Advertisements (LSAs) enthalten keine Prefix-Informationen.

  • Es sind zwei neue LSA-Typen enthalten: link-LSA und intra-area-prefix-LSA.

  • Überflutungsgebiete sind wie folgt:

    • Link-lokal

    • Bereich

    • ALS

  • Link-lokale Adressen werden für alle Neighbor Exchanges außer virtuellen Links verwendet.

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

  • Das Paketformat hat sich wie folgt geändert:

    • Versionsnummer 2 ist jetzt Versionsnummer 3.

    • Das DB-Optionsfeld wurde auf 24 Bits erweitert.

    • Authentifizierungsinformationen wurden entfernt.

    • Hallo Nachrichten haben keine Adressinformationen.

    • Es sind zwei neue Optionsbits enthalten: R und V6.

  • Zusammenfassung Typ 3 LSAs wurden in inter-area-prefix-LSAs umbenannt.

  • Zusammenfassung typ 4 LSAs wurden in Inter-Area-Router-LSAs umbenannt.

OSPF-Pakete – Übersicht

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

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 eine virtuelle Verbindung übertragen werden, werden mit der Backbone Area ID 0.0.0.0 gekennzeichnet. .

  • Prüfsumme – Fletcher Prüfsumme.

  • Authentifizierung – (nur OSPFv2) Authentifizierungsschema und Authentifizierungsinformationen.

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

Hallo Pakete

Router senden regelmäßig Hello-Pakete an allen Schnittstellen, einschließlich virtueller Verbindungen, um Nachbarbeziehungen aufzubauen und zu pflegen. Hallo Pakete sind Multicast in physischen Netzwerken, die über eine Multicast- oder Broadcast-Funktion verfügen, wodurch die dynamische Erkennung benachbarter Router ermöglicht wird. (In Nonbroadcast-Netzwerken ist eine dynamische Neighbor Discovery nicht möglich, daher müssen Sie alle Nachbarn statisch konfigurieren, wie in Beispiel beschrieben: Konfigurieren einer OSPFv2-Schnittstelle in einem Nonbroadcast Multiaccess Network.)

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

  • Netzwerkmaske – (nur OSPFv2) Netzwerkmaske, die der Schnittstelle zugeordnet ist.

  • Hallo Intervall– Wie oft sendet der Router Hello-Pakete. Alle Router in einem gemeinsam genutzten Netzwerk müssen dasselbe Hello-Intervall verwenden.

  • Optionen – Optionale Funktionen des Routers.

  • Routerpriorität– Die Routerpriorität, der bestimmte Router zu werden.

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

  • Designated Router – IP-Adresse des designierten Routers.

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

  • Neighbor – IP-Adressen der Router, von denen innerhalb des vom Router festgelegten Dead Intervals gültige Hello-Pakete empfangen wurden.

Datenbankbeschreibung Pakete

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-Anzeige.

Verbindungsstatus-Anforderungspakete

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

Link-State-Aktualisierungspakete

Link-State-Update-Pakete tragen einen oder mehrere Link-State-Anzeigen einen Hop weiter vom Ursprung entfernt. Der Router-Multicast überflutet diese Pakete in physischen Netzwerken, die den Multicast- oder Broadcast-Modus unterstützen. Der Router erkennt alle Aktualisierungspakete für den Verbindungsstatus und sendet, falls eine erneute Übertragung erforderlich ist, den erneut übertragenen Unicast.

Update-Pakete für den Linkstatus bestehen aus dem OSPF-Header und den folgenden Feldern:

  • Anzahl der Anzeigen – Anzahl der in diesem Paket enthaltenen Link-Status-Anzeigen.

  • Link-State-Werbung – Die Link-Status-Werbung selbst.

Verbindungsstatus-Bestätigungspakete

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

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

Link-State Advertisement-Pakettypen

Link-State-Anforderung, Link-Status-Update und Link-State-Bestätigungspakete werden verwendet, um Link-State-Advertisement-Pakete zuverlässig zu überfluten. OSPF sendet die folgenden Arten von Link-Status-Ankündigungen:

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

  • Ankündigungen zu Netzwerklinks: Werden von bestimmten Routern gesendet, um alle mit dem Netzwerk verbundenen Router zu beschreiben. Diese Link-State-Anzeigen werden nur in einem einzigen Bereich überschwemmt.

  • Zusammenfassung der Linkanzeigen: Werden von Area-Border-Routern gesendet, um die Routen zu beschreiben, die sie in anderen Bereichen kennen. Es gibt zwei Arten von zusammenfassenden Link-Ankündigungen: diejenigen, die verwendet werden, wenn das Ziel ein IP-Netzwerk ist, und diejenigen, die verwendet werden, wenn das Ziel ein AS-Grenzrouter ist. Zusammenfassende Linkanzeigen beschreiben Interarea-Routen, d. h. Routen zu Zielen außerhalb des Bereichs, aber innerhalb des AS. Diese Link-State-Anzeigen werden in den zugehörigen Bereichen der Werbeanzeige überschwemmt.

  • Werbung für externe Verbindungen: Werden von AS-Grenzroutern gesendet, um externe Routen zu beschreiben, von denen sie wissen. Diese Link-State-Anzeigen werden im gesamten AS überschwemmt (mit Ausnahme von Stub-Bereichen).

Jeder Link-Status-Werbetyp beschreibt einen Teil der OSPF-Routingdomäne. Alle Link-State-Anzeigen werden im gesamten AS überschwemmt.

Jedes Werbepaket mit Verbindungsstatus beginnt mit einem gemeinsamen 20-Byte-Header.

Verstehen der externen OSPF-Kennzahlen

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

  • Externe Kennzahlen vom Typ 1 entsprechen der Verbindungsstatusmetrik, wobei die Kosten der Summe der internen Kosten plus den externen Kosten entsprechen. Das bedeutet, dass die externen Typ-1-Metriken die externen Kosten zum Ziel und die Kosten (Metrik) zum Erreichen des AS-Grenzrouters enthalten.

  • Externe Typ 2-Metriken sind größer als die Kosten für jeden internen Pfad zum AS. Typ 2 externe Metriken verwenden nur die externen Kosten für das Ziel und ignorieren die Kosten (Metrik), um den AS-Grenzrouter zu erreichen.

OsPF verwendet standardmäßig die externe Kennzahl Typ 2.

Sowohl typ 1 als auch typ 2 externe Metriken können gleichzeitig in der AS vorhanden sein. In diesem Fall haben externe Kennzahlen von Typ 1 immer den Vorrang.

Typ 1 externe Pfade werden immer gegenüber externen Typ 2-Pfaden bevorzugt. Wenn es sich bei allen Pfaden um externe Pfade vom Typ 2 handelt, werden die Pfade mit der kleinsten angegebenen Typ 2-Metrik immer 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, OSPF Version 2 Management Information Base

  • 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 Konfigurationsanweisung auf Hierarchieebene [edit protocols rsvp interface interface-name ] bereitgestellt.

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

  • RFC 3623, Graceful OSPF-Neustart

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

  • RFC 4136, OSPF Refresh and Flooding Reduction in Stable Topologies

  • 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-Signalisierung

  • RFC 4813, OSPF Link-Local Signaling

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

  • RFC 5185, OSPF Mehrbereichsadjacency

  • RFC 5187, OSPFv3 Graceful Restart

  • RFC 5250, Die OSPF Opaque LSA-Option

    Hinweis:

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

  • RFC 5286, Grundlegende Spezifikation für IP Fast Reroute: Loop-Free Alternates

  • RFC 5340, OSPF für IPv6 (RFC 2740 ist von RFC 5340 überholt)

  • RFC 5838, Unterstützung von Adressfamilien in OSPFv3

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

  • Internet draft-katz-ward-bfd-02.txt, Bidirectional Forwarding Detection

    Die Übertragung von Echopaketen wird nicht unterstützt.

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

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

Die folgenden RFCs definieren keine Standards, sondern liefern Informationen zu OSPF und zugehörigen Technologien. Die IETF stuft sie als "informational" ein.

  • RFC 3137, WERBUNG FÜR OSPF-Stub-Router

  • RFC 3509, Alternative Implementierungen von OSPF Area Border Routern

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

  • RFC 8920, OSPF Anwendungsspezifische Verbindungsattribute

  • RFC 8920, OSPFv2 Prefix/Link Attribute Advertisement