Gibt es im Netzwerk mehrere Wege zu einem Ziel, dann entscheidet dynamisches Routing, welchen Weg ein IP-Paket nimmt. Aufwändige Protokolle beurteilen die Qualität der Verbindungen und treffen auf dieser Basis ihre Wahl. Die Routing-Software Zebra implementiert mehrere Routing-Protokolle.

Ausfallsichere Netze wünscht sich jeder Admin. Die Realität zeigt aber, dass Stecker wackeln, Router abstürzen und Kabel brechen. In dieser Situation zeigt sich dynamisches Routing von seiner besten Seite: Falls es einen alternativen Weg zum Zielrechner gibt, dann findet ihn Zebra[1] – und vergleichbare Routing-Programme auch. Dynamisches Routing sorgt zusätzlich für eine sinnvolle Lastverteilung auf mehrfach vorhandene Verbindungen.

Mit Hilfe verschiedener Algorithmen bestimmt das Routing-Protokoll den besten Weg zum Ziel. Grundlage für diese Entscheidung sind so genannte Metriken. Je nach Protokoll unterscheiden sich die Metriken, sie bewerten die alternativen Wege zum Beispiel abhängig von der Anzahl der Router (Hops) oder der Bandbreite auf den Wegabschnitten. Um sich der aktuellen Situation im Netz anzupassen, berechnet jeder Router seine Routing-Tabelle in bestimmten Intervallen neu, dadurch bleiben die Einträge konsistent. Im Gegensatz dazu gibt beim statischen Routing der Systemadministrator diese Tabellen vor. Bei größeren Netzen wird die Konfiguration schnell unübersichtlich, es können Inkonsistenzen entstehen, die ganze Netzabschnitte lahm legen.

In Abbildung 1 ist ein Firmennetzwerk zu sehen, das im Folgenden als Beispiel dient. Jeder Router kennt die direkt an seine Interfaces angeschlossenen Netze. Bei Router A sind es das Netz 10.0.1.0/24 an Interface E2, 10.0.2.0/24 an E0 und 10.0.3.0/24 an E1. Für jedes angeschlossene Netz enthält die Routing-Tabelle einen Eintrag, den das statische Routing verwendet.

Grundlagen des dynamischen Routings

Router A leitet IP-Pakete, die für eines der direkt angeschlossenen Netze bestimmt sind, über das richtige Interface weiter. Die Netze, die er nur indirekt über Router B und C erreicht, sind Router A aber nicht bekannt. In einfachen Fällen kommt dann eine Default-Route zum Einsatz, die alle Pakete an ein Default-Interface weiterleitet, wenn der Router das Zielnetz nicht kennt.

Beim dynamischen Routing teilen sich die Router mit Hilfe eines Routing-Protokolls gegenseitig mit, welche Netze über sie erreichbar sind. Auf diese Weise kann sich jeder Router im Netzwerk ein eigenes Bild (ein Modell) von dem Gesamtnetz machen. Die von den Nachbar-Routern eingesetzten Wege schreibt er in seine Tabelle – vorausgesetzt die Informationen sind aktueller oder besser als die alten Einträge. Jeder Router kennt nun alle Verbindungen und alle Zielnetze im Netzwerk.

Abbildung 2 zeigt, wie sich die Router gegenseitig informieren. Die Tabelle des Routers A enthält nach dem Update neue Einträge für die bisher unbekannten Netze 10.0.4.0/24, 10.0.5.0/24 und 10.0.6.0/24. Hat jeder Router im Netz alle Informationen des Netzes und sind diese konsistent, dann spricht man von einem konvergenten Netz.

Dynamische Routing-Protokolle lassen sich in zwei Gruppen einteilen: interne und externe Protokolle. Intern beziehungsweise extern bezieht sich dabei auf ein so genanntes autonomes System. Autonome Systeme (AS) sind als Administrations-Domäne definiert. Es handelt sich dabei um ein Firmennetz, ein Hochschulnetz oder ein beliebiges Netz, das als abgeschlossene Einheit zu sehen ist. Innerhalb des AS kommen interne Routing-Protokolle zum Einsatz, die Router kennen alle Wege zu den Netzen im eigenen autonomen System.

Abbildung 1: In diesem Beispielnetz kennt jeder der drei Router A, B und C nur die Wege in jene Netze, mit denen er direkt verbunden ist. Die Routing-Tabellen enthalten das zum Zielnetz passende Interface.

