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

Lehrstuhl für Kommunikationssysteme - Systeme II2 Praktische Übungen Im Rechenzentrum, SR -100/-101 (Kellergeschoss) Linux in virtueller Maschine, praktische Übungszettel Besprechung der Übungszettel (noch nicht am Mittwoch) (nächsten Mittwoch – Ort ist das Rechenzentrum!) Besuch der praktischen Übungen ist nicht verpflichtend Übungszettel direkt in der Übung Vorlesung Systeme II – Organisatorisches

Lehrstuhl für Kommunikationssysteme - Systeme II3 Inhalt der Vorlesung Kurze Wiederholung IP Header Sub/Supernetting Fragmentierung Überblick Netzwerk-Taxonomie IP-Paketzustellung in lokalen Netzen Prinzip des IP-Routings IP-Adressen DHCP zur IP Adressverteilung

Lehrstuhl für Kommunikationssysteme - Systeme II4 Letzte Vorlesung IP Version 4 Header, Aufgabe der einzelnen Header-Felder Ziel- und Quelladressen Längenfelder für Header und Gesamtpaket, Checksumme für Header, TTL,... Nächstes Protokoll (Transportschicht, Layer 4 im OSI)

Lehrstuhl für Kommunikationssysteme - Systeme II5 Letzte Vorlesung IP Adressen, Adressklassen (ursprüngliche Schema, veraltet) Subnetting (Aufteilung von IP-Netzen in kleinere Subnetze)

Lehrstuhl für Kommunikationssysteme - Systeme II6 Letzte Vorlesung IP Netze, Netz-/Broadcast-Adressen, Netzmasken Sub / supernetting (Zusammenfassung von Netzen)

Lehrstuhl für Kommunikationssysteme - Systeme II7 Letzte Vorlesung Fragmentierung eines UDP-Pakets von 8212Byte Länge via Ethernet MTU (Payload ist 8212 – 8 (UDP) – 20 (IP) = 8184)

Lehrstuhl für Kommunikationssysteme - Systeme II8 Letzte Vorlesung Übergang zu MTU 1200 – Man beachte den Fragment-Offset

Lehrstuhl für Kommunikationssysteme - Systeme II9 Intro – Packet vs. Circuit Switching Theorie der Vermittlungsschicht – nach welchen Prinzipien werden Daten im Netz weitergeleitet? Zwei zentrale Prinzipien: Packet bzw. Circuit Switching Circuit Switching Dedizierter Kommunikationspfad zwischen zwei Partnern wird vor Datenaustausch geschaltet Typischerweise in der klassischen Telekommunikation wie beispielsweise in ISDN (Integrated Services Digital Network), ATM (Asynchronous Transfer Mode), GSM (General System for Mobile Communication),... Virtuelle Kanäle (Virtual Channel) definiert einen Pfad – eine Reihe von Verbindungen und Packet Switches

Lehrstuhl für Kommunikationssysteme - Systeme II10 Intro – Packet vs. Circuit Switching Circuit Switching Virtuelle Kanäle definieren Virtual Circuit Nummern für jede Verbindung zwischen allen Systemen entlang des Weges Diese Nummern müssen nicht den Pfadnummern entsprechen – das Setup kann flexibel sein aber es müssen dann Übersetzungstabellen in jedem Wegknoten verwaltet werden Das bedeutet: Das Netzwerk muss Status Informationen bis zum Ende der Verbindung aufbewahren Nachteil: Vor eigentlichem Datenaustausch Setup der Verbindung (Verzögerungen)

Lehrstuhl für Kommunikationssysteme - Systeme II11 Intro – Packet vs. Circuit Switching Circuit Switching Einfachere Routing-Mechanismen nachdem der Pfad geschaltet wurde Kann dazu genutzt werden sehr verschiedenartige Services zu bieten: Bandbreite, Delay, Kosten,... -optimierung - könnte Kriterium beim Setup sein Damit: Quality of Service einfach - außer bei: -Leitungsaufbau (hier fällt der Aufwand an) -Leitungsdauer (vorher nicht kalkulierbar, Parameter können sich im Laufe der Zeit ändern)

