imported>Felicior: /* Freie Software-Implementierungen */ Ip -> IP

2026-03-08T14:50:23Z

Freie Software-Implementierungen: Ip -> IP

Neue Seite

{{Netzwerk-TCP-IP-Vermittlungsprotokoll|OSPF, IP(IPv4/IPv6)}}
'''Open Shortest Path First''' ('''OSPF''') bezeichnet ein von der [[Internet Engineering Task Force|IETF]] entwickeltes [[Link-State]]-[[Routing]]-Protokoll. Es ist im <nowiki>RFC 2328</nowiki><ref name="RFC2328" /> festgelegt und basiert auf dem von [[Edsger W. Dijkstra]] entwickelten „[[Dijkstra-Algorithmus|shortest-path]]“-Algorithmus.<ref>E. W. Dijkstra: ''A Note on Two Problems in Connexion with Graphs.'' In: ''Numerische Mathematik.'' 1, 1959, S. 269–271; [http://www-m3.ma.tum.de/foswiki/pub/MN0506/WebHome/dijkstra.pdf ma.tum.de] (PDF; 739 kB).</ref>

OSPF ist vielleicht das am häufigsten verwendete [[Interior Gateway Protocol]] (IGP) in großen Unternehmensnetzen. Das am häufigsten verwendete [[Exterior-Gateway-Protokoll]] (EGP) ist das [[Border Gateway Protocol]] (BGP), das Haupt-Routing-Protokoll zwischen [[Autonomes System|autonomen Systemen]] im Internet.

== Überblick ==
Um die Nachteile von RIP ([[Routing Information Protocol]]) auszugleichen, wurde ab 1988 das Open-Shortest-Path-First-Verfahren (OSPF) entwickelt. Die Hauptvorteile von OSPF gegenüber RIP bestehen in der schnelleren Konvergenz und der besseren Skalierbarkeit für größere Netzwerke. Wie der Name andeutet, besitzt OSPF zwei Charakteristika, das der Offenheit im Sinne einer öffentlichen Spezifikation als <nowiki>RFC 2328</nowiki><ref name="RFC2328" /> und das der Verwendung des [[Dijkstra-Algorithmus|SPF-Algorithmus]]. In UNIX-Systemen ist OSPF als gated-Dämon implementiert. OSPF gehört zur Klasse der Link-State-Routing-Protokolle. Für IPv6 gilt <nowiki>RFC 5340</nowiki>.<ref name="RFC5340" />

Der Standard definiert nicht, wie die Kosten zu berechnen sind. Die Grundlage des SPF-Algorithmus bilden nicht, wie der Name nahelegt, die Anzahl der Hops, sondern die Pfadkosten. Entscheidungskriterium für die Vorteilhaftigkeit eines Weges und damit Metrik wird die nominale Datenrate.

Neuere Trends bei Betreibern von [[Internet Protocol|IP]]-Netzen zeigen, dass dort vermehrt [[IS-IS]] im Zusammenhang mit [[Multiprotocol Label Switching|MPLS]] eingesetzt wird, weil die IS-IS-Features ausreichen, das Protokoll weniger komplex als OSPF ist und im Vergleich besser skaliert. Trotzdem ist OSPF heute noch das vorwiegend verwendete Routing-Protokoll.

=== Merkmale von OSPF ===
* OSPF garantiert ein [[Schleife (Graphentheorie)|schleifenfreies]] [[Routing]] im Gegensatz zu [[Routing Information Protocol|RIP]]
* Es nutzt das Hello-Protokoll für die Überwachung der Nachbarn
* Es unterstützt [[Variable Length Subnet Mask|VLSM]], sowie [[Classless Inter-Domain Routing|CIDR]]
* OSPF ist für große, skalierbare Netze gut geeignet
* Das Area-Konzept vereinfacht die Kommunikation und Wartung
* OSPF kann das [[Bidirectional Forwarding Detection|BFD]]-Protokoll nutzen, um im Fehlerfall Konvergenzzeiten im Millisekundenbereich zu ermöglichen

=== Hierarchische Struktur durch Areas ===
Ein grundlegendes und wichtiges Konzept bei OSPF stellt die Hierarchie in sogenannten ''Areas'' (Bereichen) dar. Alle OSPF-Router können verschiedenen ''Areas'' zugeordnet werden. Dabei hat die sogenannte ''Backbone Area'' (Area 0) eine besondere Stellung. Alle anderen regulären ''Areas'' müssen direkt mit dieser ''Backbone Area'' verbunden sein. Sollte eine direkte Verbindung nicht möglich sein, können diese weit entfernten ''Areas'' durch ''Virtual Links'' mit der ''Backbone Area'' verbunden werden.<ref>[https://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094aaa.shtml ''What Are OSPF Areas and Virtual Links?''] cisco.com.</ref>

==== Backbone Area ====
Wird mehr als eine Area eingesetzt, müssen diese direkt oder indirekt mittels ''Virtual Link'' über eine ''Backbone Area'' gekoppelt werden. Diese ''Backbone Area'' hat immer die Nummer 0 und stellt als oberste OSPF-Hierarchieinstanz die Verbindungsbrücke zwischen allen Areas dar.

==== Reguläre Area ====
Alle anderen ''Areas'' außer der ''Backbone Area'' sind reguläre ''Areas''. Die Area-Nummer kann ein Zahlenwert zwischen 1 und 4294967295 (= 232 - 1) oder eine äquivalente Netz-ID (z. B. 192.168.1.0) sein.

==== Transit Area ====
Normalerweise muss eine reguläre ''Area'' direkt mit der ''Backbone Area'' verbunden sein. Kann eine reguläre ''Area'' jedoch aus Designgründen nicht direkt an die ''Backbone Area'' angebunden werden, sind ''Virtual Links'' als Hilfsmittel zu konfigurieren. Diese überbrücken eine dazwischen liegende ''Area'', welche dann zur ''Transit Area'' wird. Die ''Virtual Links'' stellen eine Art Tunnelverbindung zwischen einer ''Area'' und der ''Backbone Area'' dar; der Verkehr zwischen Teilnehmern in abgesetzter Area und Transit-Area wird jedoch direkt, d. h. nicht über die Backbone-Area vermittelt.

==== Stub Area ====
Eine ''Stub Area'' ist eine reguläre ''Area'', in welcher deren ''Area Border Router'' die Weiterleitung von [[Open Shortest Path First#Link State Advertisements LSA|LSA]]-Nachrichten vom Typ 5 filtern. Damit wird für alle normalen Router in einer ''Stub Area'' deren ''Area Border Router'' als Gateway propagiert.

==== Totally Stubby Area ====
Eine ''Totally Stubby Area'' (TSA) ist eine reguläre ''Area'', in welcher deren ''Area Border Router'' die Weiterleitung von LSA-Nachrichten vom Typ 3, 4 und 5 filtern. Damit wird für alle normalen Router in einer ''Totally Stubby Area'' ausschließlich deren ''Area Border Router'' als Gateway propagiert.

==== Not So Stubby Area ====
Eine ''Not So Stubby Area'' (NSSA) ist eine ''Stub Area'', welche durch ein anderes IGP- oder EGP-Protokoll externe Routen erlernt, aber in welcher deren ''Area Border Router'' die Weiterleitung von LSA-Nachrichten vom Typ 5 filtern. Diese externen Routinginformationen würden normalerweise in einer ''Stub Area'' nicht propagiert. Ist die ''Stub Area'' aber als eine ''Not So Stubby Area'' konfiguriert, so werden externe Routing-Updates mit LSA-Nachrichten vom Typ 7 an die ''Area Border Router'' der ''Stub Area'' weitergeleitet. Diese wiederum wandeln dann diese LSA-Nachrichten vom Typ 7 in LSA-Nachrichten vom Typ 5 um und propagieren diese externen Routen in die ''Backbone Area''.<ref>[https://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094a88.shtml ''OSPF Not-So-Stubby Area (NSSA)''] cisco.com.</ref>

==== Totally Not-So-Stubby Area (TNSSA) ====
Eine '' Totally Not-So-Stubby Area'' (Totally NSSA) ist eine reguläre ''Area'', in welcher deren ''Area Border Router'' die Weiterleitung von LSA-Nachrichten vom Typ 3, 4 und 5 filtern. Externe Routen werden genauso wie bei NSSA mit LSA-Nachrichten vom Typ 7 propagiert und durch ABR in LSA-Nachrichten vom Typ 5 umgewandelt.<ref>[https://mikemstech.blogspot.de/2012/04/ospf-totally-not-so-stubby-area-nssa.html ''The OSPF Totally Not-So-Stubby-Area (NSSA).''] Mike’s Technology and Finance Blog.</ref>

==== Designated Router ====
In jedem (N)BMA-Netz (LAN-Segment) werden automatisch ein OSPF-Router zum ''Designated Router'' und ein weiterer zum ''Backup Designated Router'' gewählt.<ref>{{RFC-Internet |RFC=2328 |Titel=OSPF Version 2 |Abschnitt=9.4 |Abschnittstitel=Electing the Designated Router |Datum=1998-04 |Obsoletes=2178 |Errata=1}}</ref> Alle regulären Router senden ihre Updates an den ''Designated Router'', und dieser wiederum ist der einzige, der Updates an alle anderen Router weiterleitet. Fällt ein ''Designated Router'' aus, übernimmt der ''Backup Designated Router'' dessen Aufgaben und wird selbst zum ''Designated Router''. Sogleich wird ein anderer Router in dem LAN-Segment zum ''Backup Designated Router'' gewählt.

==== Area Border Router ====
Jede ''Area'' hat einen ''Area Border Router'' (ABR). Dieser ABR dient als Schnittstelle zwischen einer regulären ''Area'' und der ''Backbone Area''. Wenn in einer ''Area'' nur ein Router existiert, so ist dieser automatisch auch der ''Designated Router'' (DR). Existieren in einer ''Area'' mehrere Router, so wird über einen Algorithmus automatisch ein Router zum ABR propagiert und ein weiterer zum Backup-ABR. Alle weiteren Router werden als normaler Router behandelt.

Ein ABR kann LSA-Nachrichten filtern und über ''Route Summarization'' mehrere Routen zusammenfassen, um Routingtabellen zu vereinfachen.

==== Autonomous System Boundary Router ====
Erlernt ein Router externe Routen über ein IGP- oder EGP-Protokoll und propagiert diese im OSPF-Netzwerk, so stellt dieser einen ''Autonomous System Boundary Router'' (ASBR) dar.<ref>{{Internetquelle |url=https://www.mpirical.com/glossary/asbr-autonomous-system-boundary-router |titel=ASBR – Autonomous System Boundary Router |werk=Mpirical |sprache=en-GB |abruf=2019-04-09}}</ref>

=== Lastverteilung ===
Wenn alternative Netzwerkpfade aus Sicht von OSPF dieselben metrischen Pfadkosten besitzen, so werden diese Pfade abwechselnd verwendet, um eine [[Lastverteilung (Informatik)|Lastverteilung]] zu ermöglichen.

== Arbeitsweise ==
[[Datei:OSPF Network.svg|mini|hochkant=1.5|OSPF Topologie]]
Kernstück von OSPF ist die Nachbarschafts-Datenbank ''(Adjazenz-Datenbank)''/''LSD (Link State Database)'', die eine Liste aller benachbarten Router enthält, zu denen eine [[bidirektional]]e Verbindung besteht. Sie spiegelt die [[Topologie (Rechnernetz)|Topologie]] des Netzes wider. Damit diese Datenbank aufgebaut oder bei Topologie-Änderungen aktualisiert wird, ist der Austausch von Routing-Informationen notwendig. Diese werden mittels [[Flooding (Informatik)|Flooding]] übermittelt. Um den Umfang der auszutauschenden Informationen gering zu halten, wählen OSPF-Router einen designierten Router ''(DR)'' sowie einen Reserve-Router ''BDR (Backup [[Designated Router]])'', die als Schnittstellen für den Austausch dienen. Der OSPF-Router, dessen Multi-Access-Schnittstelle die höchste ''Router-Priorität'' besitzt, wird ''DR''. Haben zwei Router die gleiche Priorität, wird der Router mit der höheren ''Router-ID'' gewählt. Als Router-ID wird die [[IP-Adresse]] eines Loopback-Interfaces oder – je nach Hersteller – des Interfaces mit der numerisch höchsten IP-Adresse/des ersten aktiven Interfaces automatisch gewählt.

=== Link State Advertisements LSA ===
Ein Link State Advertisement (LSA) ist eine Nachricht mit Informationen über die lokale [[Topologie (Rechnernetz)|Topologie]] eines Netzwerkes. Sie wird von jedem Router des Netzwerkes erzeugt und enthält Informationen über benachbarte Router (d. h., beide haben eine Schnittstelle im selben Netz) und adjazente Router (d. h., sie tauschen [[Routing]]-Informationen aus). Nach der Erstellung einer LSA wird sie mittels [[Flooding (Informatik)|Flooding]] durch die gesamte Routing-Domäne verteilt. Die Gesamtheit aller LSAs aller Router und Netze bildet die [[Link State Database]] (LSDB), eine [[Nachbarschaft (Graphentheorie)|Adjazenz]]-Datenbank, anhand derer der günstigste Pfad für ein Datenpaket durch das Netz ermittelt werden kann. Die LSAs können in regelmäßigen Abständen erneut versendet werden, um Veränderungen im Netzwerk in der LSDB nachzuhalten.

OSPF-Router tauschen Informationen über die erreichbaren Netze mit sogenannten [[Link State Advertisement|LSA]]-Nachrichten (Link State Advertisements) aus. Hierbei sind folgende LSA-Typen definiert:

; Router-LSA (Typ 1)
: Für jeden aktiven Link des Routers, der der zu betrachtenden Area angehört, wird ein Eintrag im Router-LSA erzeugt. In ihm wird neben der IP-Adresse des Links auch die [[Netzmaske]] des Links und der Netzwerktyp (Loopback, Point-to-Point, normales Netz) eingetragen.
; Network-LSA (Typ 2)
: Der designierte Router (DR) eines Netzsegments erzeugt ein Network-LSA für dieses Netz, das neben der Netzadresse und -maske auch eine Liste der anderen angrenzenden Router enthält.
; Summary-LSA (Typ 3/4)
: Informationen über Ziele außerhalb einer Area können von den ABR (Area border router) je nach Konfiguration als LSA-Typ 3 (wenn es sich um eine Netz-Information handelt) oder LSA-Typ 4 (bei einer weitergeleiteten Router-Erreichbarkeit) in eine andere Area weitergegeben werden. LSAs vom Typ 3 werden auch verwendet, um Default-Routen in (Stub-)Areas zu propagieren.
; AS-External LSA (Typ 5)
: Router, die aus Sicht des OSPF das eigene [[Autonomes System|autonome System]] abschließen, können für extern gelernte oder manuell konfigurierte Routen Typ-5-LSAs erzeugen. Diese enthalten Netzadresse und -maske des Zielnetzwerks sowie einen Verweis auf den ankündigenden Router. Eine gängige Anwendung von Typ-5-LSAs ist, Default-Routen in die Backbone-Area zu injizieren.
; NSSA-External-LSA (Typ 7)
: LSA-Typ7 wird am NSSA ASBR generiert. Type-5 LSAs sind in NSSA Areas nicht erlaubt, daher generiert der NSSA ASBR Type-7 LSAs dafür. Ein NSSA-External-LSA ist annähernd identisch mit einem AS-External-LSA. Im Gegensatz zu den AS-External-LSAs, die durch ein gesamtes OSPF-AS geflutet werden, werden NSSA-External-LSAs nur innerhalb der NSSA-Area geflutet, in der sie erzeugt wurden.
; Opaque-LSA (Typ 9)
: Dieser LSA-Typ wird Link lokal und somit nicht über Router hinweg verbreitet. Aktuell wird dieser LSA-Typ für eine Graceful Restart Funktion genutzt.
; Opaque-LSA (Typ 10)
: Dieser LSA-Typ wird Area lokal verbreitet. Aktuell wird dieser LSA-Typ für [[Traffic Engineering]] Funktionen genutzt.
; Opaque-LSA/Graceful Restart (Typ 11)
: Dieser LSA-Typ wird AS weit geflutet. <nowiki>RFC 5187</nowiki><ref>{{RFC-Internet |RFC=5187 |Titel=OSPF Version 3 Graceful Restart |Datum=2008-05}}</ref> ersetzt den Opaque-LSA Typ durch Graceful Restart LSA. Diese Veränderung gilt allerdings nur für OSPFv3. Eine Nutzung dieses LSA Types ist derzeit nicht bekannt.

==== Link State ID ====
Die Link State ID identifiziert die Instanz, die von der LSA beschrieben wird. Die Link State ID wird durch die Frage „Was beschreibt die LSA?“ charakterisiert. Die folgende Tabelle zeigt die möglichen Belegungen für die Link State ID, abhängig vom Typ der LSA:

{| class="wikitable" style="width:100%;"
|-
! LSA Typ !! Beschreibung !! Link State ID
|-
| 1
| Punkt-zu-Punkt-Verbindung zu einem anderen Router
| Router-ID des aussendenden Routers
|-
| 2
| Anbindung an ein Transit-Netz (Broadcast)
| IP-Adresse des Designated Routers
|-
| 3
| Verbindung zu einem Stub-Netz
| IP-Netzadresse des Ziel-Netzes mit Subnetmask
|-
| 4
| Verbindung zu einem ASBR als Gateway
| Router-ID des beschriebenen ASBR
|-
| 5
| AS-externe Ziele
| IP-Netzadresse des Ziel-Netzes mit Subnetmask
|-
| 6
| Group Membership LSA
| Multicast-Adresse
|}

==== LSA Header ====
{| class="wikitable" style="text-align:center;"
|-
!colspan="32"| Link State Advertisement Header
|-
!style="width:3.125%"| 0
!style="width:3.125%"| 1
!style="width:3.125%"| 2
!style="width:3.125%"| 3
!style="width:3.125%"| 4
!style="width:3.125%"| 5
!style="width:3.125%"| 6
!style="width:3.125%"| 7
!style="width:3.125%"| 8
!style="width:3.125%"| 9
!style="width:3.125%"| 10
!style="width:3.125%"| 11
!style="width:3.125%"| 12
!style="width:3.125%"| 13
!style="width:3.125%"| 14
!style="width:3.125%"| 15
!style="width:3.125%"| 16
!style="width:3.125%"| 17
!style="width:3.125%"| 18
!style="width:3.125%"| 19
!style="width:3.125%"| 20
!style="width:3.125%"| 21
!style="width:3.125%"| 22
!style="width:3.125%"| 23
!style="width:3.125%"| 24
!style="width:3.125%"| 25
!style="width:3.125%"| 26
!style="width:3.125%"| 27
!style="width:3.125%"| 28
!style="width:3.125%"| 29
!style="width:3.125%"| 30
!style="width:3.125%"| 31
|-
|colspan="16" style="background:#FFFF99"| '''LS Age'''
|colspan="8" style="background:#FFFF99"| '''Options'''
|colspan="8" style="background:#FFFF99"| '''LS Type'''
|-
|colspan="32" style="background:#FFFF99"| '''Link State ID'''
|-
|colspan="32" style="background:#FFFF99"| '''Advertising Router'''
|-
|colspan="32" style="background:#FFFF99"| '''LS Sequence Number'''
|-
|colspan="16" style="background:#FFFF99"| '''LS Checksum'''
|colspan="16" style="background:#FFFF99"| '''Length'''
|}

* Das '''LS Age'''-Feld wird in Sekunden angegeben und pro Hop um InfTransDelay erhöht. InfTransDelay nimmt Alterung von Link-State-Informationen vor mit dem Maß der Latenzzeit, die am Interface prognostiziert wird.
* '''LS Type''' gibt einen der 5 Typen an. Siehe Abschnitt ''Typen''.
* Die '''Link State ID''' nennt die Instanz, die von der LSA beschrieben wird. Siehe Abschnitt ''Link State ID''.
* '''Advertising Router''' enthält die Router ID des Routers, der die LSA aussendet.
* '''Checksum''' ist die Prüfsumme, bei deren Berechnung das LS Age Feld ausgelassen wird. Der Grund dafür ist, dass das LS Age Feld bei jedem Hop modifiziert wird.
* Das Feld '''Length''' gibt die Länge an, auch hier wird das LS Age Feld ausgelassen.

== Designated Router ==
{{Belege fehlen}}
'''Designated Router''' (deutsch: ernannter Router) wird optional in ''Open Shortest Path First'' verwendet, um die durch den Routing-Prozess erzeugte Netzlast in Broadcast-Netzen mit vielen OSPF-Routern zu verringern.

Um die Menge der zu übertragenden LSAs einzudämmen, wird in Netzwerken, die nicht aus isolierten Punkt-zu-Punkt-Verbindungen bestehen, ein Designated Router (DR) gewählt. Der DR ist verantwortlich dafür, die Aktualisierungsinformation innerhalb seines Netzwerksegmentes zu verteilen. Der DR steigt damit zum verwaltungsmäßigen Zentrum einer Area auf. Der Backup-Designated Router (BDR) nimmt die Rolle seines Stellvertreters ein.

Die Wahl eines Designated Routers erfolgt transparent. Entscheidungskriterium ist die höchste Router-Priorität, diese wird vom Hello-Protokoll bestimmt. Falls keine Router-Prioritäten konfiguriert wurden bzw. die Router-Prioritäten gleich sein sollten, wird anhand der Router-ID entschieden wer der Designated Router wird. Die Router-ID ist die Loopback-Adresse, ist eine solche nicht konfiguriert, wird die höchste konfigurierte IP-Adresse des Routers gewählt. In besonderen Fällen kann direkt Einfluss auf den Auswahlprozess genommen werden, indem eine Router-ID konfiguriert oder eine Loopback-Adresse als Ersatz erzeugt wird. Der Wahlprozess findet über den Austausch von Hello-Paketen statt. Fällt der DR aus, übernimmt der BDR fast nahtlos dessen Rolle, ohne erst einen erneuten Wahlvorgang eines DR zu initiieren. Dies geschieht selbst dann nicht, wenn zwischenzeitlich neue Router mit höherer IP-Adresse hinzugekommen sein sollten. Abschließend wird noch ein BDR gewählt.

== Protokoll ==

=== Hello-Protokoll ===

Das '''Hello-Protokoll''' ist in ''Open Shortest Path First'' für den Netzwerkbetrieb ein integraler Bestandteil des gesamten Routingprozesses. Es ist verantwortlich für:

* Senden von [[Keepalive]]s in bestimmten Intervallen (damit wird bestätigt, ob der Nachbar-Router noch funktioniert und seine Routen damit weiterhin Gültigkeit haben),
* Zur Entdeckung eines neu hinzugekommenen Nachbar-Router,
* Aushandlung der Parameter, wie Hello- und Dead-Timer-Intervalle,
* Wahl eines ''Designated Routers'' (DR) und des Backup-DRs.

Alle ankommenden Hello-Pakete werden auf die ''Area ID'' und anderen Parametern geprüft. Wenn diese mit den lokalen Einstellungen übereinstimmen, wird dieser Router als Nachbar eingetragen.

=== OSPF Version 2 ===

{| class="wikitable"
|-
!colspan="32"| OSPF Header
|-
!style="width:3.125%"| 0
!style="width:3.125%"| 1
!style="width:3.125%"| 2
!style="width:3.125%"| 3
!style="width:3.125%"| 4
!style="width:3.125%"| 5
!style="width:3.125%"| 6
!style="width:3.125%"| 7
!style="width:3.125%"| 8
!style="width:3.125%"| 9
!style="width:3.125%"| 10
!style="width:3.125%"| 11
!style="width:3.125%"| 12
!style="width:3.125%"| 13
!style="width:3.125%"| 14
!style="width:3.125%"| 15
!style="width:3.125%"| 16
!style="width:3.125%"| 17
!style="width:3.125%"| 18
!style="width:3.125%"| 19
!style="width:3.125%"| 20
!style="width:3.125%"| 21
!style="width:3.125%"| 22
!style="width:3.125%"| 23
!style="width:3.125%"| 24
!style="width:3.125%"| 25
!style="width:3.125%"| 26
!style="width:3.125%"| 27
!style="width:3.125%"| 28
!style="width:3.125%"| 29
!style="width:3.125%"| 30
!style="width:3.125%"| 31
|-
!colspan="8" style="background:#FFFF99"| Version
!colspan="8" style="background:#FFFF99"| Type
!colspan="16" style="background:#FFFF99"| Length
|-
!colspan="32" style="background:#FFFF99"| Router ID
|-
!colspan="32" style="background:#FFFF99"| Area ID
|-
!colspan="16" style="background:#FFFF99"| Checksum
|colspan="16" style="text-align: center" style="background:#FFFF99; text-align:center"| AuType
|-
|colspan="32" style="background:#FFFF99; text-align:center"| Authentication
|-
|colspan="32" style="background:#00EEEE; text-align:center"| Data
|}

* Die Größe des ''Version''-Felds beträgt 8 Bit.
* Die Größe des ''Typ''-Felds beträgt 8 Bit.

{| class="wikitable" style="margin-left:3em"
|-
! Typ
! Beschreibung
! Referenz
|-
| 1 || Hello || <nowiki>RFC 2328</nowiki>,<ref name="RFC2328" /> <nowiki>RFC 5340</nowiki>
|-
| 2 || Database description || <nowiki>RFC 2328</nowiki>,<ref name="RFC2328" /> <nowiki>RFC 5340</nowiki>
|-
| 3 || Link state request || <nowiki>RFC 2328</nowiki>,<ref name="RFC2328" /> <nowiki>RFC 5340</nowiki>
|-
| 4 || Link state update || <nowiki>RFC 2328</nowiki>,<ref name="RFC2328" /> <nowiki>RFC 5340</nowiki>
|-
| 5 || Link state acknowledgment || <nowiki>RFC 2328</nowiki>,<ref name="RFC2328" /> <nowiki>RFC 5340</nowiki>
|}

* Die Größe des ''Length''-Feldes beträgt 16 Bit. Es enthält die Gesamtpaketlänge.
* Die Größe des Feldes ''Router ID'' beträgt 32 Bit.
* Die Größe des Feldes ''Area ID'' beträgt 32 Bit.
* Die Größe des ''Checksum''-Feldes beträgt 16 Bit. Es enthält die Standard [[Internet Protocol|IP]]-Prüfsumme.
* Die Größe des Felds ''AuType'' (Authentifikations-Typ) beträgt 16 Bit.

{| class="wikitable" style="margin-left:3em"
|-
! Authentication type
! Beschreibung
! Referenz
|-
| 0 || None || <nowiki>RFC 2328</nowiki><ref name="RFC2328" />
|-
| 1 || Simple password authentication || <nowiki>RFC 2328</nowiki><ref name="RFC2328" />
|-
| 2 || Cryptographic authentication || <nowiki>RFC 2328</nowiki><ref name="RFC2328" />
|-
| 3 bis 65535 || Reserved ||
|}

* Die Größe des Felds ''Authentication'' beträgt 64 Bit.

=== OSPF Version 3 ===
{| class="wikitable"
|-
! colspan="32"| OSPF Header Version 3
|-
! style="width:3.125%"| 0
! style="width:3.125%"| 1
! style="width:3.125%"| 2
! style="width:3.125%"| 3
! style="width:3.125%"| 4
! style="width:3.125%"| 5
! style="width:3.125%"| 6
! style="width:3.125%"| 7
! style="width:3.125%"| 8
! style="width:3.125%"| 9
! style="width:3.125%"| 10
! style="width:3.125%"| 11
! style="width:3.125%"| 12
! style="width:3.125%"| 13
! style="width:3.125%"| 14
! style="width:3.125%"| 15
! style="width:3.125%"| 16
! style="width:3.125%"| 17
! style="width:3.125%"| 18
! style="width:3.125%"| 19
! style="width:3.125%"| 20
! style="width:3.125%"| 21
! style="width:3.125%"| 22
! style="width:3.125%"| 23
! style="width:3.125%"| 24
! style="width:3.125%"| 25
! style="width:3.125%"| 26
! style="width:3.125%"| 27
! style="width:3.125%"| 28
! style="width:3.125%"| 29
! style="width:3.125%"| 30
! style="width:3.125%"| 31
|-
! colspan="8" style="background:#FFCC99"| Version (Version)
! colspan="8" style="background:#FFFF99"| Type (Typ)
! colspan="16" style="background:#FFFF99"| Length (Länge)
|-
! colspan="32" style="background:#FFFF99"| Router ID (Routerbezeichner)
|-
! colspan="32" style="background:#FFFF99"| Area ID (Bereichsbezeichner)
|-
! colspan="16" style="background:#FFFF99"| Checksum (Prüfsumme)
! colspan="8" style="background:#FFFF99"| Instance ID (Instanzbezeichner)
! colspan="8" style="background:#FFCC99"| Reserved (reserviert)
|-
! colspan="32" style="background:#00EEEE"| Data (Daten)
|}

* Die Version 3 des OSPF ist für [[IPv6]] vorgesehen und in <nowiki>RFC 5340</nowiki> definiert.<ref name="RFC5340" />
* Die ''Instance ID'' (Instanzbezeichner) beträgt 8 Bit.
* ''Reserved'' (reserviert) beträgt 8 Bit.

=== Unterschiede zwischen OSPFv2 und OSPFv3 ===

Die Protokolldefinition von OSPFv3 führte, neben der Erweiterung um IPv6-Funktionalität, einige Unterschiede zu OSPFv2 ein. Die Unterschiede werden im Folgenden aufgelistet:

* Die Bezeichnung „subnet“ wurde durch „link“ ersetzt. Hintergrund ist die Definition eines Interfaces. In OSPFv2 wird ein Interface als ein Subnetz betrachtet, dies führt dazu, dass auf einem Interface nur eine Nachbarschaftsbeziehung in einem Subnetz erfolgen kann. Allerdings kann ein Interface auch mehrere Subnetze enthalten und sehr wohl über diese Nachbarschaftsbeziehung aufbauen wollen. Diese Umdefinition behebt den Umstand und erhöht die Möglichkeiten zur Nachbarschaftsbildung.
* Nachbarschaftserkennung anhand der Router-ID. In OSPFv2 werden Nachbarn, auf NBMA-Links, über die Interface-Adressen erkannt. Bei Point-to-Point-Links werden die Nachbarn über die Router-ID identifiziert. Dieser Unterschied wird in OSPFv3 aufgehoben, und sämtliche Nachbarn werden über die Router-ID identifiziert.
* Authentifizierung entfernt. In OSPFv2 wird im Header eine Authentifizierung durchgeführt. Diese wurde in OSPFv3 vollständig entfernt. Die Funktion wird nun durch den ''IPv6 Authentication Header'' ersetzt (Funktion verschoben auf unteren Layer).
* Weiterleitung von unbekannten LSA-Typen. In OSPFv2 werden unbekannte LSA-Typen gelöscht und nicht weiter verbreitet. OSPFv3-Implementierungen sollen auch unbekannte LSA-Typen weiterleiten.

== Freie Software-Implementierungen ==
* [[Quagga (Software)|Quagga]] (Weiterentwicklung von GNU Zebra)
* [[Bird Internet Routing Daemon|BIRD]] (Opensource-Implementierung eines IPv4- und IPv6-fähigen TCP/IP-Routing-Daemons)
* [[EXtensible Open Router Platform|XORP]] (eXtensible Open Router Platform)
* [[OpenOSPFD]] (Unix-Systemdienst) {{man|8|ospfd|OpenBSD}}
* [https://frrouting.org/ FRRouting Project] (Internet Routing Protokollsammlung für Linux und Unix)

== Siehe auch ==
* [[Interior Gateway Protocol|Interior Gateway Protokoll]] (IGP)
* [[Exterior-Gateway-Protokoll]] (EGP)
* [[Autonomes System|Autonome Systeme]] (AS)
* [[Shortest Path Bridging]] (SPB)
* [[IS-IS|Intermediate System to Intermediate System Protocol]] (IS-IS)
* [[Dijkstra-Algorithmus]]

== Literatur ==
* Wolfgang Schulte: ''Handbuch der Routing Protokolle der Netze''. SVH Verlag, 2009, ISBN 978-3-8381-1066-0.
* John T. Moy: ''OSPF: Anatomy of an Internet Routing Protocol''. Addison-Wesley Longman Verlag, 1998, ISBN 0-201-63472-4.

== Weblinks ==
* {{RFC-Internet |RFC=5187 |Titel=OSPF Version 3 Graceful Restart |Datum=2008-05}}
* {{RFC-Internet |RFC=2740 |Titel=OSPF Version 3 |Datum=1999-12 |Updated=5340}}
* {{RFC-Internet |RFC=2370 |Titel=OSPF Opaque LSA Option |Datum=1998-07}}
* {{RFC-Internet |RFC=2328 |Titel=OSPF Version 2 |Datum=1998-04 |Obsoletes=2178 |Errata=1 |Kommentar=zuerst: RFC [[RFC:1247|1247]] von 1991}}
* {{RFC-Internet |RFC=1850 |Titel=OSPF Version 2 MIB |Datum=1995-11}}
* {{RFC-Internet |RFC=1793 |Titel=Extending OSPF to Support Demand Circuits |Datum=1995-04}}
* {{RFC-Internet |RFC=1587 |Titel=OSPF NSSA Option |Datum=1994-03}}
* {{RFC-Internet |RFC=1253 |Titel=OSPF Version 2 MIB |Datum=1991-08 |Updated=1850}}
* {{RFC-Internet |RFC=1247 |Titel=OSPF Version 2 |Datum=1991-07 |Updated=2370}}
* {{RFC-Internet |RFC=1131 |Titel=OSPF Version 2 |Datum=1982-12 |Updated=1247}}
* [http://www.welzl.at/research/tools/irvtool/ irvtool – Ein RIP/OSPF Visualisierungstool] (Java/GPL)
* [http://www.ospf.org/ OSPF-C++-Quellcode]
* [http://www.quagga.net/ Freie Implementation gängiger Routingprotokolle], unter anderem auch OSPF
* [https://www.openbgpd.org/ BGP und OSPF sicher implementiert]

== Einzelnachweise ==
<references>
<ref name="RFC2328">
{{RFC-Internet |RFC=2328 |Titel=OSPF Version 2 |Datum=1998-04 |Obsoletes=2178 |Errata=1 |Kommentar=zuerst: RFC [[RFC:1247|1247]] von 1991}}
</ref>
<ref name="RFC5340">
{{RFC-Internet |RFC=5340 |Titel=OSPF for IPv6 |Datum=2008-07}}
</ref>
</references>

[[Kategorie:Netzwerkprotokoll]]
[[Kategorie:Routingprotokoll]]

Open Shortest Path First - Versionsgeschichte

imported>Felicior: /* Freie Software-Implementierungen */ Ip -> IP