Abbildung 2: Beim dynamischen Routing informieren sich die Router gegenseitig über die ans Netzwerk angeschlossenen Netze. Die über Updates gelernten Einträge sind fett gedruckt.

Abbildung 3: Die autonomen Systeme sind über Border-Router miteinander verbunden. Sie kommunizieren über ein externes Routing-Protokoll, während im autonomen System interne Routing-Protokolle zum Einsatz kommen.

Wege suchen – intern oder extern

Das Internet besteht aus vielen autonomen Systemen. Damit die Router auch Netze außerhalb des eigenen erreichen können, sind diese Systeme über externe Routing-Protokolle verbunden (siehe Abbildung 3).

An der Grenze der AS befinden sich so genannte Border-Router, sie stellen eine Verbindung mit anderen autonomen Systemen her. Da diese nicht sämtliche Details über die interne Netzstruktur kennen müssen, geben die Border-Router nur eine Zusammenfassung an die anderen Border-Router weiter. Diese als Summary bezeichneten Informationen fassen die Adressbereiche zusammen, die über den jeweiligen Router erreichbar sind. Das sorgt auch dafür, dass die Routing-Tabellen in den Border-Routern nicht zu groß werden.

Meist ist das gesamte AS aus Sicht des externen Routing-Protokolls nur ein einzelnes Netzwerk. Ein über das Internet angeschlossener BGP-Router (Border Gateway Protocol) muss dennoch etwa 100000 Einträge in seiner Routing-Tabelle verwalten. BGP ist eines der bekanntesten externen Routing-Protokolle. Beispiele für interne Protokolle sind RIP (Routing Information Protocol), OSPF (Open Shortest Path First) und ISIS (Intermediate System to Intermediate System).

Zu den Aufgaben der Routing-Protokolle gehört es nicht nur, Wege-Informationen zu verteilen. Sie müssen auch vermeiden, dass Pakete im Kreis laufen, also dafür sorgen, dass keine Routing-Loops auftreten. Ein weiteres Kriterium für die Qualität eines Protokolls ist die Zeit, die es benötigt, um die Routen im Netz zu verteilen. Wichtig ist die Zeit, die vergeht, bis jeder Router alle nötigen Informationen hat, um alle Wege zu kennen. Dann befindet sich das Netz in einem konvergenten Zustand. Der Zeitraum, der bis zum Erreichen dieses Zustands vergeht, heißt Konvergenzzeit.

Open Shortest Path First

OSPF ist ein von der IETF (Internet Engineering Task Force) entwickeltes Link-State-Protokoll. Während RIP nur den nächsten Router (next Hop) zu einem bestimmten Netz kennt, weiß OSPF über das gesamte Netz Bescheid. Das RIP-Verfahren ist mit einem Straßenschild vergleichbar, OSPF hat dagegen eine genaue Straßenkarte.

OSPF unterteilt das autonome System in Bereiche (Areas). Area 0 spielt eine Sonderrolle: Sie ist die Backbone-Area und mit allen anderen Areas verbunden (siehe Abbildung 5). Der Vorteil des Verfahrens ist ein schneller konvergierendes Netz: je weniger Router, desto kleiner sind die Straßenkarten. Die Liste der erreichbaren Netze einer Area gibt der Area-Border-Router an die Backbone-Area weiter. Auf diese Weise sind alle Netze im AS über die Backbone-Area erreichbar. In der Praxis sollte der obere Grenzwert von 50 Routern pro Area nicht überschritten werden, um eine vernünftige Konvergenzzeit zu garantieren. Kleine Netze lassen sich auch komplett in einer Area betreiben.

Benachbarte Router senden sich Hello-Pakete zu und halten damit eine Beziehung untereinander aufrecht. Ein Ausfall lässt sich leicht erkennen, da der Nachbar-Router dann nicht mehr auf die Hello-Pakete antwortet. Jeder Router sendet alle zehn Sekunden ein Hello-Paket an jeden Nachbarn. Bleiben vier Nachrichten in Folge unbeantwortet, sind also 40 Sekunden ohne Reaktion vergangen, wertet der Router den Nachbarn als ausgefallen und löscht ihn aus der Routing-Tabelle. Hello-Pakete bauen also die Nachbarbeziehung zwischen Routern auf und halten sie am Leben. Diese Nachrichten heißen daher häufig Keep alive Messages.

