OSPF (Open Shortest Path First) mit FRR unter Debian

Einführung in OSPF und FRR

Open Shortest Path First (OSPF) ist ein weit verbreitetes Link-State-Routingprotokoll, das in vielen Unternehmensnetzwerken und Rechenzentrumsumgebungen eingesetzt wird. OSPF basiert auf dem Shortest-Path-First-Algorithmus von Dijkstra und ermöglicht es Routern, Topologiedatenbankeinträge (Link-State-Advertisement, LSA) auszutauschen, um die kürzesten Pfade zu allen bekannten Zielen zu berechnen. Im Gegensatz zu Distanzvektor-Protokollen (z. B. RIP) hat OSPF den Vorteil des schnellen Konvergens und der effizienten Nutzung von Bandbreite, da nur Änderungen und nicht der gesamte Routingtisch übertragen werden.

FRRouting (FRR) ist eine Open-Source-Routing-Suite, die auf verschiedenen Linux-Distributionen, einschließlich Debian, installiert werden kann. FRR bietet eine vollständige Implementierung von OSPFv2 (für IPv4) und OSPFv3 (für IPv6) sowie weiterer Protokolle wie BGP, RIP und IS-IS. Durch die Kombination von Debian mit FRR lassen sich robuste, flexible und kosteneffiziente Routing-Instanzen auf Standard-Hardware einrichten. In diesem Artikel werden wir uns detailliert mit verschiedenen OSPF-Konfigurationsvarianten auf Basis von FRR unter Debian beschäftigen und anhand von Beispielen demonstrieren, wie man typische Anforderungen in Netzwerken realisiert.

Grundlegender Ablauf: Installation von FRR auf Debian

Paket-Repository hinzufügen

Bevor man FRR installiert, sollte man sicherstellen, dass das richtige Paket-Repository in den /etc/apt/sources.list.d/-Verzeichnissen hinterlegt ist. Das offizielle FRR-Team stellt für Debian stabile Pakete bereit. Fügen Sie dazu eine neue Datei namens frr.list an:

echo "deb https://deb.frrouting.org/frr $(lsb_release -s -c) frr-stable" | sudo tee /etc/apt/sources.list.d/frr.list
curl -s https://deb.frrouting.org/frr/keys.asc | sudo apt-key add -

Anschließend aktualisieren Sie die Paketlisten:

sudo apt update

FRR-Pakete installieren

Installieren Sie die FRR-Basispakete inklusive OSPF-Unterstützung:

sudo apt install frr frr-pythontools

Das Paket frr enthält die wichtigsten Routing-Daemons, darunter ospfd für OSPFv2 und ospf6d für OSPFv3. Das Paket frr-pythontools liefert nützliche Skripte zum Auslesen von Datenbanken und Logdateien.

FRR-Dienst aktivieren

Nach der Installation muss FRR als Systemdienst aktiviert werden:

sudo systemctl enable frr
sudo systemctl start frr

Überprüfen Sie den Status:

sudo systemctl status frr

Wenn der Dienst läuft, können Sie über vtysh eine Verbindung zur FRR-VTY-Shell herstellen, um Konfigurationen vor- und rückzuverarbeiten.

Verzeichnisstruktur und grundlegende Konfigurationsdateien

FRR verwendet standardmäßig das Verzeichnis /etc/frr/, in dem Sie verschiedene Konfigurationsdateien finden:

• /etc/frr/frr.conf: Hauptkonfigurationsdatei, die alle Protokolle und globale Einstellungen zusammenfasst.
• /etc/frr/daemons: Datei, in der festgelegt wird, welche Daemons aktiv sind (z. B. ospfd, bgpd, etc.).
• /etc/frr/ospfd.conf: Separate Datei für OSPFv2-spezifische Einstellungen.
• /etc/frr/ospf6d.conf: Separate Datei für OSPFv3-spezifische Einstellungen (IPv6).

In vielen Fällen reicht es aus, die frr.conf zu bearbeiten. Alternativ kann man OSPF-Konfigurationen in ospfd.conf auslagern und in frr.conf einen Verweis hinterlegen.

Beispiel für /etc/frr/daemons (Auszug):

...
ospfd=yes
ospf6d=no
...

Damit wird nur OSPFv2 aktiviert und OSPFv3 deaktiviert. Möchten Sie später IPv6-OSPF nutzen, setzen Sie ospf6d=yes und starten FRR neu.

Grundlegende OSPF-Konfiguration (Single-Area)

Topologie-Szenario

Im einfachsten Fall betreiben wir ein kleines Netzwerk mit mehreren Debian-Servern, die in Area 0 (Backbone) interagieren. Jede Maschine verwendet FRR, um OSPFv2 zu sprechen und Routen auszutauschen.

Beispielnetz (IPv4):

• Server A: IP 10.0.1.1/24 (Interface eth0)
• Server B: IP 10.0.2.1/24 (Interface eth0)
• Server C: IP 10.0.3.1/24 (Interface eth0)
• Jeder Server hat zusätzlich ein Loopback-Interface mit /32, z. B. 10.100.0.1, 10.100.0.2, 10.100.0.3.

