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

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

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

2 Lehrstuhl für Kommunikationssysteme – Systeme II2 Übungszettel abgeben (nach vorne durchreichen, vorne ablegen) Praktische Übungen Erste Übung war am 29. April, nächste am 6. Mai (Mittwoch) Besprechung des ersten Übungsblattes Übungszettel ebenso wie theoretische auch immer Online verfügbar (z.B. für Arbeit Zuhause) 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 Inhalt der Vorlesung Kurze Wiederholung IP-Paketzustellung in lokalen Netzen Prinzip des IP-Routings DHCP Theorie der Vermittlungsschicht Paketstau und Stauvermeidung Mittel, Orte und Maße ICMP Hilfsprotokoll des IP ICMP Messages

4 Lehrstuhl für Kommunikationssysteme – Systeme II4 Letzte Vorlesung Prinzip des IP Routings Routing-Tabelle Prinzip der Paketzustellung Beispiel einer Routing-Tabelle auf der Linux-Plattform Lokale und Zustellung über Router Rekursion des Matchings der Zieladresse (Ziel AND Netzmaske – Vergleich mit Netzadresse)

5 Lehrstuhl für Kommunikationssysteme – Systeme II5 Letzte Vorlesung Automatische Verteilung von IP-Adressen: DHCP

6 Lehrstuhl für Kommunikationssysteme – Systeme II6 Letzte Vorlesung DHCP als Protokoll in der Applikationsschicht für die Vermittlungsschicht (Client-Server-Kommunikation)

7 Lehrstuhl für Kommunikationssysteme – Systeme II7 Aufgaben der Vermittlungsschicht IP in erster Linie als Vermittlungsschichtprotokoll anzusehen Vermittlungsschicht hat im theoretischen Modell weitere Aufgaben zu übernehmen Reine Weiterleitung der Datagramme anhand der Vermitt- lungsschichtadressen genügt nicht Was passiert bei Leitungsüberlastung (auch von Teilstücken), wer Sender/Empfänger wird wie informiert?

8 8 Congestion Control – Stauvermeidung Jedes Netzwerk hat eine eingeschränkte Übertragungs-Bandbreite Wenn mehr Daten in das Netzwerk eingeleitet werden, führt das zum Datenstau (congestion) oder gar Netzwerkzusammenbru ch (congestive collapse) Folge: Datenpakete werden nicht ausgeliefert

9 9 Schneeballeffekt Congestion control soll Schneeballeffekte vermeiden Netzwerküberlast führt zu Paketverlust (Pufferüberlauf,...) Paketverlust führt zu Neuversand Neuversand erhöht Netzwerklast Höherer Paketverlust Mehr neu versandte Pakete...

10 10 Anforderungen an Congestion Control Effizienz Verzögerung klein Durchsatz hoch Fairness Jeder Fluss bekommt einen fairen Anteil Priorisierung möglich -gemäß Anwendung -und Bedarf

11 11 Informatik IIIWinter 2007/08Informatik IIIWinter 2007/08 Mittel der Stauvermeidung Erhöhung der Kapazität Aktivierung weiterer Verbindungen, Router Benötigt Zeit und in der Regel den Eingriff der Systemadministration Reservierung und Zugangskontrolle Verhinderung neuen Verkehrs an der Kapazitätsgrenze Typisch für (Virtual) Circuit Switching Verringerung und Steuerung der Last (Dezentrale) Verringerung der angeforderten Last bestehender Verbindungen Benötigt Feedback aus dem Netzwerk Typisch für Packet Switching -wird in TCP verwendet

12 Lehrstuhl für Kommunikationssysteme – Systeme II12 Orte und Maße von Paketstaus Router- oder Host-orientiert Messpunkt (wo wird der Stau bemerkt) Steuerung (wo werden die Entscheidungen gefällt) Aktion (wo werden Maßnahmen ergriffen) Fenster-basiert oder Raten-basiert Rate: x Bytes pro Sekunde Fenster: siehe Fenstermechanismen in der Sicherungsschicht wird im Internet verwendet

13 13 Routeraktion: Paket löschen Bei Pufferüberlauf im Router muss (mindestens) ein Paket gelöscht werden Das zuletzt angekommene Paket löschen (drop-tail queue) Intuition: Alte Pakete sind wichtiger als neue (Wein) -z.B. für go-back-n-Strategie Ein älteres Paket im Puffer löschen Intuition: Für Multimedia-Verkehr sind neue Pakete wichtiger als alte (Milch)

14 14 Paketverlust erzeugt implizites Feedback Paketverlust durch Pufferüberlauf im Router erzeugt Feedback in der Transportschicht beim Sender durch ausstehende Bestätigungen Internet Annahme: Paketverlust wird hauptsächlich durch Stau ausgelöst Maßnahme: Transport-Protokoll passt Senderate an die neue Situation an

