martin mauveuniversität mannheim1 3.6 interior gateway routing protocols routing in einer autonomen...

Martin Mauve Universität Mannheim 1

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

A

D E

CB

3

6

1

4

2

5

From A to Link Cost

A local 0

From B to Link Cost

B local 0

From C to Link Cost

C local 0

From D to Link Cost

D local 0

From E to Link Cost

E local 0

Von A: A=0 auf links 1 und 3



From A to Link Cost

A local 0

From B to Link Cost

B local 0

From C to Link Cost

C local 0

From D to Link Cost

D local 0

From E to Link Cost

E local 0

A 1 1

A 3 1

Von B: A=1, B=0 auf links 1, 4, 2Von D: A=1, D=0 auf links 3, 6

A

D E

CB

3

6

1

4

2

5



From A to Link Cost

A local 0

From B to Link Cost

B local 0

From C to Link Cost

C local 0

From D to Link Cost

D local 0

From E to Link Cost

E local 0

A 1 1

A 3 1

B 1 1

D 3 1

B 2 1

A 2 2

B 4 1

A 4 2

D 6 1Von A: A=0, B=1, D=1 auf links 1, 3Von C: A=2, B=1, C=0 auf links 2, 5Von E: A=2, B=1, D=1, E= 0 auf links 4, 5, 6

A

D E

CB

3

6

1

4

2

5



From B to Link Cost

B local 0

A 1 1

D 1 2

C 2 1

E 4 1

From D to Link Cost

D local 0

A 3 1

B 3 2

E 6 1

From C to Link Cost

C local 0

B 2 1

A 2 2

E 5 1

D 5 2

From A to Link Cost

A local 0

B 1 1

D 3 1

From E to Link Cost

E local 0

B 4 1

A 4 2

D 6 1

C 5 1

Von B: A=1, B=0, C=1, D=2, E=1 auf links 1, 4, 2Von C: A=2, B=1, C=0, D=2, E=1 auf links 2, 5Von D: A=1, B=2, D=0, E=1 auf links 3, 6Von E: A=2, B=1, C=1, D=1, E= 0 auf links 4, 5, 6

A

D E

CB

3

6

1

4

2

5



From B to Link Cost

B local 0

A 1 1

D 1 2

C 2 1

E 4 1

From D to Link Cost

D local 0

A 3 1

B 3 2

E 6 1

From C to Link Cost

C local 0

B 2 1

A 2 2

E 5 1

D 5 2

From A to Link Cost

A local 0

B 1 1

D 3 1

From E to Link Cost

E local 0

B 4 1

A 4 2

D 6 1

C 5 1C 1 2

E 1 2

C 6 2

A

D E

CB

3

6

1

4

2

5


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

B local 0

A 1 inf

D 1 inf

C 2 1

E 4 1

From D to Link Cost

D local 0

A 3 1

B 3 2

E 6 1

From C to Link Cost

C local 0

B 2 1

A 2 2

E 5 1

D 5 2

From A to Link Cost

A local 0

B 1 inf

D 3 1

From E to Link Cost

E local 0

B 4 1

A 4 2

D 6 1

C 5 1C 1 inf

E 1 inf

C 6 2

A

D E

CB

3

6

XXXX

4

2

5

Von A: A=0, D=1 auf Link 3 Von B: B=0, C=1, E=1 auf Links 2, 4



From B to Link Cost

B local 0

A 1 inf

D 1 inf

C 2 1

E 4 1

From D to Link Cost

D local 0

A 3 1

B 3 inf

E 6 1

From C to Link Cost

C local 0

B 2 1

A 2 inf

E 5 1

D 5 2

From A to Link Cost

A local 0

B 1 inf

D 3 1

From E to Link Cost

E local 0

B 4 1

A 4 inf

D 6 1

C 5 1

C 1 inf

E 1 inf

C 6 2

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, 6Von E: B=1, C=1, D=1, E=0 auf Links 4, 5, 6

A

D E

CB

3

6

XXXX

4

2

5



From B to Link Cost

B local 0

A 1 inf

D 4 2

C 2 1

E 4 1

From D to Link Cost

D local 0

A 3 1

B 6 2

E 6 1

From C to Link Cost

C local 0

B 2 1

A 2 inf

E 5 1

D 5 2

From A to Link Cost

A local 0

B 1 inf

D 3 1

From E to Link Cost

E local 0

B 4 1

A 6 2

D 6 1

C 5 1

C 3 3

E 3 2

C 6 2

Von A: A=0, C=3, D=1, E=2 auf Link 3Von 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, 6Von E: A=2, B=1, C=1, D=1, E=0 auf Links 4, 5, 6