Alle drei Server sind direkt über einen Layer-2-Switch verbunden. Wir möchten, dass die Maschine A die Loops von B und C kennt, und umgekehrt.

Beispielkonfiguration für Server A

! /etc/frr/frr.conf
service advanced-vty
!
hostname serverA
password zebra
enable password zebra
!
router ospf
 ospf router-id 10.100.0.1
 network 10.0.1.0/24 area 0
 network 10.100.0.1/32 area 0
!
line vty
!

Erklärung:

• ospf router-id 10.100.0.1: Legt die Router-ID fest (meist das Loopback /32).
• network 10.0.1.0/24 area 0: Dieser Eintrag bewirkt, dass alle IPs im Subnetz 10.0.1.0/24 über dieses Interface in Area 0 teilnehmen.
• network 10.100.0.1/32 area 0: Nehmen Sie die Loopback-Adresse explizit in OSPF auf, damit sie von anderen Routern als erreichbares Ziel propagiert wird.

Beispielkonfiguration für Server B und C

Die Konfiguration ist analog, nur dass sich IPs, Netzwerke und Router-IDs unterscheiden:

! /etc/frr/frr.conf für Server B
service advanced-vty
!
hostname serverB
password zebra
enable password zebra
!
router ospf
 ospf router-id 10.100.0.2
 network 10.0.2.0/24 area 0
 network 10.100.0.2/32 area 0
!
line vty

! /etc/frr/frr.conf für Server C
service advanced-vty
!
hostname serverC
password zebra
enable password zebra
!
router ospf
 ospf router-id 10.100.0.3
 network 10.0.3.0/24 area 0
 network 10.100.0.3/32 area 0
!
line vty

Nachdem Sie die Dateien gespeichert haben, starten Sie FRR neu (sudo systemctl restart frr). Anschließend sollte auf jedem Server über vtysh die OSPF-Nachbarschaftsanzeige zeigen, dass alle drei Router miteinander in Area 0 verknüpft sind:

vtysh# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.100.0.2       1    FULL/DR        00:00:32    10.0.2.1        eth0
10.100.0.3       1    FULL/DR        00:00:32    10.0.3.1        eth0

Das Ergebnis zeigt, dass Server A Nachbarn in Area 0 von Server B und C erkannt hat. Analog verhält es sich auf den anderen Servern.

Netzwerktypen in OSPF und FRR-Konfiguration

OSPF unterstützt verschiedene Netzwerktypen, die beeinflussen, wie Router Nachbarschaften bilden und wie LSAs übertragen werden. Die wichtigsten Typen sind:

• Broadcast (z. B. Ethernet): Router erkennen automatisch DR (Designated Router) und BDR (Backup Designated Router).
• Point-to-Point (z. B. serielles Link): Keine DR/BDR-Wahl, da es nur zwei Endpunkte gibt.
• NBMA (Non-Broadcast Multiple Access): z. B. Frame-Relay, bei dem ein DR/BDR gewählt werden muss, obwohl kein Broadcast stattfindet.
• Point-to-Multipoint: Jeder OSPFv2-Router verhält sich wie ein Punkt-zu-Punkt-Link. Keine DR/BDR-Wahl.

FRR erkennt standardmäßig bei Ethernet-Interfaces den Broadcast-Modus. Möchten Sie einen anderen Modus erzwingen, können Sie das in der OSPF-Konfiguration tun:

router ospf
 network 192.168.10.0/24 area 0
 passive-interface eth1
 passive-interface eth2
!
interface eth1
 ip ospf network point-to-point
!
interface eth2
 ip ospf network point-to-multipoint
!

In diesem Beispiel:

• passive-interface deaktiviert den aktiven OSPF-Teilnehmerprozess auf dem Interface (es wird keine Nachbarschaft gebildet).
• Innerhalb eines interface eth1-Blocks wird der Netzwerktyp auf point-to-point gesetzt.
• In interface eth2 wird point-to-multipoint eingestellt.

Damit können Sie dedizierte OSPF-Nachbarschaften je nach physikalischem oder virtuellen Netzwerktyp einrichten und optimieren.

Multi-Area OSPF: Area-Design und FRR-Implementierung

Warum mehrere Areas?

In größeren Netzwerken verteilt man die OSPF-Domäne in mehrere Areas, um:

• Routing-Tabelle überschaubar zu halten.
• SPF-Berechnungen auf bestimmte Teile zu beschränken.
• LSDB-Updates innerhalb einer Area zu halten und somit Broadcast-Domänen einzugrenzen.

Jede Area muss eine Verbindung zur Backbone-Area 0 haben. Ist eine direkte Verbindung physikalisch nicht möglich, nutzt man einen virtuellen Link.

Beispielszenario: Drei Standorte