Abbildung 4: Das Beispielnetzwerk vor (links) und nach (rechts) der Wegesuche mit dem SPF-Algorithmus (Shortest Path First). An der jeweiligen Leitung sind die Kosten für diese Verbindung angegeben.

Enge Nachbarschaftsbeziehung

Zwischen einigen Nachbarn entstehen so genannte Adjacencies. Adjacent werden benachbarte Router, wenn sie sich in der gleichen Area befinden und den gleichen Authentifizierungs-String benutzen. Ob ein Nachbar adjacent wird, hängt aber auch von der Art des Netzwerks ab. Bei Punkt-zu-Punkt-Verbindungen (P2P) wird jeder der beiden Nachbarn adjacent. Anders in Multiaccess-Netzwerken: Hier bestimmt der Admin einen Designated Router (DR) und einen Backup Designated Router (BDR), zu denen dann jeder Router im Netz eine Adjacency hat.

Die Unterscheidung zwischen P2P und Multiaccess ist sinnvoll, da im Multiaccess-Netzwerk (etwa Ethernet) jeder Router mit jedem verbunden ist. Würde das Protokoll diese Beziehung voll-vermascht abbilden, würde die Komplexität explodieren: Bei n Routern ergäben sich n*( n-1)/2 Adjacencies.

OSPF verhält sich in Multiaccess-Netzen so, als ob alle Router nur mit dem DR und einem BDR verbunden wären. Damit ergibt sich eine sternförmige Anordnung der Router wie in Abbildung 6 (rechts). Jeder Router baut eine Adjacency zum DR und zum BDR auf, damit bei einem Ausfall des DR der BDR dessen Aufgaben übernehmen kann.

Informative Gespräche zwischen Nachbarn

Die OSPF-Router senden über alle Adjacencies LSA-Nachrichten (Link State Advertisement). LSAs sind Pakete, die Informationen über die Interfaces, die Verbindungen sowie deren Status enthalten. Jeder Router, der ein LSA empfängt, trägt diese Informationen in seine Link State Database ein. Eine Kopie des LSA sendet er an alle anderen Router weiter, die adjacent zu ihm sind.

Die Link State Database entspricht dabei einer Straßenkarte des Netzes. In ihr sind alle Verbindungen, deren Status sowie die Bandbreite eingetragen. Jeder Router in einer Area verfügt über die gleiche Karte. Daraus ermittelt er mit Dijkstras Shortest-Path-First-Algorithmus die kürzesten Wege. Fällt der beste Weg aus und gibt es noch eine Ausweichstrecke, verwendet er die zweitbeste Route. Sind zwei gleichwertige Alternativen vorhanden, kennt ein Router also zwei Wege zu gleichen Kosten in das gleiche Netz, dann verteilt er die Last gleichmäßig über beide Strecken (Load Sharing). Eine Beschreibung des Algorithmus ist im Kasten “SPF-Algorithmus” zu finden.

Ein Nachteil von OSPF ist, dass es im Vergleich zu anderen Routing-Protokollen sehr viel Rechenleistung für das Ausführen des SPF-Algorithmus beansprucht. Da das Verfahren Informationen in unterschiedlichen Datenbanken redundant enthält, benötigt es auch relativ viel Speicher. Beides ist aber bei den heute verfügbaren PCs kein ernstes Problem mehr.

Für Linux gibt es im Wesentlichen fünf freie Softwarepakete, die die wichtigsten dynamischen Routing-Protokolle implementieren. Der unter Unix bekannteste und älteste Routing-Daemon ist Routed. Er wird mit fast jeder Unix-Version ausgeliefert und unterstützt RIP v1 und v2.

interface eth0
 ip ospf hello-interval 60
 ip ospf dead-interval 180
 ip ospf retransmit-interval 30

Bekannte Routing-Pakete für Linux

Sehr bekannt ist auch Gated. Diese Software bietet alle wesentlichen Routing-Protokolle, etwa RIP v1 und v2, OSPF v2 und v3 sowie ISIS und BGP. Für das Programm gibt es auch APIs für Traffic Engineering. Leider handelt es sich inzwischen nicht mehr um freie Software, seit etwa zwei Jahren wird die freie Version von Gated weder weiterentwickelt noch gepflegt. Dieser Artikel betrachtet Gated daher nicht weiter (siehe aber Kasten “Gated und Zebra”). Ähnlich verhält es sich mit den Projekten Bird[4] und MRT[5], beide werden derzeit nicht weiterentwickelt.

