3.6 Interior Gateway Routing Protocols

3.6 Interior Gateway Routing Protocols
Routing in einer „Autonomen Einheit“ Distance Vector Routing Routing Information Protocol (RIP) Routing Information Protocol Version 2 (RIP2) Link State Routing Open Shortest Path First (OSPF) Alternative Ansätze IS-IS IGRP / Enhanced IGRP Alle Protokolle sind verteilt und adaptiv (s. RN)

Distance Vector Routing - Prinzipielles Vorgehen
jeder Knoten kennt sich selbst (Distanz = 0), alle anderen Knoten haben eine unendliche Distanz die eigene Routing Tabelle wird in Form von Distanzvektoren auf allen Interfaces ausgegeben periodisch, zufällige Variation der Periode wenn sich die eigene Routing Tabelle geändert hat (als Reaktion auf einen empfangenen Distanzvektor) für jeden empfangenen Distanzvektor wird überprüft ob über den Sender dieses Vektors ein Ziel besser erreicht werden kann, wenn ja: ersetze den bisherigen Eintrag durch einen neuen, bei dem über den Link geroutet wird, über den der Vektor empfangen wurde neue Distanz=Distanz im Vektor + Distanz zum Sender des Vektors

Distance Vector Routing - Cold Start Beispiel
3 6 1 4 2 5 From A to Link Cost From D to Link Cost A local D local From B to Link Cost From E to Link Cost B local E local From C to Link Cost Von A: A=0 auf links 1 und 3 C local

3 6 1 4 2 5 From A to Link Cost From D to Link Cost A local A 3 1 D local From B to Link Cost A 1 1 From E to Link Cost B local E local From C to Link Cost Von B: A=1, B=0 auf links 1, 4, 2 Von D: A=1, D=0 auf links 3, 6 C local

3 6 1 4 2 5 From A to Link Cost From D to Link Cost A local A 3 1 B 1 1 D local D 3 1 From E to Link Cost From B to Link Cost A 4 2 A 1 1 B 4 1 Von A: A=0, B=1, D=1 auf links 1, 3 Von C: A=2, B=1, C=0 auf links 2, 5 Von E: A=2, B=1, D=1, E= 0 auf links 4, 5, 6 B local D 6 1 E local From C to Link Cost A 2 2 B 2 1 C local

From A to Link Cost From C to Link Cost From E to Link Cost A local A 2 2 A 4 2 B 1 1 B 2 1 B 4 1 D 3 1 C local C 5 1 D 5 2 D 6 1 From B to Link Cost E 5 1 E local A 1 1 B local From D to Link Cost A D E C B 3 6 1 4 2 5 C 2 1 A 3 1 D 1 2 B 3 2 E 4 1 D local E 6 1 Von B: A=1, B=0, C=1, D=2, E=1 auf links 1, 4, 2 Von C: A=2, B=1, C=0, D=2, E=1 auf links 2, 5 Von D: A=1, B=2, D=0, E=1 auf links 3, 6 Von E: A=2, B=1, C=1, D=1, E= 0 auf links 4, 5, 6

From A to Link Cost From C to Link Cost From E to Link Cost A local A 2 2 A 4 2 B 1 1 B 2 1 B 4 1 C 1 2 C local C 5 1 D 3 1 D 5 2 D 6 1 E 1 2 E 5 1 E local From B to Link Cost From D to Link Cost A 1 1 A 3 1 A D E C B 3 6 1 4 2 5 B local B 3 2 C 2 1 C 6 2 D 1 2 D local E 4 1 E 6 1

Distance Vector Routing - Link Ausfall
fällt ein Link aus, dann: werden alle Einträge, die über diesen Link geroutet wurden, auf Entfernung unendlich gesetzt und, da sich die Routing Tabelle geändert hat, der neue Distanzvektor auf alle Links geschickt Einträge mit dem Wert unendlich werden nicht im Distanz Vektor übertragen erhält man auf einem Link, über den ein Ziel in der eigenen Routingtabelle geroutet wurde, eine Distanz zu diesem Ziel, die größer ist als bisher, dann muss die Routingtabelle entsprechend aktualisiert werden

Distance Vektor Routing - Link Ausfall Beispiel
From B to Link Cost From D to Link Cost A D E C B 3 6 XXXX 4 2 5 A 1 inf A 3 1 B local B 3 2 C 2 1 C 6 2 D 1 inf D local E 4 1 E 6 1 From A to Link Cost From C to Link Cost From E to Link Cost A local A 2 2 A 4 2 B 1 inf B 2 1 B 4 1 C 1 inf C local C 5 1 D 3 1 D 5 2 D 6 1 E 1 inf E 5 1 E local Von A: A=0, D=1 auf Link 3 Von B: B=0, C=1, E=1 auf Links 2, 4

From A to Link Cost From B to Link Cost From D to Link Cost A local A 1 inf A 3 1 B 1 inf B local B 3 inf C 1 inf C 2 1 C 6 2 D 3 1 D 1 inf D local E 1 inf E 4 1 E 6 1 A D E C B 3 6 XXXX 4 2 5 From C to Link Cost From E to Link Cost A 2 inf A 4 inf B 2 1 B 4 1 C local C 5 1 D 5 2 D 6 1 E 5 1 E local Von C: B=1, C=0, D=2, E=1 auf Link 2, 5 Von D: A=1, C=2, D=0, E=1 auf Links 3, 6 Von E: B=1, C=1, D=1, E=0 auf Links 4, 5, 6

From A to Link Cost From B to Link Cost From D to Link Cost A local A 1 inf A 3 1 B 1 inf B local B 6 2 C 3 3 C 2 1 C 6 2 D 3 1 D 4 2 D local E 3 2 E 4 1 E 6 1 A D E C B 3 6 XXXX 4 2 5 From C to Link Cost From E to Link Cost A 2 inf A 6 2 B 2 1 B 4 1 C local C 5 1 D 5 2 D 6 1 Von A: A=0, C=3, D=1, E=2 auf Link 3 Von B: B=0, C=1, D=2, E=1 auf Link 2, 4 Von D: A=3, B=2, C=2, D=0, E=1 auf Links 3, 6 Von E: A=2, B=1, C=1, D=1, E=0 auf Links 4, 5, 6 E 5 1 E local

From A to Link Cost From B to Link Cost From D to Link Cost A local A 4 3 A 3 1 B 3 3 B local B 6 2 C 3 3 C 2 1 C 6 2 D 3 1 D 4 2 D local E 3 2 E 4 1 E 6 1 From C to Link Cost From E to Link Cost A D E C B 3 6 XXXX 4 2 5 A 5 3 A 6 2 B 2 1 B 4 1 C local C 5 1 D 5 2 D 6 1 E 5 1 E local

Distance Vector Routing - Counting to Infinity
B C From A to Link Cost From D to Link Cost XXXX 2 A local A 3 1 3 4 B 3 3 B 6 inf 5 C 3 3 C 6 inf D XXXX E D 3 1 D local E 3 2 E 6 inf Wenn nun einer der von A periodisch versandten Distanzvektoren bei D ankommt, bevor D den neuen Vektor an A schickt, kommt es zu „Counting to Infinity“. Von A: A=0, B=3, C=3, D=1, E=2 auf Link 3

Distance Vector Routing - Counting to Infinity
From A to Link Cost From D to Link Cost A local A 3 1 B 3 3 B 3 4 Von D: A=1, B=4, C=4, D=0, E=3 auf Link 3 C 3 3 C 3 4 D 3 1 D local E 3 2 E 3 3 From A to Link Cost From D to Link Cost A local A 3 1 B 3 5 B 3 4 Von A: A=1, B=5, C=5, D=1, E=4 auf Link 3 C 3 5 C 3 4 D 3 1 D local E 3 4 E 3 3