Stellen Sie sich vor, Sie haben drei Standorte A, B und C. Standort A bildet Area 0, Standort B und C sollen jeweils eigene Areas B (Area 1) und C (Area 2) haben. Standort B und C sind jedoch nur über WAN-Verbindungen mit A verbunden.

Vereinfachte IP-Adressen:

• Site A (Backbone): Router A1 – Loopback 10.1.1.1/32
• Site B: Router B1 – Loopback 10.1.2.1/32, WAN-Verbindung zu A1 (192.168.100.0/30)
• Site C: Router C1 – Loopback 10.1.3.1/32, WAN-Verbindung zu A1 (192.168.101.0/30)

OSPF-Konfiguration für Router A1 (Site A)

! /etc/frr/frr.conf bei A1
service advanced-vty
!
hostname siteA
password zebra
enable password zebra
!
router ospf
 ospf router-id 10.1.1.1
 network 10.1.1.1/32 area 0
 network 192.168.100.0/30 area 0
 network 192.168.101.0/30 area 0
!
line vty

Hier werden die Loopback-Adresse und die beiden WAN-Netze in Area 0 aufgenommen.

OSPF-Konfiguration für Router B1 (Site B)

! /etc/frr/frr.conf bei B1
service advanced-vty
!
hostname siteB
password zebra
enable password zebra
!
router ospf
 ospf router-id 10.1.2.1
 network 10.1.2.1/32 area 1
 network 192.168.100.0/30 area 0
!
line vty

Wichtig: Das Loopback-Interface wird in Area 1 eingetragen, das WAN-Netz jedoch in Area 0, da B1 eine Area-Grenze (ABR) darstellt.

OSPF-Konfiguration für Router C1 (Site C)

! /etc/frr/frr.conf bei C1
service advanced-vty
!
hostname siteC
password zebra
enable password zebra
!
router ospf
 ospf router-id 10.1.3.1
 network 10.1.3.1/32 area 2
 network 192.168.101.0/30 area 0
!
line vty

Analog bildet C1 die Area 2 und verbindet Area 2 über das WAN-Netz nach Area 0.

Virtueller Link (Optional)

Falls Site B und C nur indirekt via A1 kommunizieren, ist kein virtueller Link nötig. Ein virtueller Link kommt zum Einsatz, wenn z. B. zwei Areas (1 und 2) sich nicht direkt an Area 0 “angrenzen” können. In unserem Szenario sind jedoch alle Standorte direkt per WAN mit A1 verbunden, sodass Area 1 und Area 2 jeweils eine direkte Area-0-Verbindung haben.

Ein Beispiel für einen virtuellen Link (wenn nötig):

router ospf
 area 1 virtual-link 10.1.1.1

Dieser Befehl müsste auf dem ABR in Area 1 gesetzt werden, um mit der Backbone-Router-ID (10.1.1.1) einen virtuellen Link herzustellen. Danach würde man auf dem anderen ABR in Area 2 analog konfigurieren.

Area-Typen: Stub, Totally Stubby und NSSA

Warum spezielle Area-Typen?

In einigen Szenarien möchte man das Flooding von externen Routen (LSA Typ 5/7) einschränken oder die Routing-Tabelle in einer Area sehr klein halten, z. B. in Zweigstellen mit begrenztem Speicher. OSPF unterstützt dafür mehrere Area-Typen:

• Standard Area: Alle LSA-Typen werden weitergegeben (Typ 1 bis 5 inkl. Typ 7 für NSSA).
• Stub Area: Externe Routen (LSA Typ 5) werden nicht weitergegeben. ASBR-Einträge (LSA Typ 5) werden durch eine Default-Route ersetzt.
• Totally Stubby Area: Wie Stub Area, aber auch Inter-Area-Routen (LSA Typ 3 und 4) werden nicht weitergegeben, außer als Default-Route.
• NSSA (Not-So-Stubby Area): Ähnlich einer Stub Area, erlaubt jedoch das Importieren externer Routen als LSA Typ 7. LSA 7 werden später in Area 0 in LSA 5 umgewandelt.

Konfiguration einer Stub Area in FRR

Gehen wir davon aus, dass Site D (mit Router D1) eine Zweigstelle ist und wir sie als Stub Area in Area 3 einrichten wollen. Site D ist über das Netz 192.168.200.0/30 mit einem ABR E1 verbunden, der in Area 3 sitzt.

Konfiguration auf E1 (ABR zwischen Area 0 und Area 3):

! /etc/frr/frr.conf bei E1
service advanced-vty
!
hostname ABR-E1
password zebra
enable password zebra
!
router ospf
 ospf router-id 10.2.0.1
 network 10.2.0.1/32 area 3
 network 192.168.200.0/30 area 3
 network 10.0.0.0/24 area 0
 area 3 stub
!
line vty

Erklärung:

• area 3 stub: Kennzeichnet Area 3 als Stub Area. E1 wird nun alle LSA 5-Einträge unterdrücken, die in Area 3 weitergeleitet werden.

