UnfragmentiertesIP‐PaketFragmentiertes IP‐Paket

(1)

Grundlegende Konzepte

Datagram‐Delivery‐Service

(2)

IP‐Datagram

SS 2012 Grundlagen der Rechnernetze ‐Internetworking 7

Version HLen TOS Length

Ident Flags Offset

TTL Protocol Checksum

SourceAdr DestinationAdr

Options (variable) Pad (variable) Data

0 4 8 16 19 32

(3)

Fragmentierung und Reassembly

H1 R1

R2 R3 H2

ETH IP (1400) FDDI IP (1400) PPP IP (512) PPP IP (512) PPP IP (376)

ETH IP (512) ETH IP (512) ETH IP (376)

Beispiel:

• H1 sendet Daten der Größe 1400 Bytes an H2

• MTU von ETH = 1500 Bytes

• MTU von FDDI = 4500 Bytes

• MTU von PPP = 532 Bytes

(4)

Fragmentierung und Reassembly

Start des Headers

UnfragmentiertesIP‐Paket Fragmentiertes IP‐Paket

Bemerkung: durch Speichern eines Offsets anstatt einer ID ist weitere Fragmentierung eines schon fragmentierten Paketes

unmittelbar möglich.

Ident = x 0 Offset = 0 Rest des Headers

1400 Bytes Daten

Start des Headers

512 Bytes Daten Start des Headers

376 Bytes Daten

• Original IP‐Paket und dessen Fragmente lassen sich durch eine eindeutige Ident‐

Nummer zueinander zuordnen.

• Offset*8 = Byte‐Position in den Originaldaten

(5)

Grundlegende Konzepte

Adressierung

(6)

IP‐Adresse:

Netzklassen:

Subnetting

Erinnerung: Adressierung und Forwarding

Class A 0 Netz Host

7 24

1 0 Netz Host

14 16

Class B

1 1 0 Netz Host

21 8

Class C

10101011 01000101 11010010 11110101

171.69.210.245

1 0 Netz Host

14 16

Zum Beispiel Class B Adresse

11111111 11111111 11111111 (255.255.255.0)

Subnetz Maske ^00000000

Netznummer

Ergebnis ^Subnetz ^Host

(7)

Erinnerung: Adressierung und Forwarding

Supernetting (CIDR)

Internet‐Anbieter Advertise

128.112.128/21

128.112.128/24

128.112.135/24

…

Kunden‐Netze

(8)

Host Configuration (DHCP)

• IP‐Adressen haben einen Netz‐ und Host‐Anteil

• Im Gegensatz zu Ethernet‐Adressen kann die IP‐Adresse damit nicht fest mit der Netzhardware „verdrahtet“ sein. Warum?

• Es muss zumindest eine Möglichkeit bestehen, die IP‐Adressen manuell zu konfigurieren. Umständlich!

• Besser: dynamische Zuweisung von IP‐Adressen.

• Bei der Gelegenheit kann man dem DHCP‐Client auch gleich den Default‐Router mitteilen.

N S DHCP‐Server

DHCP Relay H

IP‐Broadcast DHCPDISCOVER

IP‐Unicast

DHCPDISCOVER

(9)

Beispiel:

ICMP‐Redirect

Error‐Reporting (ICMP)

ICPM (Internet Control Message Protocol) definiert eine Sammlung von Fehler‐ und Kontrollnachrichten.

Beispiel für Fehlernachrichten, die an den sendenden Host verschickt werden:

• Unerreichbarer Ziel‐Host

• Reassembly‐Prozess fehlerhaft

• TTL=0 erreicht

• IP‐Header‐Checksumme falsch Beispiel für Control‐Nachricht:

ICMP‐Redirect

H1

R2 R1

Nachricht an H2 Default‐Router: R1

(10)

IP‐Tunneling und Anwendungen

• Security in Kombination mit Verschlüsselung (z.B. Virtual‐Private‐Networks (VPN))

• Router R1 und R2 haben besondere Features (z.B. Multicast‐fähige Router)

• Verbinden von Nicht‐IP‐Netzen über ein IP‐Netz (z.B. global verteilte Sensornetze)

• Auslieferung an bestimmter Stelle erzwingen, obwohl Zieladresse eine andere ist (z.B.

Mobile‐IP)

R2

Netz 1.x R1 Internet Netz 2.x

IP‐Header,

Destination = 2.x IP‐Payload

IP‐Header,

Destination = 18.5.0.1 IP‐Header,

18.5.0.1 Netz‐Nummer Next‐Hop

1 Interface 0

2 Virtual Interface 0

Default Interface 1

(11)

Internet‐Routing

(12)

Forwarding und Routing

H3 H2

H1

H5

H4 H6 H7

R1

R3 R2

H7

1 2

Forwarding‐Tabelle

Adresse Interface MAC‐Adr.

Host H1 3 Adr(H1) Host H2 3 Adr(H2) Host H3 3 Adr(H3) Netz N2 1 Adr(R2) Netz N3 2 Adr(R3) 3

Woher bekommt man die Forwarding‐Tabelle?

Netz N1

Netz N2 Netz N3

Grundlagen der Rechnernetze ‐Internetworking

SS 2012 17

(13)

Routing

Wir betrachten zunächst Routing als Graph‐Problem.

Gegeben sei ein Graph mit gewichteten Kanten

(hier der Einfachheit halber ein ungerichteter Graph):

Finde die kürzesten Pfade zwischen den einzelnen Knoten.

B D

C

F

A E

12

1 3

3

1

4

4 7

(14)

Routing Algorithmen

Link‐State‐Routing Distanzvektor‐Routing

Von allen Nachbarinformation an alle (zentraler Routing‐Algorithmus) Globale Information an Nachbarn

