Lehrstuhl für Kommunikationssysteme - Systeme II 1

Systeme II – 5te Vorlesung

Lehrstuhl für KommunikationssystemeInstitut für Informatik / Technische Fakultät

Universität Freiburg2009

Lehrstuhl für Kommunikationssysteme - Systeme II 2

Lösungsskizze Übungen Präsentation der Lösungen war letzte Übung am Montag

Lösungen auch Online im Downloadbereich zu diesem Termin (11.05.)

Aktueller Übungszettel Online (06.05. - Achtung, korrigierte Aufgabe 2, ging auch über Mailingliste)

Mailingliste Jetzt eingerichtet

Adresse: systemeII-SS09@rz (geändert wegen organisatorischer Probleme)

Jede(r) sollte die Begrüßungs-Email erhalten haben

Vorlesung Systeme II – Organisatorisches

Lehrstuhl für Kommunikationssysteme - Systeme II 3

Letzte Vorlesungen

‣ Statisches IP-Routing im lokalen Subnetz (auch letzte praktische Übungen)

Lehrstuhl für Kommunikationssysteme - Systeme II 4

Letzte Vorlesungen

‣ DHCP zur Konfiguration des IP und statischen Routings• Wichtige Eigenschaft: Dynamische Adressvergabe aus IP-Pools

• DHCP verwaltet dazu Liste verteilter IPs

• Vordefinierte IP-Adressen können an spezifische Endsysteme verteilt werden

• UDP-basiert – verbindungsorientierte Kommunikation nicht sinnvoll möglich (mehr später zu TCP und UDP)

• Applikation (OSI-Layer 7) im klassischen Client-Server-Modell

• Voraussetzung: broadcast-fähiges Netz (sonst andere Protokolle, wie PPP)

Lehrstuhl für Kommunikationssysteme - Systeme II 5

Letzte Vorlesungen

‣ Congestion Control• Jedes Netzwerk hat eine

eingeschränkte Übertragungs-Bandbreite

• Wenn mehr Daten in das Netzwerk eingeleitet werden, führt das zum Datenstau oder gar Netzwerkzusammenbruch

• Folge: Datenpakete werden nicht ausgeliefert

Lehrstuhl für Kommunikationssysteme - Systeme II 6

Letzte Vorlesungen

‣ ICMP- Hilfsprotokoll des IP für Vermittlungsschichtaufgaben• Fehlermeldungen: Mitteilung über Reihe von definierten

Fehlerzuständen

• Typfeld gibt einen der 15 möglichen Message Types an, Codefeld spezifiziert Subtypen

• Viele Routing-Parameter via ICMP verhandelbar (Netzmaske, Next-Router, Redirect, ...) jedoch aus Sicherheitsgründen kaum mehr verwendet / abgelöst durch dedizierte Protokolle

Lehrstuhl für Kommunikationssysteme - Systeme II 7

Motivation

‣ Zentrales Konzept: IP – paketorientiert, Routingentscheidung für jedes einzelne Paket wiederholt

‣ Dabei: Wenig vorhersagbarer Traffic

‣ Prinzip “unzuverlässige” Verbindungen – es wird nicht vor Paketversand geprüft ob Ziel (in einer bestimmten Qualität) erreichbar

Lehrstuhl für Kommunikationssysteme - Systeme II 8

Internet Protocol – dynamisches Routing

‣ Bisher betrachtet: Statisches Routing (auf dem Endsystem) – Routing-Einträge lagen vor

• Zahl der Router (Beispiel Campus-Netz mit ?? Routern und Layer-3-Switches) zwar deutlich kleiner als der Endsysteme (~18000)

• Dieses schon in mittleren Organisationen wie Universität Freiburg schwierig händisch zu realisieren

- Regelmäßiger Austausch von Geräten wegen Upgrade oder Defekts

- Zusätzlich: Roll-out von Voice-over-IP Geräten (neue Generation Telefone) erhöht Anzahl der IP-Devices

• Protokolle für dynamische Konfiguration von Endsystemen besprochen – DHCP, ICMP

Lehrstuhl für Kommunikationssysteme - Systeme II 9