Konfiguration auf D1 (Site D, Mitglied von Area 3):

! /etc/frr/frr.conf bei D1
service advanced-vty
!
hostname SiteD
password zebra
enable password zebra
!
router ospf
 ospf router-id 10.2.0.2
 network 10.2.0.2/32 area 3
 network 192.168.200.0/30 area 3
 area 3 stub
!
line vty

In beiden Fällen wird die Area 3 als Stub deklariert. D1 und E1 tauschen innerhalb Area 3 LSAs vom Typ 1/2 aus, jedoch keine Typ 5. E1 gibt zwar externe Routen aus Area 0 intern in Area 3 weiter, aber nur als Default-Route (0.0.0.0/0).

Konfiguration einer Totally Stubby Area

Eine Totally Stubby Area ist noch restriktiver und unterbindet zusätzlich das Propagieren von Inter-Area-Routen (LSA Typ 3/4). Nur eine Default-Route wird akzeptiert.

Auf dem ABR (E1) würde es so aussehen:

! /etc/frr/frr.conf bei ABR-E1
service advanced-vty
!
hostname ABR-E1
password zebra
enable password zebra
!
router ospf
 ospf router-id 10.2.0.1
 network 10.2.0.1/32 area 3
 network 192.168.200.0/30 area 3
 network 10.0.0.0/24 area 0
 area 3 stub no-summary
!
line vty

Option no-summary markiert Area 3 als Totally Stubby Area. Die Zweigstellenrouter in Area 3 empfangen nur eine einzige Default-Route und keine Netzwerke anderer Areas. Diese Konfiguration ist sinnvoll, wenn an diesem Standort ausschließlich Internet-Routing aus dem Backbone benötigt wird und interne Präfixe nicht lokal relevant sind.

Konfiguration einer NSSA (Not-So-Stubby Area)

NSSA erlaubt die Reklame interner externer Präfixe (z. B. statische Routen oder externe BGP-Netze) in Form von LSA Typ 7. Der ABR wandelt LSA 7 in LSA 5 um und leitet sie in andere Areas weiter.

Beispiel: Site F (Router F1) möchte lokale statische Routen als externe Routen verteilen, aber die Area soll ansonsten stubartig sein.

Konfiguration auf ABR (E1):

! /etc/frr/frr.conf bei ABR-E1
service advanced-vty
!
hostname ABR-E1
password zebra
enable password zebra
!
router ospf
 ospf router-id 10.2.0.1
 network 10.2.0.1/32 area 4
 network 192.168.300.0/30 area 4
 area 4 nssa no-redistribution
!
line vty

Konfiguration auf F1 (Site F, Mitglied von Area 4):

! /etc/frr/frr.conf bei F1
service advanced-vty
!
hostname SiteF
password zebra
enable password zebra
!
router ospf
 ospf router-id 10.2.0.2
 network 10.2.0.2/32 area 4
 network 192.168.300.0/30 area 4
 area 4 nssa
 redistribute static metric 100 subnets
!
ip route 172.16.100.0/24 Null0
!
line vty

Erklärung:

• area 4 nssa: Kennzeichnet Area 4 als NSSA.
• redistribute static metric 100 subnets: Verteilt lokale statische Routen als LSA Typ 7 mit Metrik 100.
• ip route 172.16.100.0/24 Null0: Beispiel für eine lokale statische Route, die als LSA 7 verteilt wird.
• no-redistribution auf dem ABR verhindert, dass externe Routen von außerhalb in die NSSA übernommen werden.

Der ABR wandelt in Area 0 empfangene LSA 7 intern in LSA 5 um. Somit sind die externen Routen für alle Router in anderen Areas sichtbar.

OSPF-Authentifizierung: Plain Text und MD5

Um die Sicherheit zu erhöhen und unautorisierte Router von OSPF auszuschließen, bietet OSPF verschiedene Authentifizierungsmechanismen:

• Kein Authentifizierung (Standardmodus): Jeder Router, der das gleiche Area-Passwort verwendet, kann Nachbarschaften bilden.
• Plain Text Authentifizierung: Router übertragen das Passwort im Klartext mit jeder OSPF-Nachricht.
• MD5-Authentifizierung: Router generieren eine MD5-Checksumme aus Passwort und Inhalt, sodass das Passwort im Klartext nie über das Netz geht.

Plain Text Authentifizierung in FRR

Um Plain Text Authentifizierung auf einem Interface eth0 zu aktivieren:

router ospf
 network 10.0.1.0/24 area 0
 network 10.100.0.1/32 area 0
!
interface eth0
 ip ospf authentication
 ip ospf authentication-key MeinKlarsichtPasswort

Starte FRR neu oder wende die Konfiguration in vtysh an. Alle Router auf demselben Netzsegment müssen denselben Klartext-Schlüssel haben, um OSPF-Nachbarn zu werden.

MD5-Authentifizierung in FRR