(verteilter Routing‐Algorithmus)

R

R1 R2

Ziel Distanz

H1 5

H2 3

H3 7

H4 2

… …

R

Ziel Distanz

H1 7

H2 4

H3 4

H4 1

… …

SS 2012 19

(15)

Internet‐Routing

Distanzvektor‐Routing (aka. Bellman‐Ford)

(16)

Stetiger Austausch und Aktualisierung dieser Tabellen

(Routing‐Update)

Neue Tabelle von A

Tabelle von B Tabelle von C

B C

A

Grundidee

Initiale Distanzvektortabellen

A

C B

D E ^Ziel ^Next ^Dist

A A 1

B ‐‐ 0

C C 1

D D 1

E ?? 

Ziel Next Dist

A A 1

B B 1

C ‐‐ 0

D D 1

E E 1

A ‐‐ 0

B B 1

C C 1

D B 2

E C 2

Initiale Tabelle von A Ziel Next Dist

A ‐‐ 0

B B 1

C C 1

D ?? 

E ?? 

Kantengewichte hier verein‐

facht alle auf 1 gesetzt.

SS 2012 21

(17)

Details zu Routing‐Updates

Generelle Regel für Knoten u:

1. Aktualisiere iteTabellenzeile (x_i, y_i, d_i), wenn für die von Knoten v empfangene Tabellenzeile (x_i, z_i, c_i) gilt: d_i > c_i + 1

2. Die aktualisierte Tabellenzeile ist dann (x_i, v, c_i + 1) u

v

… … …

x_i z_i c_i

… … …

x_i v_i d_i

… … …

x_i v c_i+1

(18)

Wann versendet ein Knoten ein Routing‐Update?

Periodic‐Update: Tabellen werden regelmäßig an Nachbarn geschickt

• Damit wissen die Nachbarknoten, dass es den Link und Knoten noch gibt.

• Werden über einen bestimmten Zeitraum keine Updates mehr empfangen, so wird der Link als ausgefallen interpretiert

Triggered‐Update: Wann immer ein Knoten seine Routing‐Tabelle geändert hat

• Nach lokal festgestelltem Link‐Ausfall

• Nach Empfang eines Routing‐Updates von einem Nachbarn

• Das kann wiederum eine Änderung in den Nachbarknoten und damit Routing‐Updates von den Nachbarn bewirken (usw.)

(19)

Forwarding anhand der Routing‐Tabellen

A

C B

D E

A ‐‐ 0

B B 1

A A 1

B B 1

C ‐‐ 0

D D 1

E E 1

Randbemerkung

• Routing‐Tabelle: speichert alles was man für das Routing benötigt.

• Forwarding‐Tabelle: speichert alles

(20)

Beispiel eines Link‐Ausfalls

B

D C

F A

E

G

Dst Next Hops

G F 2

Dst Next Hops

G G 1

Tabelleneinträge

bzgl. Knoten G: ^Dst ^Next ^Hops

G D 2

Stabilisiert sich das Netz immer in dieser Form?

(21)

Count‐to‐Infinity‐Problem

A B

C

A

B

C

Lösungsansatz 1: ignorieren. Am Ende wird sowieso bis  hoch gezählt.

Lösungsansatz 2: Split‐Horizon.

Routing‐Updates nur zu Nachbarn, die nicht selber der nächste Hop sind.

Lösungsansatz 3: Split‐Horizon with Poison Reverse. Routing‐Updates zu allen Nachbarn. Allerdings Routing‐

Update  zu denen, die selber der

(22)

Internet‐Routing

Link‐State‐Routing

(23)

Link‐State‐Routing

Zweiter Schritt

R R Erster Schritt

R U

V

X W Y

(R,U) (R,V) (R,W)

(R,X) (R,Y)

(24)

Reliable‐Flooding

Jeder Knoten versendet Link‐State‐Pakete (LSP) mit folgender Info:

• ID des Knotens, der das LSP erzeugt hat

• Liste der direkten Nachbarn (inklusive Link‐Kosten)

• eine Sequenznummer

• Ein TTL‐Wert für das Paket Jedes LSP wird geflutet, d.h.:

• LSP‐Erzeuger inkrementiert eine lokale Sequenznummer und versendet das LSP mit dieser Nummer

• Jeder Knoten, der ein „neueres“ (d.h. höhere Sequenznummer) LSP empfängt, leitet dieses an alle Nachbarn (außer dem, von dem das LSP empfangen wurde) weiter

• LSP mit älteren oder gleicher Nummer werden ignoriert

• Des Weiteren werden LSPs ab bestimmtem TTL‐Wert ebenfalls verworfen

(25)

Routenberechnung mittels Dijkstra‐Algorithmus

Es sei s der Startknoten, N die Menge aller Knoten und l(v,w) die Kosten der Verbindung von v nach w. Wir definieren:

c(v) = aktuelle Kosten von v

m(v) = Markierung der schon behandelten Knoten

pre(v) = Vorgänger von v entlang der kürzesten Route nach s Dijkstra‐Algorithmus:

Für alle v in N-{s} setze c(v)= und m(v)=false c(s)=0 und m(s)=false

Solange noch unmarkierte Knoten existieren:

Finde unmarkierten Knoten v mit kleinstem Wert c(v) m(v) = true

(26)

Beispiel an der Tafel

(27)

Internet‐Routing

Konkrete Realisierungen im Internet

(28)

Anwendung dieser Verfahren im Internet?

Skalierbarkeit

Kommunikationsoverhead Speicheroverhead

Langsame oder keine Konvergenz

Administrative Autonomie

Freie Wahl von Routing‐Protokollen Verbergen von Netzinterna

SS 2012 33