Counting to Infinity - Einfache Lösung
man definiert eine Zahl als „unendlich“ diese Zahl muss größer sein, als die größte mögliche Distanz zwischen zwei Knoten wird diese Zahl erreicht, dann wird der Eintrag in der Routing Tabelle auf unendlich gesetzt Probleme: dies dauert entweder sehr lange (wenn die Zahl groß ist), oder die Größe des Netzes/Auflösung der Distanzen wird beschränkt (wenn die Zahl klein ist) während counting to infinity stattfindet werden Pakete im Kreis geroutet

Counting to Infinity - Lösung durch Split Horizon
Idee: wenn Knoten A Pakete zu einem Ziel X über Knoten B routet, dann macht es keinen Sinn für B Pakete nach X über A zu routen! 2 Vorgehensweisen: Distanzvektoren werden individuell für jeden Link berechnet, dabei werden alle Ziele ausgelassen, zu denen über diesen Link geroutet wird Distanzvektoren werden individuell für jeden Link berechnet, dabei wird für alle Ziele, zu denen über diesen Link geroutet wird, die Distanz auf unendlich gesetzt (Poisonous Reverse)

Distance Vector Routing - Split Horizon
B C From A to Link Cost From D to Link Cost XXXX 2 A local A 3 1 3 4 B 3 3 B 6 inf 5 C 3 3 C 6 inf D XXXX E D 3 1 D local E 3 2 E 6 inf Auch wenn nun einer der von A periodisch versandten Distanzvektoren bei D ankommt, bevor D den neuen Vektor an A schickt kommt es zu keinem Problem: Von A: A=0, B=inf, C=inf, D=inf, E=inf auf Link 3 (poisonous reverse)

Distance Vector Routing - Problem bei Split Horizon
XXXX B 2 C From B to Link Cost A 4 3 3 4 5 B local C 2 1 D XXXX E From E to Link Cost D 4 2 A 6 inf E 4 1 B 4 1 Von E: B=inf, C=1, E=0 auf Link 4 (poisonous reverse) Von E: B=1, C=inf, E=0 auf Link 5 (poisonous reverse) Der Distanzvektor auf Link 5 geht verloren und kommt nicht bei C an. C 5 1 From C to Link Cost D 6 inf A 5 3 E local B 2 1 C local D 5 2 E 5 1

Distance Vector Routing - Problem bei Split Horizon
XXXX B 2 C From B to Link Cost A 4 inf 3 4 5 B local C 2 1 D XXXX E From E to Link Cost D 4 inf A 6 inf E 4 1 B 4 1 Nun sei für C die Zeit gekommen, das der Distanzvektor gesendet werden muss (periodische Übertragung). Von C: A=3, B=inf, C=0, D=2, E=1 auf Link 2 (poisonous reverse) Von C: A=inf, B=1, C=0, D=inf, E=inf auf Link 5 (poisonous reverse) C 5 1 From C to Link Cost D 6 inf A 5 3 E local B 2 1 C local D 5 2 E 5 1

Distance Vector Routing - Split Horizon Problem
XXXX B 2 C From B to Link Cost A 2 4 3 4 5 B local C 2 1 D XXXX E From E to Link Cost D 2 3 A 6 inf E 4 1 B 4 1 Von B: A=4, B=0, C=1, D=3, E=inf auf Link 4 (poisonous reverse) Von B: .... uninteressant auf Link 2 (poisonous reverse) C 5 1 From C to Link Cost D 6 inf A 5 3 E local B 2 1 C local D 5 2 E 5 1

Distance Vector Routing - Split Horizon Problem
XXXX B 2 C From B to Link Cost A 2 4 3 4 5 B local C 2 1 D XXXX E From E to Link Cost D 2 3 A 4 5 E 4 1 B 4 1 Jetzt existiert ein 3er Kreis, in dem es zu count to infinity kommt! C 5 1 From C to Link Cost D 4 4 A 5 3 E local B 2 1 C local D 5 2 E 5 1

Distance Vector Routing - Triggered Updates
Wann werden Distanz Vektoren gesendet? periodisch (zufällige Variation der Periode) nach Änderung der Routingtabelle (triggered update) Wenn die triggered updates schnell versandt werden, dann kann es zu counting to infinity nur durch Paketverlust kommen!

Distance Vector Routing - Löschen von Einträgen in der Routingtabelle
wenn ein Eintrag in einer Routingtabelle nicht durch periodisch versandte Distanzvektoren bestätigt wird, wird dieser Eintrag nach einer gewissen Zeit gelöscht dies verhindert das nicht länger gültige Einträge in der Routingtabelle stehen - z.B. wenn der Ausfall eines Links nicht erkannt wurde diese Zeit ist sehr viel größer als die Periode für das Versenden der Distanzvektoren daher: nur bei Verlust mehrerer Distanzvektoren kann dies zum fälschlichen Löschen eines Eintrages führen

Routing Information Protocol (RIP) Version 1
RFC1058, Routing Information Protocol, C.L. Hedrick, Jun , Status: Historic Implementierungen: routed, gated Adressen die in RIP verwendet werden sind 32 bit lange IPv4 Adressen Netzwerkadresse: Subnet ID und Host ID sind 0 Subnetzadresse: Host ID ist 0. Nur erkennbar innerhalb des Netzwerkes zu dem das Subnetz gehört, da nur dort die Informationen über Subnetzaufteilung vorhanden ist. Außerhalb des Netzes werden alle Subnetze zu dem dazugehörigen Gesamtnetz zusammengefasst. Hostadressen: Host ID nicht 0. Optional, muss nicht von jedem Router unterstützt werden.

RIP Version 1 verwendete Metrik:
jeder Knoten hat von jedem direkten Nachbarn den Abstand 1 16 ist unendlich RIP verwendet UDP (port 520) um die Distanzvektoren zu übertragen RIP verwendet split horizon/poisonous reverse triggered updates (mit zufälliger Verzögerung von 1-5 sec.) periodische Übertragung von Distanzvektoren alle 30 sec. timeout für Routingtabelleneinträge von 180 sec.

RIP Version 1 - Nachrichtenformat
7 15 31 IP + UDP header (28 bytes) command (1, 2) version (1) must be zero address family identifier (2) must be zero IP address must be zero must be zero metric weitere Einträge .....

command: 1=request, wird von einem Router verwendet der gerade neu gestartet wurde, um von seinen Nachbarn die Distanzvektoren nachzufragen 2=reply, wird alle 30 Sekunden oder als triggered update oder als Antwort auf einen request verschickt version: 1 address family identifier: 2: IP

RIP Version 2 RFC2453, RIP Version 2, G. Malkin, November 1998
abwärtskompatibel zu RIP Version 1 sehr umstritten, da die „Experten“ der Meinung waren/sind, dass Distance Vektor Routing prinzipiell nicht gut ist (counting to infinity!!!) wichtigste Erweiterungen: subnet routing authentication

7 15 31 IP + UDP header (28 bytes) command (1, 2) version (2) routing domain address family identifier (2,0xFFFF) route tag IP adress subnet mask next hop metric weitere Einträge .....

command: 1=request, 2=reply version: 2 address family identifier: 2: IP 0xFFFF: Authentication routing domain + route tag: Unterstützung mehrerer Autonomer Systeme auf dem selben LAN subnet mask: bessere Unterstützung von subnets next hop: wird in Zusammenspiel mit exterior gateway protocols (EGP, BGP) verwendet – hier nicht betrachtet