Internet Protocol – dynamisches Routing

‣ Im folgenden: Statisches und Dynamisches Routing auf Netzwerkknoten

‣ Verschiedene Begriffe zu finden

‣ Routing:• Bestimmen, Erstellen Routen, d.h.

- Kennen der Nachbar-Router- Kennen der “Wegekosten” zum Nachbarn- Erstellen der Routing-Tabelle

‣ Forwarding (Kurose & Ross):• Weiterleiten von Paketen• Deshalb eigentlich Forwarding-Table

Lehrstuhl für Kommunikationssysteme - Systeme II 10

Internet Protocol – dynamisches Routing

‣ Verschiedene Routing-Varianten• Zentral versus verteilt

• Quell-basiert oder hop-by-hop

• Single oder Multi-Path

• Statisches oder dynamisches Routing

‣ Klassisches statisches Routing• Tabelle wird manuell erstellt (Netzwerkadministrator)• Praktikabel, sinnvoll für kleine und stabile LANs

Lehrstuhl für Kommunikationssysteme - Systeme II 11

Internet Protocol – dynamisches Routing

‣ Verschiedene Strategien – Unterscheidung von zwei Hauptklassen

• Nonadaptives (statisches) Routing

- Routing Entscheidungen hängen nicht von der (ständigen) Überwachung der tatsächlich verfügbaren Bandbreite und Netzwerktopologie ab

- Damit kein Bedarf nach speziellem Überwachungsservice, der permanent oder zeitgetriggert läuft

- Routen werden im Voraus berechnet (und dann auf Router geladen, wenn Netzwerk gestartet wird)

Lehrstuhl für Kommunikationssysteme - Systeme II 12

Internet Protocol – dynamisches Routing

‣ Verschiedene Strategien – Unterscheidung von zwei Hauptklassen

• Adaptives (dynamisches) Routing

- Überwacht permanent Netzwerkzustand

- Reagiert auf Änderung voreingestellter Parameter (Bandbreite, Topologie, Fehlerraten, ...)

• Wann werden Änderungen vorgenommen?

- Alle T Sekunden, wenn sich die Netzwerklast ändert

- Bei Änderungen der Topologie

- Ereignisgesteuert ...

Lehrstuhl für Kommunikationssysteme - Systeme II 13

Internet Protocol – dynamisches Routing

‣ Dynamisches Routing• Tabellen werden durch Routing-Algorithmus erstellt• Verschiedene Algorithmen im Einsatz• Dezentraler Algorithmus, z.B. Distance Vector

- Arbeitet lokal in jedem Router- Verbreitet lokale Information im Netzwerk

• Zentraler Algorithmus, z.B. Link State- Einer/jeder kennt alle Information, muss diese erfahren

‣ Zentrales Problem: Die optimale Route

• Wie diese bestimmen?

• Welche Paramter? Beispielsweise Weglänge

Lehrstuhl für Kommunikationssysteme - Systeme II 14

Das Kürzeste-Wege-Problem

Lehrstuhl für Kommunikationssysteme - Systeme II 15

Distance Vector Routing

‣ Beim Distance Vector Routing hat jeder Router eine Tabelle gespeichtert, die die beste Verbindung zu jedem bekannten Knoten enthält

• Besteht aus Paar von Routern für jedes Subnet und dem Ziel bis dahin

• Enthält die Information über die Interfaces für jedes Ziel und die Entfernung dahin in der gegebenen Metrik

‣ Anderer Name für diesen Algorithmus ist Verteilter Bellmann-Ford oder Ford-Fulkerson

Lehrstuhl für Kommunikationssysteme - Systeme II 16

Distance Vector Routing

‣ Tabellen regelmäßig durch Informationsaustausch mit Nach-barn aktualisiert

‣ Der Nachrichtenaustausch erfolgt• Periodisch (Sekunden-oder Minuten-Intervalle)

• Bei Änderung des Distanzvektors eines Knotens

• z.B. Ausfall einer Verbindung, Auftreten neuer Verbindung

17

Distance Vector Routing Protocol

Distance Table Datenstruktur• Jeder Knoten besitzt eine

