Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 3te Vorlesung Lehrstuhl für...

Lehrstuhl für Kommunikationssysteme - Systeme II 1

Systeme II – 3te Vorlesung

Lehrstuhl für KommunikationssystemeInstitut für Informatik / Technische Fakultät

Universität Freiburg2009


Praktische Übungen Im Rechenzentrum, SR -100/-101 (Kellergeschoss)

Linux in virtueller Maschine, praktische Übungszettel

Besprechung der Übungszettel (noch nicht am Mittwoch) 29.04. (nächsten Mittwoch – Ort ist das Rechenzentrum!) 06.05. 11.05. 08.06. 15.06. 20.07.

Besuch der praktischen Übungen ist nicht verpflichtend

Übungszettel direkt in der Übung

Vorlesung Systeme II – Organisatorisches


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


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)


Letzte Vorlesung

‣ IP Adressen, Adressklassen (ursprüngliche Schema, veraltet)• Subnetting (Aufteilung von IP-Netzen in kleinere Subnetze)


Letzte Vorlesung

‣ IP Netze, Netz-/Broadcast-Adressen, Netzmasken• Sub / supernetting (Zusammenfassung von Netzen)


Letzte Vorlesung

‣ Fragmentierung eines UDP-Pakets von 8212Byte Länge via Ethernet MTU (Payload ist 8212 – 8 (UDP) – 20 (IP) = 8184)


Letzte Vorlesung

‣ Übergang zu MTU 1200 – Man beachte den Fragment-Offset


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



‣ 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)



‣ 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)



‣ 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



‣ 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



‣ Taxonomie – Einteilung von Kommunikationsnetzen


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



‣ 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)



‣ 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)



‣ Beispiele für Routing-Tabellen (Linux / Windows)



‣ 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


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: 10.8.4.0

“Klasse C” Netzmaske (255.255.255.0)

Broadcast 10.8.4.255

‣ Hosts seien 10.8.4.202 und 10.8.4.204, (Default, weil einziger) Router: 10.8.4.254



‣ 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



‣ 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



‣ Nun mal einen Blick werfen, wie ein Paket von 10.8.4.202 zu Host 10.8.4.204 zugestellt werden würde Starte mit Routing-Eintrag mit kleinster Netmask (hier:

255.255.255.0)

Logisches UND beider Binärzahlen (hier zur Verkürzung Dezimal dargestellt) 10.8.4.204 & 255.255.255 -> 10.8.4.0 (trifft zu!)

Lokale Zustellung via Interface



‣ Anderes Paket (von 10.8.4.202) 132.230.1.204 Starte mit Routing-Eintrag mit kleinster Netmask (hier wieder:

255.255.255.0)

132.230.1.204 & 255.255.255 -> 132.230.1.0 (passt nicht!)

Nimm nächsten Routing-Eintrag in der Tabelle: 132.230.1.204 & 255.0.0.0 -> 132.0.0.0 (miss!)

Setze Rekursion fort und nehme wieder den nächsten Eintrag

132.230.1.204 & 0.0.0.0 -> 0.0.0.0 (match!)

0.0.0.0 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



‣ 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



‣ 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)


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)


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


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


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



‣ 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)



‣ DHCP – seit Anfang der 1990er Jahre spezifiziert• Kein direkter Dienst/Teil des IP; Vorläufer: BOOTP

• Einige RFCs zum Thema, z.B.

- 1541 “Dynamic Host Configuration Protocol”, Oktober 1993

- 2131 “Dynamic Host Configuration Protocol”, März 1997

- 2132 “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)



‣ 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”



‣ 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



‣ 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 255.255.255.255 (als jeweilige Zieladressen)

• Absendeadressen: Eigene MAC und Spezial-IP-Adresse 0.0.0.0



‣ Aufbau eines DHCP Pakets (Darstellung als UDP Payload ohne Header)



‣ Ablauf der Client-Server-Kommunikation• Client: DHCPDISCOVER an 255.255.255.255, Port 67 zum

Ermitteln verfügbarer DHCP-Server

• Server (evtl. mehrere): Vorschlag mit Parametern als DHCPOFFER an 255.255.255.255 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

• 255.255.255.255 und 0.0.0.0 wieder frei nach Ablauf der Kommunikation

• Unterscheidung verschiedener Clients anhand von MAC und Transaction-ID



‣ 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



‣ 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



‣ 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



‣ 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



‣ 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


Ende der zweiten VorlesungEnde 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 29.4. im Rechenzentrum (H.-Herder-Str. 10, Kellergeschoss -100/-101)

Alle relevanten Informationen auf der Webseite zur Vorlesung: http://www.ks.uni-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!

http://www.ks.uni-freiburg.de/php_veranstaltungsdetail.php?id=28

http://www.ks.uni-freiburg.de/php_veranstaltungsdetail.php?id=28

Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 3te Vorlesung Lehrstuhl für...

Documents

Transcript of Lehrstuhl für Kommunikationssysteme - Systeme II1 Systeme II – 3te Vorlesung Lehrstuhl für...