RIP Version 2 - Routing per Subnet
da die subnet mask bei RIP 2 mitgeschickt wird, kann man: auch außerhalb eines Netzes für dessen verschieden Subnetze unterschiedliche Wege wählen Subnetzmasken innerhalb eines Netzes verschieden breit wählen außerdem unterstützt dies classless interdomain routing CIDR (besprechen wir später!)

RIP Version 2 - Authentication
in RIP Version 1 kann jeder die Routingtabellen durch das Verschicken von Distanzvektoren beliebig manipulieren in RIP Version 2 kann das erste Element eines Vektors Authentifikationsinformationen enthalten 16 byte Passwort, oder digitale Unterschrift über das gesamte Paket ist nicht wirklich sicher, da 16 byte zu wenig sind!

RIP Version 2 - Authentication
7 15 31 IP + UDP header (28 bytes) command (1, 2) version (2) routing domain address family identifier (0xFFFF) authentication type authentication (16 bytes) weitere Einträge ..... authentication type 2 Passwort andere Werte sind spezifiziert, z.B. MD-5 Hash authentication Daten, ja nach authentication type (z.B. Passwort)

Distance Vector Routing / RIP- Zusammenfassung
sehr einfach zu implementieren grobe Fehler sind unwahrscheinlich ABER bei Veränderungen: stabilisiert sich das Netz unter Umständen nur sehr langsam (counting to infinity) während dieser Zeit gibt es Schleifen RIP wird zunehmend von anderen Routingverfahren verdrängt die nicht auf Distance Vector Routing basieren, obwohl es auch neuere Distance Vector Routing Ansätze gibt, bei denen counting to infinity komplett vermieden wird. Diese sind allerdings nicht mit RIP kompatibel.

Link State Routing - Generelle Idee
jeder Knoten besitzt eine vollständige Karte des Netzwerkes in Form einer Datenbank (dies ist NICHT! die Routingtabelle) jeder Knoten berechnet anhand dieser Karte die Einträge in die Routing Tabelle bei Veränderungen der Topologie werden die relevanten Informationen im Netz geflutet

Link State Routing - Ausgangssituation
1 B 2 C 3 4 5 D 6 E Karte/Datenbank: From To Link Cost Number From To Link Cost Number A B 1 1 1 C E 5 1 1 A D 3 1 1 D A 3 1 1 B A 1 1 1 D E 6 1 1 B C 2 1 1 E B 4 1 1 B E 4 1 1 E C 5 1 1 C B 2 1 1 E D 6 1 1

Link State Routing - Link Ausfall
XXXX B 2 C 3 4 5 D 6 E From A, to B, link 1 distance = infinite, number 2 From B, to A, link 1 distance = infinite, number 2

Link State Routing - Nachrichtenbehandlung
Empfange Nachricht. Schlage den entsprechenden Eintrag in der Datenbank nach. Wenn kein Eintrag existiert, füge die Nachricht als neuen Eintrag in die Datenbank ein, leite die Nachricht an alle Interfaces weiter, außer dem Interface auf dem die Nachricht empfangen wurde. Wenn ein Eintrag mit niedrigerer Nummer vorhanden ist, aktualisiere den Eintrag und leite die Nachricht weiter. Wenn ein Eintrag mit höherer Nummer vorhanden ist, schicke diesen Eintrag über das Interface, auf dem die veraltete Nachricht erhalten wurde zurück. Wenn ein Eintrag mit derselben Nummer vorhanden ist, ignoriere die Nachricht.

Link State Routing - Link Ausfall
Karte/Datenbank nachdem die Informationen über den Linkausfall von A und B geflutet wurden: From To Link Cost Number From To Link Cost Number A B 1 inf 2 C E 5 1 1 A D 3 1 1 D A 3 1 1 B A 1 inf 2 D E 6 1 1 B C 2 1 1 E B 4 1 1 B E 4 1 1 E C 5 1 1 C B 2 1 1 E D 6 1 1

Link State Routing - Bringing Up Adjacencies
XXXX B 2 C 3 4 5 D XXXX E From D, to E, link 6 distance = infinite, number 2 From E, to D, link 6 distance = infinite, number 2 Im Folgenden werden die Topologieinformationen für die beiden Partitionen unterschiedlich sein! Wir wollen verstehen, wie sich diese Unterschiede wieder angleichen, wenn die Konnektivität wieder hergestellt wird. Dieser Vorgang heißt „Bringing Up Adjacencies“.

From To Link Cost Number From To Link Cost Number A B 1 inf 2 A B 1 inf 2 A D 3 1 1 A D 3 1 1 B A 1 inf 2 B A 1 inf 2 B C 2 1 1 B C 2 1 1 B E 4 1 1 B E 4 1 1 C B 2 1 1 C B 2 1 1 C E 5 1 1 C E 5 1 1 D A 3 1 1 D A 3 1 1 D E 6 inf 2 D E 6 1 1 E B 4 1 1 E B 4 1 1 E C 5 1 1 E C 5 1 1 E D 6 1 1 E D 6 inf 2 Datenbank von A und D Datenbank von B, C und E

XXXX B XXXX C 3 4 5 D XXXX E From B, to C, link 2 distance = infinite, number 2 From C, to B, link 2 distance = infinite, number 2 Diese Informationen werden nur in einer Partition geflutet (die andere ist nicht zu erreichen)!

From To Link Cost Number From To Link Cost Number A B 1 inf 2 A B 1 inf 2 A D 3 1 1 A D 3 1 1 B A 1 inf 2 B A 1 inf 2 B C 2 1 1 B C 2 inf 2 B E 4 1 1 B E 4 1 1 C B 2 1 1 C B 2 inf 2 C E 5 1 1 C E 5 1 1 D A 3 1 1 D A 3 1 1 D E 6 inf 2 D E 6 1 1 E B 4 1 1 E B 4 1 1 E C 5 1 1 E C 5 1 1 E D 6 1 1 E D 6 inf 2 Datenbank von A und D Datenbank von B, C und E

1 B XXXX C 3 4 5 D XXXX E From A, to B, link 1 distance = 1, number 3 From B, to A, link 1 distance = 1, number 3 Jetzt existiert wieder ein einziges unpartitioniertes Netz. Allerdings mit inkonsistenten Datenbanken.

From From Link Cost Number From From Link Cost Number A B 1 1 3 A B 1 1 3 A D 3 1 1 A D 3 1 1 B A 1 1 3 B A 1 1 3 B C 2 1 1 B C 2 inf 2 B E 4 1 1 B E 4 1 1 C B 2 1 1 C B 2 inf 2 C E 5 1 1 C E 5 1 1 D A 3 1 1 D A 3 1 1 D E 6 inf 2 D E 6 1 1 E B 4 1 1 E B 4 1 1 E C 5 1 1 E C 5 1 1 E D 6 1 1 E D 6 inf 2 Datenbank von A und D Datenbank von B, C und E

sobald ein Link wieder hochfährt: database description packets werden ausgetausch, diese identifizieren die Einträge in der Datenbank und die jeweilige Nummer: z.B. From A, to B, Number 3 der Austausch findet zwischen den beiden Knoten statt, zwischen denen die Verbindung wieder hergestellt wurde diese Beschreibung wird vom Empfänger überprüft, sind Einträge vorhanden, die eine höhere Nummer haben, als in der eigenen Datenbank, dann werden diese Einträge mit Hilfe von link state request packets angefordert dieses Vorgehen minimiert das Volumen der Daten, die übertragen werden müssen

Link State Routing - Sicherung der Updates
Nachrichten werden beim Fluten bestätigt Jeder Datenbankeintrag wird durch einen Timer überwacht, der Eintrag wird gelöscht, wenn der Timer abläuft, bevor der Eintrag durch periodische Übertragung bestätigt wird Einträge werden mit einer Checksumme gegen Änderungen geschützt Nachrichten können beim Fluten authentifiziert werden (Passwort, Signatur)