- Zeile für jedes mögliches Ziel

- Spalte für jeden direkten Nachbarn

Verteilter Algorithmus• Jeder Knoten kommuniziert

nur mit seinem Nachbarn• Schickt diesem Pakete mit

der Liste seiner erreichbaren Ziele im Netz (Distanzvektor)

• Jeder Router empfängt diese Pakete und aktualisiert anhand dieser seine eigenen Tabellen

Lehrstuhl für Kommunikationssysteme - Systeme II 18

Distance Vector Routing Protocol

‣ Beim Distance Vector Routing Protocol • Asynchroner Betrieb

• Knoten müssen nicht Informationen austauschen in einer Runde

• Selbst Terminierend - läuft bis die Knoten keine Informationen mehr austauschen

‣ Einfach zu implementieren

‣ Metrik kann eine der vorgenannten sein – vielfach einfach Hop-Count

‣ Jeder Router sollte Entfernung zum Nachbarn kennen – mit Hop-Count einfach – Entfernung (Pfadlänge, ...) genau 1

Lehrstuhl für Kommunikationssysteme - Systeme II 19

Distance Vector Routing Protocol

‣ Queue-Länge als Metrik einfach durch Ermitteln der internen Warteschlangen für jedes Interface

‣ Für Verzögerungs-Metrik – senden spezieller Ping-Pakete zur Berechnung der Round-Trip-Time (RTT)

‣ Ziele können auf ganz verschiedenen Wegen erreicht werden (Beispielgrafik von vorhin)

• Router bestimmt anhand der Info-Pakete die kürzeste Entfernung zu jedem Ziel

• Verwirft alle weiteren (alternativen) Routen

‣ Das funktioniert in der Theorie ganz gut, hat aber einige Nachteile in der Praxis

20

Das “Count to Infinity” - Problem

Gute Nachrichten verbreiten sich schnell• Neue Verbindung wird

schnell veröffentlicht

Schlechte Nachrichten verbreiten sich langsam• Verbindung fällt aus• Nachbarn erhöhen

wechselseitig ihre Entfernung• “Count to Infinity”-Problem• Im folgenden näher

betrachtet ...

Lehrstuhl für Kommunikationssysteme - Systeme II 21

Das “Count to Infinity” - Problem

‣ Selbst wenn Distant Vector konvergiert, so tut es das ziemlich langsam

‣ Besonders betroffen sind schlechte Nachrichten (Ausfall, Überlastung eines Links/Verbindung)

‣ Zur Illustration sei das stark vereinfachte Beispiel von fünf linear gekoppelten Routern gegeben

Lehrstuhl für Kommunikationssysteme - Systeme II 22

Das “Count to Infinity” - Problem

‣ Der Algorithmus ist initial sehr schnell

‣ Kommt Router 1 hinzu, weiss erstmal kein anderer Router einen Weg zum ihm (übersetzt in Distance Vector Sprache “unendlicher Weg”)

‣ Erscheint nun 1 neu – im ersten Informationsaustausch (zur Vereinfachung nehmen wir an, dass die gesamte Routing-Information im selben Moment ausgetauscht wird) bekommt 2 die frohe Botschaft von 1, dass dieser eine Route der Länge “0” zu 1 hat (ist er ja selbst)

‣ 2 fügt diese Information der eigenen Tabelle hinzu

Lehrstuhl für Kommunikationssysteme - Systeme II 23

Das “Count to Infinity” - Problem

‣ Im nächsten Schritt verkündet nun 2 diese Neuigkeiten seinem Nachbar-Router 3, dass er nun eine Route mit dem Hop-Count “1” zum Router 1 kennt

‣ Router 3 lernt dieses und fügt die Route mit der Metrik “2” für das Ziel 1 hinzu

‣ Die nächsten Schritte erfolgen komplett analog

‣ Die Aktion ist beendet nach Abschluss der vierten Runde

‣ Alle Router kennen nun die neue Netzstruktur

‣ Umgekehrt hat 1 schon im ersten Schritt erfahren, was 2 wusste und daraus seine Tabelle erstellt