15 15 Proaktive Methoden Pufferüberlauf deutet auf Netzwerküberlast hin Idee: Proaktives Feedback = Stauvermeidung (Congestion avoidance) Aktion bereits bei kritischen Anzeigewerten z.B. bei Überschreitung einer Puffergröße z.B. wenn kontinuirlich mehr Verkehr eingeht als ausgeliefert werden kann... Router ist dann in einem Warn- Zustand

16 Lehrstuhl für Kommunikationssysteme – Systeme II16 Paket drosseln (Choke packets) Wenn der Router in dem Warnzustand ist: Sendet er Choke-Pakete (Drossel-Pakete) zum Sender Choke-Pakete fordern den Sender auf die Sende-Rate zu verringern Problem: Im kritischen Zustand werden noch mehr Pakete erzeugt Bis zur Reaktion beim Sender vergrößert sich das Problem wird im Internet verwendet

17 17 Proaktive Aktion: Warnbits Wenn der Router in dem Warnzustand ist: Sendet er Warn-Bits in allen Paketen zum Ziel-Host Ziel-Host sendet diese Warn-Bits in den Bestätigungs-Bits zurück zum Sender Quelle erhält Warnung und reduziert Sende-Rate

18 18 Proaktive Aktion: Random Early Detection Random Early Detection (RED) Verlorene Pakete werden als Indiz aufgefasst Router löschen Pakete willkürlich im Warnzustand Löschrate kann mit der Puffergröße steigen P(drop) 1.0 MaxP MinThMaxThAvgLen

19 19 Reaktion des Senders Raten-basierte Protokolle Reduzierung der Sende-Rate Problem: Um wieviel? Fenster-basierte Protokolle: Verringerung des Congestion-Fensters z.B. mit AIMD (additive increase, multiplicative decrease)

20 Lehrstuhl für Kommunikationssysteme – Systeme II20 Aufgaben der Vermittlungsschicht Probleme nur teilweise durch IP behandelt Schichtenmodell nicht in Reinform umgesetzt – andere Schichten übernehmen Aufgaben oder Aufgaben auch doppelt implementiert (spätere Vorlesungen) In TCP/IP wird feine Flusskontrolle von TCP übernommen IP selbst wenig Möglichkeiten diese Vermittlungsschichtauf- gaben zu implementieren TOS (Type of Service – 2te Vorlesung) Feld als Entscheidungshilfe zur Paketklassifizierung ICMP übernimmt Teile der IP-Aufgaben

21 Lehrstuhl für Kommunikationssysteme – Systeme II21 IP – Internet Control Message Protocol IP paket-orientiertes, verbindungsloses Protokoll Hat keine eingebauten, direkten Mechanismen der Paketverfolgung Prinzip: Verschicken & Vergessen Pakete können zu lange verzögert oder auch verloren gehen Zielmaschine kann unerreichbar sein (temporär, für länger) -Maschine selbst (abgeschaltet, abgestürzt,...) -Routing schlägt fehl (Netzwerkfehlkonfiguration, Netzwerkkomponenten,...) -Protokoll auf höherem Level existiert nicht oder schlägt fehl

22 Lehrstuhl für Kommunikationssysteme – Systeme II22 IP – Internet Control Message Protocol Typischerweise kümmert sich Protokoll auf höherer Schicht (TCP) oder Applikation implementiert Time-Outs,... Alternatve: Einführung eines Hilfsprotokolls der Vermittlungs- schicht, da nicht alle Aufgaben sinnvoll an höhere Schichten delegierbar Einführung eines IP-nahen Mechanismus für Fehlermeldun- gen und speziellen Informationsaustausch – ICMP ICMP definiert Erweiterungen zum unsicheren IP Diese logisch als Teil des IP-Moduls angelegt, aber in IP- Datagramme eingepackt Damit können IP-Module von Systemen sich Informationen zustellen

23 Lehrstuhl für Kommunikationssysteme – Systeme II23 IP – Internet Control Message Protocol Beschränkt auf Fehlermeldungen und Reporting Anfragen: Laufen nach dem Client/Server Info Request/Response Verfahren Fehlermeldungen: Mitteilung über Reihe von definierten Fehlerzuständen Dabei: Reihe von Einschränkungen, um ICMP Message Kaskaden zu vermeiden Deshalb dürfen keine ICMP Messages als Antwort verschickt werden, wenn: Eine ICMP Fehlermeldung einen Fehler generiert (Antwort OK für spezielle ICMP-Anfragen, die Antwort erwarten)