Lehrstuhl für Kommunikationssysteme - Systeme II12 Intro – Packet vs. Circuit Switching Circuit Switching Problem: Statische Zuordnung der Leitung für die gesamte Dauer einer Session Ineffiziente Ausnutzung des Kommunikationsmedium bei dynamischer Last (bestimmte Bandbreite reserviert aber nur sehr selten wirklich genutzt) Hoher Aufwand bei kurzen Sessions -Overhead des Verbindungsaufbaus im Verhältnis zur tatsächlich in der Session transportierten Datenmenge

Lehrstuhl für Kommunikationssysteme - Systeme II13 Intro – Packet vs. Circuit Switching Packet Switching Routing-Entscheidungen finden in jedem Netzwerkknoten erneut statt Routing-Entscheidungen werden für jedes einzelne Paket erneut getroffen, da keine Statusinformationen gespeichert werden Problem: Quality of Service -Qualität der Verbindung hängt von einzelnen Paketen ab (Pakete eines Datenstroms können unterschiedlich behandelt worden sein) -Entweder Zwischenspeichern oder Paketverlust -Vorteil: Effiziente Ausnutzung des Mediums bei dynamischer Last

Lehrstuhl für Kommunikationssysteme - Systeme II14 Intro – Packet vs. Circuit Switching Taxonomie – Einteilung von Kommunikationsnetzen

Lehrstuhl für Kommunikationssysteme - Systeme II15 IP auf der Vermittlungsschicht Was macht IP so aktiv und warum hat es sich weitgehend durchgesetzt? Grundprinzip von IP: Daten werden in Pakete aufgeteilt und mit Absender/Ziel-Information unabhängig versandt bei besserer Ressourcennutzung Ergebnis: Packet Switching hat Circuit Switching in praktisch allen Anwendungen abgelöst -Am offensichtlichsten: Übergang von traditioneller Telefonie auf VoIP

Lehrstuhl für Kommunikationssysteme - Systeme II16 IP auf der Vermittlungsschicht Warum lange Einführung in das IP Adressschema, Netzwerk- namen, Broadcast-Adressen und Netzmasken? IP als Packet Switching Netzwerk nimmt Routing- Entscheidungen für jedes Paket vor Wie werden nun IP Datagramme durch das (globale) Internet zum jeweiligen Endsystem transportiert? Man kann zwei Zustellungsmethoden in IP-Netzen unterscheiden: -Lokale Zustellung - ohne (weiteren) involvierten Router) – Gemeinsames Prefix von Netzadresse und Zieladresse -Nicht-lokale Zustellung (Router benötigt)

Lehrstuhl für Kommunikationssysteme - Systeme II17 IP auf der Vermittlungsschicht Routing-Entscheidungen werden anhand gemeinsamer Prefixes getroffen (Erinnerung: Aufbau einer IP-Adresse) Teilung muss nicht genau an der Byte-Grenze stattfinden (hier nur einfacher in der Dezimaldarstellung)

Lehrstuhl für Kommunikationssysteme - Systeme II18 IP auf der Vermittlungsschicht Beispiele für Routing-Tabellen (Linux / Windows)

Lehrstuhl für Kommunikationssysteme - Systeme II19 IP auf der Vermittlungsschicht Regelwerk für Zustellung benötigt: Jeder Router und jedes Endsystem verwaltet eine (eigene) Routing-Tabelle Lesen der Zieladresse von jedem zu routendem Paket (nicht der Quelladresse, solange nicht im Ziel) Ermitteln der Netzmaske des kleinsten angeschlossenen Netzwerks (man sieht warum man hier anfangen sollte) Berechnen: Netzmaske AND Zieladresse Vergleich des Ergebnisses mit der Netzwerkadresse bezogen auf die gesetzte Netzmaske Wenn es passt: Zustellung des Pakets auf diese Route Wenn es nicht passt: Rekursion – Starte den Algorithmus mit dem nächsten Eintrag in der Routing-Tabelle

