lehrstuhl für kommunikationssysteme - systeme ii1 systeme ii – 5te vorlesung lehrstuhl für...
Post on 05-Apr-2015
109 Views
Preview:
TRANSCRIPT
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!
top related