A

D E

CB

3

6

XXXX

4

2

5



From B to Link Cost

B local 0

A 4 3

D 4 2

C 2 1

E 4 1

From D to Link Cost

D local 0

A 3 1

B 6 2

E 6 1

From C to Link Cost

C local 0

B 2 1

A 5 3

E 5 1

D 5 2

From A to Link Cost

A local 0

B 3 3

D 3 1

From E to Link Cost

E local 0

B 4 1

A 6 2

D 6 1

C 5 1

C 3 3

E 3 2

C 6 2

A

D E

CB

3

6

XXXX

4

2

5


Distance Vector Routing - Counting to Infinity

A

D E

CB

3

XXXX

4

2

5

XXXX

From D to Link Cost

D local 0

A 3 1

B 6 inf

E 6 inf

From A to Link Cost

A local 0

B 3 3

D 3 1

C 3 3

E 3 2

C 6 inf

Wenn nun einer der von A periodisch versandten Distanzvektoren bei Dankommt, 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 D to Link Cost

D local 0

A 3 1

B 3 4

E 3 3

From A to Link Cost

A local 0

B 3 3

D 3 1

C 3 3

E 3 2

C 3 4

Von D: A=1, B=4, C=4, D=0, E=3 auf Link 3

From D to Link Cost

D local 0

A 3 1

B 3 4

E 3 3

From A to Link Cost

A local 0

B 3 5

D 3 1

C 3 5

E 3 4

C 3 4

Von A: A=1, B=5, C=5, D=1, E=4 auf Link 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

A

D E

CB

3

XXXX

4

2

5

XXXX

From D to Link Cost

D local 0

A 3 1

B 6 inf

E 6 inf

From A to Link Cost

A local 0

B 3 3

D 3 1

C 3 3

E 3 2

C 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

A

D E

CB

3

XXXX

4

2

5

XXXX

From B to Link Cost

B local 0

A 4 3

D 4 2

C 2 1

E 4 1

From C to Link Cost

C local 0

B 2 1

A 5 3

E 5 1

D 5 2

From E to Link Cost

E local 0

B 4 1

A 6 inf

D 6 inf

C 5 1Von E: B=inf, C=1, E=0 auf Link 4 (poisonous reverse)Von E: B=1, C=inf, E=0auf Link 5 (poisonous reverse)

Der Distanzvektor auf Link 5 geht verloren und kommt nicht bei C an.


Distance Vector Routing - Problem bei Split Horizon

A

D E

CB

3

XXXX

4

2

5

XXXX

From B to Link Cost

B local 0

A 4 inf

D 4 inf

C 2 1

E 4 1

From C to Link Cost

C local 0

B 2 1

A 5 3

E 5 1

D 5 2

From E to Link Cost

E local 0

B 4 1

A 6 inf

D 6 inf

C 5 1Nun sei für C die Zeit gekommen, dasder 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=infauf Link 5 (poisonous reverse)


Distance Vector Routing - Split Horizon Problem

A

D E

CB

3

XXXX

4

2

5

XXXX

From B to Link Cost

B local 0

A 2 4

D 2 3

C 2 1

E 4 1

From C to Link Cost

C local 0

B 2 1

A 5 3

E 5 1

D 5 2

From E to Link Cost

E local 0

B 4 1

A 6 inf

D 6 inf

C 5 1Von B: A=4, B=0, C=1, D=3, E=infauf Link 4 (poisonous reverse)Von B: .... uninteressantauf Link 2 (poisonous reverse)


Distance Vector Routing - Split Horizon Problem

A

D E

CB

3

XXXX

4

2

5

XXXX

From B to Link Cost

B local 0

A 2 4

D 2 3

C 2 1

E 4 1

From C to Link Cost

C local 0

B 2 1

A 5 3

E 5 1

D 5 2

From E to Link Cost

E local 0

B 4 1

A 4 5

D 4 4

C 5 1Jetzt existiert ein 3er Kreis, in dem es zu count to infinity kommt!


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-01-1988, 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

IP + UDP header (28 bytes)

0 7 15 31

command (1, 2) must be zeroversion (1)

IP address

must be zeroaddress family identifier (2)

must be zero

metric

must be zero

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




0 7 15 31

command (1, 2) routing domainversion (2)

IP adress

route tagaddress family identifier (2,0xFFFF)

subnet mask

metric

next hop




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

authentication type 2 Passwort andere Werte sind spezifiziert, z.B. MD-5 Hash

authentication Daten, ja nach authentication type (z.B. Passwort)


0 7 15 31

