ubuntuusers.de

Du betrachtest eine alte Revision dieser Wikiseite.

Dynamisches Routing

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:

Dieser Artikel ist mit keiner aktuell unterstützten Ubuntu-Version getestet! Bitte teste diesen Artikel für eine Ubuntu-Version, welche aktuell unterstützt wird. Dazu sind die Hinweise zum Testen von Artikeln zu beachten.

Artikel für fortgeschrittene Anwender

Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.

Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:

Wiki/Icons/service.png 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.

Prinzipielle Funktionsweise

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.

Verfügbare Protokolle

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.

Protokoll - Übersicht

RIP - Routing Information Protocol

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

OSPF - Open Shortest Path First

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 - Intermediate System To Intermediate System

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

EIGRP

Ein von CISCO entwickeltes Hybrid-Routing Protokoll. Es hat sowohl Eigenschaften eines Distant-Vektor als auch Link-State Protokolls.

Weitere Informationen: EIGRP - Wikipedia

BGP - Border Gateway Protocol

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

Implementierungen

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

Übersichtstabelle

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

Quagga - Beispiel

Benötigt werden folgende Pakete:

  • quagga

Befehl zum Installieren der Pakete:

sudo apt-get install quagga 

Oder mit apturl installieren, Link: apt://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 🇬🇧.

BIRD - Beispiel

Hinweis:

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

Hinweis!

Zusätzliche Fremdquellen können das System gefährden.


Ein PPA unterstützt nicht zwangsläufig alle Ubuntu-Versionen. Weitere Informationen sind der Wiki/Vorlagen/PPA/ppa.png PPA-Beschreibung des Eigentümers/Teams cz.nic-labs zu entnehmen.

Nach dem Aktualisieren der Paketquellen wird folgendes Paket benötigt:

  • bird (ppa)

Befehl zum Installieren der Pakete:

sudo apt-get install bird 

Oder mit apturl installieren, Link: apt://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 🇬🇧

Diese Revision wurde am 9. März 2019 13:23 von noisefloor erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Netzwerk, Server, System, Internet