MD5 ist aufgrund der kryptografischen Sicherheit, die es bietet, die bevorzugte Methode. Beispiel für MD5 auf eth0:

router ospf
 network 10.0.1.0/24 area 0
 network 10.100.0.1/32 area 0
!
interface eth0
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 SehrSicheresMD5Passwort

Erklärung:

• ip ospf authentication message-digest: Aktiviert MD5-Authentifizierung auf dem Interface.
• ip ospf message-digest-key 1 md5 SehrSicheresMD5Passwort: Legt den Schlüssel mit Key-ID 1 fest; der glückliche Befehl md5 zeigt an, dass MD5-Checksumme benutzt wird.

Alle Router im gleichen Segment müssen denselben MD5-Schlüssel verwenden. Andernfalls werden sie sich nicht gegenseitig als OSPF-Nachbarn akzeptieren.

Routen-Redistribution und Metrik-Anpassung

In vielen Netzwerken ist es notwendig, Routen aus anderen Quellen (statisch, BGP, Connected) in OSPF zu verteilen oder umgekehrt. FRR macht dies über die redistribute-Direktive möglich.

Statische Routen in OSPF einfügen

Angenommen, Sie haben eine statische Route auf dem Router, z. B.:

ip route 203.0.113.0/24 Null0

Um diese als externe OSPF-Routen zu verteilen:

router ospf
 redistribute static metric 20 subnets

Erklärung:

• metric 20: Setzt die externe Kosten (Costs) auf 20.
• subnets: Sorgt dafür, dass alle Subnetze verteilt werden (nicht nur Klassen-Netze).

FRR verteilt nun das Präfix 203.0.113.0/24 als LSA Typ 5 in der OSPF-Domäne.

BGP-Routen nach OSPF redistributieren

Wenn FRR sowohl BGP als auch OSPF spricht, können Sie BGP-Routen in OSPF verteilen:

router bgp 65000
 neighbor 198.51.100.1 remote-as 65001
 !
 address-family ipv4 unicast
  network 192.0.2.0/24
  neighbor 198.51.100.1 activate
 exit-address-family
!
router ospf
 redistribute bgp metric 30 subnets

Die Routen, die von BGP empfangen wurden, werden als externe OSPF-Routen (LSA Typ 5) verteilt. Durch metric 30 werden die Kosten festgelegt.

OSPF nach BGP redistributieren

In Szenarien, in denen Sie OSPF-Routen in ein externes BGP-Netzwerk veröffentlichen wollen, konfigurieren Sie:

router ospf
 network 10.0.0.0/8 area 0
!
router bgp 65000
 neighbor 203.0.113.1 remote-as 65002
 !
 address-family ipv4 unicast
  redistribute ospf metric 100
  neighbor 203.0.113.1 activate
 exit-address-family

Nun werden OSPF-Präfixe in das BGP-Nachbar-AS verteilt. Die BGP-Metrik (oder local-preference) wird hier über metric 100 gesteuert.

Inter-Area-Redistribution und Filterung

Oft möchte man nicht alle internen Routen aus einer Area in eine andere verteilen. FRR unterstützt Route-Maps, um Routen selektiv zu filtern:

route-map FILTER-AREA permit 10
 match ip address prefix-list ONLY-10
!
ip prefix-list ONLY-10 seq 5 permit 10.0.0.0/8 le 24
!
router ospf
 area 1 filter-list prefix ONLY-10 in
 area 1 filter-list prefix ONLY-10 out

Damit werden in und aus Area 1 nur Routen mit Präfix 10.0.0.0/8 (mit Subnetzen bis /24) akzeptiert bzw. angekündigt.

OSPFv3 für IPv6 mit FRR auf Debian

Obwohl OSPFv2 (IPv4) häufiger anzutreffen ist, ist OSPFv3 für IPv6 in modernen Netzwerken unerlässlich. FRR beinhaltet den Daemon ospf6d, um OSPFv3-Funktionen bereitzustellen.

Aktivieren von OSPFv3 in /etc/frr/daemons

ospf6d=yes
ospfd=no
...

Stellen Sie sicher, dass OSPFv3 aktiviert ist und starten Sie FRR neu:

sudo systemctl restart frr

Beispielkonfiguration für OSPFv3

Wir nehmen ein einfaches IPv6-Netz 2001:db8:1::/64 an. Die Loopback-IPv6-Adresse ist 2001:db8:1::1/128.

! /etc/frr/ospf6d.conf
service advanced-vty
!
hostname server-ipv6
password zebra
enable password zebra
!
interface eth0
 ipv6 ospf6 hello-interval 10
 ipv6 ospf6 dead-interval 40
 ipv6 ospf6 mtu-ignore
 ipv6 ospf6 enable
!
router ospf6
 ospf6 router-id 1.1.1.1
 interface eth0 area 0
!
line vty

Hierbei:

• ipv6 ospf6 hello-interval 10: Setzt das Hello-Intervall auf 10 Sekunden.
• ipv6 ospf6 dead-interval 40: Setzt das Dead-Intervall auf 40 Sekunden (4×10 Sekunden).
• ipv6 ospf6 mtu-ignore: Ignoriert MTU-Differenzen, um Nachbarschaften bei unterschiedlichen MTUs zu erlauben.
• ospf6 router-id 1.1.1.1: OSPFv3-Router-ID, üblicherweise im IPv4-Format.

Nach dem Eintragen und Neustarten von FRR sollten IPv6-Nachbarn sichtbar sein:

vtysh# show ipv6 ospf6 neighbor
Neighbor ID           Pri State           Dead Time Address         Interface
1.1.1.2                1 FULL/POINT-TO-POINT 00:00:34 2001:db8:1::2 eth0

OSPF-Timer und Leistungsoptimierung

OSPF bietet verschiedene Timer, die angepasst werden können, um die Netzwerkkonvergenz zu optimieren. Standardwerte (Broadcast-Teilnetz) sind Hello-Intervall 10 Sekunden und Dead-Intervall 40 Sekunden. In Hochverfügbarkeitsumgebungen kann man diese verringern, um schnellere Nachbar-Timeouts zu erreichen:

interface eth0
 ip ospf hello-interval 2
 ip ospf dead-interval 6

Dadurch erzeugt jeder Router alle 2 Sekunden ein Hello-Paket, und ein Nachbar gilt nach 6 Sekunden als tot, wenn kein Hello empfangen wurde. Dies erhöht die Konvergenzgeschwindigkeit, erhöht jedoch die CPU-Last und Bandbreitennutzung für OSPF-Pakete.

SPF-Berechnungen beeinflussen

SPF-Berechnungen laufen standardmäßig, wenn die LSDB sich ändert. Auf hoch frequentierten Links oder in großen Netzen kann man via spf-delay und spf-priority steuern, wie oft und mit welcher Priorität SPF-Prozesse laufen:

router ospf
 spf-delay 100
 spf-priority 1

Dadurch wird ein SPF-Lauf um mindestens 100 ms verzögert, um mehrere Topologieänderungen zu bündeln. Die Priorität legt fest, dass dieser verzögerte SPF-Lauf weniger dringend behandelt wird.

LSA-Refresh-Intervalle

Standardmäßig werden LSAs alle 30 Minuten (1800 Sekunden) refresht. In stabilen Netzwerken kann man die Frequenz reduzieren, wenn die CPU-Belastung durch LSDB-Verarbeitung hoch ist:

router ospf
 lsa-refresh 3600

Dadurch werden LSAs nur alle 60 Minuten erneuert. Vorsicht: Höhere Intervalle können bei Netzwerkausfällen zu längeren Konvergenzzeiten führen.

OSPF auf VRF-Instanzen (VRF Lite) mit FRR

Virtual Routing and Forwarding (VRF) ermöglicht die Isolation mehrerer Routing-Instanzen auf demselben physischen Router. FRR unterstützt VRF-Lite, sodass OSPF für jede VRF separat betrieben werden kann.

VRF-Struktur in Debian/Linux

Zuerst erstellen wir eine VRF-Instanz:

sudo ip link add vrf-blue type vrf table 10
sudo ip link set dev vrf-blue up

Dem Interface, das zu dieser VRF gehören soll (z. B. eth1), weisen wir die VRF zu:

sudo ip link set dev eth1 master vrf-blue
sudo ip link set dev eth1 up

Danach kann man eth1 in die VRF-Instanz verschieben. Anschließend müssen IP-Adressen innerhalb der VRF konfiguriert werden:

sudo ip addr add 10.10.10.1/24 dev eth1

FRR-Konfiguration für OSPF in VRF

In FRR muss man VRF-Instanzen in der frr.conf definieren. Beispiel:

! /etc/frr/frr.conf
service advanced-vty
!
hostname vrf-router
password zebra
enable password zebra
!
vrf blue
 vni 10
 exit-vrf
!
router ospf vrf blue
 ospf router-id 10.10.10.1
 network 10.10.10.0/24 area 0
!
line vty

Erklärung:

• vrf blue: Definiert eine VRF-Instanz namens “blue”.
• router ospf vrf blue: Startet einen OSPF-Daemon innerhalb der VRF “blue”.
• ospf router-id und network sind innerhalb der VRF gültig.

Nachdem FRR neu gestartet wird (sudo systemctl restart frr), läuft OSPF isoliert in der VRF “blue” und bildet keine Nachbarschaften außerhalb der VRF.

Beschleunigte Konvergenz mit BFD (Bidirectional Forwarding Detection)

Bidirectional Forwarding Detection (BFD) ist ein Protokoll zur schnellen Erkennung von Link-Ausfällen. In Kombination mit OSPF kann BFD die Ausfalldetektion von Links drastisch beschleunigen, oft auf Millisekunden-Ebene.

BFD in FRR aktivieren