command (1, 2) routing domainversion (2)

authentication (16 bytes)

authentication typeaddress family identifier (0xFFFF)



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

A

D E

CB

3

6

1

4

2

5

From Link Cost

A 1 1

A 3 1

B 1 1

B 2 1

B 4 1

To

B

D

A

C

E

C 2 1B

From Link Cost

C 5 1

D 3 1

D 6 1

E 4 1

E 5 1

To

E

A

E

B

C

E 6 1D

Karte/Datenbank:

Number

1

1

1

1

1

1

Number

1

1

1

1

1

1


Link State Routing - Link Ausfall

A

D E

CB

3

6

XXXX

4

2

5

From A, to B, link 1 distance = infinite, number 2From 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

From Link Cost

A 1 inf

A 3 1

B 1 inf

B 2 1

B 4 1

To

B

D

A

C

E

C 2 1B

From Link Cost

C 5 1

D 3 1

D 6 1

E 4 1

E 5 1

To

E

A

E

B

C

E 6 1D

Karte/Datenbank nachdem dieInformationen über den Linkausfallvon A und B geflutet wurden:

Number

2

1

2

1

1

1

Number

1

1

1

1

1

1


Link State Routing - Bringing Up Adjacencies

A

D E

CB

3

XXXX

4

2

5

From D, to E, link 6 distance = infinite, number 2From E, to D, link 6 distance = infinite, number 2

XXXX

Im Folgenden werden die Topologieinformationen für die beiden Partitionenunterschiedlich sein! Wir wollen verstehen, wie sich diese Unterschiedewieder angleichen, wenn die Konnektivität wieder hergestellt wird. DieserVorgang heißt „Bringing Up Adjacencies“.


Link State Routing - Bringing Up AdjacenciesFrom Link Cost

A 1 inf

A 3 1

B 1 inf

B 2 1

B 4 1

To

B

D

A

C

E

C 2 1B

C 5 1

D 3 1

D 6 inf

E 4 1

E 5 1

E

A

E

B

C

E 6 1D

Number

2

1

2

1

1

1

1

1

2

1

1

1

Datenbank von A und D

From Link Cost

A 1 inf

A 3 1

B 1 inf

B 2 1

B 4 1

To

B

D

A

C

E

C 2 1B

C 5 1

D 3 1

D 6 1

E 4 1

E 5 1

E

A

E

B

C

E 6 infD

Number

2

1

2

1

1

1

1

1

1

1

1

2

Datenbank von B, C und E



A

D E

CB

3

XXXX

4 5

From B, to C, link 2 distance = infinite, number 2From C, to B, link 2 distance = infinite, number 2

XXXX

Diese Informationen werden nur in einer Partition geflutet (die andere istnicht zu erreichen)!

XXXX



A 1 inf

A 3 1

B 1 inf

B 2 1

B 4 1

To

B

D

A

C

E

C 2 1B

C 5 1

D 3 1

D 6 inf

E 4 1

E 5 1

E

A

E

B

C

E 6 1D

Number

2

1

2

1

1

1

1

1

2

1

1

1


From Link Cost

A 1 inf

A 3 1

B 1 inf

B 2 inf

B 4 1

To

B

D

A

C

E

C 2 infB

C 5 1

D 3 1

D 6 1

E 4 1

E 5 1

E

A

E

B

C

E 6 infD

Number

2

1

2

2

1

2

1

1

1

1

1

2




A

D E

CB

3

XXXX

4 5

From A, to B, link 1 distance = 1, number 3From B, to A, link 1 distance = 1, number 3

Jetzt existiert wieder ein einziges unpartitioniertes Netz. Allerdings mitinkonsistenten Datenbanken.

XXXX1



A 1 1

A 3 1

B 1 1

B 2 1

B 4 1

From

B

D

A

C

E

C 2 1B

C 5 1

D 3 1

D 6 inf

E 4 1

E 5 1

E

A

E

B

C

E 6 1D

Number

3

1

3

1

1

1

1

1

2

1

1

1


From Link Cost

A 1 1

A 3 1

B 1 1

B 2 inf

B 4 1

From

B

D

A

C

E

C 2 infB

C 5 1

D 3 1

D 6 1

E 4 1

E 5 1

E

A

E

B

C

E 6 infD

Number

3

1

3

2

1

2

1

1

1

1

1

2



Link State Routing -Bringing Up Adjacencies

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:1 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.

2 Wenn O leer ist, oder alle Pfade in O unendliche Kosten haben, dann markiere alle Knoten in R als nicht erreichbar. Ende.

3 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.

3 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

A

D E

CB

2