Link State Routing - Lokale Berechnung der Routing Tabelle
Mit Hilfe des von Dijkstra entwickelten „shortest Path first“ Algorithmus: Initialisiere E mit dem Sender S, und R mit allen anderen Knoten. Initialisiere O mit allen Pfaden, die von S einen Schritt weit entfernt sind. Sortiere diese Pfade nach ihren Kosten. Wenn O leer ist, oder alle Pfade in O unendliche Kosten haben, dann markiere alle Knoten in R als nicht erreichbar. Ende. Sei P der kürzeste Pfad in O, entferne P aus O. Sei V der letzte Knoten in Pfad P. Wenn V in E vorhanden ist dann weiter mit Schritt 2. Ansonsten ist P der kürzeste Pfad von S nach V. Konstruiere neue Pfade, die P als Basis haben und die um die Pfade die von V einen Schritt weit wegführen. Füge diese in O in sortierter Weise ein. Gehe zu Schritt 2.

Link State Routing - Lokale Berechnung der Routing Tabelle - Beispiel
1 B 5 C Achtung! Nun repräsentieren die Zahlen die „Distanz“ (= Verzögerung, Kosten, etc.) zwischen zwei Knoten. 2 2 1 D 2 E E={A, B, D, E}, R={C} O={A-D-E-4, A-B-E-C-4, A-B-C-6} Kürzeste Pfade: {A-B-1, A-D-2, A-B-E-3} E={A}, R={B, C, D, E} O={A-B-1, A-D-2} Achtung 2 Schritte!!! E={A, B, C, D, E}, R={} O={A-B-C-6} Kürzeste Pfade: {A-B-1, A-D-2, A-B-E-3, A-B-E-C-4} E={A, B}, R={C, D, E} O={A-D-2, A-B-E-3, A-B-C-6} Kürzeste Pfade: {A-B-1} E={A, B, D}, R={C, E} O={A-B-E-3, A-D-E-4, A-B-C-6} Kürzeste Pfade: {A-B-1, A-D-2} Dann noch 1 weiterer Schritt bis zum Ende!

Link State Routing - Vorteile
schnelle Konvergenz ohne Schleifen mehrere Metriken können gleichzeitig verwendet werden: z.B. für IP Pakete mit unterschiedlichem Inhalt im Type of Service Feld für ein und dasselbe Paket muss dann aber dieselbe Metrik für das Routing verwendet werden

Link State Routing - Vorteile
es muss nicht immer über den kürzesten Pfad geroutet werden: man kann Pakete alternierend über mehrere annähernd gleich gute Pfade schicken es lässt sich mathematisch zeigen, dass dies den Gesamtdurchsatz des Netzes deutlich verbessert dabei besteht aber die Gefahr, dass partielle Schleifen entstehen dies kann man verhindern indem Pakete nur zu Knoten weitergeleitet werden dürfen, die näher am Ziel sind als der Knoten an dem sie sich momentan befinden

Open Shortest Path First (OSPF)
Open Shortest Path First ist die Spezifikation der IETF für Link State Routing: J. Moy, „OSPF Version 2“, RFC-1247, 1991 Open, da es in offener Weise von der IETF standardisiert wurde Shortest Path First, da der gleichnamige Dijkstra Algorithmus verwendet wird 3 Nachrichtentypen werden in OSPF definiert: hello - erkennen ob Nachbarn da sind exchange - Bringing Up Adjancencies flooding - update der Netzwerkkarte bei laufendem Betrieb OSPF wird direkt über IP verwendet (Protokoll Typ 89)

OSPF - Gemeinsamer Header
7 15 31 IP header (20 bytes) - protocol type 89 version (2) type (1-5) packet length router ID area ID checksum autype authentication authentication type specific header

OSPF - Gemeinsamer Header
version: 2 type: OSPF Nachrichtentype 1-5 packet length: Anzahl der bytes im Paket router ID: IP Adresse des Routers (eine wird ausgewählt um diesen zu identifizieren) area ID: identifiziert ein Gebiet (dient der hierarchischen Gestaltung eines OSPF Netzes - in dieser Vorlesung nicht besprochen!) checksum: über das ganze Paket (ohne IP header), wird wie für den IP header berechnet autype: welche Art der Authentifizierung wird gewählt (0=keine, 1= Passwort, andere) authentication: z.B. Passwort

OSPF - Hello Protocol 7 15 31 OSPF packet header, type=1 (hello)
7 15 31 OSPF packet header, type=1 (hello) network mask hello interval options priority dead interval designated router backup designated router neighbor more neighbors ...

OSPF - Hello Protocol network mask: des Subnetzes, auf welches das hello Packet geschickt wurde hello interval: in diesem Intervall wird die Hello Nachricht wiederholt dead interval: wenn keine Nachricht von einem Nachbar Router in dieser Zeit empfangen wurde, dann gilt die Verbindung als gestört, der Eintrag wird entfernt neighbor: in dieser Liste stehen alle Nachbarn, von denen ein hello in den letzten dead interval Sekunden empfangen wurde alle anderen Felder: hier nicht behandelt (s. Huitema Buch oder RFC 1247)

OSPF - Hello Protocol für OSPF gilt eine Verbindung zwischen zwei Routern als hergestellt, wenn sie gegenseitig ihre Hello Nachrichten empfangen können dies erkennt man daran, daß man eine Hello Nachricht von einem Nachbarn empfängt, in der man selbst in der neighbor Liste eingetragen ist der Zusammenbruch von Verbindungen kann durch timeout (dead interval) oder durch Signale von unteren Netzwerkschichten erkannt werden

OSPF - Exchange Protocol
7 15 31 OSPF packet header, type=2 (database descritpion/dd) must be 0 options must be 0 IMMS DD sequence number link state type link state ID advertising router link state sequence number link state checksum link state age more record descriptions

OSPF - Exchange Protocol
IMMS: 3 Bits (initialize, more, master-slave) die zur Signalisierung verwendet werde (s. unten). DD sequence number: Sequenznummer für dd Pakete. Link State Type - Link State Age: Zusammenfassung eines Eintrages in der Datenbank. Kommt für jeden Eintrag in der Datenbank einmal vor. Link State Type: Es gibt verschiedene Arten von Links, z.N. von Router zu Router, von Router in ein Subnetz, von Router in externe Netze, etc. wir betrachten nur Router-Router. Link State ID + Advertising Router: identifiziert zusammen mit Link Stae Type eindeutig die Informationen die angekündigt werden. Rest ist selbsterklärend Achtung! Bei OSPF beinhaltet ein Datenbankeintrag alle Wege, die von einem Router berichtet werden – daher werden die Einträge sehr kompakt!

OSPF - Exchange Protocol - Funktionsweise
Wenn ein neuer Link hochfährt: Sende ein leeres dd Paket mit IMMS = und einer initialen DD sequence number. Warte auf Antwort, wenn Timeout, dann wiederhole die Übertragung. Wenn man ein dd Paket bekommt: Falls man selbst keines geschickt hat wird man slave und antwortet mit einem dd Paket mit IMMS = und der gleichen Sequenznummer, sowie einer Zusammenfassung der eigenen Einträge in der Datenbank soweit diese in ein einziges Paket passt. Wenn man eines geschickt hat, dann haben sich beide Pakete im Netz überkreuzt (oder es ist eines verloren gegangen). Dann wird derjenige slave, der die niedrigere IP Adresse hat. Dieser antwortet entsprechen.