Lehrstuhl für Kommunikationssysteme - Systeme II 24

Das “Count to Infinity” - Problem

‣ Nun wird das Szenario umgekehrt: 1 fällt aus irgendeinem Grund aus und verschwindet aus dem Netz

‣ Der nun folgende Datenaustausch braucht bedeutend länger!

Lehrstuhl für Kommunikationssysteme - Systeme II 25

Das “Count to Infinity” - Problem

‣ In der nächsten Runde des Paketaustauschs hört 2 nichts mehr von Router 1, aber 3 springt mit der Botschaft ein “keine Sorge, ich kenne eine Route zu 1”

‣ Dieser Information folgend aktualisiert 2 seinen Hop-Count auf “3” für den Weg zur 1

‣ 2 hat leider keine Ahnung, dass die Route von 3 leider durch ihn selbst hindurchläuft

‣ Im Zuge des zweiten Info-Austauschs hat 3 nun zwei Einträge für 1 mit der identischen Metrik von “3”, deshalb wird ein Eintrag zufällig ausgewählt und die Routing-Tabelle mit einem Hop-Count von “4” bestückt

Lehrstuhl für Kommunikationssysteme - Systeme II 26

Das “Count to Infinity” - Problem

‣ Das Ganze geht nun munter weiter ...

‣ Problem hierbei: Kein Router hat einen Hop-Count größer als das Minimum von allen Nachbarn – damit wandern alle langsam bis Unendlich

‣ Nun kommt es darauf an, wo “Unendlich” liegt• IP-Netzwerk-Durchmesser dürfte 256 betragen (TTL im IP-Header)

• Gibts so eher nicht (man stelle sich Netzwerke und dazugehörige Routing-Tabellen nach dem gezeigten Muster vor!), deshalb typischerweise 16 (was aber wieder eine Einschränkung sein kann)

Lehrstuhl für Kommunikationssysteme - Systeme II 27

Das “Count to Infinity” - Problem

‣ Wann also Router 1 als “unerreichbar” gesetzt wird, hängt vom Wert des “Unendlich” ab

‣ Deshalb: Setze den Wert auf den maximalen Durchmesser des Netzwerks plus “1”

‣ Aber selbst in mittelgroßen Netzwerken kann die Zeit bis ein Router als unerreichbar markiert wird deutlich zu hoch sein

• Man rechne dieses einfach mal mit dem Beispiel durch bei einer Austauschfrequenz von drei Infos pro Minute

• Anderes Problem: Der Wert sollte auch nicht zu klein sein, da sonst eher einfache Probleme wie kurzzeitige Überlastungen etc. einen Router schnell “abschalten” könnten

Lehrstuhl für Kommunikationssysteme - Systeme II 28

“Count to Infinity” & “Split Horizon”

‣ Einer der möglichen Lösungsvorschläge (leider hat keiner das Problem wirklich gelöst) ist der “Split-Horizon-Hack”

‣ Idee: Router annoncieren keine Verbindung zum Nachbarn N wenn N selbst der aktuelle Next-Hop für dieses Ziel ist

‣ Löst triviale Count-to-Infinity-Probleme wie gezeigt, siehe aber nebenstehendes Beispiel

Lehrstuhl für Kommunikationssysteme - Systeme II 29

“Count to Infinity” & “Split Horizon”

‣ Was passiert, wenn der Pfad 3 – 4 ausfällt:• Mit Split-Horizon beide Router 1 und 2 erzählen 3 dass sie 4

nicht mehr erreichen können

• Daraus schliesst 3, dass 4 nicht mehr erreichbar ist – OK

• Aber: 1 hört von Router 2 dass dieser Router 4 innerhalb zwei Hops erreichen kann

• Woraus 2 schlussfolgert, dass er 4 via 1 innert drei Hops sieht

• Im nächsten Schritt wird diese Entfernung dann hochgezählt und das Problem wiederholt sich

‣ Split-Horizon ist also keine Lösung für dieses Szenario

Lehrstuhl für Kommunikationssysteme - Systeme II 30

“Count to Infinity” & “Split Horizon”

‣ Nächster Versuch mit Variation der Idee: Poison Reverse – anstelle von keiner Mitteilung schicke einen Distanzvektor mit einem Eintrag von Unendlich

‣ Das löst aber auch nicht alle Probleme

‣ Ergebnis: Distance Vector Routing wird immer unbedeutender

‣ Ursache für Count-to-Infinity: Nur lokale Sicht

‣ Gerade in großen Netzwerken ist die lokale Sicht auf die Topologie unzureichend

‣ Klassische Umsetzung von Distance Vector sind RIP (II)

Lehrstuhl für Kommunikationssysteme - Systeme II 31

Routing Information Protocol

‣ RIP – sehr primitives dynamisches Routing Protokoll• Zum Selbstausprobieren (einfach mal nach quagga, zebra, ...

suchen und in z.B. der Übung testen)

• Distanzmetrik – simpler Hop-Count (Maximum von 15)

• Keine anderen Metriken verfügbar

‣ Router teilen ihre komplette Routing-Tabelle mit• Benutzt wird hierzu UDP

• Einfach einzurichten und zu implementieren

• RIP II kennt SEHR einfache Authentifikationsmethoden

• Daher nur für lokale (sichere) Netzwerke einsetzbar

32

Routing Information Protocol

Distanzvektoren• Werden alle 30s durch Response-Nachricht (advertisement)

ausgetauscht Für jedes Advertisement

• Für bis zu 25 Zielnetze werden Routen veröffentlicht Falls kein Advertisement nach 180s empfangen wurde

• Routen über Nachbarn werden für ungültig erklärt• Neue Advertisments werden zu den Nachbarn geschickt• Diese antworten auch mit neuen Advertisements

- falls die Tabellen sich ändern• Rückverbindungen werden unterdrückt um Ping-Pong-Schleifen

zu verhindern (poison reverse) gegen Count-to-Infinity-Problem- Unendliche Distanz = 16 Hops

Routing Information Protocol

Initiale Routing Tabelle für Router A:

A

B D

C

10.1.0.0

10.2.0.0 10.3.0.0

10.4.0.0 10.5.0.0

10.6.0.0 10.7.0.0

E

1

2 3

Destination Next Hop Interface Hops 10.1.0.0 0 1 1 10.2.0.0 0 2 1 10.3.0.0 0 3 1

Nachdem von Router B Info empfangen:

Destination Hops 10.2.0.0 1 10.4.0.0 1 10.6.0.0 2

Destination Next Hop Interface Hops 10.1.0.0 0 1 1 10.2.0.0 0 2 1 10.3.0.0 0 3 1 10.4.0.0 B 2 2 10.6.0.0 B 2 3

Router ARouter ARoutingRoutingTable:Table:

Router ARouter ARoutingRoutingTable:Table:

Router B only knewRouter B only knewof its direct networksof its direct networksand router C’sand router C’s

Routing Information Protocol

Endgültige Routing Tabelle für A:

Destination Next Hop Interface Hops 10.1.0.0 0 1 1 10.2.0.0 0 2 1 10.3.0.0 0 3 1 10.4.0.0 B 2 2 10.5.0.0 D 3 2 10.6.0.0 B 2 3 10.7.0.0 D 3 3

A

B D

C

10.1.0.0

10.2.0.0 10.3.0.0

10.4.0.0 10.5.0.0

10.6.0.0 10.7.0.0

E

1

2 3

Router A only receives direct advertisementsfrom routers B and D. Router C and E’s routesare learned from router B and D.

Lehrstuhl für Kommunikationssysteme - Systeme II 35

Ende der zweiten VorlesungEnde der fünften Vorlesung

Nächste Vorlesung am Montag an diesem Ort, gleiche Zeit: Ende IP/Routing, anschliessend Start im OSI-Stack in Layer 7

Das zweite Theorieblatt ist draußen (Online) seit letzter Woche Alle relevanten Informationen auf der Webseite zur Vorlesung:

http://www.ks.uni-freiburg.de/php_veranstaltungsdetail.php?id=28

Zu lesen: Kapitel zu IP/Routing, dann längerfristig zu DNS, Email und HTTP in der angegebenen Literatur!