nwa_gesamt_videolinks_2024.pdf

Netzwerksicherheit und -anwendungen Vorlesungsskript zum Modul Netze im Bachelor-Studiengang (B.Sc.) Media Systems Prof. Dr. Nils Martini Hochschule für Angewandte Wissenschaften Hamburg...

Netzwerksicherheit und -anwendungen Vorlesungsskript zum Modul Netze im Bachelor-Studiengang (B.Sc.) Media Systems Prof. Dr. Nils Martini Hochschule für Angewandte Wissenschaften Hamburg Fakultät Design, Medien, Information Department Medientechnik Stand: 08.11.2023 2  3 Inhaltsverzeichnis 1 Sicherungsschicht..................................................................................................................................8 1.1 Einleitung......................................................................................................................................................8 1.2 Logical Link Control LLC................................................................................................................................9 1.2.1 Rahmenerstellung.................................................................................................................................9 1.2.2 Fehlererkennung, Fehlerkorrektur........................................................................................................10 1.2.3 Flusskontrolle, Sliding Window............................................................................................................11 1.3 Media Access Control MAC.........................................................................................................................14 1.3.1 IEEE-Normen.......................................................................................................................................14 1.3.2 CSMA/CD............................................................................................................................................15 1.3.3 MAC-Adressen....................................................................................................................................15 1.3.4 Ethernet-Protokoll...............................................................................................................................16 1.4 Switching....................................................................................................................................................17 1.4.1 Funktionen..........................................................................................................................................17 1.4.2 Address Learning.................................................................................................................................17 1.4.3 Spanning Tree Protokoll.......................................................................................................................19 1.5 Virtual LAN..................................................................................................................................................20 1.6 Link Aggregation LACP................................................................................................................................22 1.7 Address Resolution Protokoll ARP................................................................................................................23 1.8 Address Resolution bei IPv6.........................................................................................................................24 1.9 MTU Path Discovery....................................................................................................................................24 2 Vermittlungsschicht.............................................................................................................................25 2.1 Einleitung....................................................................................................................................................25 2.2 IPv4-Protokoll.............................................................................................................................................25 2.3 IPv6-Protokoll.............................................................................................................................................25 2.4 ICMP...........................................................................................................................................................26 2.5 Routing Information Protocol......................................................................................................................26 3 Transportschicht TCP...........................................................................................................................27 3.1 Einleitung....................................................................................................................................................27 3.2 TCP-Header.................................................................................................................................................28 3.3 Verbindungsmanagement...........................................................................................................................28 3.3.1 Verbindungsaufbau.............................................................................................................................28 3.3.2 Verbindungsabbau..............................................................................................................................29 3.3.3 Datenübertragungsphase...................................................................................................................30 3.3.4 Flussteuerung: Sliding Window...........................................................................................................31 3.3.5 ACK-Delay, Silly-Window und Nagle-Algorithmus................................................................................32 4 TCP-Funktionen...................................................................................................................................34 4.1 MTU und MSS.............................................................................................................................................34 4.2 MTU Path Discovery....................................................................................................................................34 4.3 Window Size Scaling...................................................................................................................................35 4.4 RTT, RTO und Timestamps...........................................................................................................................35 4.5 Retransmission............................................................................................................................................38 4.5.1 go-back-n (GBN).................................................................................................................................38 4.5.2 Selective Retransmission.....................................................................................................................39 4.5.3 Fast Retransmit...................................................................................................................................40 4.5.4 Selective Acknowledgement (SACK)....................................................................................................40 4.6 TCP Segmentation Offload..........................................................................................................................41 4.7 Stauvermeidungs-Strategien.......................................................................................................................42 4.7.1 Überlastsituation.................................................................................................................................42 4.7.2 Slow Start...........................................................................................................................................43 4.7.3 TCP-Tahoe...........................................................................................................................................43 4.7.4 TCP-Reno............................................................................................................................................44 4.7.5 Explicit Congestion Notification...........................................................................................................45 5 Anwendungsschicht.............................................................................................................................46 5.1 Einleitung....................................................................................................................................................46 5.2 Simple Mail Transfer Protocol SMTP............................................................................................................46 4 5.2.1 Message Transfer Agent und User Agent.............................................................................................46 5.2.2 SMTP-Kommunikation........................................................................................................................47 5.2.3 Nachrichtenformat RFC 822................................................................................................................47 5.2.4 MIME-Format und Base64-Kodierung.................................................................................................47 5.3 HyperText Transport Protocol HTTP..............................................................................................................48 5.3.1 HTTP-Kommandos..............................................................................................................................48 5.3.2 HTTP-1.0.............................................................................................................................................49 5.3.3 HTTP-1.1..............................................................................................................................................49 5.3.4 HTTP-2...............................................................................................................................................49 5.3.5 HTTP-3 und QUIC...............................................................................................................................50 5.4 File Transfer Protocol FTP.............................................................................................................................51 5.5 Remote Login..............................................................................................................................................51 5.5.1 Telnet..................................................................................................................................................51 5.5.2 Remote Shell rsh.................................................................................................................................52 5.5.3 SecureShell SSH..................................................................................................................................52 5.6 Domain Name Service.................................................................................................................................52 5.6.1 Namensauflösung...............................................................................................................................52 5.6.2 DNS-Server.........................................................................................................................................54 5.6.3 DNS-Protokoll.....................................................................................................................................54 5.6.4 Weitere Namensdienste......................................................................................................................55 6 Netzwerksicherheit..............................................................................................................................57 6.1 Einleitung....................................................................................................................................................57 6.2 Scanner.......................................................................................................................................................57 6.2.1 TCP-Connect-Scan...............................................................................................................................57 6.2.2 SYN-Stealth-Scan................................................................................................................................57 6.2.3 Xmas- und Null-Scan..........................................................................................................................58 6.2.4 SYN-FIN-Scan.....................................................................................................................................58 6.2.5 ACK-Scan............................................................................................................................................58 6.2.6 Idle-Scan............................................................................................................................................58 6.3 Denial of Service DoS..................................................................................................................................60 6.3.1 SYN-Flooding......................................................................................................................................60 6.3.2 TCP-Reset............................................................................................................................................61 6.3.3 TCP Session Hijacking.........................................................................................................................62 6.4 Spoofing.....................................................................................................................................................62 6.4.1 IP-Spoofing.........................................................................................................................................62 6.4.2 ARP-Spoofing.....................................................................................................................................63 6.4.3 Port-Stealing.......................................................................................................................................64 6.4.4 RIP-Spoofing.......................................................................................................................................64 6.4.5 DNS-Spoofing.....................................................................................................................................65 6.5 Web-Services..............................................................................................................................................66 6.5.1 HTTP Session Hijacking........................................................................................................................66 6.5.2 Unerwartete Eingaben........................................................................................................................67 6.5.3 SQL-Injection......................................................................................................................................68 7 Firewall und Intrusion Prevention........................................................................................................69 7.1 Funktionsweise von iptables........................................................................................................................69 7.1.1 Chains und Targets...............................................................................................................................69 7.1.2 Grundsätzliches...................................................................................................................................70 7.2 Filterregeln..................................................................................................................................................71 7.2.1 Paket-Filter..........................................................................................................................................71 7.2.2 OUTPUT-Filterkette..............................................................................................................................72 7.2.3 Stateful-Inspection-Firewall.................................................................................................................72 7.2.4 Schwellwert-Filter...............................................................................................................................72 7.3 Bastion........................................................................................................................................................73 7.4 Network Address Translation NAT................................................................................................................74 7.5 Intrusion Prevention Systeme.......................................................................................................................75 8 Virtualisierung.....................................................................................................................................76 8.1 Grundlagen.................................................................................................................................................76 8.2 Funktionen in VirtualBox.............................................................................................................................78 8.2.1 Installation..........................................................................................................................................78 8.2.2 System-Einstellungen..........................................................................................................................78 8.2.3 Festplatten / Massenspeicher..............................................................................................................79  5 8.2.4 Virtuelle Netzwerk-Hardware..............................................................................................................79 8.2.5 Netzwerk mit NAT..............................................................................................................................79 8.2.6 NAT-Netzwerk....................................................................................................................................80 8.2.7 Port-Forwarding im NAT-Netzwerk.....................................................................................................80 8.2.8 Netzwerkbrücke (Bridge)....................................................................................................................80 8.2.9 Internes Netzwerk..............................................................................................................................80 8.2.10 Host-only Netzwerk..........................................................................................................................80 8.3 Docker-Container........................................................................................................................................81 8.3.1 Grundlagen.........................................................................................................................................81 8.3.2 Docker-Hub........................................................................................................................................82 8.3.3 Image.................................................................................................................................................82 8.3.4 Container...........................................................................................................................................82 8.3.5 Volumes.............................................................................................................................................83 8.3.6 Dockerfile...........................................................................................................................................83 6 Einleitung Bei diesem Skript handelt es sich um ergänzendes Lernmaterial zum Modul „Netze“ im zweiten Studienjahr des Studiengangs Media Systems. Vorausgesetzt werden die Kenntnisse der Module Informatik A und B aus dem ersten Studienjahr. Dieses Skript stellt kein umfassendes Lehrbuch zum Thema Internet und Netzwerksicherheit dar. Es dient im Wesentlichen zur grundlegenden Vorbereitung diejenigen Themen, die in den Laborübungen praktisch umgesetzt werden. Es zeigt die theoretischen Hintergründe auf, die zum Verständnis der Laborübungen erforderlich sind. Der Detailgrad bei der Darstellung der Themenbereiche orientiert sich an den für die einzelnen Laborübungen erforderlichen Grundlagenkenntnissen und fällt daher sehr unterschiedlich aus. Hinweis: Bei dem hier vorliegenden Vorlesungsskript handelt es sich um eine Auflistung der wesentlichen in der Vorlesung behandelten Stichpunkte und nicht um eine vollständige Wiedergabe aller behandelten Themen; es dient lediglich zur Unterstützung der Studierenden bei der Erarbeitung und Verfolgung des Vorlesungsstoffes. Das Skript eignet sich nicht als alleinige Grundlage zur Vorbereitung auf Prüfungen. 7 8 1 Sicherungsschicht 1.1 Einleitung Die Bitübertragungsschicht (Schicht 1) im OSI-Modell beschreibt die Funktionen der Hardware (Netzwerkkarte, engl. Network Interface Card NIC). Beim Sender werden die vorliegenden binären Nullen und Einsen in physikalische Signale gewandelt (Lichtimpulse, elektromagnetische Wellen, elektrische Spannung) und über das Medium (Kupferkabel, Lichtwellenleiter usw.) an den Empfänger übertragen. Diverse Störungen können das Signal bei der Übertragung verändern, sodass beim Empfänger nach der Rückwandlung der Signale entsprechende Maßnahmen zur Fehlerkontrolle getroffen werden müssen. Außerdem müssen die Dateneinheiten (Datenrahmen, engl. Frames) genau so wiederhergestellt werden, wie sie zuvor beim Sender vorhandenen waren. Eine weitere wichtige Aufgabe ist die Steuerung des Datenflusses: Ein Sender könnte Daten schneller abschicken als sie der Empfänger aufnehmen kann, es würde zu Datenverlusten kommen. Je nach verwendeter Technik kann eine weitere Aufgabe der Sicherungsschicht die Zugangskontrolle zum Netzwerk sein. Bei Punkt-zu-Punkt-Netzen ist dies nicht erforderlich, aber bei Mehrfachzugriffsnetzen, bei denen mehrere Endgeräte mit dem Übertragungskanal verbunden sind, ist eine Regelung des Kommunikationsablaufes erforderlich. Ohne eine solche Funktion würden sich die Signale mehrerer gleichzeitig sendender Geräte überlagern, sodass die Information des einzelnen Signals nicht mehr aufzulösen wäre. Außerdem ist eine eindeutige Adressierung der Endgeräte in solchen Netzwerken erforderlich, um die Datenrahmen einem Zielgerät eindeutig zuordnen zu können. Diese Aufgaben übernimmt im OSI-Modell die Schicht 2, die Sicherungsschicht (engl. Data Link Layer). Bei Punkt- zu-Punkt-Netzen werden alle Aufgaben in einer Schicht ausgeführt, bei Mehrfachzugriffsnetzen werden die Aufgaben unterteilt: Die Teilschicht Logical Link Control LLC führt die grundlegenden Funktionen aus (Rahmenerstellung, Fehlerkontrolle, Flusssteuerung), die Teilschicht Media Access Control MAC übernimmt die Aufgabe der Adressierung und der Kanalzuordnung (Zugriffskontrolle). Die konkrete technische Umsetzung dieser Aufgaben hängt von der verwendeten Hardware ab; daher kann die Sicherungsschicht in jedem Teilabschnitt einer Datenübertragung im Internet verschieden sein. In Abbildung 1 könnte beispielsweise die Verbindung von Rechner A zum Router 1 ein lokales Netzwerk z.B. Ethernet sein, die Verbindung von Router 1 zu Router 2 eine DSL- Verbindung über eine Telefonleitung, Router 2 und Router N sind mittels einer ATM-Glasfaserleitung verbunden und Router N und Rechner B kommunizieren über ein Wireless Local Area Network (WLAN). Das „gemeinsame Dach“ über diesen Hardware-Mix stellt das Internet Protokoll IP dar, das mithilfe von Routing- Protokollen und einer eindeutigen Adressierung eine Übermittlung von Daten-Paketen (Datagrammen) zwischen den beiden Endgeräten Rechner A und B ermöglicht. A B Anwendung Anwendung TCP TCP IP IP IP IP IP LLC LLC 2 2 2 2 2 2 MAC MAC Hardware 1 1 1 1 1 1 Hardware Router 1 Router 2 Router N Abbildung 1: Internet-Modell  9 1.2 Logical Link Control LLC 1.2.1 Rahmenerstellung Der Sender der Datenrahmen übergibt der Bitübertragungsschicht einen Strom von Nullen und Einsen, der sich aus den hintereinander gesendeten Rahmen ergibt. Für den Empfänger dieses Bitstroms ist es jedoch ohne zusätzliche Informationen nicht möglich, aus dieser rohen Folge von Nullen und Einsen wieder die ursprünglichen Datenrahmen zu erzeugen. Eine einfache Möglichkeit der Rahmentrennung sind Zeitlücken: Der Sender wartet eine bestimmte Zeit ab, bevor er den nächsten Rahmen abschickt und der Empfänger kann dadurch das Ende des einen bzw. den Beginn des nächsten Rahmens erkennen. Die Zeitabstände müssen jedoch ausreichend lang sein, damit eine eindeutige Erkennung eines Rahmenendes möglich ist, denn Dispersionseffekte führen zu einer zeitlichen Ausdehnung von Signalen, sodass die gesamte Rahmenlänge beim Sender kürzer ist als beim Empfänger und damit die Zeitlücke zwischen zwei Rahmen mit zunehmender Übertragungsdauer immer kleiner wird. Ein weiteres Problem sind verlorene Bits, die eine Zeitlücke vortäuschen können, die eigentlich gar nicht vorhanden ist. Außerdem wird die insgesamt zur Verfügung stehende Übertragungsrate nicht optimal ausgenutzt. Ein weiteres Verfahren zur Rahmentrennung ist das so genannte Zeichenzählen. Hierbei wird in den Header des gesendeten Rahmens die Anzahl der Bits dieses Rahmens gesetzt, sodass der Empfänger am Beginn des Rahmens weiß, wie groß der Rahmen ist. Zu einem Problem bei diesem Verfahren können verfälschte oder verlorene Bits werden, die zu einem fehlerhaften Abzählen der Bits führen. Außerdem kommt es dann unvermeidlich zu einem Synchronisationsverlust zwischen Sender und Empfänger, da der Empfänger die Rahmentrennung an einer anderen Stelle setzt als sie ursprünglich beim Sender war. Eine andere Methode zur Rahmentrennung stellt das Einfügen von speziellen Trennzeichen am Ende und am Beginn eines Rahmens dar. Die Methode Zeichenstopfen (Abbildung 2)verwendet die ASCII-Zeichen DLE (Data Link Escape) sowie STX (Start of Text) und ETX (End of Text). Ein Rahmen beginnt immer mit dem Zeichen STX und endet immer mit ETX. Beide Zeichen werden jeweils mit einem davorstehenden Zeichen DLE geschützt: Dadurch wird eine in den Nutzdaten enthaltene Bitfolge, die dem STX- bzw. dem ETX-Zeichen gleicht, vom Sender ignoriert und kann somit nicht fälschlicherweise als Start oder Ende des Rahmens interpretiert. Kommt jedoch das DLE- Zeichen in den Nutzdaten vor, so wird eine Fehlinterpretation durch den Empfänger dadurch verhindert, dass der Sender beim Auftreten eines DLE dieses Zeichen zusätzlich einfügt, es also verdoppelt. Der Empfänger erkennt anhand dieses doppelten DLE, dass es sich um Nutzdaten handelt, und entfernt das doppelte DLE. Sender Empfänger DLE STX Nutzdaten DLE ETX DLE STX Nutzdaten DLE ETX DLE STX Nutzdaten STX DLE ETX DLE STX Nutzdaten STX DLE ETX DLE STX Nutzdaten DLE DLE DLE ETX DLE STX Nutzdaten DLE DLE DLE ETX verdoppeln Abbildung 2: Zeichenstopfen Der Nachteil des Zeichenstopfens ist die enge Bindung an den ASCII-Zeichensatz und die Notwendigkeit, immer ganze Bytes zu bearbeiten bzw. einzufügen. Daher verwendet die Methode Bitstopfen (Abbildung 3) eine bestimmte Bitfolge (01111110) als Start- und Ende-Zeichen (Trennzeichen) und fügt zur Erkennung dieser Zeichenfolge innerhalb der Nutzdaten statt ganzer Bytes nur jeweils ein Bit in die Nutzdaten ein. Damit das Trennzeichen niemals innerhalb der Nutzdaten auftreten kann, wird beim Sender nach fünf aufeinanderfolgenden Eins-Bits in den Nutzdaten grundsätzlich immer ein Null-Bit eingefügt. Entsprechend wird beim Empfänger nach fünf Eins-Bits das nachfolgende Null-Bit grundsätzlich immer entfernt. Folgt nach fünf Eins-Bits ein weiteres Eins- Bit, so handelt es sich eindeutig um das Trennzeichen. Diese Art der Rahmentrennung wird bei Punkt-zu-Punkt- Netzen verwendet (z.B. HDLC-Protokoll oder PPPoE), bei Mehrfachzugriffsnetzen wie dem Ethernet wird aufgrund der zusätzlichen MAC-Teilschicht (siehe Kapitel 1.3) anders verfahren. 10 Sender Empfänger 01111110 Nutzdaten 111110 01111110 01111110 Nutzdaten 111110 01111110 0 einfügen 0 entfernen Abbildung 3: Bitstopfen 1.2.2 Fehlererkennung, Fehlerkorrektur Bei jeder Signalübertragung kann es unabhängig vom verwendeten physikalischen Medium zu Übertragungsfehlern kommen, indem physikalische Signale durch äußere Einflüsse verfälscht, ausgelöscht oder auch hinzugefügt werden. Bei glasfaserbasierten Techniken sind Fehler sehr selten, wogegen bei elektrischen oder insbesondere elektromagnetischen Übertragungstechniken die Fehlerrate sehr hoch sein kann. Betrachtet man Abbildung 1 so wird deutlich, dass solche Fehler möglichst bereits von der Sicherungsschicht erkannt und behoben werden sollten, da sonst erst der Zielrechner mithilfe der Fehlererkennung des TCP-Protokolls einen Fehler erkennt (das IP-Protokoll der Vermittlungsschicht verfügt über keine Fehlererkennungsmechanismen). Ein fehlerhaftes Datenpaket würde somit unnötigerweise das gesamte Netzwerk durchlaufen, bevor der Fehler korrigiert werden kann. Wenn zudem ein TCP-Paket aus mehreren Datenrahmen zusammengesetzt wird (TCP Segmentation Offload, siehe Kapitel 4.6), würde ein Fehler innerhalb eines einzigen Rahmens zur erneuten Übertragung mehrerer Rahmen führen. Es ist zwischen verschiedenen Fehlertypen zu unterscheiden: Bündelfehler (engl. burst error) oder Synchro- nisierungsfehler betreffen größere Datenmengen bzw. eine längere Zeitspanne der Übertragung, wogegen Einzelfehler nur ein Bit innerhalb eines Rahmens betreffen. Die Auswirkungen auf eine bestimmte Netzwerk- Anwendung können sehr unterschiedlich sein: Bündelfehler können entweder zu einer kurzzeitigen Unterbrechung des Datenflusses führen, was insbesondere bei nicht-interaktiven Store-and-Forward-Anwendungen (z.B. EMail) kaum zu bemerken sein wird, oder auch zum Abbruch einer Verbindung auf höherer Protokollebene aufgrund von Timeouts. Einzelfehler können auch bei interaktiven Verbindungen entweder kaum feststellbar sein, da nur einige wenige Rahmen auf einzelnen Abschnitten der Verbindung erneut übertragen werden müssen, was lediglich zu einer geringfügigen Verringerung der Übertragungsrate innerhalb der üblichen Schwankungsbreite führt und somit kaum feststellbar ist. Dagegen können regelmäßig auftretende Einzelfehler eine Datenübertragung sogar zum Erliegen bringen, wenn – insbesondere bei großen Rahmen – fast jeder Datenrahmen von einem Fehler betroffen ist. Es ist grundsätzlich zwischen Fehlererkennungscodes und Fehlerkorrekturcodes zu unterscheiden. Letztere sind in der Lage ausschließlich anhand der zusätzlich im Rahmen übertragenen redundanten Informationen einen Fehler direkt zu identifizieren und zu korrigieren. Allerdings ist die Menge der redundanten Informationen i.d.R. so groß, dass der Aufwand bei den üblichen Netzwerktechniken viel zu hoch wäre; solche Verfahren werden daher nicht eingesetzt. Fehlererkennungscodes übertragen wesentlich weniger redundante Informationen, mit denen lediglich das bloße Vorhandensein eines Fehler festgestellt werden kann. Als Konsequenz kann der Empfänger, der den Fehler erkannt hat, lediglich mittels eines geeigneten Rückmeldeverfahrens den Sender auffordern, den betreffenden Rahmen erneut zu senden (siehe Kapitel 1.2.3). Auf die Funktionsweise von Fehlererkennungscodes wird an dieser Stelle nicht weiter eingegangen. Es sei lediglich darauf hingewiesen, dass das Ethernet-Protokoll das Fehlererkennungs-Verfahren „Cyclic Redundancy Check“ CRC verwendet, bei dem der Sender eine Prüfsumme über die Nutzdaten bildet und das Ergebnis in den Ethernet- Header schreibt. Der Empfänger bildet ebenfalls die Prüfsumme und vergleicht sein Ergebnis mit dem im Ethernet- Header übermittelten Wert: Ist das Ergebnis gleich, so ist der Rahmen fehlerfrei, andernfalls wird vom Sender die erneute Übertragung des betroffenen Rahmens angefordert bzw. (wie beim Ethernet-Protokoll) der Rahmen verworfen.  11 1.2.3 Flusskontrolle, Sliding Window Eine weitere wichtige Funktion der Sicherungsschicht ist die Gewährleistung eines kontrollierten Datenflusses: Ein schneller Sender darf einen langsameren Empfänger nicht mit Daten überlasten, da es sonst zu Rahmenverlusten kommen würde. Die einfachste Möglichkeit ist in Abbildung 4 dargestellt (Stop-and-Wait-Protokoll). Der Sender schickt den Rahmen A ab und wartet bis eine positive Bestätigung ACK (engl. Acknowledgement) eingetroffen ist. Rahmen A bleibt bis dahin im Sendepuffer gespeichert. Dann kann Rahmen A aus dem Sendepuffer entfernt werden und der nächste Rahmen B kann geladen und abgeschickt werden. Auf der Seite des Empfängers wird Rahmen A im Empfangspuffer gespeichert, auf Fehler überprüft und – sofern alle Daten korrekt sind – an die höhere Schicht (i.d.R. das IP-Protokoll, Schicht 3) weitergereicht. Erst dann wird eine positive Bestätigung an den Sender abgeschickt und der Rahmen aus dem Empfangspuffer gelöscht. Der Empfangspuffer steht nun für den nächsten Rahmen zur Verfügung. Im Falle eines Übertragungsfehlers (in der Abbildung ist die Übertragung von Rahmen B betroffen) erkennt der Empfänger anhand der Prüfsumme, dass ein Fehler vorliegt. Es wird daraufhin entweder eine negative Bestätigung (NAK) zurückgeschickt (oder alternativ gar keine Bestätigung). Der Sender erkennt anhand des NAK, dass der noch im Sendepuffer befindliche Rahmen B erneut verschickt werden muss. Da nicht nur ein Datenrahmen von Fehlern oder einem Totalverlust betroffen sein kann, sondern auch ein Bestätigungspaket, ist der Start eines Timers beim Abschicken eines Rahmens zwingend erforderlich. Falls kein ACK eintreffen sollte, muss der Sender in der Lage sein, selbstständig die erneute Übertragung eines Rahmens zu starten. Der Timer muss hierbei so eingestellt sein, dass die maximal mögliche Laufzeit von Datenrahmen und Bestätigungsrahmen berücksichtigt wird. Diese so genannte Round-Trip-Time RTT ist auf Schicht 2 leicht zu bestimmen, denn sie hängt von den fest vorgegebenen Parametern der verwendeten Netzwerktechnik ab (die maximale Segment- bzw. Kabellänge ermöglicht die Berechnung der physikalischen Signallaufzeit zwischen den entferntesten Enden eines Netzwerks und für die Leistungsfähigkeit der Hardware der NICs können bestimmte Standard-Vorgaben definiert sein). Aus diesem Grund kann auf negative Bestätigungen verzichtet werden, da das Abschicken eines Duplikats ohnehin nach dem Ablauf des Timers ausgelöst wird. Vorteil einer negativen Bestätigung ist lediglich eine etwas schnellere Reaktionszeit, da nicht erst auf den Timer-Ablauf gewartet werden muss. Ein entscheidender Nachteil dieses einfachen Stop-and-Wait-Protokoll ist die geringe Nutzung der zur Verfügung stehenden Bandbreite. Der Sender muss nach dem Abschicken von Rahmen A warten bis die Bestätigung eintrifft, bevor der nächste Rahmen verschickt werden kann. Diese Wartezeit ist abhängig von der RTT und der Verarbeitungszeit beim Empfänger. Es wäre daher sinnvoll, wenn der Sender trotz eines noch ausstehenden ACK bereits weitere Rahmen abschicken könnte, was jedoch weitere Funktionen im Protokoll sowie der Hardware nötig macht. Stop-and-Wait Sender Empfänger Rahmen A Rahmen A ACK leer Rahmen A Rahmen B Fehler RahmXXX NAK leer Rahmen B Duplikat Rahmen A B ACK leer Rahmen B Zeit Abbildung 4: Stop-and-Wait-Protokoll 12 Die Erweiterung des Stop-and-Wait-Protokolls zu einem so genannten Schiebefenster-Protokoll (Sliding- Window) erfordert die Einführung von Folgenummern (Sequenznummern SEQ), da der Empfänger sonst keine Möglichkeit hätte, die richtige Reihenfolge der eingetroffenen Rahmen festzustellen. Außerdem muss sichergestellt sein, dass alle eintreffenden Rahmen unabhängig von der Verarbeitungsgeschwindigkeit und auch im Falle von Datenverlusten (sowohl Fehler als auch Totalverluste) in der richtigen Reihenfolge gespeichert und an die höhere Schicht weitergegeben werden können. Abbildung 5 zeigt die Situation nur auf der Seite des Senders, beim Empfänger müssen die entsprechenden Speicherplätze und ihre Nummerierung vorhanden sein. SEQ 0 ACK A A B 1 1 ACK B B C 2 C 2 2 C D D 3 3 D 3 E 0 E 0 F 1 Abbildung 5: Sliding Window (nur Sendeseite) Der Sender lädt die vier Rahmen A bis D in seinen Sendepuffer, schreibt in den Header der Rahmen die entsprechende Sequenznummer 0 bis 3 hinein und schickt sie ab, ohne auf eine Bestätigung zu warten. Der Sender hört erst dann auf zu senden, wenn der Sendepuffer voll belegt ist. Idealerweise ist die Größe des Sendepuffers auf die Round Trip Time des Netzwerks abgestimmt: Wenn die Bestätigung für Rahmen A (SEQ 0) spätestens dann eintrifft wenn Rahmen D abgeschickt wird, so kann der Speicherplatz von A geleert werden und steht für den nächstfolgenden Rahmen E zur Verfügung, der ohne Verzögerung gesendet werden kann. Da der Bereich der Sequenznummern nicht beliebig groß sein kann (es muss ein Headerfeld dafür vorgesehen sein, das nur eine bestimmte definierte Größe haben kann), erhält Rahmen E die Sequenznummer SEQ 0. Das Sendefenster (roter Kasten in der Abbildung) wird also „weitergeschoben“ und umfasst nun die Rahmen B bis E mit den Sequenznummern 1, 2, 3 und 0. Trifft die Bestätigung für Rahmen B ein, so wird B aus dem Puffer gelöscht, das Sendefenster weitergeschoben und Rahmen F (mit SEQ 1) geladen und abgeschickt. Dadurch kommt es zu keiner Unterbrechung des Datenstroms beim Sender und die zur Verfügung stehende Bandbreite des Netzwerks kann vollständig genutzt werden. Die richtige Reihenfolge der Rahmen beim Empfänger ist mittels der Sequenznummer gewährleistet, auch im Falle eines Fehlers oder Totalverlustes. Diese Situation ist in Abbildung 6 dargestellt (nur Sender). SEQ 0 ACK A A B 1 1 NAK 1 ACK B B B C Fehler 2 2 Duplikat 2 C C 2 C D D 3 D 3 3 D 3 E E 0 0 E 0 F 1 Abbildung 6: Sliding Window mit Übertragungsfehler  13 Rahmen A wird korrekt übertragen und bestätigt, sodass das Sendefenster weitergeschoben und Rahmen E geladen und abgeschickt werden kann. Bei der Übertragung von Rahmen B tritt jedoch ein Fehler auf und eine negative Bestätigung trifft ein (oder keine Bestätigung). Rahmen B muss daher erneut verschickt werden und darf erst dann aus dem Sendepuffer entfernt werden, wenn eine positive Bestätigung eingetroffen ist; das Sendefenster darf auch erst dann weitergeschoben werden. Im Idealfall gibt es auch hierbei keine Sendeunterbrechung und die Bandbreite des Netzwerks wird vollständig genutzt, wenn auch in diesem Fehlerfall für ein Duplikat. Schwieriger wird die Situation im Sliding-Window-Protokoll, wenn nicht ein Datenrahmen verloren geht sondern eine Bestätigung. Abbildung 7 zeigt Sender- und Empfängerseite im Falle einer korrekten Übertragung der Rahmen A bis D. Der Empfänger stellt die Korrektheit aller Rahmen fest, reicht sie an die höhere Schicht weiter, schickt die ACKs 0 bis 3 und löscht die Rahmen aus dem Empfangspuffer. Der Empfangspuffer ist nun bereit für die Rahmen E bis H mit den Sequenznummern 0 bis 3. Die Bestätigung ACK 0 trifft beim Sender ein, Rahmen A wird aus dem Sendepuffer gelöscht, das Sendefenster weitergeschoben, Rahmen E geladen und abgeschickt. Die Bestätigung ACK 1 für Rahmen B geht verloren, sodass nach Ablauf des entsprechenden Timers der Sender Rahmen B mit SEQ 1 erneut abschickt. Das nun entstehende Problem zeigt die rechte Seite von Abbildung 7: Da der Empfänger aufgrund der korrekt empfangenen Rahmen das Empfangsfenster bereits weitergeschoben hat und nun die Rahmen E bis H erwartet (mit den SEQ 0 bis 3), wird das eintreffende Duplikat von Rahmen B zwar richtig in den Speicherplatz mit der SEQ 1 geschrieben, dort wird aber eigentlich Rahmen F erwartet. Der Empfänger hat keine Möglichkeit, diesen Fehler festzustellen! Die Lösung dieses Problems besteht darin, nur die Hälfte der zur Verfügung stehenden Speicherplätze bzw. Sequenznummern im Sende- und Empfangspuffer freizugeben. Abbildung 8 zeigt diese Lösung: Es gibt zwar die Sequenznummern 0 bis 3, aber statt wie zuvor immer alle Plätze im Puffer zu belegen, wird nur die Hälfte verwendet. Der Sender lädt nur Rahmen A und B mit SEQ 0 und 1. Der Empfänger verarbeitet diese korrekt empfangenen Rahmen, schickt die ACK 0 und 1, löscht die entsprechenden Speicherplätze und schiebt das Fenster weiter (es werden nun die Rahmen mit SEQ 2 und 3 erwartet, die Speicher für SEQ 0 und 1 sind noch nicht wieder freigegeben). Nun geht ACK 1 verloren, sodass der Sender sein Fenster nur um einen Schritt weiterschiebt, Rahmen C lädt und Rahmen B als Duplikat nach Ablauf des Timers erneut verschickt. Dieses Duplikat müsste beim Empfänger im Speicher für SEQ 1 abgelegt werden, welcher jedoch nicht freigegeben ist. Obwohl das Paket nicht verarbeitet wird, so muss dennoch das ACK 1 erneut verschickt werden, damit beim Sender der Rahmen B gelöscht und das Fenster weitergeschoben werden kann. Sender Empfänger Sender Empfänger SEQ ACK 0 0 A A SEQ 1 ACK 1 B 1 B 0 K0 A AC C 2 C 2 Du K1 B 1 pli AC ka SEQ D t S D 3 EQ 0 3 C 1 K0 E K2 2 AC AC E 0 1 D K1 B K3 3 AC AC 2 3 Abbildung 7: Sliding Windung bei verlorenem ACK 14 Sender Empfänger Sender Empfänger SEQ 0 ACK 0 A A SEQ 1 ACK 1 B 1 0 B K0 A AC 2 C 2 SEQ K1 B 1 2 AC Du K2 C 3 pl ika AC 3 2 t SE Q 3 0 1 3 0 K1 1 AC Abbildung 8: Sliding Window: Lösung des ACK-Problems In der Praxis werden Flusskontroll-Mechanismen insbesondere bei Punkt-zu-Punkt-Netzen eingesetzt. Bei Mehrfachzugriffsnetzen wie dem Ethernet sind solche Verfahren weniger sinnvoll, da der Sender hier oftmals gar nicht weiß, an welche Zielgeräte der Datenrahmen tatsächlich gesendet wird bzw. der Rahmen von mehreren Zielgeräten angenommen wird (Multicast oder Broadcast). Ein Protokoll für ein Rückmeldeverfahren, das Bestätigungen von mehreren Empfängern an einen Sender ermöglicht, wäre unverhältnismäßig aufwändig. 1.3 Media Access Control MAC 1.3.1 IEEE-Normen Das Institute of Electrical and Electronical Engineers IEEE hat diverse Normen für lokale Netzwerktypen definiert. Die Norm Nr. 802 definiert die Grundfunktionen für lokale Netzwerke, die im vorangegangenen Abschnitt bereits erläutert wurden. Alle in Norm 802 definierten Netzwerktypen sind auf der LLC-Schicht (Unternorm 802.2) kompatibel. Viele dieser Netztypen sind heute in der Praxis nicht mehr im Einsatz. Dazu gehören z.B TokenBus (Unternorm 802.4), TokenRing (802.5) oder DQDB (802.6), die an dieser Stelle nicht weiter betrachtet werden sollen. Für heutige lokale Netzwerke hat sich ein Grundprinzip durchgesetzt, das unter dem Namen „Ethernet“ bekannt ist. Dies ist aber lediglich ein Oberbegriff für verschiedene Techniken und Verkabelungen, denen jedoch das gleiche Prinzip zugrunde liegt. Diese Norm hat die Nummer 802.3 und besteht aus diversen weiteren Unternormen, die mit Buchstaben bezeichnet werden. Diese Techniken sind der MAC-Teilschicht (Media Access Control) zugeordnet. Einige Beispiele für 802.3-Normen mit verschiedenen Datenübertragungsraten (die Länge der Verkabelung beträgt meistens maximal 100 Meter bei Kupfer-basierten Kabeln): 802.3a: 10Base2 (10 Mbps) mit dünnem Koaxialkabel und BNC-Steckern 802.3i: 10BaseT (10 Mbps) mit Cat3-Kabeln „Unshielded Twisted Pair“ UTP 802.3u: 100 BaseTX (100 Mbps) mit Cat5, 5E oder 6 UTP oder als 100BaseFX mit Multimode Glasfaser (LWL) 802.3ab: 1000BaseT (1000 Mbps) UTP mit 4 Kabelpaaren 802.3z: 1000BaseSX oder LX mit Multimode bzw. Singlemode LWL 802.3ae: 10GBase (10 Gbps) mit LWL-Verkabelung 802.3an: 10GBase (10 Gbps) mit TP-Verkabelung 802.3ba: 40 Gbps und 100 Gbps  15 1.3.2 CSMA/CD Die ursprüngliche Ethernet-Technik besteht nur aus einem einzigen Kabel (meist ein Koaxialkabel), an das alle Rechner z.B. mit Steckverbindern (BNC) angeschlossen sind (Mehrfachzugriffsnetz, engl. Multiple Access). Dies bedeutet, dass sich alle Rechner in einem Netzwerk die maximale Übertragungsrate teilen müssen, und außerdem ein Mechanismus für die Zugriffsregelung existieren muss, da immer nur ein Rechner gleichzeitig Daten senden kann. Die Ethernet-Technik sieht keine zentrale Überwachungs-Station vor, die den Zugriff der sendewilligen Rechner regelt. Alle Rechner sind gleichberechtigt und dürfen jederzeit ohne Erlaubnis durch eine „höhere Instanz“ Daten ins Netzwerk senden. Damit jedoch nicht mehrere Rechner gleichzeitig senden, hört jeder Rechner den Kanal ab (engl. Carrier Sense), und sendet seine Daten nur dann, wenn der Kanal frei ist. Ist der Kanal belegt, wartet ein Rechner mit dem Abschicken seiner Daten. Es kann jedoch vorkommen, dass ein Rechner einen freien Kanal vorfindet und daraufhin seine Daten abschickt, aber ein zweiter Rechner zum exakt gleichen Zeitpunkt ebenfalls seine Daten sendet. Dies führt unvermeidlich zu einer Überlagerung der Signale beider Rechner, sodass das einzelne Signal nicht mehr aufgelöst werden kann. Diese Situation wird als „Kollision“ bezeichnet (auch wenn der Begriff physikalisch wenig sinnvoll ist, da Wellen nicht kollidieren können sondern sich lediglich überlagern). Wird eine Kollision erkannt (engl. Collision Detection), wird ein spezielles Störsignal gesendet (Jam-Signal) und alle Rechner beenden sofort ihre Übertragung. Je mehr Rechner Daten senden wollen, umso wahrscheinlicher wird das Auftreten einer Kollision: Mehrere Rechner finden einen belegten Kanal vor und warten; sobald der Kanal frei geworden ist, senden daher mehrere Rechner gleichzeitig und es kommt unvermeidlich zu einer Kollision. Da es aber weder eine übergeordnete Entscheidungsinstanz noch eine direkte Kommunikation zwischen den Rechnern gibt, wird das Problem wie folgt gelöst: Ein Rechner sendet entweder sofort nach Freiwerden des Kanals oder er wartet eine bestimmte Zeit ab (die Länge dieses Zeitintervalls hängt von der Technik ab, insbesondere von der maximalen Signallaufzeit im Netzwerk). Ob er wartet oder nicht, wird zufällig von jedem Rechner selbst entschieden. Kommt es trotzdem zu einer weiteren Kollision, wird aus vier verschiedenen Zeitintervallen eine Wartezeit zufällig ausgewählt (sofort senden oder ein, zwei oder drei Zeitintervalle warten), nach einer weiteren Kollision aus acht Intervallen usw. (sog. Backoff-Verfahren). Aus den genannten Bezeichnungen Carrier Sense, Multiple Access und Collision Detection ergibt sich die Abkürzung CSMA/CD. Da die einfache Verkabelung mittels eines einzigen Koaxialkabels sehr unzuverlässig sein kann und zudem bei einem einzigen auftretenden Kabel- oder Steckerproblem das gesamte Netzwerk nicht mehr funktioniert, wurde die sternförmige Verkabelung entwickelt, bei der jeder Rechner mit einer eigenen Zuleitung (Kupferkabel mit verdrillten Kabelpaaren, engl. Twisted Pair) mit einem zentralen Verteiler (Hub) verbunden sind. Ein Hub ist lediglich ein Signalverstärker, der alle Signale, die auf einer Leitung hereinkommen, auf allen anderen Leitungen herausschickt. Da auch bei dieser Verkabelungsart Kollisionen auftreten können, wird ein solcher Netzwerkbereich als „Collision Domain“ bezeichnet. Alle Rechner, die an einen Hub angeschlossen sind (auch bei mehreren hintereinandergeschalteten Hubs), befinden sich nicht nur in dieser Collision Domain sondern auch in der Broadcast Domain, da ein Datenrahmen bzw. Signal unabhängig von dem tatsächlichen Zielrechner automatisch an alle Rechner geschickt wird; erst beim Rechner wird die Zieladresse (MAC-Adresse, siehe Kapitel 1.3.3) mit der eigenen MAC-Adresse verglichen und dann entschieden, ob der eingetroffene Rahmen weiterverarbeitet oder verworfen wird. Damit wird deutlich (Stichwort: Netzwerksicherheit), dass jeder Rechner prinzipiell alle Datenrahmen annehmen kann, auch wenn die Daten gar nicht für ihn bestimmt sind. In modernen lokalen Netzwerken werden statt Hubs so genannte Switches eingesetzt (siehe Kapitel 1.4). 1.3.3 MAC-Adressen Ein Datenrahmen benötigt unabhängig von der im lokalen Netzwerk verwendeten Übertragungstechnik eine eindeutige Adresse, damit der Zielrechner feststellen kann, ob ein Rahmen für ihn bestimmt ist oder andernfalls verworfen oder ggf. weitergeleitet werden kann. Diese Adressierung muss auf der Netzwerkkarte (Network Interface Card NIC), auf der die Funktionen der Sicherungsschicht ablaufen, vorhanden sein. Die mehrfache Verwendung derselben Adresse muss unbedingt vermieden werden, da sonst keine eindeutige Zuordnung von Datenrahmen zu Zielrechnern nicht möglich ist. Daher werden diese sog. MAC-Adressen i.d.R. nicht manuell vergeben sondern bereits bei der Produktion der Netzwerkkarte vom Hersteller fest „eingebrannt“. Eine MAC-Adresse hat eine Länge von 48 Bit (6 Byte) und wird in hexadezimaler Form geschrieben; die einzelnen Bytes werden mit einem Doppelpunkt voneinander getrennt (z.B. 12:34:AB:CD:5F:E0). Die beiden rechten Bit im linken Byte haben eine spezielle Bedeutung: ist das rechte Bit eine 0, so handelt es sich um die individuelle Adresse eines einzelnen Gerätes (Netzwerkkarte), ist das rechte Bit eine 1, stellt die MAC-Adresse eine Multicast-Adresse (Gruppenadresse) dar. Das zweite Bit von rechts sagt aus, ob die Adresse lokal verwaltet wird (manuell vergeben, dann ist dieses Bit 1) oder global verwaltet wird (vom Hersteller vergeben, dann ist dieses Bit 0). Die verbleibenden 22 linken Bit sind (bei global verwalteten Adressen) die Hersteller-Kennung, die von der IEEE eindeutig vergeben wird. Die rechten 24 Bit werden vom Hersteller eindeutig vergeben und bei der Herstellung in die Firmware einer 16 Netzwerkkarte geschrieben. 0: globale Adresse 0: Unicast 1: lokal verwaltet 1: Multicast bin. 11000100 10101010 00011101 11111101 000001001 00110010 hex. C4 AA 1D FD 09 32 Herstellerkennung NIC Identifier allg: Organisation Unique Identifier OUI Abbildung 9: MAC-Adresse (Beispiel) Alle im Netzwerk angeschlossenen Rechner benötigen zwingend eine MAC-Adresse, um erreichbar zu sein. Ein Hub benötigt keine MAC-Adresse, da es sich lediglich um einen Signalverstärker handelt, der nicht direkt an der Kommunikation mittels Datenrahmen beteiligt ist. Ein Switch wertet zwar die Quell- und Ziel-MAC-Adressen der weiterzuleitenden Datenrahmen aus, benötigt für seine Grundfunktion aber keine eigene MAC-Adresse, da er Rahmen nur weiterleitet aber nicht selbst verarbeitet. Handelt es sich jedoch um einen konfigurierbaren Switch, der mittels Netzwerkprotokollen wie HTTP oder SSH erreichbar sein soll, so benötigt auch er eine MAC-Adresse; auch für die Verwendung des Spanning Tree Protokolls (siehe Kapitel 1.4.3) sind MAC-Adressen erforderlich. 1.3.4 Ethernet-Protokoll Das Ethernet-Protokoll definiert das Format des Headers eines Datenrahmens in einem Mehrfachzugriffsnetz. Neben den bereits bekannten Funktionen wie Adressierung und Fehlerkontrolle enthält der Header Informationen zum Protokoll, das in den Nutzdaten enthalten (gekapselt) ist. Statt der aus Kapitel 1.2.1 bekannten Rahmentrennung, wird im Ethernet eine Startsequenz aus insgesamt acht Byte verwendet. Die ersten sieben Byte bestehen aus einer Eins-Null-Folge (Präambel), die zum einen den anderen Rechnern im Netz signalisiert, dass der Kanal belegt ist und nun ein Datenrahmen folgt, zum anderen zur technischen Synchronisierung zwischen den NICs dient. Die eigentliche Startkennung ist der Start-of-Frame- Delimiter SFD, der aus der Bitfolge 10101011 besteht. Danach folgen die Ziel- und Quell-MAC-Adresse, wobei die Quell-Adresse immer eine Unicast-Adresse sein muss, während die Zieladresse auch eine Multicast- oder die Broadcast-Adresse FF:FF:FF:FF:FF:FF (binär: alles Einsen) sein kann. Präambel (7) SFD (1) Ziel-MAC (6) Quell-MAC (6) Typ (2) Nutzdaten (46-1500) FCS (4) Abbildung 10: Ethernet-Frameheader Das Feld Ethertype (2 Byte) gibt das Protokoll des Payloads (Nutzdaten) an, meistens das IP-Protokoll (hex. Wert: 0800), IPv6 (hex.: 86DD) oder das ARP-Protokoll (hex.: 0806). Die Unterscheidung der Payload-Protokolle ist an dieser Stelle insofern sinnvoll, da ein IP-Paket an die Vermittlungsschicht weitergeleitet werden muss, während ein ARP-Paket gar keinen IP-Header und somit auch keine IP-Adressen hat und folglich das IP-Protokoll für die Zuordnung von IP- und MAC-Adressen im ARP-Cache auch gar nicht zuständig ist (siehe Kapitel 1.7). Problematisch ist, dass ältere Ethernet-Varianten statt des Ethertype ein Längenfeld (Größe des Payloads) nutzen; zur eindeutigen Unterscheidung wurde festgelegt, dass Werte kleiner als 1536 (hex.: 0600) als Payload-Länge interpretiert werden und größere Werte als Ethertype. Um eine zuverlässige Kollisionserkennung zu ermöglichen, ist eine Mindestlänge eines Rahmens erforderlich, die bei 10/100 Mbps-Netzen bei 64 Byte liegt und im Gigabit-Ethernet bei 512 Byte. Grund hierfür ist, dass ein Rahmen die gesamte Collision Domain bzgl. der Signallänge ausfüllen muss, damit auch die entferntesten Rechner eine Kollision erkennen können. Der Frame-Header enthält jedoch nur die beiden 6-Byte-MAC-Adressen den Ethertype bzw. das Längenfeld (2 Byte) sowie 4 Byte FCS (Präambel und SFD gehören nicht dazu). Bei geringen Nutzdatenmengen oder leeren Rahmen müssen daher bis zu 46 Byte mittels eines Paddings (Nullen) ergänzt werden. In der Praxis verzichten einige NIC-Treiber jedoch auf das Padding, da die heute typischerweise verwendeten Gigabit-NICs fast immer mit Full-Duplex-Technik arbeiten, CSMA/CD jedoch nur bei Halb-Duplex erforderlich ist. Das Entfernen des Paddings beim Empfänger wäre nur möglich, wenn er darüber informiert wäre  17 wie viele Padding-Bytes vom Sender eingefügt wurden. Es wird jedoch auf das Entfernen des Paddings beim Empfänger verzichtet, da die Protokolle innerhalb des Payloads eigene Längenfelder besitzen (z.B. IP) oder feste Längen verwendet werden (z.B. ARP) und damit die zusätzlich eingefügten Nullen von diesen Protokollen ignoriert werden. Die maximale Länge eines Ethernet-Frames beträgt 1500 Byte Nutzdaten (sog. Maximum Transmission Unit MTU) zzgl. Header, also 1518 Byte bzw. 1522 Byte bei VLAN-Tagging (siehe Kapitel 1.5). Diese maximale Länge soll sicherstellen, dass alle Rechner innerhalb einer Collision Domain regelmäßig die Möglichkeit bekommen Daten abzusenden). Für höhere Protokolle wie IP oder TCP ist diese Beschränkung wegen der dortigen Paketgröße von bis zu 64 kB jedoch ungünstig (Fragmentierung oder Zusatzfunktionen nötig wie TCP Segmentation Offload, siehe Kapitel 4). Auch für Anwendungen mit sehr hohen Anforderungen an die Übertragungsrate (z.B. iSCSI), ist die MTU von 1500 Byte ebenfalls zu klein, da der Overhead durch Frame-/IP-/TCP- und Anwendungs-Header sehr viel Bandbreite beansprucht. Für solche Anwendungen ist spezielle Hardware (NIC, Switches) verfügbar, die größere Rahmen (Jumbo-Frames) bis zu 9000 Byte erlaubt. Das Längenfeld in älteren Ethernet-Varianten soll dem Empfänger die Möglichkeit geben, das Ende des Nutzdaten- Felds zu erkennen. Dies ist aber nicht unbedingt erforderlich, da ein Empfänger das Ende eines Rahmens auch am „Inter-Frame-Gap“ erkennen kann; hierbei handelt es sich um eine Zeitlücke zwischen dem Ende des einen und dem Beginn des folgenden Rahmens (die Lücke entspricht einer Länge von mindestens 12 Byte). Das FCS-Feld (Frame Check Sequence) enthält eine 4-Byte Prüfsumme nach dem CRC32-Verfahren. Zu beachten ist, dass das Ethernet-Protokoll keine Rückmeldemechanismen, wie in Kapitel 1.2.3 beschrieben, kennt. Wird anhand der Prüfsumme ein Fehler festgestellt, wird der Rahmen lediglich verworfen. Aufgrund der Verkabelungstypen im Ethernet (verdrillte oder geschirmte Kupferkabel, Glasfaser) und relativ kurzen Leitungslängen im LAN sind Fehler extrem selten, sodass ein Rückmeldeverfahren mit Sequenz- und Bestätigungsnummern unverhältnismäßig aufwändig wäre. 1.4 Switching 1.4.1 Funktionen In modernen Ethernet-basierten Netzwerken werden statt einfacher Hubs sog. Switches verwendet, die einen eingehenden Datenrahmen nur an diejenige Ausgangsleitung herausschicken, an der der Zielrechner angeschlossen ist. Im Gegensatz zum Hub, der lediglich Signale weiterleitet, muss ein Switch die Header der eingehenden Datenrahmen einlesen und die Adressen verarbeiten. Ein Switch muss hierzu allerdings wissen, welcher Rechner an welcher Ausgangsleitung (Port) angeschlossen ist. Diese Information lernt ein Switch selbstständig (siehe Kapitel 1.4.2). Er interpretiert also die Daten auf OSI-Schicht 2 (Layer 2) und lernt Adressen; man spricht daher von L2- Learning-Switches. Anhand der gelernten Adressen ist der Switch in der Lage Datenrahmen weiterzuleiten (Forwarding). Eine weitere wichtige Funktion ist die Vermeidung von Schleifen (Loop-Protection) auch dann, wenn die Verkabelung solche Schleifen im Netzwerk ermöglicht (was aus Gründen der Ausfallsicherheit sinnvoll sein kann). Bei Verwendung eines Switches umfasst jeder einzelne Port eine eigene Collision Domain; eine Kollision kann daher nur noch auftreten, wenn ein Rechner Daten an den Switch sendet und gleichzeitig umgekehrt der Switch Daten an den Rechner. Werden zudem mehrere Kabelpaare in einer Zuleitung verwendet, so kann eine Kollision überhaupt nicht mehr auftreten, da jeweils ein eigenes Kabel für jede Richtung zur Verfügung steht (Voll-Duplex- Leitung). 1.4.2 Address Learning Ein Switch, der neu gestartet wurde, kennt zunächst keine der Adressen der angeschlossenen Rechner oder Geräte. Die so genannte MAC-Adress-Tabelle ist noch leer. Erst nach dem Abschicken eines Datenrahmens durch einen der Rechner, kann der Switch den Header dieses eingehenden Rahmens einlesen und die dort stehende Quell-Adresse zusammen mit der Nummer des Eingangsports in seiner MAC-Adresstabelle (s.u.) temporär speichern. Schickt Rechner R1 einen Rahmen ab (Abbildung 11), so wird seine in diesem Rahmen stehende Quell-MAC- Adresse zusammen mit Port-Nr. 1 in der MAC-Adresstabelle gespeichert. Die Ziel-MAC-Adresse des Rahmens ist jedoch noch unbekannt, daher hat der Switch keine andere Möglichkeit, als diesen Rahmen an alle Ports mit Ausnahme des Eingangsports per Flooding herauszuschicken. 18 MAC-Adressen Port 12:34:CE:FF:03:1E 1 R1 unbekannt 2 1 Switch 3 R3 2 unbekannt 3 12:34:CE:FF:03:1E 28:31:C4:AA:4B:6A C0:55:D7:F0:19:CF R2 Abbildung 11: Kommen daraufhin Antwort-Rahmen von einem der anderen Rechner (oder von mehreren Rechnern), so können auch deren Quell-MAC-Adressen gespeichert werden. Nun können alle eintreffenden Rahmen direkt an den richtigen Ausgangsport weitergeleitet werden. Schickt R1 Rahmen an R2, so nutzen diese beiden Rechner im Prinzip eine eigene Leitung; Rechner R3 bekommt keinen dieser Rahmen. Sollen jedoch alle Rechner erreicht werden, so muss als Ziel-MAC-Adresse die Broadcast-Adresse (FF:FF:FF:FF:FF:FF) verwendet werden; in diesem Fall verteilt der Switch alle eintreffenden Rahmen an alle Ausgangsports. Die Broadcast Domain umfasst also auch im „geswitchten“ Netzwerk alle angeschlossenen Geräte. MAC-Adressen Port 12:34:CE:FF:03:1E 1 C0:55:D7:F0:19:CF 2 28:31:C4:AA:4B:6A 3 Video in der Mediathek (Channel NWA): Switching (Grundfunktionen) Video in Moodle (alt): switch_address-learning.mp4 Sind mehrere Switches hintereinandergeschaltet (Abbildung 12), so funktioniert das Lernen der MAC-Adressen genauso wie zuvor erläutert. R1 1 Switch A 3 1 Switch B 2 2 12:34:CE:FF:03:1E C0:55:D7:F0:19:CF R2 R3 28:31:C4:AA:4B:6A Abbildung 12: Schickt Rechner R1 einen Rahmen an R3 ab und die Switches haben noch keine Informationen in ihrer MAC- Adresstabelle, so wird der Rahmen per Flooding an alle Ausgangsports (auch Port 3 bei Switch A) geschickt. Switch B schickt – sofern er noch keine Informationen über R3 hat – diesen über Port 1 hereingekommenen Rahmen ebenfalls per Flooding an alle Ausgangsleitungen. Nach diesem ersten Rahmen haben die beiden MAC- Adresstabelle der Switches A und B folgendes Aussehen Switch A: MAC-Adressen Port Switch B: MAC-Adressen Port 12:34:CE:FF:03:1E 1 12:34:CE:FF:03:1E 1 unbekannt 2 unbekannt 2 unbekannt 3 Kommen Antwort-Pakete der beiden Rechner R2 und R3 so vervollständigen sich die MAC-Adresstabellen: Switch A: MAC-Adressen Port Switch B: MAC-Adressen Port 12:34:CE:FF:03:1E 1 12:34:CE:FF:03:1E 1 C0:55:D7:F0:19:CF 2 C0:55:D7:F0:19:CF 1 28:31:C4:AA:4B:6A 3 28:31:C4:AA:4B:6A 2 Switch B hat nun die beiden MAC-Adressen der Rechner R1 und R2 mit seinem Ausgangsport 1 (der Verbindung zu Switch A) verknüpft. Video in der Mediathek (Channel NWA): Switching (Grundfunktionen) Video in Moodle: switch2_address-learning.mp4  19 1.4.3 Spanning Tree Protokoll Mithilfe des Spanning Tree Protokolls STP sollen Switching-Schleifen vermieden werden. Die in der Abbildung 13 dargestellte Vernetzung von drei Switches in einem lokalen Netzwerk führt ohne STP unweigerlich zu der Situation, dass Ethernet-Frames von einem Switch zum nächsten weitergeschickt werden und somit eine unendlich fortgesetzte Schleife entsteht, da im Frame-Header im Gegensatz zum IP-Header kein TTL-Feld oder eine andere Funktionalität zur Erkennung von fehlgelaufenen Paketen existiert. Bei Verwendung einfacher Switches, die STP nicht unterstützen, muss unbedingt eine solche Verkabelung vermieden werden. Bridge-ID: 32768.00-...-01 Segment 1 Bridge-ID: 32768.00-...-02 Switch A Switch B Segment 2 Segment 3 Switch C Bridge-ID: 32768.00-...-03 Abbildung 13: Switches in einer Schleife Beim Start halten sich zunächst alle Switches für eine sog. Root-Bridge, sodass die Root-ID bei allen Switches der Bridge-ID entspricht. Die Bridge-ID besteht aus einem Prioritätswert (Standard 32768, hex.: 8000) und der MAC- Adresse. Mit dem Spanning Tree Protocol (STP) werden regelmäßig zwischen den Switches sog. Bridge Protocol Data Units (BPDU) ausgetauscht. Angenommen Switch B sendet eine BPDU mit der Root-ID 02 an die Switches A und C. Da bei STP der kleinere Wert immer der bessere ist, ändert sich bei A bzgl. der Root-ID nichts, aber C ändert seinen Wert für die Root-ID auf 02, d.h. Switch C hält nun B für die Root-Bridge. Sendet nun auch Switch A eine BPDU an B und C, so wird bei B und C die Root-ID auf 01 gesetzt. Damit haben sich alle Switches auf Switch A als Root- Bridge geeinigt. Im nächsten Schritt muss jede Non-Root-Bridge einen Root-Port bestimmen; dies ist der „nächstliegende“ Port zur Root-Bridge (welcher Port der nächstliegende ist, wird auf Basis der aufsummierten Kosten des Weges zur Root- Bridge berechnet, wobei die Kosten vom IEEE standardisiert sind (siehe Tabelle). Die Werte der Pfadkosten sind abhängig von der Übertragungsrate; Netgear-Switches verwenden abweichend von den IEEE-Standards folgende Werte: Geschwindigkeit Pfadkosten Pfadkosten Netgear IEEE 1 Gbps 20.000 4 100 Mbps 200.000 19 10 Mbps 2.000.000 100 Für jedes Segment (Verbindung zwischen zwei Switches) wird ein „Designated Port“ bestimmt. Es wird derjenige Port zum Designated Port, der die geringsten Pfad-Kosten zur Root-Bridge hat. Die Segmente 1 und 2 hängen direkt an der Root-Bridge A, sodass die entsprechenden Ports von Switch A zu Designated Port werden. Für Segment 3 müssen die Pfad-Kosten bestimmt werden, falls gleiche Kosten vorliegen sollten, so „gewinnt“ die kleinere Bridge-ID (hier also B). Alle Root-Ports und alle Designated Ports werden in den Zustand „Forwarding“ gesetzt, sodass über diese Ports Pakete hinausgeschickt werden können. Alle anderen Ports (im Beispiel derjenige Port von Switch C, der zu B führt) befinden sich nun im Zustand „Blocking“ (auch als „Alternate“ bezeichnet), sodass keine Pakete von diesem Port versendet werden. Damit ist eine Switching-Schleife verhindert. Das Ergebnis dieses Aushandlungsprozesses ist in Abbildung 14 dargestellt. Jeder Port mit dem besseren BPDU-Wert schickt nun regelmäßig in kurzen Abständen eine BPDU an den Nachbar- Port und dokumentiert so seine „Überlegenheit“. Es können hierbei Fehler entstehen, wenn diese BPDUs nicht 20 mehr ankommen. Wenn bspw. der DP von Switch B keine BPDUs mehr an C schickt (z.B. wegen eines Konfigurationsfehlers in den Halb-/Voll-Duplex-Einstellungen), so würde dann der zuvor blockierte Port bei C in den Forwarding-Modus gesetzt werden und es entsteht die unerwünschte Schleife. Bridge-ID: 32768.00-...-01 Bridge-ID: 32768.00-...-02 Root Port Root-ID:...-01 Root-ID:...-01 Root-Bridge A Switch B Designated Ports Designated Port Switch C X Blocked Port Root Port Bridge-ID: 32768.00-...-03 Root-ID:...-01 Abbildung 14: Spanning Tree Sonderfall: Sind zwei Switches über zwei Leitungen direkt (mit den gleichen Pfadkosten) miteinander verbunden, reichen die bisher genannten Entscheidungskriterien nicht aus, denn die Bridge-ID wäre für beide Leitungen dieselbe. In diesem Fall müsste die Non-Root-Bridge beide Verbindungen zur Root-Bridge zu Root-Ports erklären. In diesem Fall entscheidet die Port-ID, die aus einer Port-Priorität (i.d.R. 128, hex.: 80) und der Port-Nummer besteht (z.B. hex. 800A für Port-Nr. 10 entspricht hex. 0A). Video in der Mediathek (Channel NWA): Switching (Spanning Tree Protocol) Video in Moodle (alt): spanning-tree.mp4 1.5 Virtual LAN Mit virtuellen LANs lassen sich Netzwerke in getrennte Abschnitte aufteilen, ohne dass für jeden Abschnitt ein eigener (physikalischer) Switch oder eine getrennte Verkabelung erforderlich wären. Im Beispiel (Abbildung 15) befinden sich die Rechner R1 und R2 in einem LAN und die Rechner R3 und R4 in einem anderen (d.h. sie befinden sich in unterschiedlichen IP-Subnetzen). Alle Rechner aus VLAN 3 „sehen“ die Rechner aus VLAN 4 nicht (und umgekehrt), d.h. die Broadcast Domain ist jeweils auf ein VLAN begrenzt, obwohl alle Rechner physikalisch mit einem einzigen Switch verbunden sind. Um eine Kommunikation zwischen den Rechnern aus unterschiedlichen VLANs herzustellen, ist ein Router erforderlich, dessen Interfaces ebenfalls an den jeweiligen VLANs angeschlossen sein müssen. Prinzipiell könnten die beiden IP-Subnetze auch ohne VLAN-Konfiguration an den Switch angeschlossen sein, allerdings würde dann nur eine einzige Broadcast Domain auf Schicht 2 existieren, sodass eine vollständige Trennung der beiden IP-Subnetze nicht gegeben wäre. VLAN 3 A Router B 3 Switch A 6 VLAN 4 1 2 4 5 R1 R2 R3 R4 VLAN 3 VLAN 4 Abbildung 15: VLANs  21 Um eine Trennung der Broadcast Domains zu erreichen, muss in der Switch-Konfiguration jedem Port ein VLAN zugeordnet sein: Ein IP-Paket, das von R1 an R2 geschickt wird, verlässt das VLAN 3 nicht: Mithilfe von ARP erfolgt die Verknüpfung der IP- und MAC-Adressen von R1 und R2, sodass R1 den Rahmen direkt an die MAC- Adresse von R2 schickt, und der Switch kennt anhand seiner MAC-Adresstabelle (s.u.) alle Ports und MAC- Adressen aus VLAN 3; ein Datenrahmen von R1 an R2 wird vom Switch dirket an den entsprechenden Port weitergeleitet. Wird dagegen ein IP-Paket von R1 an R4 geschickt, so erkennt R1 anhand der fremden IP-Adresse (aus dem anderen Subnetz), dass das Paket an die Gateway-Adresse (Router) des eigenen Subnetzbereiches geschickt werden muss; der Datenrahmen wird an die MAC-Adresse des Router-Interfaces A aus VLAN 3 geschickt und vom Router (anhand der IP-Adresse) in das VLAN 4 vermittelt. VLAN MAC-Adressen Port 3 MAC(R1) 1 3 MAC(R2) 2 3 MAC(Router_A) 3 4 MAC(R3) 4 4 MAC(R4) 5 4 MAC(Router_B) 6 Solange alle VLANs an einem einzigen Switch angeschlossen sind, kann der Switch die Zuordnung der Rahmen zu den VLANs selbst vornehmen, da er über alle erforderlichen Informationen verfügt. Abbildung 16 zeigt einen erweiterten Aufbau mit zwei Switches, die beide jeweils die VLANs 3 und 4 kennen. Wenn Rechner R1 (VLAN 3) ein IP-Paket an R3 (VLAN 4) schickt, läuft dieses Paket (in VLAN 3) über die „Trunk Line“ zu Switch B und weiter zum Router und von dort aus wieder zurück (jetzt in VLAN 4) über Switch B zu Switch A. Das Problem ist: Switch B kennt zwar die MAC-Adressen der Rechner R3 und R4, aber nicht die dazugehörige VLAN-Konfiguration (denn die ist nur in Switch A vorhanden). Anders ausgedrückt: Die Broadcast Domains VLAN 3 bzw. VLAN 4 können ohne weitere Informationen nicht über mehrere Switches hinweg aufgespannt werden. Es ist daher erforderlich, diese Information über die Trunk Line auszutauschen, was mithilfe einer Erweiterung des Ethernet-Headers erfolgt. Hierzu dient der Standard 802.1Q, der eine Erweiterung des Ethertype-Headerfeldes definiert (sog. VLAN-Tagging). Schickt Switch A einen Rahmen von Rechner R1 an Switch B, so fügt er die VLAN-ID von R1 in den Rahmen-Header ein. Somit weiß Switch B zu welchem VLAN bzw. welcher Broadcast Domain dieser Rahmen gehört und ist damit in der Lage, diesen Rahmen ausschließlich an Ports weiterzuleiten, die zu diesem VLAN gehören. Die Ports der Trunk Line (Trunk Ports) müssen hierzu so konfiguriert werden, dass sie zu beiden VLANs gehören und das VLAN-Tagging unterstützen („tagged Ports“). VLAN 3 Router Trunk Link VLAN 4 Switch A VLAN 3 und 4 Switch A B R1 R3 R2 R4 VLAN 3 VLAN 4 VLAN 3 VLAN 4 Abbildung 16: VLAN mit zwei Switches Abbildung 17 zeigt den veränderten Ethernet-Frame-Header: Zwischen der Quell-MAC-Adresse und dem Ethertype wird ein Zusatzfeld eingefügt. Damit dieses Feld erkannt werden kann, beginnt es mit einem eigenen Typ-Feld mit dem Typ „VLAN-Tagging“ (hex.: 8100). Der eigentliche Ethertype des Payloads folgt nach dem Tagging-Feld. Ein 3- Bit-Prioritätswert ermöglicht die Weiterleitung von Rahmen mit unterschiedlicher Priorität, das CF-Bit definiert die Lese-Richtung der Adressen (bei TokenRing „verkehrt herum“). Danach folgt die VLAN-ID (bis zu 4096), wobei berücksichtigt werden muss, dass in Abhängigkeit von der Switch-Hardware einzelne IDs oder ID-Bereiche für 22 spezielle Zwecke reserviert sein können oder als „extended VLAN“ (bei Cisco ab 1006) konfiguriert werden müssen. Ziel-MAC (6) Quell-MAC (6) 802.1Q (4) Typ (2) Nutzdaten (46-1500) FCS (4) Typ 8100 (16 Bit) Priorität (3 Bit) CF (1 Bit) VLAN ID (12 Bit) Abbildung 17: VLAN-Tagging, IEEE 802.1Q Das VLAN-Tagging darf jedoch nur für Trunk Ports aktiviert werden; sog. Access-Ports, an denen nur die Endgeräte angeschlossen sind, müssen immer als „untagged“ konfiguriert sein, da normale NICs kein VLAN-Tagging interpretieren können. Video in der Mediathek (Channel NWA): Switching (Virtual LAN) Video in Moodle (alt): vlan.mp4 und vlan-tagging.mp4 1.6 Link Aggregation LACP Die heute üblichen Ethernet-NICs arbeiten mit einer Übertragungsrate von 1 Gbps. Höhere Übertragungsraten sind mit 10 oder 40 Gbps verfügbar, jedoch ist die dafür erforderliche Hardware (Netzwerkkarte, Switch-Hardware, oft Glasfaser-Verkabelung) im Vergleich zur 1-Gbps-Technik sehr teuer und für viele Anwendungsfälle auch nicht zwingend erforderlich. Oftmals ist bereits eine Verdopplung der Übertragungsrate auf 2 Gbps ausreichend, die mithilfe von zwei einfachen 1-Gbps-NICs erreicht werden kann. Allerdings können zwei unabhängige Ethernet- Anschlüsse am Rechner nicht einfach parallel genutzt werden, da jedes Interface eine eigene IP-Adresse benötigt. Bei Trunk Lines zwischen Switches ist zudem zu beachten, dass einzelne Leitungen durch das Spanning Tree Protokoll u.U. deaktiviert werden könnten, da jede Leitung bzgl. STP für sich betrachtet wird. Mit dem Link Aggregation Control Protocol LACP steht eine Technik zur Verfügung, die zwei oder mehr physikalische Leitungen zu einem logischen Kanal zusammenfassen kann. Ein Rechner ist zwar mit mehreren unabhängigen Leitungen mit dem Switch verbunden, die von LACP jedoch zu einer einzigen virtuellen Leitung zusammengefasst werden. Zu beachten ist allerdings, dass auch mit LACP eine einzelne TCP-Verbindung nicht auf zwei oder mehr Leitungen aufgeteilt werden kann, und sich die höhere Bandbreite nur bei mehreren verschiedenen parallel laufenden TCP-Verbindungen bemerkbar macht. Switch A Switch B 2 Gbps 2 Gbps 1 Gbps 1 Gbps R1 R2 R3 R3 Für das Zusammenschalten mehrerer Leitungen zu einer einzigen virtuellen Trunk Line ist eine geeignete Switch- Hardware erforderlich, die das LACP-Protocol unterstützt. Auch das Betriebssystem von Rechner R1 muss dieses Protokoll kennen. Die konkrete Konfiguration eines Switches oder Netzwerk-Interfaces ist je nach Hersteller oder Betriebssystem sehr unterschiedlich, Bezeichnungen sind z.B.: Port-Channel, Channel-Group, Ether-Channel, Bonding, Aggregation. Die Funktionen von LACP sind im Standard 802.3ad definiert. Die benachbarten Interfaces (Switch – Switch oder Rechner – Switch) müssen mit gleichen LACP-Parametern konfiguriert sein, da sich die beiden Interfaces gegenseitig erkennen müssen; es werden in bestimmten Intervallen LACP-Data-Units ausgetauscht (meist 100 ms), um den Link-Status zu überprüfen. Ein wichtiger Parameter in der LACP-Konfiguration ist der Load-Balancing-Algorithmus, der die Verteilung der Rahmen über die physikalischen Leitungen (Link) regelt. Der einfachste Algorithmus berücksichtigt nur die Quell-/Ziel-MAC-Adressen (oder auch IP-Adressen). Hierbei wird folgende Berechnung beim sendenden Rechner durchgeführt: (Quell-MAC XOR Ziel-MAC) mod n mit n als Anzahl der physikalischen Links, wobei statt der kompletten MAC-Adresse oft nur die linken x Bit verwendet werden.  23 Beispiel: mit Quell-MAC (binär): 011, Ziel-MAC: 101 und n=4: 011 xor 101 = 110 (dez. 6) und: 6 mod 4 = 2 Es wird in diesem Beispiel immer der Link Nr. 2 genutzt. Allerdings wird hierbei für eine bestimmte Adresskombination immer der gleiche Link verwendet. Sendet bspw. Rechner R2 Rahmen an R1, so wird auch bei mehreren parallelen TCP-Verbindungen zwischen diesen beiden Rechnern grundsätzlich immer nur einer der Links der virtuellen Trunk Line verwendet. Mehrere Links gleichzeitig werden also nur bei parallelen Verbindungen zwischen unterschiedlichen Rechnern genutzt. Besser ist die Verwendung von Informationen aus höheren Protokollschichten wie TCP-Ports (Layer3+4) als Load- Balancing-Algorithmus. Berechnung mit: (Quell-Port XOR Ziel-Port) XOR (Quell-IP XOR Ziel-IP) mod n Baut R2 gleichzeitig zwei TCP-Verbindungen zum Webserver von R1 auf, sind zwar die beiden IP-Adressen und der Ziel-Port gleich, aber nicht der zufällig gewählte Quell-Port, sodass unterschiedliche Links verwendet werden können (allerdings nicht müssen). Problematisch kann dieses Load-Balancing bei fragmentierten IP-Paketen werden, da die Port-Nummer nur im ersten aber nicht in den folgenden Fragmenten steht, sodass fragmentierte und nicht- fragmentierte Pakete einer TCP-Verbindung unterschiedliche Links verwenden und damit die Wahrscheinlichkeit einer falschen Reihenfolge der IP-Pakete steigt (dadurch z.B. unnötige Aktivierung von TCP-Stauvermeidungs- Strategien). LACP ist nicht zu verwechseln mit einfachen Bonding-Verfahren beim Senden von Paketen. Rechner R1 könnte z.B. zwei oder mehr Links in Sende-Richtung gleichzeitig z.B. über eine einfache Round-Robin-Verteilung bedienen. Würde die Trunk Line zwischen Switch A und B eine Übertragungsrate von 10 Gbps haben und auch R2 mit dieser Technik angeschlossen sein, so könnte R1 auch ohne LACP am Switch mit 2 Gbps an R2 senden (aber nicht selbst empfangen). Es können auch mehrere Leitungen an verschiedene Switches angeschlossen werden, um eine technische Ausfallsicherheit bzw. Redundanz bzgl. der Links zu schaffen; hierbei wird das Bonding entweder so konfiguriert, dass nur einer der Links aktiv genutzt wird und der andere Link lediglich beim Ausfall des ersteren aktiviert wird, oder alle Pakete werden über alle Links verteilt (Broadcast-Modus, Achtung: großer Overhead). 1.7 Address Resolution Protokoll ARP Ein Rechner bzw. ein Anwendungsprotokoll baut eine Verbindung zu einem Zielrechner i.d.R. anhand der Ziel-IP- Adresse auf. Diese Adressierung auf der Vermittlungsschicht (Schicht 3) ist auf der Sicherungsschicht allerdings nicht bekannt, hier werden die MAC-Adressen verwendet. Bei der Übergabe eines IP-Paketes an die Vermittlungs- schicht, muss daher die MAC-Adresse des Ziels bekannt sein, sodass beim sendenden Rechner bereits vor dem senden eines Paketes eine Verknüpfung bzw. Zuordnung von IP- zu MAC-Adressen vorhanden sein muss. Diese Zuordnung kann manuell mittels einer statischen Adresstabelle vorgenommen werden oder dynamisch mithilfe des Address Resolution Protokolls ARP. Es ist zunächst zu unterscheiden, ob das Ziel im eigenen Subnetz (LAN) des Senders liegt oder nicht. Ist dies der Fall, so wird die zur IP-Adresse gehörige MAC-Adresse des Ziels aus der Adresstabelle (ARP-Cache) entnommen und kann somit bei der Erstellung des Ethernet-Frame-Headers als Ziel-MAC-Adresse eingetragen werden. Liegt die IP- Adresse des Ziels jedoch außerhalb des eigenen Subnetz-Bereiches, so wird der Datenrahmen an die MAC-Adresse des Standard-Routers geschickt. Dessen IP-Adresse muss in der Netzwerk-Konfiguration eines Rechners bekannt sein (sog. Default-Gateway). Die manuelle Pflege einer Adresstabelle ist sehr aufwändig und fehleranfällig, sodass üblicherweise das dynamische ARP-Protokoll zum Einsatz kommt. Möchte der Sender ein IP-Paket abschicken und kennt die zugehörige MAC- Adresse (entweder Ziel-Rechner oder Router) noch nicht, wird zunächst ein ARP-Request an die MAC-Broadcast- Adresse geschickt. Das Format diese Anfrage ist in Abbildung 18 dargestellt. Die Standardwerte sind: Hardware „Ethernet“, Protocol „IPv4“, Hardware-Size (hier Länge der MAC-Adresse) 6, Protocol-Size (Länge der IP-Adresse) 4, Op-Code entweder „Request“ oder „Reply“, danach folgen die beiden eigenen Adressen des Senders und die beiden Adressen des Ziels. Beim ARP-Request ist die MAC-Target-Adresse des Ziels leer (Null), also noch unbekannt. Zu beachten ist, dass bereits beim ARP-Request die eigene Adress- Kombination mitgeteilt wird, obwohl niemand danach gefragt hatte. Dies ist einerseits effizient, da praktisch immer der andere Rechner Daten zurückschicken wird und damit ebenfalls die Adress-Kombination benötigt, andererseits besteht dadurch das Risiko von ARP-Spoofing-Angriffen. Hierbei können mit gefälschten Adress- Kombinationen Datenströme im LAN umgeleitet werden. Ein ARP-Request wird per MAC-Broadcast-Adresse an alle Rechner im LAN geschickt, woraufhin nur der Besitzer der angefragten IP-Adresse ein ARP-Reply gezielt an die MAC-Adresse des anfragenden Rechners zurückgeschickt. 24 Hardware-Type (2 Byte) Protocol-Type (2) Hardware-Size (1) Protocol-Size (1) Op-Code (2) Sender MAC-Address (erste 4 Byte) Sender MAC-Address (letzte 2 Byte) Sender IP-Address (erste 2 Byte) Sender IP-Address (letzte 2 Byte) Target MAC-Address (erste 2 Byte) Target MAC-Address (letzte 4 Byte) Target IP-Address (4) Abbildung 18: ARP-Header Video in der Mediathek (Channel NWA): ARP (Address Resolution Protocol) Video in Moodle (alt): arp.mp4 1.8 Address Resolution bei IPv6 Das Internet-Protokoll IPv6 nutzt nicht ARP für die dynamische Zuordnung von MAC- und IPv6-Adressen sondern verwendet verschiedene ICMPv6-Typen. An dieser Stelle sei nur der einfache Fall einer gezielten Abfrage einer MAC-Adresse im Netzwerk betrachtet. Der fragende Rechner schickt eine ICMPv6-Neighbor-Solicitation an den anderen Rechner im lokalen Netz, um dessen MAC-Adresse gezielt herauszufinden (analog ARP). Als Ziel-Adresse wird die Solicited-Node-Multicast- Adresse des Ziels verwendet: FF02::1:FF. Die MAC-Zieladresse dieses Rahmens ist die ICMPv6-MAC-Multicast-Adresse: 33:33:FF:. Entsprechend ARP ist auch hier die MAC-Adresse des fragenden Rechners bereits enthalten (die IPv6-Adresse des fragenden Rechners wird dem IPv6-Header entnommen). Als Antwort darauf schickt der angesprochene Rechner ein ICMPv6-Neighbor-Advertisement zurück (direkt an die Adresse des fragenden Rechners) mit seiner eigenen MAC-Adresse. 1.9 MTU Path Discovery Die Maximum Transmission Unit MTU beträgt im normalen Ethernet 1500 Byte. Da die MTU hardware-abhängig ist, kann ein Rechner direkt nur die MTU des eigenen LANs ermitteln. Wird bspw. ein TCP-Paket mit einer größeren Maximum Segment Size MSS als 1460 bzw. 1440 Byte Nutzdateninhalt abgeschickt (bei MTU 1500 Byte und 20 IPv4-Header bzw. 40 Byte IPv6-Header sowie 20 Byte TCP-Header) und trifft dieses Paket auf seinem Weg zum Ziel auf ein Netzwerk mit geringerer MTU, so kann es nur weitergeleitet werden, wenn es fragmentiert wird. Diese Fragmentierung durch Router auf dem Pfad ist bei IPv4-Paketen möglich, bei IPv6 jedoch nicht. Hier gibt es nur den Fragmentation Extension Header, der ausschließlich eine Fragmentierung durch den Quell-Rechner erlaubt. Daher ist IPv6 auf ein funktionierendes MTU Path Discovery angewiesen: ein sendender Rechner muss eine Information bekommen können, dass ein Netzwerk auf dem Pfad nur eine geringere MTU hat. Hierzu dient der ICMPv6-Typ 2 (Packet too big), der an den Quellrechner von demjenigen Router zurückgeschickt wird, der den Anschluss an das Netzwerk mit der geringeren MTU hat. Nun fragmentiert der Quellrechner alle folgenden Pakete mit derjenigen maximalen MTU, die in dem ICMPv6-Paket übermittelt wurde. Dieser Wert wird für ca. 10 Minuten im lokalen Kernel-Routing-Cache gespeichert. Die minimale erlaubte MTU bei IPv6 beträgt 1280 Byte, bei kleinerer MTU ist ein Netzwerk nicht IPv6-fähig. Ein Routingprotokoll wie beispielsweise RIPng würde in diesem Fall eine Ungültig-Meldung (Metrik 16) verschicken.  25 2 Vermittlungsschicht 2.1 Einleitung Die Vermittlungsschicht wird im Bachelorstudium Media Systems bereits im 2. Semester (Modul Informatik B, Netzwerk-Grundlagen) einschließlich der Themen IPv4- und IPv6-Protokoll, IP-Adressierung, Netzwerkmasken sowie Routing-Algorithmen und Routing-Verfahren behandelt und wird daher in diesem Skript nur der Vollständigkeit halber in kurzer Form dargestellt. 2.2 IPv4-Protokoll IPv4-Header 0 31 Version IHL ToS/DiffServ Total Length Identification Flags Fragmentation Offset TTL Protocol Header Checksum Source Address Destination Address Optionen... Header-Felder: Version: IPv4 (4 Bit) IHL (4): IP Header Length, Länge des (variablen) Headers als Anzahl der 32-Bit-Worte, Standard (ohne Optionen) 20 Byte (fünf 32-Bit-Worte), ToS (8): Type of Service (alte Bezeichnung) oder Differentiated Services-Feld zur Definition von Dienstklassen (Expedited und Assured Forwarding) sowie einige Bits für ECN (Explicit Congestion Notification, Stauvermeidung) Total Length (16): Gesamtlänge einschließlich Header und Payload, max. 65535 Byte Identification (16): Zugehörigkeit von Fragmenten zu einem IP-Paket Flags (3 Bit): mittleres Bit: Don‘t Fragment (keine Fragmentierung erlaubt), rechtes Bit: More Fragment (ist bei allen Fragmenten eines Paketes außer dem letzten gesetzt, um festzustellen, wann alle Fragmente eingetroffen sind) Fragmentation Offset (13): Position eines Fragments im Paket TTL (8): Time to Live (Zähler für die Lebensdauer eines Paketes, der bei jedem Router um 1 verringert wird; derjenige Router, der die TTL auf Null setzt, verwirft das Paket und schickt eine Fehlermeldung) Protocol (8): Protokoll im Payload (Transportprotokolle TCP (6), UDP (17) oder Art des Routingprotokolls oder ICMP (1)) Header Checksum (16): Prüfsumme nur für den Header Adressen: 32-Bit IPv4-Quell- und Zieladresse 2.3