nachdem der Master bestimmt ist, sendet dieser eine Zusammenfassung aller seiner Datenbankeinträge: IMMS = 0 1 1, solange weitere Pakete folgen IMMS = 0 0 1, für das letzte Paket jedes dieser Pakete wird vom slave bestätigt mit einem leeren dd Paket, dessen Sequenznummer gleich der empfangenen Sequenznummer ist wenn keine Bestätigung eintrifft wiederholt der master die Übertragung des Paketes wenn der Master mit der Übertragung fertig ist setzt er im letzten Paket IMMS auf 0 0 1, daraufhin sendet der slave die Beschreibung seiner Einträge, wenn der slave ein Paket mit IMMS sendet ist diese Phase beendet

7 15 31 OSPF packet header, type=3 (request/rq) link state type link state ID advertising router more record requests nun wissen beide Teilnehmer welche Einträge in der Datenbank beim anderen Teilnehmer aktuelle sind, diese werden nachgefragt geantwortet wird wie beim OSPF - Flooding Protocol, das wir gleich besprechen

OSPF - Flooding Protocol
7 15 31 OSPF packet header, type=4 (link state update) number of advertisements link state age options link state type link state ID advertising router link state sequence number link state checksum link state length zero or more link descriptions .... link state age options link state type link state ID ....

in jeder link state update Nachricht können mehrere link state advertisements enthalten sein link state age - link state checksum: wie IP für Exchange protocol link state length: Gesamtlänge diese Eintrages link descriptions: Beschreibung der links, die von dem advertising router ausgehen. Dies beinhaltet Metriken, die für jeden IP type of service getrennt angegeben werden können. Jeder Eintrag ist recht gross: 50+ bytes.

OSPF Link Description (Beispiel!)
7 15 31 Flags Number of Links Link ID Link Data Type Number of TOS Default Metric TOS Must be 0 TOS Metric .... TOS Must be 0 TOS Metric Link ID Link Data ....

OSPF Link Description Link ID: Identifiziert einen Link
Link Data: genauere Beschreibung des Links, z.B. IP Adresse des Nachbarn falls es ein Link zu einem anderen Router ist. Type: Art des Links, z.B. zu einem anderen Router, in ein Subnetz, etc. Default metric: Metrik die normalerweise für diesen Link verwendet wird. TOS/TOS Metrik: Metriken die für bestimmte TOS verwendet werden.

7 15 31 OSPF packet header, type=5 (link state acknowledgement) link state age options link state type (1) link state ID advertising router link state sequence number link state checksum link state length more acknowledgement

Link State Routing/OSPF -Zusammenfassung
relative komplex OSPF RFC hat 186 Seiten OSPF braucht 5 Nachrichtentypen und baut auf zuverlässige Nachrichtenübertragung durch acknowledgements ABER: OSPF ist sehr viel effizienter als RIP da routing wichtig ist, wird die zusätzliche Komplexität für eine Steigerung der Effizienz in Kauf genommen, OSPF setzt sich zunehmend gegen RIP durch

Alternative Ansätze - IS-IS
Intra-Domain Intermediate System to Intermediate System Routeing Protocol ISO-OSI Vorschlag Routing basiert auf Link State Technologie, wie OSPF

Alternative Ansätze - IGRP
Interior Gateway Routing Protocol proprietäres Protokoll der Firma cisco verwendet distance vector Technik verbessert RIP in einigen entscheidenden Gebieten: verschiedene Metriken besserer Schutz vor Schleifen alternierendes Routing auf mehreren Pfaden einige der Verbesserungen sind von cisco patentiert

Alternative Ansätze - EIGRP
Enhanced Interior Gateway Routing Protocol proprietäres Protokoll der Firma cisco verwendet distance vector Technik verbessert IGRP: es ist loop-free wird von einigen Experten als die bessere Lösung im Vergleich mit OSPF betrachtet, da die Komplexität niedriger ist, aber ein propritäres Protokoll mit patentierten Bestandteilen ist problematisch!

Wie sieht das Internet aus?
Exkursion NAPs, POPs und ISPs: Wie sieht das Internet aus?

Das Internet (USA) 1969 Aus: Sam Halabi: „Internet Routing Architctures“, second edition.

Das Internet (USA) - Gegenwart
Aus: Sam Halabi: „Internet Routing Architctures“, second edition.

ISP Ein Internet Service Provider (ISP) stellt den Zugang zum Internet zur Verfügung: Über Standleitungen/Einwahlverbindungen/DSL/etc. Kann auch Zugang für andere ISPs bereitstellen (wird dann manchmal Network Service Provider (NSP) genannt) Kann erweiterte Dienste anbieten: Web-Hosting Sicherheitsgarantien Hardwareverleih und -pflege

POP Ein point-of-presence (POP) ist eine Einrichtung bei der ein ISP physikalisch präsent ist: Niederlassung Kabelhäusschen Ein POP ermöglicht den Zugang zu diesem ISP POPs können gemeinsam benutzt werden (siehe Telekom)

NAP Ein Network Access Point (NAP) ist eine Ansammlung von Routern mehrerer ISPs, er dient dem Weiterleiten des Verkehrs zwischen ISPs (peering). ISPs können auch direkt untereinander verbunden sein (direct interconnection): auch dies ist ein peering. Probleme Wo lohnt sich der Anschluss an einen NAP, wann ist eine direkte Verbindung sinnvoll? wer zahlt wem wieviel Geld für welche Leistung?

3.7 Exterior Gateway Routing Protocols
ursprünglich war das Internet eine einzige Einheit, d.h. ein einziges homogenes routing Protokoll wurde für das gesamte Internet verwendet (Gateway to Gateway Protocol - GGP) große routing Tabellen hoher Kommunikationsoverhead Interoperabilität zwischen Routern verschiedener Hersteller war schwierig Umstellung auf neue Routingprotokolle war nahezu unmöglich Lösung: das Netzwerk wird in Autonome Einheiten eingeteilt, in jeder dieser Einheiten kann individuell geroutet werden Routing zwischen „Autonomen Einheiten“ über exterior gateway routing protocols

Autonomous System AS=„A set of routers and networks under the same administration“ technische Definition: alle Bestandteile eines AS müssen intern miteinander verbunden sein jedem AS wird eine 2 Byte lange Autonomous System ID zugewiesen i.d.R. sollte in einem AS genau ein Interior Gateway Routing Protocol (z.B. OSPF) verwendet werden zwischen AS wird ein Exterior Gateway Protocol verwendet: Exterior Gateway Protocol (EGP) - inzwischen veraltet, da es von einer Internetarchitektur ausgeht, bei der die AS über EIN backbone Netz miteinander verbunden sind Border Gateway Protocol (BGP-4) - wird zur Zeit verwendet

Autonomous System Definition im BGP RFC
The classic definition of an Autonomous System is a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS and using an exterior gateway protocol to route packets to other AS's. Since this classic definition was developed, it has become common for a single AS to use several interior gateway protocols and sometimes several sets of metrics within an AS. The use of the term Autonomous System here stresses the fact that, even when multiple IGPs and metrics are used, the administration of an AS appears to other AS's to have a single coherent interior routing plan and presents a consistent picture of which destinations are reachable through it.

Warum eigenständige Exterior Routing Protokolle und nicht RIP oder OSPF?
Die interior gateway protocols (IGPs) sind für eine kleine Anzahl an Routern gedacht (z.B. OSPF <200) exterior gateway protocols müssen viele tausend AS miteinander verknüpfen. Die IGPs gehen von einem homogenen Umfeld aus, bei dem ein und dasselbe Paket nach einer einzigen Politik geroutet wird (minimiere Verzögerung/Kosten, etc.) dies ist nicht mehr der Fall, wenn ein Paket die Grenzen eines AS verlässt. Hier kann jeder Router eines neue AS verschiedene Prioritäten setzen, wenn man dies nicht berücksichtigt kommt es zu Routing Schleifen und anderen Anomalien!