Stellen Sie sicher, dass FRR mit BFD-Unterstützung kompiliert wurde. Unter Debian ist dies in der Regel der Fall, wenn das Paket frr-bfd installiert ist. Aktivieren Sie den BFD-Daemon:

sudo apt install frr-bfd
sudo systemctl enable frr-bfd
sudo systemctl start frr-bfd

In FRR muss man BFD global aktivieren:

! /etc/frr/frr.conf
service advanced-vty
!
hostname bfd-router
password zebra
enable password zebra
!
bfd
 bfd template 1
  interval minimum 50 min_rx 50 multiplier 3
  exit
 exit-bfd
!
router ospf
 bfd all-interfaces
 ospf router-id 10.50.0.1
 network 10.50.1.0/24 area 0
!
line vty

Erklärung:

• bfd template 1: Definiert einen Template mit einem Hello-Intervall von 50 ms und einem Dead-Intervall von 150 ms (3 x 50 ms).
• bfd all-interfaces: Aktiviert BFD für alle in OSPF verwendeten Interfaces.

OSPF verwendet BFD nun, um Link-Ausfälle schneller zu erkennen, anstatt nur auf OSPF-Hellos zu warten.

Nachbarschaftsaufbau mit BFD überprüfen

Nach Restart von FRR und BFD kann man den Status abfragen:

vtysh# show bfd peers
Peer Addr    LD/LU  RH/RT  RDr/RDt  FD/FT  Intvl Rx  Intvl Tx  ToRx  ToTx
10.50.1.2     1/1    3/3    0/0      0/0    50        50        3     3   Gi1

Dies zeigt, dass BFD-Sitzungen mit dem Nachbarn aufgebaut wurden. Kombiniert mit show ip ospf neighbor kann man verifizieren, dass OSPF die BFD-Sitzung für Link-Ausfälle nutzt.

Monitoring und Troubleshooting von OSPF mit FRR

Eine funktionierende OSPF-Umgebung erfordert ständiges Monitoring und zuverlässiges Troubleshooting, um sicherzustellen, dass alle Nachbarschaften korrekt aufgebaut sind und keine Routing-Schleifen auftreten.

Wichtige vtysh-Befehle

• show ip ospf neighbor: Zeigt aktuelle OSPF-Nachbarn und deren Status (FULL, 2-Way, etc.).
• show ip ospf database: Listet sämtliche LSAs in der lokalen LSDB auf.
• show ip ospf interface: Zeigt OSPF-Parameter pro Interface an (Hello-Interval, Dead-Interval, Netzwerktyp, etc.).
• show ip route ospf: Listet Routen auf, die durch OSPF gelernt wurden.
• show ip ospf border-routers: Listet ABRs (Area Border Routers) und ASBRs (Autonomous System Border Routers) im OSPF-System.
• show log: Zeigt FRR-Logdateien an (standardmäßig in /var/log/frr/), um Fehler oder Warnungen zu finden.

Beispiel: Unerwartete Nachbarschaftsstati

Wenn ein Router “2-Way” anzeigt, bedeutet dies, dass die Nachbarschaft zwar teilweise aufgebaut wurde, aber kein FULL-Status erreicht wurde. Mögliche Ursachen:

• Unterschiedliche OSPF-Auth-Konfiguration (kein gemeinsamer Schlüssel).
• Unterschiedliche Hello-/Dead-Intervalle.
• MTU-Unterschiede, die das DBD-Paket (Database Descriptor Packet) verhindern.
• Unterschiedliche Area-Zuordnungen (z. B. Router in verschiedenen Areas).

Um MTU-Probleme zu beheben, können Sie ip ospf mtu-ignore auf dem Interface setzen, um MTU-Checks zu ignorieren und die Nachbarschaft trotzdem aufzubauen.

LSDB-Konsistenz überprüfen

Stellen Sie sicher, dass alle Router in einer Area dieselbe LSDB haben. Verwenden Sie:

vtysh# show ip ospf database summary

Vergleichen Sie die LSA-IDs und Checksum-Werte. Abweichungen deuten auf Synchronisierungsprobleme oder LSA-Flutungsfehler hin.

Routing-Schleifen erkennen

Routing-Schleifen können auftreten, wenn OSPF-Areas nicht korrekt zusammenhängen oder falsche Filtereinstellungen vorgenommen wurden. Überprüfen Sie mithilfe von show ip route und show ip ospf database, ob mehrere Pfade zum selben Ziel existieren und ob eine Root-Router-Existenz (Area 0-Verbindung) fehlen könnte. Achten Sie auch auf falsch konfigurierte virtuelle Links.

Log-Level erhöhen

Um detailliertere Informationen zu erhalten, können Sie das OSPF-Log-Level temporär erhöhen:

vtysh# configure terminal
vtysh(config)# log ospf events debugging
vtysh(config)# exit

Anschließend in /var/log/frr/frr.log nach Fehlermeldungen oder Anomalien suchen.

Praktische Anwendungsfälle und Best Practices

Campus-Netzwerk mit redundanten Pfaden

