PRRU Skriptum – Kapitel 6
I) Inhalt
6.2.1 Distance Vector Routing Protocol
6.2.2 Link State Routing Protocol
6 Routing
6.1 Statisches Routing
6.2 Dynamisches Routing
Unter dynamischen Routing versteht man das selbständige Lernen der Wege in einem Netz. Die Router tauschen untereinander mithilfe des Routing Protokolls Routinginformationen aus. Mithilfe dieses Routing Protokolls lernen die Router das gesamte Netz kennen und können so den besten Weg zum Ziel wählen.
Wichtig dabei ist die Konvergenzzeit: Das ist jene Zeitspanne, die für den Informationsaustausch über ein Netzwerk und für die Berechnung der besten Pfade für alle Router benötigt wird.
Es gibt grundsätzlich 2 Arten von Routing Protokollen:
6.2.1 Distance Vector Routing Protocol
Distance Vector bedeutet, dass sich der Router für jedes Zielnetzwerk Richtung (next hop) und Länge (metric) ab. Distance Vector Routing Protokolle senden die gesamte Routingtabelle periodisch an die Nachbarn aus. Empfängt ein Router eine Routingtabelle, dann addiert er den Vektor von sich zum Nachbarn zu den Einträge. Erhält er dadurch bessere oder neuere Routen zu einem Zielnetzwerk, dann bessert er diese in seiner Routingtabelle aus oder fügt sie ein.
Man sagt auch: die Router lernen aufgrund der Sichtweise der Nachbarn.
6.2.2 Link State Routing Protocol
Bei Link State Routing Protokollen senden die Router beim Neustart oder bei Änderungen LSA (Link State Advertisement) - Pakete aus, die von den Nachbarroutern in der Topology Database abgespeichert und an deren Nachbarn weitergesandt werden. Am Ende dieses Informationsaustausches, auch Flooding Process genannt, haben alle Router eine idente Topologie Datenbank – das bedeutet jeder Router kennt das gesamte Netz. Unter Zuhilfenahme des Dijkstra Algorithmus berechnet jeder Router eine Baumstruktur des Netzwerks, in der er selbst die Wurzel bildet. In diesem Baum kann der Router zu jedem Zielnetz den kürzest möglichen Weg (OSPF = Open shortest path first) erkennen.
6.2.3 Vergleich
|
|
Distance Vector Routing Protocol |
Link State Routing Protocol |
|
Lernweise |
Lernt aufgrund der Sichtweise der Nachbarn |
Erhält alle Informationen von der Quelle |
|
Updates |
Periodisch |
Bein Neustart und Änderungen |
|
Routingentscheidung |
Übernimmt neue oder bessere Informationen der Nachbarn durch Addition der Vektoren |
Erstellt mittels Dijkstra Algorithmus aus der Datenbank einen Baum |
|
Vorteile |
Weniger Anforderungen an den Router -> billiger |
Schnell |
|
Beispiel |
RIP, RIPv2, IG-RP |
OSPF, IS-IS |
6.2.4 Protokolle
6.2.4.1 RIP (Distance Vector Protokoll)
RIP ist eine Anwendung (Layer 7) und verwendet auf Layer 4 UDP (Port 520). Es ist daher ein unsicheres Protokoll. Als Metrik für die Distanz verwendet RIP den Hopcount (Anzahl der Sprünge bis zum Ziel).
RIP zählt zur Familie der Distance Vector Protocols, und sendet daher periodisch Updates aus. Die gesamte Routingtabelle wird per Default alle 30 Sekunden ausgesandt. Erhält ein Router mit RIP 2 gleichlange Wege (equal cost routes) zu einem Ziel, merkt er sich beide und verteilt die Last auf max. 6 Pfade (default: 4). Diese Lastverteilung, verbunden mit dem Hopcount als Metrik, ist einer der großen Nachteile von RIP: Auch wenn eine Route physikalisch langsamer ist, wird sie verwendet, vorausgesetzt sie hat den selben Hopcount wie die anderen Routen.
Hier sehen wir den Ablauf und Aufbau der Routingtabellen in einem Netzwerk mit 3 Routern:
Abbildung 6.2.4.1a: Aufbau der Routingtabellen in
einem RIP-gerouteten Netzwerk
Jeder Schritt benötigt 20 Sekunden. Für dieses Netzwerk ist die Konvergenzzeit deshalb 1 Minute.
6.2.4.1.1 Routing Loops und Split Horizon Challenge (siehe auch Abbildung 6.2.4.1a)
Das Netzwerk 10.1.0.0 geht offline. R3 löscht deshalb den entsprechenden Eintrag aus seiner Liste. Er lernet dann vom Router2, dass es eine Verbindung zum Zielnetzwerk (über R3) gibt, die 1 Hop braucht. Er speichert also ab, dass es einen Weg über R2 gibt, der 2 Hops benötigt. R2 realisiert dann, dass die Route über R3 statt 1 nun 2 Hops benötigt und updated seine Tabelle (stellt also die metric der Route auf 3). Nun empfängt R3 wieder dieses Update usw.
Problem: Es entsteht eine endlose Schleife (dieses Problem wird im Englischen als Counting to infinity bezeichnet).
Abhilfe: Es wird eine Maximalanzahl festgelegt (16). Das löst zwar unser Problem, aber es dauert noch immer sehr lange (16 mal 20 Sekunden), bis der Router das Problem realisiert. Ausserdem gibt es Triggered Updates, das bedeutet Updates werden immer sofort gesandt und nicht erst wenn der Update Intervall eintritt. Dadurch wird die Konvergenzzeit bei einer Änderung geringer und die Wahrscheinlichkeit eines Count to Infinity geringer.
Das Problem entsteht eigentlich dadurch, dass ein Router von einem anderen Router eine Route lernt, die er selbst definiert hat. Um dieses Kernproblem zu lösen, gibt es das Split Horizon Verfahren. Beim Split Horizon Verfahren wird ein Update nur an jene Netzwerke, die nicht über dieselbe Schnittstelle erlernt wurden, weitergesandt.
Auch Split Horizon zieht Probleme mit sich: Die Konvergenzzeit ist sehr hoch (und zwar genau (Anzahl der Router – 1) * Expiration Timer). Der Expiration Timer ist normalerweise 3mal die Updatezeit.
6.2.4.1.2 Route poisoning
Um die schlechte Konvergenz des Split Horizon Verfahrens zu minimieren, wird Route poisoning verwendet. Dabei wird eine nicht erreichbare Route nicht gelöscht, sondern Ihre Hopanzahl auf das Maximum gesetzt – damit werden die anderen Router über die „toten Route“ informiert.
Einige Router können Split Horizon – das selektive Updateverfahren – nicht umsetzen und senden deshalb einfach die Information über die tote Route zurück.
6.2.4.1.2 Hold-down Timer
In einer Schleifenanordnung (einem Kreis) kann trotz Split Horizon ein Count to Infinity passieren – wenn sich Pakete überholen. Um auch dieses Problem auszuschließen, gibt es den Hold Down Timer. Wenn sich die Distanz zu einem Ziel erhöht wird der Hold-Down Timer gestartet. Solange er nicht abgelaufen ist, wird der Router keine Änderungen für diese Route annehmen. Nachteil: Schlechtere Konvergenzzeit. (Default für Hold-Down bei RIP:180sek., IGRP: 280sek.).
6.2.4.1.3 Zusammenfassung der „Count-to-Infinity“ Problematik
Es gibt folgende Maßnahmen, um den Count-to-Infinity zu vermeiden:
- Expiration Timer: Damit ein ausgefallener Router erkannt wird
- Route poisoning
- Maximum beim Hop Count
- Split Horizon mit Poison reverse
- Triggered Update
- Hold Down Timer
6.2.4.1.4 Konfiguration des Routings
Zuerst das Protokoll auswählen:
Router(config)# router rip
Danach ein Netzwerk auswählen:
Router(config-router)# network <Netzadresse>
An allen Interfaces, die in die Netzadresse fallen, werden dann RIP-Pakete ausgesandt.
Ausserdem wird dieses Netz angekündigt.
Die Anzahl der Pfade, auf die der Traffic verteilt wird, lässt sich konfigurieren:
Router(config-router)# maximum-paths <anzahl>
Um das Aussenden von RIP-Paketen an einem Interface zu unterdrücken, dieses aber trotzdem zu routen, kann man ein passives Interface definieren:
Router(config-router)# passive-interface <interface>
In jedem guten Netzwerkdesign werden Interfaces, an denen keine weiteren Router hängen, als passive Interfaces definiert.
Mit show ip protocols können wir die aktivierten (Routing)protokolle und Timer einsehen:
Router# show ip protocols
Mit show ip route können wir die Routingtabelle einsehen:
Router#show ip route
Zur Fehleranalyse steht auch ein Debug-Modus zur Verfügung:
Router#debug ip rip
Beispiel:
Ein Router mit 3 angeschlossenen Netzen:
- 192.17.1.1
- 10.1.0.0
- 10.2.0.0
Wir aktivieren das Netzwerk 10.0.0.0:
Router(config-router)# network 10.0.0.0
Nun werden am Interface 10.1.0.0 und 10.2.0.0 RIP-Pakete ausgesandt. Das Netz 192.17.1.1 wird nicht an den anderen Interfaces angekündigt. Um dieses Netz auch zu routen, müssen wir folgenden Befehl eingeben:
Router(config-router)# network 192.17.1.0
6.2.4.2 IGRP
Die Metrik bei IGRP besteht aus einer Fülle von Parametern, und zwar aus:
- Bandbreite
- Verzögerung
- Zuverlässigkeit
- Last
- MTU
IGRP erlaubt dem Administrator, wesentlich in die Auswahl der Pfade einzugreifen, indem er festlegt welche dieser Parameter in die Metrik einfließen.
Bei IGRP ist die Lastverteilung auf mehrere Pfade – auch Pfade mit unterschiedlicher Distanz (non-equal paths) – möglich.
Die Updateperiode ist per Default auf 90 Sekunden – also dreimal so hoch wie bei RIP – eingestellt.
IGRP unterstützt autonome Systeme.
Per Default wird nur die Bandbreite für die Metrik verwendet.
Bandbreite = 
Wobei KleinsteBandbreite der geringsten Bandbreite entlang der Route entspricht. Die Einheit der Bandbreite ist kilobyte.
Delay = 
Delay wird in µSekunden angegeben.
Metrik = 
Der 2. Teil der Multiplikation wird nur dann durchgeführt, wenn Zuverlässigkeit konfiguriert ist. k1…k5 sind die konfigurierenbaren Werte. Per default sind k1 und k3 gleich 1, alle anderen gleich 0 (sprich per default wird Bandbreite und Delay verwendet, alle anderen Wert ignoriert).
Beispiel:
Abbildung 6.2.4.2a: Beispiel Metrik-Berechnung bei IGRP
Wir berechnen die Metrik von Router1 bis 172.16.0.0:
Bandbreite = = 
= 64102
Delay = = 
= 2001
Metrik = 
= 
= 66103
6.2.4.2.1 Konfiguration von IGRP
Zuerst müssen wir IGRP aktivieren:
Router(config)# router igrp <AS-Nummer>
Die AS-Nummer gibt eine Nummer eines autonomen Systems an.
Die Netzwerke werden genauso wie bei RIP aktiviert:
Router(config-router)# network 10.0.0.0
Da die Wahrscheinlichkeit, dass 2 Routen die gleiche Metrik haben, sehr gering ist, gibt es eine Lastverteilung auch auf mehrere Leitungen, die unterschiedliche Metriken haben (unequal-cost). Dafür lässt sich eine Varianz konfigurieren.
Ist die Metrik einer Route kleiner oder gleich der Metrik der kürzesten Router * der Varianz, so wird die Route als Alternative aufgenommen. Ausserdem muss die Metrik vom Next Hop Router bei der neuen Route zum Ziel kleiner sein als die Metrik der kürzesten Route. Damit wird verhindert, das eine Routingschleife entsteht.
Wie bei RIP wird per Default die Last auf 4 und maximal auf 6 Routen aufgeteilt.
Konfiguration der Lastverteilung:
Router(config-router)# variance <Faktor>
Traffic share lässt sich auf balanced oder Minimum einstellen. Bei balanced wird der Traffic immer gleichmäßig aufgeteilt, bei min. findet eine Lastverteilung erst dann statt, wenn ein bestimmter Wert überschritten wird. Konfiguration:
Router(config-router)# traffic-share <balanced/min>
Beim Addieren des Vektors zu einem empfangenen Routingtabellen-Eintrag werden nur die Parameter des eigenen Interfaces dazuaddiert.
6.2.4.2.2 Verifzieren und debuggen von IGRP
Verifizieren der Protokolle:
Router# show ip protocols
Anzeige der Routingtabelle:
Router# show ip route
Fehleranalyse:
Router# debug ip igrp transaction
Router# debug ip igrp events
IGRP events zeigt nur eine Zusammenfassung der laufenden Aktionen an.
6.2.4.3 RIP Version 2
RIP Version 2 funktioniert genauso wie RIP v1, bietet aber neue Features:
- Subnet Mask wird mitübertragen
- Updates werden als Multicast übertragen
- Authentifizierung möglich
- Next Hoprouter kann angegeben werden
- Externe Routen können verwendet werden
6.3 Administrative Distanz
Um in einem Netz mit mehreren Routingprotokollen zu entscheiden, welches Protokoll verwendet werden soll, gibt es die administrative Distanz.
Die administrative Distanz gibt die Glaubwürdigkeit eines Routingprotokolls wieder. Dabei gilt: Je kleiner der Wert, desto glaubwürdiger ist das Protokoll.
|
Quelle |
Administrative Distanz |
|
Direkt angeschlossen |
0 |
|
Statische Route |
1 |
|
EIGRP |
90 |
|
IGRP |
100 |
|
OSPF |
110 |
|
RIP |
120 |
|
External EIGRP |
170 |
Die administrative Distanz ist konfigurierbar. Damit lässt sich zum Beispiel eine Statische Route als Backup zu einer dynamische Route konfigurieren (dazu setzt man die administrative Distanz der statischen Route auf 130 – sie wird also nur verwendet, wenn es keine RIP-Informationen zu dieser Route gibt).
PRRU Skriptum – Kapitel 6
Dies ist ein Teil des PRRU Skriptums von Markus Wilthaner und anderen Autoren. Bitte die Hinweise zum Copyright unter http://school.wilth.net/prru/ beachten.
E-Mail: contact@wilth.net