IPv4 Probleme für Exterior Gateway Routing
Class B Exhaustion Routing Table Explosion

Problem 1: Class B Exhaustion
Class A Adressen sind nur unter sehr besonderen Umständen zu bekommen Class C Adressen sind i.d.R. zu klein für eine Netzwerkstruktur Class B Adressen sind bevorzugte Wahl in vielen Fällen, sind aber in aller Regel zu groß, d.h. es werden Adressen „verschwendet“ ABER: es gibt nur Class B Adressen! diese wären bis März 1994 aufgebraucht gewesen, hätte man keine Gegenmaßnahmen ergriffen

Problem 2: Routing Table Explosion
je mehr Netzwerke an das Internet angeschlossen werden, desto größer werden die Routing Tabellen für Exterior Gateway Routing Protocols das Wachstum der an das Internet Angeschlossenen Netze war in den letzten Jahren exponentiell! daher sind die Routingtabellen förmlich „explodiert“ Speicherprobleme und Zeitprobleme bei der Bestimmung von Routen sind die Folge in 1993 hatte man bereits Routing Tabellen mit über Einträgen!

Kurzfristige Lösung: Classless Iterdomain Routing (CIDR)
Organisationen bekommen nicht mehr eine Class B Adresse (die zu groß für sie wäre) sondern soviele zusammenhängende Class C Adressen wie sie benötigen die Verteilung der Class C Adressen erfolgt nicht zufällig sondern nach einem Schema, welches deren Aggregation beim Routing erlaubt dies erfolgt hierarchisch, z.B.: Europa: North America: etc. so können z.B. alle Ziele die sich in Europa befinden in den USA mit einem einzigen Routing Tabellen Eintrag bezeichnet werden!

CIDR Provider based Allocation
auf einer tieferen Ebene (Kontinental/National) muss berücksichtigt werden, dass Provider lieber innerhalb ihres Netzes routen und es u.U. nur 1 oder 2 Austauschpunkte zwischen den Provider in einem Land/Kontinent gibt eine feinere Unterteilung sollte daher auf Provider Basis erfolgen Problem: dann „gehören“ die Adressen dem jeweiligen Provider und man kann sie nicht beibehalten, wenn man den Provider wechselt!

CIDR – Beispiel für Adressvergabe
Router in den USA 194.x.x.x x.x.x über Link 1 Link 1 Router im Europäischen Backbone (z.B. London) 194.0.x.x x.x über Link 2 nach D x.x x.x über Link 3 nach F Link 2 Router im Deutschen Backbone (z.B. Berlin) 194.0.x.x x.x über Link 10 nach T-Online D 194.9.x.x x.x über Link 11 nach AOL D Link 10 Link 12

Weltweite Adresseinteilung

CIDR – Beispiel für Routinginformationen

CIDR – Longest Match Routing Rule
Aus: Sam Halabi: „Internet Routing Architctures“, second edition. Verwende den Weg, bei dem das Ziel am genausten (mit den meisten bit) beschrieben wird.

CIDR: Verwendung von fremden Adressen
Wenn man Adressen verwendet, die nicht zum Bereich des eigenen ISP gehören, dann: Kann der eigene ISP die Adressen nicht aggregieren Kann der ISP zu dem die Adressen gehören diese nicht mehr aggregieren, da man ein „Loch“ in seinen Adressraum gerissen hat.

CIDR: Multihoming Problem
Achtung: wenn man Adressen aggregiert, die einem nicht gehören, kann es zu „Black Holes“ kommen! Aus: Sam Halabi: „Internet Routing Architctures“, second edition.

CIDR: Multihoming Lösung
Keine Aggregation von fremden Adressen! Aus: Sam Halabi: „Internet Routing Architctures“, second edition.

CIDR: Multihoming Problem II
Wenn einer der ISPs ausfällt, dann sind in Largenet die entsprechenden Adressen nicht mehr zu erreichen. Aus: Sam Halabi: „Internet Routing Architctures“, second edition.

CIDR: Multihoming Lösung II
/20 /20 Ankündigen des spezifischen Netzes, keine Aggregation! Aus: Sam Halabi: „Internet Routing Architctures“, second edition.

Anforderungen an ein Border Gateway Protocol
komplette weltweite Vernetzung ist erforderlich die Granularität sollte auf AS Ebene liegen “Politisches” Routing sollte möglich sein CIDR sollte unterstützt werden dabei muss berücksichtigt werden, dass viele IP-Adressen bereits vor Einführung von CIDR vergeben wurden es darf keine Routing-Schleifen geben Border Gateway Protocol Version 4 (BGP-4) erfüllt diese Anforderungen im Wesentlichen, und wird heute weltweit eingesetzt!

Border Gateway Protocol Version 4 (BGP-4)
Y. Rekhter, T. Li. A Border Gateway Protocol 4 (BGP-4). RFC Wichtiges Ziel in BGP-4 ist es, dass jedes AS autonom mit Hilfe von Politiken entscheiden kann, wie der Verkehr in das/aus dem eigenen AS und wie Verkehr aus anderen AS (transit Verkehr) weitergeleitet wird. Dies ist mit IGPs nicht möglich! Der wesentliche Fortschritt von BGP-3 nach BGP-4 war die Unterstützung von CIDR.

BGP–4 Grundlagen: Architektur
EBGP BR1 IBGP IGP BR2 IR1 IGP IGP EBGP IR2 IR3 IGP AS: 100

EBGP External Border Gateway Protocol (EBGP):
wird zwischen einem BGP fähigen Routern (BGP Speaker) eines AS und einem BGP Speaker eines anderen AS verwendet dient der Mitteilung von Routen die von einem AS dem anderen AS zur Verfügung gestellt werden ist Bestandteil von BGP-4

IBGP Internal Border Gateway Protocol (IBGP):
wird zwischen BGP Speakern innerhalb eines AS verwendet sorgt für eine konsistente Sicht aller BGP Speaker in einem AS auf alle Routen nach außen ist Bestandteil von BGP-4

IGP (Routen von Innen nach Außen)
Interior Gateway Protocol (IGP): ist das von diesem AS verwendete routing Protokoll für das Routing innerhalb des AS (z.B. RIP oder OSPF) Routen die vom Inneren des AS nach außen führen können auf zwei prinzipielle Arten im IGP behandelt werden: 1. Möglichkeit: es gibt einen standard BGP Speaker an welchen alle Pakete nach außen weitergeleitet werden. 2. Möglichkeit: die BGP Speaker leiten die Informationen über Routen in das IGP weiter (als Distanzvektoren für RIP2, als Topologieinformationen in Form von externen Links in OSPF) Häufig wird die 1. Möglichkeit verwendet, da man die Komplexität (Anzahl der Routen) im IGP gering halten möchte.

Routen von Außen nach Innen
Die BGP Speaker können von den Routen ins Innere auf zwei Arten erfahren: durch das IGP – Problem hierbei ist das häufige Veränderungen in einem AS zu häufigen Routenupdates (u.U. weltweit!) von BGP führen. durch statische Konfiguration – Probleme entstehen hier weil sich die BGP Informationen nicht an die aktuelle Situation anpassen. Beispiel: BR2 kündigt statisch die Erreichbarkeit aller Systeme im AS 100 an die Verbindung zwischen IR2 und IR3 bricht IR1 und IR2 sind nicht mehr erreichbar (obwohl externe System sie über BR1 erreichen könnten)

