Ubuntu 14.04 Trusty Tahr
Ubuntu 12.04 Precise Pangolin
Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.
Die Aufgabe eines Routers besteht darin, Pakete zwischen mehreren Netzen zu vermitteln. Dazu muss dem Router bekannt sein, wie ein Zielnetzwerk zu erreichen ist. Der Aufwand, diese Information manuell zu pflegen, steigt mit jedem angeschlossenen Router. Kommt es noch zu häufigen Änderungen in der Netztopologie, werden Technologien benötigt die auf diese Änderungen dynamisch reagieren.
Beim dynamischen Routing geht es um die Fähigkeit eines Routers oder Servers, die angeschlossene Netzwerktopologie selbständig zu erlernen, auf Veränderungen zu reagieren und daraus Rückschlüsse auf die optimale Route zum Zielnetzwerk zu ziehen.
Um unter Ubuntu einen Router zu betreiben, gibt es unterschiedliche Routing-Daemons (Dienste). Diese arbeiten alle nach dem gleichen Prinzip: Sie erlernen aus der Routing-Tabelle des Kernels die direkt angeschlossenen Netzwerke/Interfaces und ggf. statisch konfigurierte Routen. Anschließend verteilen sie diese Informationen (je nach Konfiguration) an ihre Nachbar-Router. Diese sammeln diese Informationen und verteilen ihrerseits die ihnen bekannten Netzwerke und Routen. So bildet sich nach einer Initialisierungsphase auf jedem Router ein Abbild der Netzwerktopologie.
Diese Routen-Tabellen existieren parallel zur Kernel-Routing Tabelle, stehen dementsprechend für Paket-Routing erst einmal nicht zur Verfügung. Erst in einem zweiten Schritt wird abhängig von der Konfiguration entschieden, welche Route dem Kernel bekannt gemacht wird. Dabei wird nur der nächste Nachbar (Gateway) und das Zielnetzwerk in die Routing-Tabelle kopiert.
Ist dieser Vorgang auf allen Routern durchgeführt, kann zwischen den Netzen geroutet werden. Das Routing selber übernimmt der Kernel bzw. das IP-Subsystem. Das Routing-Protokoll ist nur für die Routenfindung verantwortlich.
Es gibt unterschiedliche Routing-Prokolle für unterschiedliche Anwendungsfälle. Die geläufigsten Vertreter für kabelgebundene Netze sind OSPF, RIP und BGP. Jüngst hinzugekommen sind RAdv für IPv6 und neuere Verfahren für offene Mesh Netzwerke. Bekanntester Vertreter ist hier OLSR.
Vorteile:
geringe Anforderung an Hardware (CPU, RAM)
Nachteile:
konvergiert langsam nach Topologie-Änderung. Fällt eine bekannte Route aus, muss die Ersatzroute erst erneut gelernt werden.
hat Probleme bei Loops/Multi-Homing
maximale Pfadlänge zwischen zwei Netzen limitiert auf 15 Router
Ein sehr einfaches Routing Protokoll der DistantVektor-Familie. Ein Router teilt alle ihm bekannten Routen mit seinem Nachbarn. Dieser erlernt eine Route nur, wenn die Route unbekannt ist oder deren Kosten geringer sind als die bekannte Route. Wird eine bessere Route erlernt, wird die alte Route verworfen. Dies hält die Routing-Tabelle klein, hat aber den Nachteil, dass keine Loops erkannt werden können. Obwohl es zwei mögliche Routen zu einem Ziel gibt, kennen alle Router nur eine Route. Je nach Topologie nutzen ein paar Router jedoch die Alternativroute als Primär-Route. Fällt eine der beiden Routen aus, ist das Zielnetzwerk für alle von dieser Route betroffenen Router nicht erreichbar. Erst wenn von einem Router mit Alternativroute eine Routen-Bekanntmachung versendet wird, verteilt sich die Information über die Alternativroute über das ganze Netz.
Siehe auch: RIP - Wikipedia
Vorteile:
konvergiert "sofort". Alle Alternativrouten sind immer bekannt.
kann stabil mit Loops und Multi-Homing umgehen.
Nachteile:
Höhere Anforderungen an Hardware (CPU und RAM)
Bei OSPF handelt es sich um ein sogenanntes LinkState Protokoll. Den Namen hat es vom Dijkstras Algorithmus "Shortest Path First" geerbt, der zur Routenfindung genutzt wird. Der Hauptunterschied zu RIP ist, dass jeder Router im OSPF-Netz jeden anderen Router und deren Routen kennt. Das umgeht die Hauptkritikpunkte von RIP. Wenn ein beliebiger Router die Information erhält, dass eine Route ausgefallen ist, kann dieser sofort ermitteln, ob eine Ersatzroute vorhanden ist. Auch die Problematik der Loop-Erkennung entfällt beim "Shortest Path First"-Algorithmus. Diese Vorteile werden mit höherem Aufwand für die Hardware erkauft. Um Bandbreite zu schonen, wird beim Protokoll-Start ein primärer (designated router) und sekundärer Router (backup designated router) "gewählt". Über diese werden dann die Topologie-Informationen verteilt. So muss nicht jeder Router an jeden anderen Router Informationen verteilen.
Siehe auch: OSPF - Wikipedia
IS-IS ähnelt OSPF stark. Es nutzt sogar den gleichen Dijkstras Algorithmus zur Routenermittlung. Dementsprechend erbt es auch die Stärken und Schwächen von OSPF. Wichtigstes Alleinstellungsmerkmal gegenüber OSPF ist die Unabhängigkeit vom IP-Stack. IS-IS setzt auf den CLNS-OSI-Stack auf und ist somit prinzipiell in der Lage, jedes routingfähige Protokoll zu Verwalten. So war IS-IS von Anfang an in der Lage, IPv6 Routen zu verwalten, wohingegen RIP und OSPF jeweils erweitert werden mussten.
Siehe auch: IS-IS - Wikipedia
Ein von CISCO entwickeltes Hybrid-Routing Protokoll. Es hat sowohl Eigenschaften eines Distant-Vektor als auch Link-State Protokolls.
Weitere Informationen: EIGRP - Wikipedia
Das Border-Gateway-Protokoll ist der einzige Vertreter der Exterior-Gateway-Protokollklasse. Diese kommen hauptsächlich zur Kommunikation zwischen großen Netzen zum Einsatz. Bei BGP handelt es sich im Prinzip um ein Distant-Vektor-Protokoll, das jedoch so verbessert wurde, dass Skalierungs- und Loop-Probleme nicht auftreten.
Siehe auch: BGP - Wikipedia
Hierbei handelt es sich, wie der Name schon angibt, um ein Link-State-Protokoll wie OSPF oder IS-IS. Allerdings wurden Anpassungen vorgenommen, damit das Protokoll besser in Ad-Hoc Umgebungen skaliert. Da sich Ad-Hoc Netze schnell ändern können, skaliert das Konzept eines "designated Routers" pro Netzwerk nicht. OLSR Router wählen in einer 2-Hop Umgebung ihren "Vertreter" (multipoint relay, MPR). Dieser verteilt dann die Topologie-Informationen. Eine weitere Eigenschaft von OLSR ist, dass es keinen Mechanismus bietet, um zu garantieren, dass eine Topologie-Änderung alle Teilnehmer erreicht hat. Die Änderung werden einfach so oft ins Netz geflutet, dass jeder Teilnehmer sie mitbekommen muss.
Siehe auch: OLSR - Wikipedia
Das Feld der verfügbaren Implementierungen teilt sich in zwei Routing-Suites und spezielle Einzelimplementierungen. Bei den Suites stehen sich Quagga und BIRD gegenüber. Beide decken ungefähr den gleichen Funktionsumfang ab.
Quagga ist die ältere Implementierung, wird aber u.a. von Canonical weiterentwickelt. Die Suite startet für jedes Protokoll einen eigenen Daemon, die untereinander kommunizieren. Das hat den Vorteil, dass einzelne Daemonen abstürzen können, ohne gleich den ganzen Router unbrauchbar zu machen. Für Linux-Systeme ungewöhnlich gestaltet sich die Konfiguration der Daemonen. Jeder Daemon macht einen Telnetport auf, über den er Befehle entgegen nimmt. Diese Befehlssyntax ähnelt stark der CISCO Syntax. Prinzipiell ist es möglich, die Daemonen mit einer Minimalkonfiguration zu starten, via Telnet on-the-fly zu konfigurieren und abschließend die Konfiguration speichern zu lassen.
BIRD entstand ursprünglich als Studentenprojekt, hat sich mittlerweile aber als ernstzunehmende Alternative zu Quagga etabliert. Einige Internet-Exchanges setzten zum Beispiel auf BIRD anstatt auf Quagga. In den Publikationen wird sowohl die Performance als auch die Stabilität gegenüber Quagga hervorgehoben. BIRD bietet zwar auch ein Commandline-Interface, ist jedoch nicht über Telnet erreichbar und dient auch nicht zur Konfiguration. Die komplette Konfiguration läuft UNIXartig über eine einfach gehaltene Konfigurationsdatei.
Quelle: LINX - BIRD Route Server Daemon Deployment
Verfügbare Implementierungen | |||
Quagga | BIRD | OLSRd | |
OSPF | Ja | Ja | Nein |
IS-IS | Ja (Hinweis beachten) | Nein | Nein |
RIP | Ja | Ja | Nein |
EIGRP | CISCO eigener Standard | ||
BGP | Ja | Ja | Nein |
RAdv | Ja | Ja | Nein |
OLSR | Nein | Nein | Ja |
Benötigt werden folgende Pakete:
quagga
mit apturl
Paketliste zum Kopieren:
sudo apt-get install quagga
sudo aptitude install quagga
Nach der Installation findet man unter /etc/quagga/ zwei Konfigurationsdateien:
daemons und
debian.conf
In daemons wird definiert, welche Dienste gestartet werden sollen. Der Zebra-Dienst wird immer gebraucht, wenn Routen in den Kernel exportiert werden sollen.
zebra=yes bgpd=no ospfd=yes ospf6d=no ripd=no ripngd=no isisd=no
Die Datei debian.conf legt fest, auf welchen Interfaces die Telnet-Ports aufgemacht werden. Standardmäßig wird dort an das Loopback-Interface gebunden.
Für den einfachen Start findet man unter /usr/share/doc/quagga/examples Beispielkonfigurationen für alle Dienste (Daemonen). Hier ein sehr einfaches OSPF-Beispiel:
/etc/quagga/zebra.conf:
!setzt den Routernamen hostname ospf-router !aktiviert das Logging über syslog log syslog !starte Konfiguration für Interface br0 interface br0 !Aktiviert die Überwachung des Medialinks link-detect interface ath1 link-detect
/etc/quagga/ospf.conf:
log syslog !Starte Konfiguration des br0 Interfaces für OSPF-Parameter interface br0 !Das Interface hat die fiktiven Kosten 10. Dieser Wert wird für die Gewichtung der besten Route benutzt. ip ospf cost 10 !Ein HELLO-Packet wird alle 30 Sekunden an die Nachbarn verteilt. WICHTIG: Dieser wert muss bei allen Teilnehmern gleich sein. ip ospf hello-interval 30 !Bei einer fehlgeschlagenen Aktualisierung wird das Paket nach 5 Sekunden wiederholt. ip ospf retransmit-interval 5 !Meldet sich ein Router nach 120 Sekunden nicht, wird er als "nicht verfügbar" angesehen und seine Routen werden verworfen. ip ospf dead-interval 120 ip ospf network broadcast !Aktiviere OSPF router ospf !setzt die Router-ID - wird zum Bestimmen des "designated Routers" benötigt. ospf router-id 10.10.69.2 !Aktiviere OSPF auf br0 (diesem ist 10.10.69.2 zugeordnet network 10.10.69.0/24 area 0 !Verteile (statische) Routen die im Kernel hinterlegt wurden redistribute kernel !Verteile alle direkt angeschlossenen Netzwerke redistribute connected !Aktiviere logging für diverse Events debug ospf ism status debug ospf nsm status debug ospf zebra
Im Beispiel sind an den Router zwei Netzwerkinterfaces angeschlossen, jedoch wird OSPF nur auf dem br0
-Interface betrieben.
Eine komplette Dokumentation aller Konfigurationsbefehle gibt es hier: Quagga-Dokumentation . Für den schnelleren Einstieg dient eine Beispielanleitung .
Die BIRD-Version, die mit Ubuntu 12.04 und 14.04 ausgeliefert wird, ist stark veraltet. Einige Funktionen werden noch nicht unterstützt und die verwendete iBGP-Implementierung entspricht nicht dem Standard. Ein "Personal Package Archiv" (PPA) wird direkt vom Entwickler angeboten und gepflegt.
Adresszeile zum Hinzufügen des PPAs:
ppa:cz.nic-labs/bird
Zusätzliche Fremdquellen können das System gefährden.
Ein PPA unterstützt nicht zwangsläufig alle Ubuntu-Versionen. Weitere Informationen sind der PPA-Beschreibung des Eigentümers/Teams cz.nic-labs zu entnehmen.
Damit Pakete aus dem PPA genutzt werden können, müssen die Paketquellen neu eingelesen werden.
Nach dem Aktualisieren der Paketquellen wird folgendes Paket benötigt:
bird (ppa)
mit apturl
Paketliste zum Kopieren:
sudo apt-get install bird
sudo aptitude install bird
Nach der Installation findet man die Konfiguration unter /etc/bird/bird.conf. Hier ein einfaches OSPF-Beispiel:
#Aktiviert das Logging über syslog log syslog all; #setzt die Router-ID (wird zum bestimmen router id 10.11.0.1; protocol kernel { #Alle gelernten Routen werden dem Kernel bekannt gemacht. export all; } protocol device { #Überprüft die Interfaces alle 60 Sekunden scan time 60; } protocol ospf { #Legt fest was geloggt werden soll. debug { states, routes, interfaces }; area 0 { interface "eth0" 10.10.69.0/24 { cost 10; #legt die Kosten für die Route fest. type broadcast; hello 30; #Ein HELLO-Packet wird alle 30 Sekunden an die Nachbarn verteilt. WICHTIG: Dieser Wert muss bei allen Teilnehmern gleich sein. retransmit 5; #Bei einer fehlgeschlagenen Aktualisierung wird das Paket nach 5s wiederholt. wait 10; #Nach dem Hochfahren des Dämons wird 10s gewartet, bis die Wahl des Designated Routers gestartet wird. dead 120; #Meldet sich ein Router nach 120s nicht, wird er als "nicht verfügbar" angesehen und seine Routen werden verworfen. authentication none; #Es wird keine Authentifizierung der LSA-Pakete vorgenommen. check link; #Der MediaLink wird überprüft. }; interface "eth1.1" 192.168.99.0/24 { cost 10; #legt die Kosten für die Route fest. stub; #OSPF-Bird propagiert keine angeschlossenen Netzwerk. Um ein Lokales Netz bekannt zu machen, aber nicht als OSPF-Netz zu nutzen, wird STUB verwendet. check link; }; }
Wie im Quagga-Beispiel wird hier ein Netz für OSPF freigeschaltet, ein weiteres wird nur bekannt gemacht.
Eine komplette Dokumentation aller Konfigurationsbefehle gibt es hier: Bird-Dokumentation
Router - Einen Rechner als Router verwenden
Netzwerk Übersichtsartikel
Routing Overview - Übersicht über IP-Routing
Diese Revision wurde am 16. November 2015 11:25 von aasche erstellt.