Lehrstuhl für Kommunikationssysteme - Systeme II20 Internet Protocol – Routing Nachdem die Route bestimmt, die das Paket nehmen soll Wenn kein Gateway/Router angegeben wurde -> stelle das Paket direkt zu (wie im einzelnen kommt z.T. später in der Vorlesung) Wenn Gateway/weiterer Router angegeben sind -> stelle das Paket an diesen Router (verwende dazu die jeweilige Niedrigere-Schicht-Technik die für diesen Weg vorgesehen ist, spätere Vorlesung) Beispiel: Netzwerk Adresse: Klasse C Netzmaske ( ) Broadcast Hosts seien und , (Default, weil einziger) Router:

Lehrstuhl für Kommunikationssysteme - Systeme II21 Internet Protocol – Routing Ein kleines Beispiel-Ethernet (wie typischerweise in kleinen Büros, Zuhause zu finden) Einfach mal die Routing-Tabellen Zuhause ansehen Siehe auch praktische Übung am Mittwoch

Lehrstuhl für Kommunikationssysteme - Systeme II22 Internet Protocol – Routing Routing-Tabelle eines typischen Endsystems in einem klassichen Subnetz (LAN) hat typischerweise drei Einträge: Route ins lokale Netz (LAN) selbst (ohne weiteren Router) Die Loopback Route (großzügigerweise ein ganzes Klasse-A- Netzwerk) Die Default Route, die über einen Router in einem vorher definierten Subnetz erreichbar sein muss

Lehrstuhl für Kommunikationssysteme - Systeme II23 Internet Protocol – Routing Nun mal einen Blick werfen, wie ein Paket von zu Host zugestellt werden würde Starte mit Routing-Eintrag mit kleinster Netmask (hier: ) Logisches UND beider Binärzahlen (hier zur Verkürzung Dezimal dargestellt) & > (trifft zu!) Lokale Zustellung via Interface

Lehrstuhl für Kommunikationssysteme - Systeme II24 Internet Protocol – Routing Anderes Paket (von ) Starte mit Routing-Eintrag mit kleinster Netmask (hier wieder: ) & > (passt nicht!) Nimm nächsten Routing-Eintrag in der Tabelle: & > (miss!) Setze Rekursion fort und nehme wieder den nächsten Eintrag & > (match!) passt im logischen UND immer – daher der Name Default Route Ist keine Default-Route vorhanden, würde das Paket als nicht- zustellbar verworfen und die höhere Schicht (Applikation) informiert werden

Lehrstuhl für Kommunikationssysteme - Systeme II25 Internet Protocol – Routing Lokale Zustellung zum Router Da Default Route für jedes Paket passt, muss sie immer am Ende stehen Sonst würden andere Routing-Tabellen-Einträge nie erreicht Eine lokale Paketauslieferung findet immer statt Entweder direkt auf die Zielmaschine (erstes Beispiel) Oder direkt auf den nächsten Router Deshalb müssen Router/Gateway IP Teil des Subnetz sein

Lehrstuhl für Kommunikationssysteme - Systeme II26 Internet Protocol – Routing Zur Paketzustellung auf dem Weg wird lediglich die Zieladresse zur Weiterleitung in Betracht gezogen Sicherheitsproblem wegen möglichen IP-Spoofings Eintragen einer falschen Quelladresse in ein IP-Paket (für Angriffsszenarien über eine weitere Maschine) Meisten aktuellen Router überprüfen deshalb auch die Quelladresse (einfach mal probieren von zuhause ein Paket mit falscher Quelladresse loszuschicken, die nicht aus einem privaten Netz stammt) Nicht Teil der Spezifikation Nicht komplett im gesamten Internet umsetzbar (flexible, dynamische, redundante Routen, so dass Pakete an mehreren Interfaces auftauchen könnten)

Lehrstuhl für Kommunikationssysteme - Systeme II27 Internet Protocol – Paketanpassungen Eher selten, dass ein einziges Netzwerk zwischen zwei Endsystemen liegt Zudem ist IP auf verschiedenen Hardware-Netzen und Softwarenetzwerkprotokollen einsetzbar Bedeutet: Adress- und Paketgrößenanpassungen benötigt Die Internet Adresse (IP Adressen) müssen auf die Link- spezifischen Adressen des jeweiligen darunterliegenden Netzes angepasst werden (Ethernet, ISDN, GPRS,...) Häufig muss beim Übergang die Datagrammgröße angepasst werden (wobei wegen aktueller schneller Netze immer seltener) Anpassung erfolgt mittels Fragmentierung (letzte Vorlesung) Problem: Zusammenbau erfolgt erst im Ziel – u.U. Bandbreiten- verschwendung in Teilnetzen davor (durch kleine Pakete – relativ größerer Overhead durch Header)

Lehrstuhl für Kommunikationssysteme - Systeme II28 Internet Protocol – Adressen IP Adressen sind topologisch sensitiv Alle Interfaces zu einem Netzwerk haben dasselbe Prefix Sie sind 32bit global eindeutig (im öffentlichen Internet) Die Adresse liegen nur in Software vor (und sind nicht, wie beispielsweise MAC-Adressen an die darunterliegende Hardware gebunden) Da darunterliegende Netzwerkschichten oder Software-Layer eigene Adressschemata aufweisen muss es eine Übersetzung geben Das Prefix wird entweder vom ISP (unterschiedliche Level) oder vom jeweils lokalen Netzwerkadministrator zugeteilt

Lehrstuhl für Kommunikationssysteme - Systeme II29 Internet Protocol – Adresszuweisung Zuweisung von IP-Adressen zentrales Prinzip Jedoch Zahl der Endsysteme (erste Vorlesung) sehr hoch und schon in mittleren Organisationen wie Universität Freiburg schwierig, wenn rein manuell Anders gelagert, aber ähnliches Problem: Heimanwender soll sich bei mehreren Geräten nicht um IP-Konfiguration kümmern müssen Deshalb verschiedene Protokolle, die IP-Adressen automatisch an Endsysteme vergeben können (nach vorheriger Konfiguration durch Netzwerk-Administrator) Lösung: Spezialisierter Dienst für die Vergabe von IP- Adressen, Bekanntgabe der Netzwerkstruktur und Konfiguration weiterer Parameter: DHCP

Lehrstuhl für Kommunikationssysteme - Systeme II30 Dynamic Host Configuration Protocol Zudem weitere Überlegungen Zusätzlich: Inzwischen grosse Zahl mobiler Endgeräte, die sich zwischen verschiedenen Netzen (Uni, WG, Zuhause,...) bewegen können Manuelle Umkonfiguration aufwändig und fehlerträchtig Oft weit mehr Geräte als Anschlüsse (Typisches Szenario: Uni mit vielen tausend Studierenden und entsprechend vielen mobilen Geräten und begrenzter Zahl von Anschlüssen) Wenige dieser Geräte dauerhaft verbunden Aufwändiges Management statischer Adressen wäre notwendig Beispielsweise WLAN-Netz der Uni auf diesem Wege kaum betreibbar

Lehrstuhl für Kommunikationssysteme - Systeme II31 Dynamic Host Configuration Protocol Zudem weitere Überlegungen IP hat keinen Schutz vor Doppelvergabe Manuelles Management fehlerträchtig (ausprobieren in der praktischen Übung Doppelvergabe einer IP) Viele IP-Daten wiederholen sich im Teilnetz -Ziemlich langweilig/fehlerträchtig das manuell zu regeln Hoher Aufwand bei manueller Umstellung von Netzwerkparametern Bereitstellen wichtiger Zusatzinformationen -Rechnername und Domainname -Domain Name Server (DNS, spätere Vorlesung) -Druckserver, Windowsverzeichnisdienst (WINS)

Lehrstuhl für Kommunikationssysteme - Systeme II32 Dynamic Host Configuration Protocol DHCP – seit Anfang der 1990er Jahre spezifiziert Kein direkter Dienst/Teil des IP; Vorläufer: BOOTP Einige RFCs zum Thema, z.B Dynamic Host Configuration Protocol, Oktober Dynamic Host Configuration Protocol, März DHCP Options and BOOTP vendor extensions, März 1997 Nur noch wenige nutzen BOOTP (sehr einfache Boot- Implementierungen von Embedded Devices z.B. für Recovery) -Größter Nachteil: Es gibt kein Lease Management (zur Neu/ Vergabe von IP-Adressen nach einer bestimmten Frist)

Lehrstuhl für Kommunikationssysteme - Systeme II33 Dynamic Host Configuration Protocol DHCP für die meisten Betriebssysteme, Geräte implementiert Wichtige Eigenschaft: Dynamische Adressvergabe aus IP-Pools DHCP verwaltet dazu Liste verteilter IPs Vordefinierte IP-Adressen können an spezifische Endsysteme verteilt werden -Match anhand von MAC-Adressen (des anfragenden Endsystems) -Match anhand von Geräte-Identifiern (Geräte-ID angezeigt bspw. beim PXE-Boot, insbesondere bei Business Systemen) -Kombination von Kriterien, Matches programmierbar

Lehrstuhl für Kommunikationssysteme - Systeme II34 Dynamic Host Configuration Protocol Standard-Merkmale (typische Klassifizierung) UDP-basiert – verbindungsorientierte Kommunikation nicht sinnvoll möglich (mehr später zu TCP und UDP) Ermöglicht leichtgewichtige Implementierung, die auch in ein Boot- ROM passt (Bsp. PXE – meisten Intel-basierten Maschinen – einfach mal das eigene Laptop daraufhin untersuchen) Applikation (OSI-Layer 7) im klassischen Client-Server-Modell Voraussetzung: broadcast-fähiges Netz (sonst andere Protokolle, wie PPP) Client sendet Anfrage an Server auf Standardport 67 Server antwortet an Client auf Port 68

Lehrstuhl für Kommunikationssysteme - Systeme II35 Dynamic Host Configuration Protocol Eigenschaften Trotz Fire&Forget leicht unterscheidbare Anfragen durch unterschiedliche Ports für Server/Client und ID im Header Arbeitet mit speziellen Datenpaketen an alle (Broadcast) für MAC- Layer (unterhalb der IP-Ebene) -MAC benutzt 48bittige Adressen, bsp. 00:e0:23:e5:2a:2d -Höchste Adresse: ff:ff:ff:ff:ff:ff, Spezialadresse -> alle Netzwerkadapter nehmen solche Pakete entgegen DHCP-Anfrage: IP-Paket mit o.g. MAC und der allg. IP-Broadcast- Adresse (als jeweilige Zieladressen) Absendeadressen: Eigene MAC und Spezial-IP-Adresse

Lehrstuhl für Kommunikationssysteme - Systeme II36 Dynamic Host Configuration Protocol Aufbau eines DHCP Pakets (Darstellung als UDP Payload ohne Header)

Lehrstuhl für Kommunikationssysteme - Systeme II37 Dynamic Host Configuration Protocol Ablauf der Client-Server-Kommunikation Client: DHCPDISCOVER an , Port 67 zum Ermitteln verfügbarer DHCP-Server Server (evtl. mehrere): Vorschlag mit Parametern als DHCPOFFER an auf Port 68 Client wählt aus eventuell mehreren Offers aus und richtet DHCPREQUEST an den entsprechenden Server Server bestätigt mit DHCPACK gerichtet an den Client oder lehnt mit DHCPNACK den Client ab und wieder frei nach Ablauf der Kommunikation Unterscheidung verschiedener Clients anhand von MAC und Transaction-ID

Lehrstuhl für Kommunikationssysteme - Systeme II38 Dynamic Host Configuration Protocol

Lehrstuhl für Kommunikationssysteme - Systeme II39 Dynamic Host Configuration Protocol Wireshark DHCP- Paket-Mitschnitt DHCP-Request (siehe oben und Option 53) Anfrage eines Win-XP (erkennbar bspw. am Identifier MSFT 5.0) Option 55 enthält Wunschliste der zu schickenden Konfigurations- parameter Einfach mal zuhause testen

Lehrstuhl für Kommunikationssysteme - Systeme II40 Dynamic Host Configuration Protocol Weitere DHCP-Pakettypen Client-Paket: DHCPDECLINE, wenn der Client mit dem Angebot des Servers nicht klarkommt DHCPRELEASE kann vom Client geschickt werden, um eine Lease vorzeitig zurückzugeben (damit diese der Server schneller neu vergeben kann) DHCPRENEW Client-Paket, um eine Verlängerung der gehaltenen Lease anzufordern Wenn der Server zustimmt -> erfolgt erneutes DHCPACK, sonst DHCPNACK

Lehrstuhl für Kommunikationssysteme - Systeme II41 Dynamic Host Configuration Protocol DHCP in großen Setups DHCP operiert typischerweise im selben Subnetz mit den zu konfigurierenden Endsystemen Was sollte man jedoch in größeren Setups wie einer Universität, größeres Unternehmen machen, wo es aufwändig wäre den Dienst in jedem Subnetz einzeln zu betreiben Hierzu DHCP-Relay spezifiziert Proxy Funktionalität: Typischerweise in Netzwerkkomponenten zwischen den Subnetzen – Routern – implementiert Sammeln der DHCP Request Broadcast Messages im jeweiligen Subnetz

Lehrstuhl für Kommunikationssysteme - Systeme II42 Dynamic Host Configuration Protocol DHCP-Relay Umschreiben der DHCP-Anfrage (damit später die DHCP- Antworten zugestellt werden können) und weiterleiten an einen oder mehrere DHCP-Server als uni-cast Pakete Einsammeln der Antwort(en) und Rückübersetzung, um entsprechende DHCP offer/ack Messages zu generieren DHCP weitgehend durchgesetzter Standard Meisten Betriebssystemanbieter nutzen den ISC DHCPv3, 4 (oder davon abgeleitete Produkte) Standard bei den meisten Linux Distributionen Services heissen dann: dhcpd und dhclient

Lehrstuhl für Kommunikationssysteme - Systeme II43 Dynamic Host Configuration Protocol DHCP-Services Andere typische DHCP-Clients pump (e.g. knoppix), dhcpcd (e.g. SuSE) Clients der Windows Plattformen sind Bestandteil des ipconfig Kommandos (z.B. ipconfig -renew) oder winipcfg Kompakte Implementierungen für eingebettete Systeme udhcpd der Busybox oder Bestandteil des mdnsd o.ä. Nächste Vorlesung Weitere Methoden zur IP-Konfiguration (IP-Autoconfig) Prinzipielles Routing (Algorithmen, Methoden und Protokolle) Dynamisches IP-Routing

Lehrstuhl für Kommunikationssysteme - Systeme II44 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, den 4.5. an diesem Ort, gleiche Zeit: Weiter zu IP/Routing Erste praktische Übung (fakultativ): Mittwoch, den im Rechenzentrum (H.-Herder-Str. 10, Kellergeschoss -100/-101) Alle relevanten Informationen auf der Webseite zur Vorlesung: freiburg.de/php_veranstaltungsdetail.php?id=28 freiburg.de/php_veranstaltungsdetail.php?id=28 Mailingliste geht hoffentlich diese Woche an den Start und dann auch eine erste Info-Mail zum Test... Zu lesen: Kapitel zu Routing-Protokollen, IP-Routing, DHCP, Auto-IP, in der angegebenen Literatur!