Routen von Außen nach Außen (Transitverkehr)
Auch hier gibt es zwei Möglichkeiten: Transitverkehr wird durch das AS durchgeleitet. Dabei sind auch Router involviert, die keine BGP Speaker sind. Problem: um die Pakete weiterleiten zu können muss das IGP die Information über alle externen Routen haben. Das macht i.d.R. keinen Sinn, da man genau dieses durch BGP verhindern möchte. Transitverkehr wird nur von BGP Speaker zu BGP Speaker weitergeleitet. Dies ist bei weitem der häufigste Fall in der Praxis.

BGP-4 Grundlagen: Pfad Vektor
BGP verwendet zum Mitteilen von Routen Informationen sogenannte Pfad Vektoren. Ein Pfad Vektor beinhaltet die Nummer der AS, die auf der Route liegen. Hierdurch kann eine Schleifenbildung sicher verhindert werden. Durch den Pfad Vektor erhält man auch Informationen über den Weg, den ein Paket auf dieser Route nehmen wird. Dies erlaubt Routing Politiken, die bestimmte Pfade bevorzugen.

Pfadvektor & Aggregation von Routen
AS X 24 / AS T (Provider) es werden lokal 24 / und 24 / verwendet AS Z AS Y 24 / Ziel: der Provider würde gerne eine einzigen Eintrag der Art 22 / an AS Z weitergeben Frage: was wird in die Liste der AS geschrieben, die wir mit der Route durchqueren, wenn mehrere Einträge aggregiert werden?

Pfadvektor & Aggregation von Routen
1. Möglichkeit: nur T das kann zu Schleifen über X und Y führen, da die Informationen fehlen, dass diese AS in der Route enthalten sind! 2. Möglichkeit: T, X und Y auch nicht gut, da dies wie ein Pfad aussieht, der durch 3 AS führt! Lösung die Informationen werden in 2 Teile zerlegt, eine Liste und eine Menge: Pfad (T), Menge (X, Y) wenn der Pfad z.B. von Z weitergeleitet wird kommt Z in de Liste: Pfad (Z, T), Menge (X, Y) wenn die Pfade rekursiv weiter aggregiert werden, dann wird der Pfad zur Schnittmenge aller aggregierten Pfade und die Menge beinhaltet alle anderen AS aus der Vereinigung aller Pfade und Mengen

BGP-4: Routing Politiken I
Aus: S. Halabi: Internet Routing Architectures. Second Edition. Cisco Press, Sehr empfehlenswert zum Verständnis von BGP.

BGP-4 Routing Politiken II
Empfangene Routen: ein BGP-Speaker empfängt Erreichbarkeitsinformationen von benachbarten BGP-Speakern Eingabe Politik hier werden die empfangenen Erreichbarkeitsinformationen nach unterschiedlichen Kriterien gefiltert: Pfadvektor Präfix andere Kriterien

BGP-4 Routing Politiken III
Entscheidungsprozess unter den noch vorhandenen Erreichbarkeitsinformationen werden die „besten“ ausgewählt, die kann wieder durch Politiken beeinflusst werden. Ausgabe Politiken wie bei den Eingabe Politiken werden auch die an die Nachbar BGP-Speaker anhand verschiedener Kriterien gefiltert man kann so z.B. vermeiden, dass man als transit AS für gewisse andere AS verwendet wird (zur Sicherheit erfordert dies i.d.R. auch eine Filterung des Datenverkehrs)

BGP-4: Routing Politiken - Beispiel
Aus: S. Halabi: Internet Routing Architectures. Second Edition. Cisco Press, Sehr empfehlenswert zum Verständnis von BGP.

BGP-4 Zuverlässigkeit BGP-4 benutzt ein zuverlässiges Transportprotokoll (TCP) für die Kommunikation zwischen Routern dies reduziert die Komplexität des Protokolls, erhöht aber gleichzeitig die Abhängigkeit (TCP ist Voraussetzung für die Verwendung von BGP-4)

BGP-4 Generelle Funktionsweise
zunächst wird zwischen zwei Routern auf TCP Ebene eine Verbindung hergestellt dann erfolgt ein Nachrichtenaustausch um eine BGP Verbindung herzustellen (OPEN + KEEPALIVE) dann werden die kompletten BGP Routing-Tabellen als Pfad Vektoren ausgetauscht (UPDATE) anschließend werden nur noch die Veränderungen an dieser Tabelle dem jeweiligen Partner mitgeteilt - es erfolgt kein weiterer Austausch der vollständigen Tabelle (UPDATE) periodisch wird geprüft of der Kommunikationspartner noch da ist (KEEPALIVE)

BGP-4 Gemeinsamer Header
7 15 31 marker (16 byte) length type (1-4) marker: der Inhalt dieses Feldes wird durch von BGP getrennt spezifizierte Sicherheitsalgorithmen festgelegt, er soll der Authentifikation dienen length: Gesamtlänge des Paketes - notwendig, da TCP einen byte-stream verschickt und keine einzelnen Pakete type: Pakettyp (1=OPEN, 2=UPDATE, 3=NOTIFICATION Fehlermeldung - hier nicht weiter besprochen, 4=KEEPALIVE)

<Type, Length, Value>
BGP-4 OPEN 7 15 31 marker (16 byte) length type: OPEN version my autonomous system hold time BGP identifier opt. param. len. optional parameters <Type, Length, Value>

BGP-4 OPEN wird versendet sobald eine Transport (TCP) Verbindung hergestellt ist version: 4 für BGP-4 my autonomous system: Identifier für die AS ID des Senders hold time: Zeitraum in dem ein BGP-4 Paket (z.B. KeepAlive) empfangen werden muss, damit die Verbindung bestehen bleibt BGP identifier: eine IP Adresse des Senders, diese muss durchgehend für jede BGP Kommunikation verwendet werden

BGP-4 OPEN optional parameters: Möglichkeit zur Angabe weiterer Parameter (z.B. weitere Informationen zur Authentifikation) wenn der Verbindungsaufbau erfolgreich war (BGP Versionen stimme überein und der Empfänger der OPEN Nachricht akzeptiert eine Verbindung mit dem Sender und die Parameter sind Akzeptabel), dann sendet der Empfänger der OPEN Nachricht eine KEEPALIVE Nachricht zum Sender wenn der Verbindungsaufbau erfolglos war, wird mit einer NOTIFICATION Nachricht geantwortet bei Erfolglosigkeit kann der Verbindungsaufbau mit anderen Parametern wiederholt werden

BGP-4 KEEPALIVE BGP-4 header ohne weitere Daten
wird verwendet um dem Nachbarn zu signalisieren, dass man noch da ist wird in der Regel so versandt, dass durchschnittlich 3 BGP-4 Nachrichten beim Nachbarn in hold time Sekunden ankommen, d.h. wenn viele andere BGP-4 Nachrichten an einen Nachbarn versendet werden müssen wenige KEEPALIVE Nachrichten versandt werden

BGP-4 UPDATE 7 15 31 marker (16 byte) length type: UPDATE
7 15 31 marker (16 byte) length type: UPDATE infeasible route len infeasible route len withdrawn routes (variable length) path attribute length path attributes (variable length) <length, prefix (vairable length)> .... network layer reachability information (NLRI)

BGP-4 UPDATE infeasible route length: Anzahl der Routen, die zurückgezogen werden sollen, da sie nicht länger gültig sind. infeasible routes: Liste der zurückgezogenen Routen. Einträge in dieser Liste haben die Form: Anzahl signifikante Bits (1 Byte), Signifikante Bits (1-4 Bytes) beschrieben - z.B. 16 / network layer reachability information: Liste der Netze, die über diese Route erreicht werden. Diese Liste hat das gleiche Format wie die Liste der zurückgezogenen Routen.

