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

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

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

2 Lehrstuhl für Kommunikationssysteme - Systeme II2 Mailingliste zur Vorlesung Einrichtung einer Mailing-Liste systemeII-SS09@....uni... Ankündigungen zur Vorlesung Bei Bedarf Nachfragen/Diskussion zu Vorlesungsthemen Hinweise etc. Verwaltet von Phillip Chlap (Hiwi am Lehrstuhl), der sich auch um Vorlesungsaufzeichnungen und Materialien kümmert Ein- und Austragungen von der Liste bitte über ihn regeln Vorlesung Systeme II – Organisatorisches

3 Lehrstuhl für Kommunikationssysteme - Systeme II3 Theoretische Übungen Ausgabe der Blätter in den folgenden Veranstaltungen 22.04. (Bitte ein Blatt ergreifen oder Online herunterladen) 06.05. 20.05. 27.05. 10.06. 24.06. 08.07. Zwischendrin praktische Übungsblätter in den Übungen Bearbeitung der Blätter ist nicht verpflichtend, ebensowenig wie der Besuch der praktischen Übungen Vorlesung Systeme II – Organisatorisches

4 Lehrstuhl für Kommunikationssysteme - Systeme II4 Inhalt der Vorlesung IP auf der Vermittlungsschicht IP Header Fragmentierung TTL Ziel und Quelladressen... IP-Adressräume Sub / supernetting Datagramm-Zustellung Routing-Tabelle

5 Lehrstuhl für Kommunikationssysteme - Systeme II5 Intro - Motivation Basisprotokoll des Internets / Grundlage seines Erfolgs Bietet notwendigen Service Diensten in höheren Schichten an Überbrückt transparent verschiedene physikalische Netze

6 Lehrstuhl für Kommunikationssysteme - Systeme II6 Internet Protocol Schichtenmodelle und Implementierung

7 Lehrstuhl für Kommunikationssysteme - Systeme II7 Intro - Schichtenmodelle Wiederholung: Schichtenmodelle, Protokolle und Anwendungen

8 Lehrstuhl für Kommunikationssysteme - Systeme II8 Intro - Universaldienst IP (internet protocol) entspricht OSI-Layer 3 (Vermittlungs- schicht) Universeller Service zum Verbinden verschiedener Netze benötigt

9 Lehrstuhl für Kommunikationssysteme - Systeme II9 Intro - Universaldienst Letzte Veranstaltung: Verschiedene Weitverkehrsnetze Hinzu kommen: Endanwender via DSL, Kabel, UMTS, ISDN, Modem, GPRS... Local Area Netzwerke (LAN, heutzutage typischerweise Ethernet – spätere Vorlesung) in unterschiedlichen Größen: Zu Hause mit unter zehn Maschinen Große Organisationen mit vielen Tausend,...

10 Lehrstuhl für Kommunikationssysteme - Systeme II10 Intro – Universaldienst Netzwerkabstraktion Unabhängig von physikalischer Hardware Ausschliesslich in Software implementiert Bestandteil des OS oder Applikation, die unter OS läuft Aufgaben folgend aus Vermittlungsschicht Nachrichtentransport ohne Interpretation bzw. Prüfung der Semantik Zuweisung von logischen Quell- und Ziel-Adressen Steuerung des Kommunikations-Subnetzes Routing - Paketweiterleitung

11 Lehrstuhl für Kommunikationssysteme - Systeme II11 Internet Protocol Warum IP? IP ist im Wesentlichen ein Vermittlungsschichtprotokoll Lokale Netzwerke können nicht nur über Hubs, Switches oder Bridges verknüpft werden Ethernet-Hubs: Kollisionen nehmen überhand (später genauer) Switches: -Routen-Information durch Beobachtung der Daten ineffizient -Broadcast aller Nachrichten schafft Probleme Es gibt über 10 Mio. lokale Netzwerke im Internet... Zur Beförderung von Paketen in großen Netzwerken braucht man Routeninformationen Wie baut man diese auf? Wie leitet man Pakete weiter?

12 Lehrstuhl für Kommunikationssysteme - Systeme II12 Internet Protocol Definition eines einheitlichen Adressierungsschemas, das Hardware/Software-unabhängig ist Bereitstellung eines Datagrammaustauschs zwischen Netzen Hosts – im IP Sprech: Endsysteme Router in mehr als einem Teilnetz, leiten Vermittlungsschicht- datagramme zwischen ihnen weiter Router implementieren Routing-Protokolle zum Füllen ihrer Routing-Tabellen Hilfsprotokolle (wie bspw. ARP und ICMP für IP – spätere Vor- lesungen) können benötigt werden

13 Lehrstuhl für Kommunikationssysteme - Systeme II13 Internet Protocol Der IP Layer stellt damit eine Ende-zu-Ende Zustellung von Paketen sicher Dabei konsistente Datagrammabstraktion Best-effort Zustellung Keine Fehlererkennung in den Daten (Payload) Konsistente Maximalgröße der Datagramme Konsistentes globales Adressierungsschema Sollte in der Lage sein, sich an verschiedene Paketgrößen auf dem Gesamtpfad anpassen können Implementierung der geforderten Features im IP-Header

14 Lehrstuhl für Kommunikationssysteme - Systeme II14 Internet Protocol – Header Protokoll-Header beinhaltet: Versionsfeld Quell- und Zieladressen Längenfelder (Header, Optionen und Daten) Header Checksumme Fragmentierungssteuerung TTL und TOS Info Wobei TOS Info normalerweise ignoriert wird Sehr leicht auf dem Weg zu ändern (warum beachten?) Problem: Konsistente Sicht auf Prioritäten Wie sollen die am Übergang zwischen Autonomen Systemen (letzte Vorlesung) gehandhabt werden?

15 Lehrstuhl für Kommunikationssysteme - Systeme II15 Internet Protocol – Header Versionsfeld (4 für Standard IP, 5 STII, 6 nächste Generation IP) und IP Header-Länge haben jeweils 4 Byte IP Header normalerweise 20 Byte groß, kann mit Optionen größer werden Längenfeld benötigt, um zu wissen, wann der nächste Header im Paket folgt

16 Lehrstuhl für Kommunikationssysteme - Systeme II16 Internet Protocol – Header IP Optionen können bis zu 40 Byte groß werden Feld für die Paketgesamtlänge ist 16 bit groß, woraus eine maximale Paketlänge von 64kbyte nicht überschritten werden darf Das Minimum liegt bei 20 Byte (nur der IP Header selbst) Die MTU von üblichen physikalischen Netzen ist deutlich kleiner, z.B. 1500 Byte beim Ethernet Es gibt ein 16 bit Identifikationsfeld für IP-Fragmente Wird für jedes Paket (ob gebraucht oder nicht) vom Sender des Datagramms eingetragen Man kann nicht wissen, ob Fragmentierung irgendwann nochmal auftritt

17 Lehrstuhl für Kommunikationssysteme - Systeme II17 Internet Protocol – Fragmentierung IP hat die Aufgabe der Datagrammanpassung IP Datagramme können nicht größe als 64 kByte sein (Beschränkung durch Größenfeld im Header) Layer 2 Protokolle melden initiale MTU Linux loopback 16384 Byte Ethernet Frames können max. 1500 Byte (aufgehoben für Gigabit-Ethernet) ATM kann 48 Byte Langsame Modem/GPRS-PPP Verbindungen könnten bspw. 296 Byte als MTU melden In der praktischen Übung mal mit ifconfig oder ip nachsehen

18 Lehrstuhl für Kommunikationssysteme - Systeme II18 Internet Protocol – Fragmentierung Fragmentierung und Wieder-Zusammenbau Alle Verbindungsschichts-Datagramme werden in mehrere Sicherungsschichts-Einheiten umgebaut, die kleiner/gleich zur MTU sind Weitere Fragmentierung kann auftreten Manchmal deshalb geschickter schon in der Quelle eine kleinere MTU einzutragen, um spätere Fragmentierung zu vermeiden (typische Situation im LAN zuhause wegen DSL/PPPoE)

19 Lehrstuhl für Kommunikationssysteme - Systeme II19 Internet Protocol – Fragmentierung Zusammenbau der Datagramme erst im Ziel(!) und nicht schon irgendwo zwischendurch Jedes Fragment verhält sich als autonomes, vollständiges und damit routebares IP-Datagramm Nicht im Router zusammengebaut: Damit können sie unterschiedliche Wege durchs Netz nehmen Reduzieren Komplexität in Router-Hard/Software Werden durch das Tripel aus Quelle, Ziel und Fragment-ID unterschieden

20 Lehrstuhl für Kommunikationssysteme - Systeme II20 Internet Protocol – Header/Fragmentierung IP-Fragmentfelder Initiale Zerteilung der Ursprungsmessage kann noch nicht klein genug sein für ein spezielles Teilsegment Bei auftretender Fragmentierung wird die ID in jedes IP- Fragment kopiert Inhalt des 16 bit Felds wird vom Sender erzeugt Verschiedene OS nutzen verschiedene Schemata zur Generierung der ID So kann man maskierte Hosts durch ihre Fragment-IDs unterscheiden, da die Zähler jeder Maschine unterschiedliche Werte haben (z.B. Traffic-abhängig) Private Netze können so unbewusst Informationen liefern

21 Lehrstuhl für Kommunikationssysteme - Systeme II21 Internet Protocol – Header/Fragmentierung IP-Fragmentierung - weitere Felder: Flags für Fragmentierungssteuerung MF: More fragments (folgen) DF: dont fragment (Einige Protocol Implementierungen wie DHCP in Boot-ROMs können Pakete nicht wieder zusammenbauen) Feature kann für MTU Path Discovery genutzt werden (Erhöhen der Paketgröße bis keine ICMP Fehlermeldung mehr kommt) Fragmentation Offset

22 Lehrstuhl für Kommunikationssysteme - Systeme II22 Internet Protocol – Header/Fragmentierung IP-Fragmentierung - weitere Felder: Offset bezieht sich auf das Originaldatagramm Feld ist Null, wenn keine Fragmentierung genutzt wurde Warum Offset und nicht Fragmentnummern? Falls weitere Fragmentierung benötigt wird – Fragmentierung von Fragmenten Fehlertolerant bei vertauschter Reihenfolge beim Empfang und bei Duplizierung

23 Lehrstuhl für Kommunikationssysteme - Systeme II23 Internet Protocol – Fragmentierung Probleme durch Fragmentierung: Verlust von einem oder mehr Fragmenten impliziert den Verlust des gesamten Originaldatagramms IP ist best effort und hat damit keine Wieder-Übertragung bei Verlust, muss erst ein Time-Out auftreten, damit Verlust klar wird Kann Interessant für DoS Angriffe sein (Crash von Maschinen oder deren IP-Stack, Einschleusen von Fragmenten,...) Fragmentierungskonzept wurde deshalb mit IPv6 komplett geändert

24 Lehrstuhl für Kommunikationssysteme - Systeme II24 Internet Protocol – Header Weitere Header-Felder TTL mit 8 bit (Max. Netzwerkdurchmesser von 256 Routern) Sorgt für das Verschwinden von unzustellbaren, kreisgerouteten Paketen aus dem Netz -1 bei jedem Router-Hop (bei jeder vergangenen Sekunde)

25 Lehrstuhl für Kommunikationssysteme - Systeme II25 Internet Protocol – Header Weitere Header-Felder Protocol mit 8 bit Wohin soll das Paket nach weiter oben im Stack (Transport- schicht) weitergereicht werden? Typische Kennungen: TCP – 6 (spätere Vorlesung) UDP – 17 (spätere Vorlesung) ICMP – 1 (IP Status-Protokoll für bestimmte Meldungen) IGMP – 2 (Multicast, spätere Vorlesung) IP – 4 (warum – IP-in-IP-Szenarien) Weitere siehe beispielsweise /etc/protocols in der praktischen Übung

26 Lehrstuhl für Kommunikationssysteme - Systeme II26 Internet Protocol – Header Weitere Header-Felder Header Checksum – Überprüfung der Integrität des Headers Warum nicht gleich des gesamten Pakets? Nicht Aufgabe der Vermittlungsschicht Aufwand – muss beim Routerdurchlauf erneut erzeugt werden (warum?) Fragmentierung

27 Lehrstuhl für Kommunikationssysteme - Systeme II27 Internet Protocol – Header Adressen als wichtig(st)e Header-Information Zwei 32 bit Felder für Quell- und Zieladressen Für Routing-Entscheidungen wird nur die Binärform verwendet – die Dezimaldarstellung mit Punkten ist lediglich für menschliche Lesbarkeit

28 Lehrstuhl für Kommunikationssysteme - Systeme II28 Internet Protocol – Header Programme und Betriebssystems übersetzen IP-Adressen deshalb automatisch zwischen den beiden Repräsentationen IP-Adressen sind/waren topologisch sensitiv Host-Interfaces im selben Netzwerk haben dasselbe Prefix Prefix wird durch ISP oder lokale Netzwerkadmins zugeteilt, wobei sie 32-bit global eindeutig sein müssen (mit bestimmten Einschränkungen)

29 Lehrstuhl für Kommunikationssysteme - Systeme II29 Internet Protocol – Header/Adressen IP-Adressen sind damit (virtuell) in Netzwerk- und Host-Teil aufgespalten

30 Lehrstuhl für Kommunikationssysteme - Systeme II30 Internet Protocol – Header/Adressen Frühe Standards definierten für diese Aufteilungen ursprünglich fünf Adressklassen A, B, C, D and E IP-Adresseen sollten selbsterklärend sein, sie sollten Informationen zur Netzwerkstruktur enthalten – ist aber Geschichte In dieser Darstellung besteht eine IP aus bestimmten Mustern von höherwertigen Bits, welche die Klasse repräsentierten, gefolgt von einem Netzwerk und Host Anteil Rechner im selben Netzwerk besitzen ein gemeinsames Prefix und müssen ein eindeutiges Suffix haben

31 Lehrstuhl für Kommunikationssysteme - Systeme II31 Internet Protocol – Adressklassen

32 Lehrstuhl für Kommunikationssysteme - Systeme II32 Internet Protocol – Header/Adressen Klasse A: (high order bits: 0) Große Organisationen, wenige Netze (127), gewaltige Zahl von Hosts (16.7 Millionen, völlig unrealistisch) Adressbereich in Dezimaldarstellung 0.0.0.0 – 127.255.255.255 Class B: (high order bits: 10) Mittelgroße Organisationen und Firmen, wie beispielsweise die Universitäten in Deutschland, es gibt einige Netze (16,384 – viel zu wenige) und eine größere Zahl von Hosts (65,536) Adressebereich 128.0.0.0 – 191.255.255.255 Class C: (high order bits: 110) Kleine Organisationen und Firmen, ziemlich viele Netze (2,097,152) mit einer kleinen Zahl von Maschinen pro Netz

33 Lehrstuhl für Kommunikationssysteme - Systeme II33 Internet Protocol – Header/Adressen Klasse C reicht von 192.0.0.0 bis 223.255.255.255 Class D: (high order bits: 1110) Multicast-Adresses, definiert aber kaum wirklich genutzt – deutlich anders als A – C (spätere Vorlesung) Adresse range 224.0.0.0 – 239.255.255.255 Class E: (high order bits: 1111) Für experimentelle Nutzung reserviert Adresse range 240.0.0.0 – 255.255.255.255 Theoretischer Adressraum mit 4,294,967,296 sieht üppig aus, aber jetzige Erdbevölkerung schon größer Zudem im Internet nur 1.X.Y.Z bis 223.X.Y.Z (mit weiteren Lücken) nutzbarX.Y.Z

34 Lehrstuhl für Kommunikationssysteme - Systeme II34 Internet Protocol – Header/Adressen Weitere Spezialadressen sind nicht direkt nutzbar: 0.0.0.0 definiert die sogenannte default route or ist die spezielle Startadresse eines Hosts, der nach einer dynamisch vergebenen IP fragt 255.255.255.255 ist die lokale broadcast Adresse (und die damit auch die Zieladresse in Paketen von Hosts, die DHCP machen) 127.0.0.0 ist ein sehr großer Bereich für die spezielle loop back network Adresse (wo man eigentlich immer nur genau eine, typischerweise die 127.0.0.1 braucht) Diese Adresse findet man auf jeder Maschine mit IP für Applikationen, die IP nutzen ohne dafür die Maschine selbst zu verlassen

35 Lehrstuhl für Kommunikationssysteme - Systeme II35 Internet Protocol – Header/Adressen Spezialadressen, die nur eingeschränkt nutzbar sind: Adressen für private Nutzung – Viele Organizationen nutzen IP, aber mit eingeschränktem/abgeschotteten Zugriff 10.0.0.0 – 10.255.255.255 (im Klasse A Bereich) 172.16.0.0 – 172.31.255.255 (16 Klasse B Netze) 192.168.0.0 – 192.168.255.255 (65,536 Klasse C) So hat das Universitäts-WLAN primär 10.X.Y.Z Adressen, über die dann eine echte IP via VPN bezogen wird (alles andere wäre Verschwendung und gegen das Konzept)X.Y.Z Pakete mit Adressen aus diesen Bereichen sollten auf Internet Routern verworfen werden

36 Lehrstuhl für Kommunikationssysteme - Systeme II36 Internet Protocol – Header/Adressen Für Adressierung ganzer Subnetze oder die Ansprache aller Hosts in einem gegeben LAN (hängt aber von den Fähigkeiten der darunterliegenden phys. Netze ab) wurden ebenfalls spezielle IP-Adressen definiert Netzwerk Nummer ist die kleinste IP-Adresse in einem gegebenen (Sub)Netzwerk, sie adressiert nicht eine Maschine und darf daher nicht an einen Host vergeben werden. Man findet sie in den Routingtabellen (Ende dieser Vorlesung) Broadcast Adresse ist die größtmögliche IP in einem Netzwerk. Nicht für einen einzelnen Host – an diese Adresse kann man alle Hosts in einem Subnetz mit einem einzigen Paket erreichen (kommt auf das drunterliegende phys. Netz an)

37 Lehrstuhl für Kommunikationssysteme - Systeme II37 Internet Protocol – Header/Adressen Wenn man nun die Beispiel Klasse B Adresse 172.31.5.200 nimmt: Dieser Host ist ein Mitglied im Netzwerk mit der Netzwerk Nummer 172.31.0.0 und einer Broadcast Adresse 172.31.255.255 Andere Zuordnungen möglich, denn Netzwerke mit einer sehr großen Zahl von Hosts lassen sich in Subnetze für bessere Administration und Berücksichtigung der physikalischen Netzwerktopologien (zu diesen mehr in der Vorlesung zu Schichten 1 & 2) aufteilen

38 Lehrstuhl für Kommunikationssysteme - Systeme II38 Internet Protocol – Header/Adressen Das Beispiel Klasse B Netzwerk 172.16 mit 65536 Host IP Adressen, erlaubt z.B. die Aufteilung in 256 Subnetze mit 256 Hosts (minus Netz- und Broadcast-Adresse) falls an der Byte-Grenze unterteilt Jedoch: Die resultierenden 256 Klasse C Netzwerke haben dasselbe high order bit Muser, wie das originale Klasse B Netzwerk

39 Lehrstuhl für Kommunikationssysteme - Systeme II39 Internet Protocol – Subnetze Die Zahl der Klasse B Netzwerke war deutlich zu wenig (Deutschland alleine hat schon mehr als 100 Universitäten und Fach/Hochschulen und würde alleine schon mindestens 100 Klasse B Netzwerke der vorhandenen 16,384 verbraten)... und es gibt keinen wirklichen Bedarf für Klasse A Netzwerke (IBM, HP,... hatten mal eines – im RFC nachlesen) Es gibt Bedarf für größere Netzwerke als Klasse C, die jedoch deutlich kleiner als B sind Die Adressverschwendung war zu Beginn groß, so dass der Bedarf nach IPv6 Mitte der 1990er sehr hoch schien Aber erstmal wurde das Konzept von Sub- und Supernetzen eingeführt

40 Lehrstuhl für Kommunikationssysteme - Systeme II40 Internet Protocol – Subnetze Supernetting bedeutet die Aneinanderhängung von Adressräumen zu größeren mit genau einer gemeinsamen Netzwerk- und Broadcast-Adresse Damit IP Adressen nicht mehr selbsterklärend Zur Info auf die Spanne von Adressen wurden Netzmasken definiert: 1 markiert den Prefix Teil IP (Netzwerk) 0 den Suffixteil einer IP (Host)

41 Lehrstuhl für Kommunikationssysteme - Systeme II41 Internet Protocol – Subnetze Die Netzmaske von 255.255.0.0 markiert gerade die Größe eines Klasse B Netzwerks, 255.0.0.0 steht für Größen der Klasse A und 255.255.255.0 für C Netzmaskes lassen sich durch die Zahl der 1 in der Netzmaske abkürzen: Klasse A: 8, B: 16, C: 24 Bei der Zusammenfassung von zwei Klasse C Netzwerken in ein größeres, ergibt das aus: Netzwerk 192.168.10.0 mit Broadcast 192.168.10.255 & Netzwerk 192.168.11.0 mit Broadcast 192.168.11.255 Ein kombiniertes Netz: Netzwerk 192.168.10.0 mit Broadcast 192.168.11.255 und Netzmaske 255.255.254.0

42 Lehrstuhl für Kommunikationssysteme - Systeme II42 Internet Protocol – Subnetze

43 Lehrstuhl für Kommunikationssysteme - Systeme II43 Internet Protocol – Subnetze Aufteilung der Netzmaske in Prefix und Suffix passiert am Übergang zwischen 1 und 0 Beispielsweise steht 1111 1111.1111 1111.1 000 0000.0000 0000 für die Netzmaske 255.255.128.0 (vielfach sieht man auch die Abkürzung zu 17, Zahl der 1 in der Maske) Wenn wir das Netzwerk 132.230.0.0/255.255.0.0 in zwei Subnetze aufteilen wollen: 132.230.0.0 – 132.230.127.255 132.230.128.0 – 132.230.255.255

44 Lehrstuhl für Kommunikationssysteme - Systeme II44 Internet Protocol – Subnetze Theoretisch könnte man das Netzwerk auch anders teilen: 1111 1111.1111 1111.0000 0000.0000 0001 ist die Netzmaske 255.255.0.1 und man erhält zwei Subnetze, eines mit geraden Zahlen (im letzten Octet der IP Adresse) und eines mit den ungeraden IP Adressen Das Management von Netzwerken in dieser Weise ist jedoch ziemlich riskant und hängt von der Implementierung des IP- Stacks ab – ausprobieren :)

45 Lehrstuhl für Kommunikationssysteme - Systeme II45 Internet Protocol – Subnetze Generell gilt Netzwerk können zur größeren zusammengefasst und große geteilt werden: Aufteilung bedeutet addieren einer 1 zur Netzmaske (verlängern des Prefix und Verkürzung des Suffix) Zusammenfassung von Netzwerken durch Entfernen einer 1 von der Netzmaske und Hinzufügen einer 0 stattdessen Deshalb gibts derzeit (noch) einige Blöcke von Klasse C Netzwerken zur Verteilung, was den Drang nach IP v6 erstmal etwas reduziert(e)

46 Lehrstuhl für Kommunikationssysteme - Systeme II46 Internet Protocol – Subnetze Nachteil: Zusätzliche Information ist benötigt und Router brauchen mehr Speicher, um sich die Netzmasken in Kombination mit den Netzwerknamen zu merken Vorteil: Routing-Tabellen können durch geeignete Aggregation von Routen vereinfacht werden Damit alle Informationen (Header) und Konzepte (Adressierung) vorhanden, um sich über die Routing- Funktionalität von IP zu unterhalten Einsatz von Tabellen mit Zielnetzen (Routing Tables)

47 Lehrstuhl für Kommunikationssysteme - Systeme II47 Internet Protocol – Routing IP-Routing-Tabelle Enthält für Ziel (Destination) die Adresse des nächsten Rechners (Router oft auch als Gateway bezeichnet) Destination kann einen Rechner oder ganze Sub-nets beschreiben Einträge sind nach Netzmaske sortiert (von oben nach unten mit sinkender Zahl an 1 für Prefix) Zusätzlich wird am unteren Ende der Tabelle ein Default- Gateway angegeben (Netzmaske 0.0.0.0)

48 Lehrstuhl für Kommunikationssysteme - Systeme II48 Internet Protocol – Routing Packet Forwarding Auch Packet Routing genannt (früher) IP-Paket (Datagramm) enthält Start-IP-Adresse und Ziel-IP- Adresse im Header: Ist Ziel-IP-Adresse = eigene Rechneradresse dann Nachricht ausgeliefert Ist Ziel-IP-Adresse in Routing-Tabelle dann leite Paket zum angegeben Gateway Ist Ziel-IP-Subnetz in Routing-Tabelle dann leite Paket zum angegeben Gateway Ansonsten leite zum Default-Gateway Darauf hin sich mal die Routing-Tabelle im eigenen Rechner ansehen

49 Lehrstuhl für Kommunikationssysteme - Systeme II49 Internet Protocol – Routing Im Router kommt die bereits angesprochene TTL zum Tragen: Behandlung eines Pakets Verringere TTL (Time to Live) um 1 Falls TTL 0 dann Packet-Forwarding aufgrund der Routing-Tabelle Falls TTL = 0 oder bei Problemen in Packet-Forwarding: Lösche Paket Falls Paket ist kein ICMP-Paket dann Sende spezielles IP/ICMP-Paket mit Start= aktuelle IP-Adresse und Ziel = alte Start-IP-Adresse

50 Lehrstuhl für Kommunikationssysteme - Systeme II50 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 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, Header und Routing in der angegebenen Literatur!