24 Lehrstuhl für Kommunikationssysteme – Systeme II24 IP – Internet Control Message Protocol Deshalb keine ICMP Messages wenn: Für IP-Datagramme, deren Header Fehler aufweisen (könnte ja die Quelladresse von betroffen sein – Meldung an andere Maschine sinnlos) Für Broadcast (vorletzte Vorlesung) oder Multicast IP-Datagramme Link Layer Broadcast oder Multicast Frames Ungültige Quelladressen oder das Null-Netzwerkprefix Auf IP-Fragmente bis auf das erste (die Ausgangsmaschine schickt ja genau nur ein Paket los)

25 Lehrstuhl für Kommunikationssysteme – Systeme II25 IP – Internet Control Message Protocol ICMP als Standard-IP-Paket hat definierten Aufbau und einen Header der Form: Typfeld gibt einen der 15 möglichen Message Types an Codefeld spezifiziert Subtypen Check-Summe deckt die gesamte ICMP Message ab

26 Lehrstuhl für Kommunikationssysteme – Systeme II26 IP – Internet Control Message Protocol Nicht mehr adäquat angesichts der komplexeren IP- Anwendungen heutzutage Gekapselte IP-Pakete (GRE – General Routing Encapsulation für IP-over-IP Tunnel) IPsec Pakete und andere komplexere Protokoll-Header Probleme bei NAT Neuere Regeln definieren deshalb: Soviel wie möglich des Original-pakets ohne dabei die Gesamtpaket-Länge von 576 Byte (Art von Minimum Transfer Unit) zu überschreiten Zudem: Für bestimmte ICMP-Typen lassen sich Test-Pattern definieren, z.B. bei ping (Manpage aufrufen und nachsehen) Besseres Wiederfinden von Testpaketen bei großen Setups

27 Lehrstuhl für Kommunikationssysteme – Systeme II27 IP – Internet Control Message Protocol ICMP Messages vom Typ Fehler (erstes Header Feld): 3 = Destination Unreachable 4 = Source Quench (Weg-Überlastung, Thema später noch vertieft behandelt) 5 = Redirect (IP Routing) 11 = Time Exceeded (TTL) 12 = Parameter Problem

28 Lehrstuhl für Kommunikationssysteme – Systeme II28 IP – Internet Control Message Protocol Bei Fehlermeldungen übermittelt ICMP den Header des fehlgeschlagenen IP-Pakets und weitere 8 Daten-Bytes (Start des nächsten Protokoll-Headers)

29 Lehrstuhl für Kommunikationssysteme – Systeme II29 IP – Internet Control Message Protocol ICMP Meldungen vom Typ Query 0 = Echo Reply (z.B. bei der ping Antwort) und 8 = Echo Request ("ping Anfrage")

30 Lehrstuhl für Kommunikationssysteme – Systeme II30 IP – Internet Control Message Protocol ICMP Meldungen vom Typ Query Sollte nicht in Firewalls gefiltert werden für einfaches Netzwerk-Debugging, aber... Sicherheitserwägungen, Verschleierung der Netzwerkstruktur... Deshalb im Beispiel in der praktischen Übung beim traceroute * * * statt Router-IP 9 = Router Advertisement 10 = Router Solicitation(beide nicht mehr üblich, ersetzt beispielsweise durch DHCP)

31 Lehrstuhl für Kommunikationssysteme – Systeme II31 IP – Internet Control Message Protocol ICMP Meldungen vom Typ Query 13 = Time Stamp Request 14 = Time Stamp Reply – überholt und durch andere Protokolle, wie RDate (TCP) oder Network Time Protocol (NTP – Applikationsschicht) übernommen 17 = Address Mask Request 18 = Address Mask Reply (überholt, ersetzt bspw. Durch DHCP – letzte Vorlesung) Deshalb werden die meisten dieser ICMP Messages einfach unterdrückt oder ignoriert – bieten zu einfache Einfallstore für Spoofing, Sniffing, Verfälschungen,...

32 Lehrstuhl für Kommunikationssysteme – Systeme II32 IP – Internet Control Message Protocol ICMP Meldungen vom Typ Query Ging auch etwas an der Idee von IP als einfaches Fire-Forget- Protokoll vorbei ICMP zu unterkomplex, deshalb viele der genannten Aufgaben auf höhere Schichten verlagert Meldungen des Typs Destination Unreachable Arten von Unreachable Meldungen: -0: Network – keine Route in das Zielnetzwerk vorhanden, tritt typischerweise auf einen Wege-Router auf -1:host – Rechner im Zielnetz nicht erreichbar -2:protocol – Höherschichtige Protokoll nicht erreichbar, nicht implementiert