BGP-4 UPDATE: PATH-Attributes
PATH-Attributes werden verwendet um Informationen über eine Route mitzuteilen. Dazu gehören: Pfad Vektor + Menge der durchquerten AS Ausgangs-/Aggregations AS diese Informationen werden von den Routing-Politiken verwendet um festzustellen, welche Routen verwendet werden sollen path attribute length: Gesamtlänge aller folgenden Attribute path attributes: Liste bestehend aus folgenden Elementen: attribute flags attribute type attribute length (1 or 2 Bytes) attribute data

BGP-4 UPDATE – PATH-Attributes
attribute flags: bit 0 (high order bit) optional bit: wenn 0, dann ist dieses Attribut bekannt (well-known) und muss von allen BGP Routern verstanden werden; wenn 1, dann ist das Attribut optional bit 1 transitive bit: wenn 0, dann wird dieses Attribut nur vom Empfänger interpretiert und nicht von diesem weitergeleitet; wenn 1, dann wird dieses Attribut (möglicherweise nach einem update) weitergeleitet. Well-known Attribute sind immer transitiv (transitiv bit ist auf 1 gesetzt). bit 2 partial bit: wird von einem Router auf 1 gesetzt wenn ein optionales Attribut nicht erkannt wurde bit 3 extended length bit: das length Feld für dieses Attribut ist 2 byte lang wenn dieses bit gesetzt ist, sonst nur ein Byte

BGP-4 UPDATE – PATH-Attribute
Attribute die im BGP-4 RFC festgelegt sind: ORIGIN, type 1, length 1, well-known, transitive: ein Wert von 0 sagt aus, daß die Netzwerke intern zum AS des ursprünglichen Senders sind, 1 sagt aus, daß die Netzwerke über EGP vom Sender kennengelernt wurden und 2 sagt aus, daß die Netzwerke durch andere Methoden dem Sender bekanntgegeben wurden. AS_PATH, type 2, length variable, well-known, transitive: dies beinhaltet: Den Pfad den die Ankündigung vom ursprünglichen Sender der Errichbarkeitsinformationen oder seit einer Aggregatíon zurückgelegt hat. Hier trägt jeder BGP Speaker, der die Ankündigung weiterleitet seine AS ID ein. Bei einer Aggregation geht diese Information verloren. Die Menge der AS die durchquert wurde. Hierbei wird bei einer Aggregation die Vereinigungsmenge gebildet.

BGP-4 UPDATE PATH-Attribute
weitere Attribute die im BGP-4 RFC festgelegt sind: INTER_AS METRIC, type 5, length 2, optional, non-transitive: dies erlaubt extern vorzugeben welche Route bevorzugt werden soll. Prinzipiell wird ein AS zunächst lokale Politiken verwenden um festzustellen, welche Route am besten geeignet ist. Führen die lokalen Politiken für mehr als eine Route zum gleichen Ergebnis, so wird diese Metrik verwendet: die Route mit dem niedrigeren Wert gewinnt. AGGREGATOR. typ 7, length 6, optional, transitiv. Identifiziert den BPG-Speaker der die letzte Aggregation für diesen Eintrag vorgenommen hat.

BGP-4 Zusammenfassung BGP-4 ist das Aktuelle Protokoll für inter AS Routing im Internet BGP-4 löst das Problem, dass verschiedene AS unterschiedliche Politiken zum Routing verwenden wollen BGP-4 trifft beschränkt nicht die Struktur, in der mehrere AS zusammengeschaltet werden es löst die Probleme Class B Address Depletion und Routing Table Explosion zumindest soweit, dass das Internet heute noch funktioniert

Routing Zusammenfassung
jedes System im Internet besitzt eine Routing Tabelle bei Endsystemen ist diese meist trivial und besteht häufig im wesentlichen nur aus dem default route Eintrag zum nächsten Router bei Routern können die Einträge manuell konfiguriert sein oder durch Interior und Exterior Gateway Protocols automatisiert bestimmt werden Interior Gateway Protocols werden zum Routing in einem Autonomen System unter einheitlicher Administration verwendet Exterior Gateway Protocols werden zum Routing zwischen Autonomen Systemen verwendet, die unterschiedliche Politiken für das Weiterleiten von Paketen haben können

IP Fragmentation ein IP Paket kann auf seinem Weg zum Sender Netze mit unterschiedlicher maximum transmission unit (MTU) durchqueren die MTUs sind i.d.R. kleiner als die maximale Größe eines IP Paketes (65536 Bytes) es ist also möglich, dass ein IP Paket zu groß für ein Netz ist, in das es weitergeleitet werden soll um dieses Problem transparent für höhere Schichten zu lösen gibt es IP Fragmentation

IP Fragmentation - Terminologie
IP Datagramm: eine IP Übertragungseinheit, wie sie vom Sender erzeugt wird IP Paket: ein IP Datagramm, oder ein Fragment eines fragmentierten IP Datagramms

IP Fragmentation - Unterstützung im IP Header
7 15 31 version hlength type of service total length identification flags fragment offset time to live protocol header checksum source IP address destination IP address options (if any) data

IP Fragmentation - Unterstützung im IP-Header
das identification Feld hat den gleichen Wert für alle Fragmente eines IP Datagramms und verschiedene Werte für verschiedene IP Datagramme das fragment offset Feld sagt aus wieweit dieses Fragment vom Anfang des IP Datagramms entfernt ist das flags Feld beinhaltet das more fragments bit, dieses ist genau dann gesetzt, wenn das IP Paket nicht das letzte für ein IP Datagramm ist das total length Feld wird nach einer Fragmentierung neu berechnet, so dass es die Länge des Fragmentes beinhaltet

Fragmentation Considered Harmfull
Fragmentierung wird im Allgemeinen als etwas sehr! schlecht angesehen: geht ein Fragment verloren, so müssen auch alle Fragmente desselben IP Datagramms verworfen werden, die beim Empfänger angekommen sind! Es besteht keine Möglichkeit lediglich das verlorengegangene Fragment nocheinmal zu übertragen - der Sender weis nichts von der Fragmentierung.

Vermeidung der Fragmentierung - Path MTU Discovery
im flags Feld im IP Header gibt es ein Don‘t Fragment Bit (DF Bit) ist das DF Bit gesetzt, so fragmentiert ein Router das Paket nicht, sondern verwirft es, wenn es größer als die MTU des Netzes ist, in welches es weitergeleitet werden soll außerdem schickt der Router einen ICMP Unreachable Error (Fragmentation Required) an den Sender des Paketes zurück dieser Error beinhaltet die MTU die zu klein für das Paket war der Sender verringert daraufhin die Größe seiner IP Pakete an den Empfänger

ICMP Unreachable Error - Fragmentation Required
7 15 31 IP header (20 bytes) type (3) code (4) checksum unused (0) MTU of next-hop network IP header (incl. options) + first 8 bytes of original IP packet data

Fragmentation Demo? mit -s kann unter LINUX die Größe eines ping Paketes festgelegt werden dann kann man mit tcpdump nachsehen was passiert wir verwenden diesmal ein nettes GUI frontend zu tcpdump mit dem Name ethereal mit -D kann man das don‘t fragment Bit setzen, dies bringt jedoch nicht viel, da meist die MTU des LAN der Engpass ist, d.h. man sieht nichts da das Paket nie den Rechner verlässt

3.6 Interior Gateway Routing Protocols

Ähnliche Präsentationen

Präsentation zum Thema: "3.6 Interior Gateway Routing Protocols"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

3.6 Interior Gateway Routing Protocols

Ähnliche Präsentationen

Präsentation zum Thema: "3.6 Interior Gateway Routing Protocols"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback