Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 5te Vorlesung Lehrstuhl für Kommunikationssysteme Institut für Informatik / Technische Fakultät.

Präsentation zum Thema: "Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 5te Vorlesung Lehrstuhl für Kommunikationssysteme Institut für Informatik / Technische Fakultät."—  Präsentation transkript:

1 Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 5te Vorlesung Lehrstuhl für Kommunikationssysteme Institut für Informatik / Technische Fakultät Universität Freiburg 2009

2 Lehrstuhl für Kommunikationssysteme - Systeme II2 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)systemeII-SS09@rz Jede(r) sollte die Begrüßungs-Email erhalten haben Vorlesung Systeme II – Organisatorisches

3 Lehrstuhl für Kommunikationssysteme - Systeme II3 Letzte Vorlesungen Statisches IP-Routing im lokalen Subnetz (auch letzte praktische Übungen)

4 Lehrstuhl für Kommunikationssysteme - Systeme II4 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)

5 Lehrstuhl für Kommunikationssysteme - Systeme II5 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

6 Lehrstuhl für Kommunikationssysteme - Systeme II6 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

7 Lehrstuhl für Kommunikationssysteme - Systeme II7 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

8 Lehrstuhl für Kommunikationssysteme - Systeme II8 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

9 Lehrstuhl für Kommunikationssysteme - Systeme II9 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

10 Lehrstuhl für Kommunikationssysteme - Systeme II10 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

11 Lehrstuhl für Kommunikationssysteme - Systeme II11 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)

12 Lehrstuhl für Kommunikationssysteme - Systeme II12 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...

13 Lehrstuhl für Kommunikationssysteme - Systeme II13 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

14 Lehrstuhl für Kommunikationssysteme - Systeme II14 Das Kürzeste-Wege-Problem

15 Lehrstuhl für Kommunikationssysteme - Systeme II15 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

16 Lehrstuhl für Kommunikationssysteme - Systeme II16 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 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

18 Lehrstuhl für Kommunikationssysteme - Systeme II18 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

19 Lehrstuhl für Kommunikationssysteme - Systeme II19 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 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...

21 Lehrstuhl für Kommunikationssysteme - Systeme II21 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

22 Lehrstuhl für Kommunikationssysteme - Systeme II22 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

23 Lehrstuhl für Kommunikationssysteme - Systeme II23 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

24 Lehrstuhl für Kommunikationssysteme - Systeme II24 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!

25 Lehrstuhl für Kommunikationssysteme - Systeme II25 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

26 Lehrstuhl für Kommunikationssysteme - Systeme II26 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)

27 Lehrstuhl für Kommunikationssysteme - Systeme II27 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

28 Lehrstuhl für Kommunikationssysteme - Systeme II28 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

29 Lehrstuhl für Kommunikationssysteme - Systeme II29 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

30 Lehrstuhl für Kommunikationssysteme - Systeme II30 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)

31 Lehrstuhl für Kommunikationssysteme - Systeme II31 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 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

33 Routing Information Protocol Initiale Routing Tabelle für Router A: A B D C 10.1.0.0 10.2.0.010.3.0.0 10.4.0.010.5.0.0 10.6.0.010.7.0.0 E 1 23 Destination Next Hop Interface Hops 10.1.0.0011 10.2.0.0021 10.3.0.0031 Nachdem von Router B Info empfangen: Destination Hops 10.2.0.01 10.4.0.01 10.6.0.02 Destination Next Hop Interface Hops 10.1.0.0011 10.2.0.0021 10.3.0.0031 10.4.0.0B22 10.6.0.0B23 Router A RoutingTable: RoutingTable: Router B only knew of its direct networks and router Cs

34 Routing Information Protocol Endgültige Routing Tabelle für A: Destination Next Hop Interface Hops 10.1.0.0011 10.2.0.0021 10.3.0.0031 10.4.0.0B22 10.5.0.0D32 10.6.0.0B23 10.7.0.0D33 A B D C 10.1.0.0 10.2.0.010.3.0.0 10.4.0.010.5.0.0 10.6.0.010.7.0.0 E 1 23 Router A only receives direct advertisements from routers B and D. Router C and Es routes are learned from router B and D.

35 Lehrstuhl für Kommunikationssysteme - Systeme II35 Informatik IIIWinter 2007/08Informatik IIIWinter 2007/08 Rechnernetze und TelematikAlbert-Ludwig-Universität FreiburgChristian SchindelhauerRechnernetze und TelematikAlbert-Ludwig-Universität FreiburgChristian Schindelhauer Ende der zweiten Vorlesung Ende 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 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!