Ein relativ junges, viel versprechendes GNU-Projekt ist Zebra. Die modular aufgebaute Routing-Software enthält für jedes unterstützte Protokoll einen eigenen Daemon. Der zentrale »zebra«-Server aktualisiert die Routing-Tabelle im Kernel und verbreitet die Routing-Informationen an die einzelnen Protokoll-Daemons. Den Informationsaustausch zwischen den Routing-Protokollen bezeichnet man als Redistribution. Damit lassen sich beispielsweise auch statische Routen des Kernels über OSPF verteilen. Das Zusammenspiel zwischen Zebra, den einzelnen Daemons und dem Kernel ist in Abbildung 7 dargestellt. Zebra unterstützt die Protokolle RIP v1 und v2, RIPng, OSPF v2 und v3 sowie BGP v4 und 4+. OSPF v3 und BGP+ sind die Versionen für IP v6.

Das ISIS-Protokoll wird vom Zebra-Projekt selbst nicht unterstützt. Es gibt jedoch ein Projekt unter[3], das ein ISIS-Modul für die Zebra-Plattform entwickelt. Weitere Informationen zu ISIS sind unter anderem bei Cisco[2] zu finden.

Abbildung 5: Alle Areas eines autonomen Systems sind mit der Backbone-Area (Area 0) verbunden.

Abbildung 6: Im Multiaccess-Netz (links) ist jeder Router mit jedem anderen verbunden. OSPF betrachtet aber nur die Verbindungen zum DR und zum BDR und sieht daher eine Sterntopologie (rechts). Jeder Router hat eine Adjacency mit DR und BDR.

OSPF in der Praxis

Die folgende OSPF-Konfiguration ist angelehnt an das Beispielnetzwerk in Abbildung 8. Auf Router A und Router B läuft jeweils ein OSPF-Prozess. Die Router befinden sich in der gleichen Area und sind über das Ethernet-Interface 0 miteinander verbunden.

Nach der Installation (siehe Kasten “Installation von Zebra”) gibt es zwei Möglichkeiten, um Zebra zu konfigurieren: direkt im Config-File »zebra.conf« oder interaktiv, indem der Administrator den Daemon per Telnet anspricht. Zebra bietet daraufhin ein nüchternes Text-Interface an. Die Oberfläche reagiert auf die [?]-Taste und gibt zum jeweiligen Kontext passende Hilfe. Auch das Vervollständigen von Kommandos mit [Tab] funktioniert.

Für den ersten Start des Zebra-Daemon mit »zebra -d« genügt eine Kopie der Datei »zebra.conf.sample«, ohne Konfigurationsdatei »zebra.conf« startet der Daemon nicht. Jetzt kann die interaktive Konfiguration beginnen. Der Zebra-Daemon läuft auf Port 2601, eine Verbindung lässt sich also per »telnet localhost 2601« herstellen. Admins, die bereits Erfahrungen mit IOS (Internet Operating System) auf einem Cisco-Router gesammelt haben, fühlen sich hier schnell zu Hause. Der Zebra-Daemon fordert nun die Eingabe des Passworts. Per Default lautet es »zebra«, einen User-Namen muss der Admin nicht eingeben.

Wie Cisco IOS kennt auch Zebra drei Modi nach dem Login. Die erste Variante ist eine Art User Mode (auch Normal Mode genannt), in dem sich der Admin direkt nach dem Einloggen befindet. Hier sind nur wenige Kommandos erlaubt, der Benutzer hat kaum Rechte. Der Enable Mode dagegen ist vergleichbar mit dem Root-User auf einem Linux-Rechner. Auf dieser Stufe darf der Admin alle Befehle ausführen. Als letzten Modus gibt es noch den Config Mode. Er dient zur Konfiguration des Routers.

Abbildung 7: Der zentrale »zebra«-Daemon aktualisiert die Routing-Tabellen im Kernel und gibt die Routing-Informationen zwischen den einzelnen Protokoll-Daemons weiter.

Abbildung 8: In diesem Beispielnetzwerk sind drei Netze über zwei Router verbunden. Die Verbindungsstrecke 10.0.2.0/24 ist an beide über das Interface 0 angeschlossen.

Ermächtigung

Nach einem Login mit Passwort gelangt der Admin zunächst in den User Mode. Für den Enable Mode muss er den Befehl »enable« sowie das zugehörige Passwort eingeben. Per Default lautet es ebenfalls »zebra«. Im Enable Mode kann der Benutzer zum Beispiel mit dem Befehl »show running-config« die aktuelle Konfiguration einsehen. Mit »configure terminal« gelangt er aus dem Enable-Modus weiter in den Konfigurationsmodus, den er – wie die anderen Modi auch – mit »exit«, »quit« oder [Ctrl]+[D] verlassen kann.

Als Erstes sollte der Admin unbedingt das Passwort seines neuen Routers ändern. Das erledigt man im Konfigurationsmodus mit dem Kommando »password mein Passwort«. Mit »enable password zweites Passwort« lässt sich das Enable-Passwort setzen. Zum Ändern des Hostnamens dient der Befehl »hostname mein Name«.

Im nächsten Schritt sind die IP-Adressen der Netzwerk-Interfaces an der Reihe. Das Kommando »interface eth0« wählt das Interface »eth0« aus, danach gibt »ip address 10.0.2.1/24« ihm die IP-Adresse 10.0.2.1/24. Als Letztes erhält der Router noch ein Dummy-Interface.

Das virtuelle Interface hat den Vorteil, dass es für alle Prozesse immer verfügbar ist und nicht wie ein physikalisches seinen Status (up/down) ändert. Hier lautet das Kommando »interface dummy0«, gefolgt von der entsprechenden IP-Adresse (für Router A aus Abbildung 8 »ip address 172.20.0.1/32«). Um die neue Konfiguration zu speichern, muss der Admin im Enable Mode das Kommando »copy running-config startup-config« eingeben.

Sind die Interfaces auf Router A und B konfiguriert, dann muss das Interface 0 des jeweils anderen Rechners auf »ping IP-Adresse« reagieren. Befindet sich der Admin auf Router A, dann muss E0 von Router B pingbar sein und umgekehrt. Ist das nicht der Fall, sind als Erstes die Verkabelung und die Zebra-Konfiguration zu kontrollieren.

Routing mit dem OSPF-Daemon

Der OSPF-Daemon lässt sich nach dem Kopieren der Datei »ospfd.conf.sample« nach »ospfd.conf« mit dem Befehl »ospfd -d« starten. Er läuft per Default auf Port 2604. Das Kommando »telnet localhost 2604« stellt eine Verbindung zum OSPF-Prozess her. Dieses Text-Interface funktioniert wie das des Zebra-Daemon, es kennt ebenfalls drei Modi. Die folgenden Kommandos sind im Konfigurationsmodus einzugeben.

Der Daemon wird mit dem Kommando »router ospf« aktiviert und zur weiteren Konfiguration ausgewählt. Dann muss der Admin die Router-ID setzen, sie gibt an, mit welcher Absender-IP-Adresse der OSPF-Daemon seine Informationen verschickt. Im vorliegenden Beispiel kommt das virtuelle Interface »dummy0« zum Einsatz: »ospf router-id 172.20.0.1«. Der Befehl »network Adressbereich area Nummer« teilt dem OSPF-Prozess mit, welche Netzwerke über diesen Router erreichbar sind sowie die Area, in der sich der Router befindet.

Im Beispiel findet alles in einer Area statt. Da es sich um das Backbone-Netz einer kleinen Firma handeln soll, ist es die Area 0. Alle Interfaces, die kein OSPF benutzen, sollte der Admin mit »passive-interface Name« auf passiv setzen, damit sie keine Hello-Pakete ins angeschlossene Netz senden.

Abgespeichert wird die Konfiguration mit dem Kommando »copy running-config startup-config« im Enable Mode. Dabei überschreibt Zebra leider alle Kommentare, die der Admin vorher von Hand in die Konfigurationsdatei eingefügt hat. Betrachten kann er das bisher Konfigurierte mit »show running-config«. Um sich auch Wochen später noch zurechtzufinden, sollte man den Befehl »description« recht oft benutzen, er fügt Kommentare und andere wichtige Informationen in die Konfiguration ein. Der Befehl steht im Konfigurationsmodus zur Verfügung, wenn ein Konfigurationsziel ausgewählt wurde, etwa Ethernet-Interface oder OSPF-Router.

Sind schließlich beide OSPF-Daemons konfiguriert, senden sie sich gegenseitig Hello-Pakete zu und bilden eine Adjacency. Nach einer kurzen Konvergenzzeit sind alle Interfaces von jedem Router aus erreichbar.

01 !
02 ! Zebra configuration saved from vty
03 ! 2003/01/02 17:44:30
04 !
05 hostname Router A
06 password zebra
07 enable password zebra
08 log file /usr/local/etc/log.zebra.log
09 no banner motd
10 !
11 interface dummy0
12  description Loopback-Interface
13  ip address 172.20.0.1/32
14 !
15 interface eth0
16  description Ethernet-Interface zum Router B
17  ip address 10.0.2.1/24
18 !
19 interface eth1
20  ip address 10.0.3.1/24
21 !
22 ! Zebra kann durch die folgende Access-Liste nur
23 ! vom lokalen Host aus konfiguriert werden.
24 !
25 access-list localhost permit 127.0.0.1/32
26 access-list localhost deny any
27 !
28 ! Der Befehl "access-class" bindet die Access-Liste
29 ! "localhost" an das Interface "vty". "vty" ist das
30 ! Interface, über das sich der Admin einloggt, wenn
31 ! er Zebra interaktiv per Telnet konfiguriert.
32 !
33 line vty
34 access-class localhost
35 exec-timeout 0 0
36 !

01 !
02 ! Zebra configuration saved from vty
03 ! 2003/01/02 17:53:58
04 !
05 hostname Router A
06 password zebra
07 enable password zebra
08 !
09 !
10 !
11 interface lo
12 !
13 interface eth0
14 !
15 interface eth1
16 !
17 router ospf
18  ospf router-id 172.20.0.1
19  passive-interface eth0
20  network 10.0.3.0/24 area 0
21  network 10.0.2.0/24 area 0
22  network 172.20.0.1/32 area 0
23 !
24 ! OSPFD kann durch die folgende Access-Liste nur
25 ! vom lokalen Host aus konfiguriert werden.
26 !
27 access-list localhost permit 127.0.0.1/32
28 access-list localhost deny any
29 !
30 !
31 line vty
32 access-class localhost
33 exec-timeout 0 0
34 !
35 !

Authentische Nachbarn

Optional ist es auch möglich, die Nachbar-Router zu authentifizieren. Wenn sie Routing-Informationen austauschen wollen, prüfen die Nachbarn, ob ihr Partner das richtig Passwort kennt. Ist das nicht der Fall, kommt auch keine Adjacency zustande. In der Praxis ist es Standard, jeden Routing-Prozess mit einem solchen Authentifizierungspasswort zu versehen. Dann können etwa im LAN versehentlich gestartete Router keine falsche Fährten legen und damit nicht zu Stabilitäts- und Sicherheitsproblemen führen.

Die beiden Konfigurationsdateien »zebra.conf« (Listing 1) und »ospfd.conf« (Listing 2) enthalten die vollständige Konfiguration von Router A entsprechend dem Beispiel. Für die Konfiguration von Router B sind nur die IP-Adressen anzupassen.

Bewertung

Mit Zebra und einem Standard-PC lassen sich Router realisieren, die einen Durchsatz von 500 MBit/s schaffen, und zwar zu einem unschlagbar günstigen Preis. Leider sind WAN-Adapter für PCs jenseits der 2 MBit/s nur von wenigen Herstellern und zu relativ hohen Kosten erhältlich. Das hält viele Betreiber von WAN-Routern davon ab, die Linux-Lösung zu testen. Im LAN ist Zebra aber auf jeden Fall einen Versuch wert. Für 10 MBit/s oder 100 MBit/s genügt bereits ein älterer Computer.

Für den Einsatz von dynamischen Routing-Protokollen im Firmennetz spricht zum einen die mögliche Redundanz, zum anderen die optionale automatische Konfiguration. So könnte ein Rechner seine IP-Adresse über DHCP beziehen, mit dieser Adresse einen Routing-Prozess starten und darüber automatisch alle Routen zu anderen Netzen von einem Router lernen. Fällt im LAN einer von mehreren Router aus, entscheidet sich der Prozess sofort für den nächstbesten Weg in der Routing-Tabelle. Der Rechner ist also stets erreichbar.

Wegen des modularen Aufbaus von Zebra sind Erweiterungen recht einfach. Der Admin kann einzelne Routing-Daemons durch andere ersetzen oder neue hinzufügen, etwa aus dem ISIS-Projekt[3]. Durch den Aufbau ist die Software auch für Entwickler als Basis für neue Module interessant. Ein kurzer, kommentierter Rundgang durch den Zebra-Code ist unter[7] zu finden. (fjl)n