33 Lehrstuhl für Kommunikationssysteme – Systeme II33 IP – Internet Control Message Protocol Arten von Unreachable Meldungen: -3:port – Auf diesem Port reagiert kein Dienst/Applikation -Generelles Problem bei der Erreichung eines Ziels: -4: frag needed – aber das Dont Fragment Bit im IP Header war gesetzt (genutzt für bestimmte Protokolle oder MTU Path Discovery) -Neuere Implementierungen ersetzen das zweite Wort des ICMP Header (üblicherweise undefiniert) mit der MTU des nächsten Hops -5: source route failed – eher selten, da IP-Option (beim IP- Header nicht näher besprochen) Source-Route eingetragen war, diese aber nicht realisiert werden konnte

34 Lehrstuhl für Kommunikationssysteme – Systeme II34 IP – Internet Control Message Protocol ICMP Source Quench: Ursprüngliche Idee war, dass Routers Staumeldungen generieren konnten (Idee der Bandbreiten- steuerung) Problem nur: Generieren von weiterem Traffic in Phasen der Überlastung nicht besonders clever und mögliche Interferenzen mit der TCP Fluss-Kontrolle Deshalb sollten Router keine solchen ICMP Messages erzeugen

35 Lehrstuhl für Kommunikationssysteme – Systeme II35 IP – Internet Control Message Protocol ICMP Time Exceeded (vom Typ 11) Zeigt an, dass die Zustellungszeit für ein IP-Paket abgelaufen ist (vgl. Diskussion in der Vorlesung zu IP Header) Inhalt des Code-Felds: -0: TTL exceeded in transit -1: fragment reassembly time exceeded Darüber hinaus Typ: Parameter problem (Typ 12) - Generelles Catch-All für Zustellungsfehler, die nicht durch andere ICMP-Typen abgedeckt sind

36 Lehrstuhl für Kommunikationssysteme – Systeme II36 IP – Internet Control Message Protocol ICMP Redirect (vom Typ 5) Zeigt an, dass ein falscher First-Hop-Router vom sendenden System benutzt wird Redirect zeigt den Router, der anstelle verwendet werden sollte Code-Feld Werte: -0:network, 1:host, 2:TOS & Network, 3:TOS & Host Meldung des ping Kommandos

37 Lehrstuhl für Kommunikationssysteme – Systeme II37 IP – Internet Control Message Protocol ICMP Redirect (vom Typ 5) als Wireshark-Mitschnitt Noch aktives Relikt vergangener Tage, welches aber vielfach noch funktioniert (zumindest im Sinne der Generierung solcher Pakete)

38 Lehrstuhl für Kommunikationssysteme – Systeme II38 IP – Internet Control Message Protocol ICMP Redirect (vom Typ 5) Idee: Einsparen von überflüssigen Hops, Reduktion von Traffic im gleichen Subnetz (Paket passiert dieses nur einmal statt doppelt) Prinzip: End-System schickt Paket zum Default-Router (nach eigener Routing-Tabelle)

39 Lehrstuhl für Kommunikationssysteme – Systeme II39 IP – Internet Control Message Protocol ICMP Redirect (vom Typ 5) Empfangener Rechner (der nicht der Router ist) informiert die andere Maschine über korrekten Default-Router (in der heilen Welt) Einfallstor für Angriffe durch Paketumleitung, für Denial-of-Service,...

40 Lehrstuhl für Kommunikationssysteme – Systeme II40 IP – Internet Control Message Protocol ICMP Redirect (vom Typ 5) Ursprünglicher Sender aktualisiert seine Routing-Tabelle auf den korrekten Router War interessant in frühen (pre-DHCP und Böse-Buben) Zeiten, nun überholt Nun zurück zu allgemeineren (Weitverkehrs-)Routing-Prinzipien

41 Lehrstuhl für Kommunikationssysteme – Systeme II41 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 (~18.000) Dieses schon in mittleren Organisationen wie Universität Freiburg schwierig Deshalb – automatische Ermittlung von Routen nach bestimmten Kriterien (Optimalität) durch geeignete Algorithmen Umsetzung in speziellen Routing-Protokollen, die Routing- Informationen austauschen und lokale Routing-Tabellen konfigurieren – nächste Vorlesung(en)

42 Lehrstuhl für Kommunikationssysteme – Systeme II42 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 Nächste Vorlesung am Montag an diesem Ort, gleiche Zeit: Weiter zu IP/Routing Jede(r) sollte spätestens jetzt ersten Übungszettel abgegeben haben Praktische Übung am Mittwoch wieder im Rechenzentrum (Keller) 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 Mailingliste wird in der Zwischenzeit aufgesetzt und eine erste Info-Mail verschickt... Zu lesen: Kapitel zu IP, ICMP und Routing in der angegebenen Literatur!