2

1

2

5

1

Achtung! Nun repräsentieren die Zahlendie „Distanz“ (= Verzögerung, Kosten, etc.)zwischen zwei Knoten.

E={A}, R={B, C, D, E}O={A-B-1, A-D-2}

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}

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}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}

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

IP header (20 bytes) - protocol type 89

0 7 15 31

version (2) packet lengthtype (1-5)

router ID

autypechecksum

area ID

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

OSPF packet header, type=1 (hello)

0 7 15 31

optionshello interval priority

network mask

dead interval

backup designated router

designated router

more neighbors ...

neighbor



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)



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

OSPF packet header, type=2 (database descritpion/dd)

0 7 15 31

optionsmust be 0 IMMS

DD sequence number

link state ID

link state type

more record descriptions

advertising router

must be 0

link state sequence number

link state checksum link state age


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 = 1 1 1 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 = 1 1 0 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 0 0 0 sendet ist diese Phase beendet



nun wissen beide Teilnehmer welche Einträge in derDatenbank beim anderen Teilnehmer aktuelle sind, diese werden nachgefragt

geantwortet wird wie beim OSPF - Flooding Protocol, das wir gleich besprechen

OSPF packet header, type=3 (request/rq)

0 7 15 31

link state ID

link state type

more record requests

advertising router


OSPF - Flooding Protocol

OSPF packet header, type=4 (link state update)

0 7 15 31

number of advertisements

link state ID

zero or more link descriptions

advertising router


link state checksum link state length

link state age options link state type

....

link state ID

link state age options link state type

....



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!)

0 7 15 31

Link ID

Link Data

Type

Flags Number of Links

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.



OSPF packet header, type=5 (link state acknowledgement)

0 7 15 31

link state ID

advertising router


link state checksum link state length

link state age options link state type (1)

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!


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



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 16.384 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 10000 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: 194.0.0.0 - 195.255.255.255 North America: 198.0.0.0 - 199.255.255.255 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 USA194.x.x.x - 195.x.x.x über Link 1

Link 1

Router im Europäischen Backbone (z.B. London)194.0.x.x - 194.30.x.x über Link 2 nach D194.31.x.x - 194.60.x.x über Link 3 nach F

Router im Deutschen Backbone (z.B. Berlin)194.0.x.x - 194.8.x.x über Link 10 nach T-Online D194.9.x.x - 194.12.x.x über Link 11 nach AOL D

Link 2

Link 10 Link 12


Weltweite Adresseinteilung



CIDR – Beispiel für Routinginformationen



CIDR – Longest Match Routing Rule

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!



CIDR: Multihoming Lösung

Keine Aggregation von fremden Adressen!



CIDR: Multihoming Problem II

Wenn einer der ISPs ausfällt, dann sind in Largenet die entsprechenden Adressen nicht mehr zu erreichen.



CIDR: Multihoming Lösung II

Ankündigen des spezifischen Netzes, keine Aggregation!

198.24.0.0/20198.32.0.0/20



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 1771. 1995.

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

AS: 100

IR1

IR2

BR1

BR2

IR3

EBGP

IBGP

EBGP

IGP

IGP

IGP

IGP


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

Ziel: der Provider würde gerne eine einzigen Eintrag der Art 22 / 197.8.0.0 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?

AS X24 / 197.8.2.0

AS Y24 / 197.8.3.0

AS Z

AS T (Provider)es werden lokal24 / 197.8.0.0

und24 / 197.8.1.0

verwendet


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, 2001. 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, 2001. 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

0 7 15 31

length type (1-4)

marker (16 byte)

marker: der Inhalt dieses Feldes wird durch von BGP getrennt spezifizierteSicherheitsalgorithmen 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)


optional parameters<Type, Length, Value>

BGP-4 OPEN

0 7 15 31

length type: OPEN

marker (16 byte)

version

my autonomous system hold time

BGP identifier

opt. param. len.


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

path attributes (variable length)

0 7 15 31

length type: UPDATE

marker (16 byte)

path attribute length

<length, prefix (vairable length)>....

infeasible route len

infeasible route len withdrawn routes (variable 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 / 192.100.

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

identification

time to live

source IP address

version total lengthtype of service

destination IP address

header checksum

data

hlength

0 7 15 31

flags fragment offset

protocol

options (if any)


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

IP header (20 bytes)

0 7 15 31

type (3) checksumcode (4)

IP header (incl. options) + first 8 bytes of original IP packet data

unused (0) MTU of next-hop network


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

martin mauveuniversität mannheim1 3.6 interior gateway routing protocols routing in einer autonomen...

Documents