In einem Campus-Netzwerk sind mehrere demilitarisierte Zonen (DMZ), Serverräume und Access-Switches per OSPF miteinander verbunden, oft in mehreren Areas für unterschiedliche Gebäudebereiche. Best Practices:

• Backbone (Area 0) in jedem Core-Switch-Cluster realisieren.
• Jede Gebäudeetage in eigene Area, wenn die Topologie es erfordert.
• Redundante Links zwischen Area-Boundary-Routern (ABRs) bereitstellen.
• Spezielle Areas (Stub oder NSSA) für kleine Zweigstellen.

Ein Beispiel-Szenario:

1. Data Center: Area 0 mit mehreren Core-Routern.
2. Gebäude A: Area 1, verbunden mit Data Center über 10 Gbit-Link.
3. Gebäude B: Area 2, ebenfalls verbunden mit Data Center.
4. Zweigstelle C: Pfad via VPN, Area 3 stump, damit nur Default-Routen benötigt werden.

Die Konfiguration der ABRs in Data Center muss sorgfältig erfolgen, um Subnetzexporte zu steuern und Schleifen zu vermeiden.

Rechenzentrums-Leaf-Spine-Architektur

In modernen Rechenzentren nutzt man oft Leaf-Spine-Architekturen, bei denen Leaf-Switches OSPF in einer einzigen Area 0 sprechen. Spine-Switches fungieren als reine IRF-Aggregatoren. Best Practices:

• Verwenden Sie punkt-zu-punkt-Verbindungen zwischen Leafs und Spines, um DR/BDR-Wahl zu vermeiden.
• Aktivieren Sie ip ospf network point-to-point auf allen Interfaces.
• Verkürzen Sie Hello-Intervalle auf 1 Sekunde und Dead-Intervalle auf 3 Sekunden für schnellere Konvergenz.
• Nutzen Sie BFD, um Link-Ausfälle in wenigen Millisekunden zu erkennen.

Beispiel für Leaf-Switch-Konfiguration:

router ospf
 ospf router-id 10.10.10.10
 spf-delay 50
 bfd all-interfaces
!
interface eth1
 ip ospf network point-to-point
 ip ospf hello-interval 1
 ip ospf dead-interval 3
!
interface eth2
 ip ospf network point-to-point
 ip ospf hello-interval 1
 ip ospf dead-interval 3

Diese Konfiguration stellt sicher, dass alle Leafs sehr schnell auf Spine-Ausfälle reagieren.

Fehlervermeidung und Konsistenzprüfungen

Fehler in den OSPF-Konfigurationen führen häufig zu Netzwerkausfällen oder Subnetz-Isolationen. Achten Sie auf:

• Einheitliche Router-IDs (müssen eindeutig sein).
• Konsistente Area-IDs (z. B. nicht versehentlich zwei Router in unterschiedlichen Areas mit derselben Area-ID präsentieren).
• Passende Hello/Dead-Intervalle auf denselben Nachbarnetzsegmenten.
• MTU-Anpassungen, wenn Link-Technologie MTU-Unterschiede aufweist.
• Korrekte Authentifizierungsschlüssel, falls Sie sie verwenden.

Führen Sie regelmäßig show ip ospf interface aus, um sicherzustellen, dass alle Einstellungen korrekt übernommen wurden.

Zusammenfassung

In diesem umfassenden Artikel haben wir die Grundlagen und fortgeschrittenen Konzepte von OSPF mit FRR unter Debian beschrieben. Wir begannen mit der Installation von FRR, führten in die Verzeichnisstruktur und grundlegenden Konfigurationsdateien ein und zeigten anhand eines Single-Area-Beispiels, wie man OSPF-Grundkonfigurationen anlegt. Darauf aufbauend untersuchten wir verschiedene OSPF-Netzwerktypen, die Notwendigkeit von Multi-Area-Design, virtuelle Links, sowie spezielle Area-Typen wie Stub, Totally Stubby und NSSA.

Wir haben uns zudem mit Authentifizierungsmechanismen (Plain Text und MD5), der Redistribution von Routen (statisch, BGP) und Metrik-Anpassungen beschäftigt. OSPFv3 für IPv6, VRF-Implementierungen, BFD-Integration für schnelle Konvergenz sowie Monitoring- und Troubleshooting-Werkzeuge wurden ausführlich erläutert. Abschließend gaben wir praktische Anwendungsbeispiele und Best Practices für Campus-Netzwerke und Leaf-Spine-Architekturen in Rechenzentren.

Mit diesen Fähigkeiten können Netzwerkadministratoren robuste, skalierbare und performante OSPF-basierte Netzwerke auf Debian-Plattformen mit FRR realisieren. Die zahlreichen Beispiele und Konfigurationsvarianten sollen als Fundament dienen, um individuelle Anforderungen und Topologien erfolgreich umzusetzen. Viel Erfolg beim Einrichten und Optimieren Ihrer OSPF-Umgebung!