LUG Erding
Hier ist der Überblick über die einzelnen Passagen:
Das OSI (Open Systems Interconnect) Modell ist das Referenzmodell für Netzwerkimplementationen. Das besondere daran ist, dass es fast niemand wirklich implementiert hat. Es wurde hauptsächlich von Europa und Japan als Standard forciert um ein Gegengewicht zu dem US-dominierten TCP/IP zu etablieren.
Das Modell schreibt 7 Netzwerkschichten vor die alle voneinander unabhängig sind, d.h. jede Schicht kommuniziert nur mit sich selbst. Jede Schicht hängt natürlich von der funktionierenden Schicht darunter ab.
Die 7 Schichten sind:
Dieses Schema stellt die Verschachtelung der Protokolle bei TCP/IP dar:
+-----------------+--------------------------------------+-----+
| Ethernet-Header | Payload | END |
+-----------------+--------------------------------------+-----+
^ ^
| |
+-------------+------------------------+
| IP-Header | Payload |
+-------------+------------------------+
^ ^
| |
+-------------+----------+
| TCP-Header | Payload |
+-------------+----------+
^ ^
| |
+----------+
| App-Data |
+----------+
Die Applikationsdaten sind die Nutzdaten (Payload) des TCP-Protokolls, das komplette TCP-Paket ist die Payload des IP-Paketes. Letzteres ist wiederum die Payload des Ethernet-Paketes.
Auf diese Weise müssen die höheren Protokolle keine Informationen über die darunterliegenden haben. Dies macht es einfach einzelne Protokolle auszutauschen.
Gerade bei Ethernet wird es deutlich, hier kann dann z.B. problemlos ein Token-Ring oder FDDI-Protokoll verwendet werden ohne das sich an den Schichten darüber etwas wesentlich ändert. Die mögliche Größe der eigentlichen Pakete ist natürlich vom untersten Paket bestimmt, siehe MTU bzw. MSS weiter unten.
Standard-Ethernet (10 Mbit/s), Fast-Ethernet (100 Mbit/s) und Gigabit-Ethernet (1000 Mbit/s) verwenden alle das gleiche Zugriffsverfahren. Daher ist es auch sehr beliebt, es ändert sich im wesentlichen nicht viel wenn zu schnelleren Topologien gewechselt wird.
Dieser Standard ist vom Institute of Electrical and Electronic Engineers (IEEE, eine Art VDI) als IEEE 802.3 festgelegt. Eine Besonderheit ist die Nutzung des Mediums durch viele Stationen. Will eine Station Daten übertragen, so prüft sie zuerst ob der Datenkanal auch frei ist (Carrier Sense, CS). Ist dies der Fall so beginnt die Station mit dem Senden der Daten und überwacht gleichzeitig das Kabel. Da mehrere Systeme Zugang zum Kabel haben (Multiple Access, MA) kann es passieren, dass zwei Stationen gleichzeitig senden, es kommt zu Kollisionen. Werden solche festgestellt (Collision Detection, CD), so senden die beteiligten Systeme ein Jam Signal über das Kabel um andere Geräte über das Problem zu informieren. Anschließend wird via Zufallsgenerator bestimmter Zeitintervall gewartet bevor beide Stationen wieder senden dürfen. Zuvor findet dann natürlich wieder ein CS statt.
Das gesamte Verfahren wird folglich CSMA/CD genannt.
Ein wichtiger Begriff aus diesem Umfeld ist die Collision Domain, dieser beschreibt alle Geräte die am gleichen Kabel Kollisionen herbeiführen bzw. davon betroffen sein können.
Da mehrere Geschwindigkeiten und Modi bei Ethernet möglich sind gibt es auch eine Möglichkeit die bestmögliche Vernetzung anhand er eigenen Möglichkeiten auszuhandeln:
Autonegotiation
Leider funktioniert dieses Verfahren nicht immer so gut wie es sollte, insbesondere wenn die Gegenstelle es nicht unterstützt. Hinzu kommt das Problem, dass hier nur aktive Geräte miteinander kommunizieren. Der kleinste gemeinsame Nenner sind 10 MBit/s. Daher werden die Parameter mit dieser Geschwindigkeit beim Anschluss/Aktivieren eines Teilnehmers ausgehandelt. Dabei kann z.B. keine Aussage über die Qualität der Verkabelung getroffen werden!
Aufgrund von Idle-Signalen können die Ethernetkarten aber herausfinden ob 10 MBit/s oder 100 MBit/s verwendet werden. Was jedoch zu Problemen führen kann sind unterschiedliche Modi: Half-Duplex und Full-Duplex. Dies ist eine häufige Ursache für Netzwerkprobleme die nur unter Last auftreten.
Aber zuerst zu den Modi:
Bei Half-Duplex kann immer nur ein Gerät senden und kommt immer dann zum Einsatz wenn mehrere Geräte sich ein Kabel teilen.
Full-Duplex hingegen kann immer nur zwischen zwei Stationen stattfinden. Bei Twisted Pair (TP) Verkabelung wird ein Adernpaar für das Senden, das andere für das Empfangen von Daten verwendet. Dadurch ist das parallele Senden und Empfangen hier möglich. Da hier keine Kollisionen entstehen können wird auch keine Collision Detection durchgeführt!
Twisted pair Kabel bestehen jeweils aus zwei verdrillten Adern in einem Kabel. Diese gibt es in verschiedener Güte die als Category, bzw. kurz Cat bezeichnet wird:
Es gibt noch neuere Standards wie Cat 5e (enhanced, verbessert), Cat 6 und Cat 7. Diese unterliegen strengeren Grenzwerten und sind häufig abgeschirmte Kabel.
Bridges sind Geräte die eine Collision Domain in zwei unabhängige aufspaltet, d.h. diese zwei Netze liegen innerhalb eines IP-Netzes.
Repeater sind Geräte, die einfach nur das Signal wiederholen, d.h. sie empfangen auf der einen Seite Signale und senden diese auf der anderen Seite verstärkt weiter. Dadurch können Kabel verlängert werden.
Ein Hub ist streng genommen nur ein Verteiler, alle Daten werden an alle Stationen weitergeleitet, d.h. an der Collision Domain ändert sich nichts.
Ein Switching Hub oder kurz Switch genannt verteilt die Daten nur an die Geräte für die die Daten auch bestimmt sind. In diesem Fall kommuniziert jedes Gerät nur mit dem Switch, dieser nimmt die Daten entgegen, puffert, englisch buffert, Sie und sendet diese anschließend an den Empfänger weiter.
Mit einem Switch ist Full-Duplex Betrieb möglich, ein Empfänger sieht dann im wesentlichen nur Traffic der auch für ihn bestimmt ist. Zu der Funktionsweise eines Switches und dem im wesentlichen kommen wir später beim Ethernet-Protokoll bzw. bei den MAC-Adressen.
Die Typenbezeichnung ist meist recht einfach, die erste Zahl gibt die Übertragungsrate an, danach folgt gewöhnlich BASE für baseband, das ist das Gegenteil von broadband, d.h. Ethernet wird direkt über das Kabel gesprochen, es findet keine Modulation statt. Dabei existiert nur ein Übertragungskanal.
Das letzte Kürzel gibt dann entweder das Medium an oder die mögliche Kabellänge. Bei TP-Kabeln liegt diese immer bei 100 Metern.
Hier sind nur die häufigsten bzw. wichtigsten Typen aufgeführt.
10 Mbit/s
--------
10BASE5 : Dickes Koaxial-Kabel, meistens gelb isoliert, daher wird
es oft auch Yellow Cable genannt, 10 MBit/s, 500m Länge
10BASE2 : Dünnes Koaxial-Kabel, daher auch Thin Ethernet oder
Cheapernet genannt, 185m
10BASE-T: Twisted-pair Kabel (Cat 3), 100m
10BASE-F: Fiber optic, Glasfaser
Beim Yellow Cable wurden die Stationen über sogenannte transceiver taps (MAU, media attachment unit) und Vampirklammern direkt angeschlossen, d. h. die Isolierung wurde hier durchbohrt. Vom Transceiver ging ein Transceiver Kabel zum AUI (attachment unit interface) der Ethernetkarte. Der Transceiver übersetzt dabei das Signal in ein anderes Format, so dass es über das 15-polige AUI gelesen werden kann.
Bei 100 MBit/s gibt es einen ähnlichen Konstrukt, hier heißt das dann MII, media independent interface. Dies ist dann zwar ein separates Gerät, es befindet sich aber in der Regel bereits auf der Ethernetkarte.
Beim Thin Ethernet werden die einzelnen Ethernetkarten über sogenannte T-Stücke direkt an das Koaxialkabel angeschlossen. Hier muss das Kabel aber unterbrochen werden um ein T-Stück einzubauen. Diese werden über BNC-Anschlüsse realisiert. Dies ist eine einfache und preiswerte Art der Verkabelung, daher auch der Name Cheapernet. Allerdings war diese Art der Verkabelung auch recht fehleranfällig da eine Unterbrechung des Kabels, davon gab es aufgrund der T-Stücke viele Möglichkeiten, das gesamte Netzsegment gestört ist.
Beide Kabelarten werden als Strang verwendet mit Terminatoren an beiden Enden um Signalreflexionen zu vermeiden. Die Kabellängen sind im wesentlichen durch Paketlaufzeiten oder der Dämpfung des Kabels bestimmt.
Anhand dieser wohl heute nur noch selten verwendeten Technik wird aber schnell deutlich was CSMA/CD bedeutet und warum hier nur Half-Duplex funkioniert.
Die TP Verkabelung erlaubt eigentlich nur die Verbindung zweier Geräte. Für mehr wird ein Hub oder Switch benötigt und das Ergebnis ist dann eine sternförmige Verkabelung.
100 MBit/s --------- 100BASE-T : Allgemeine Abkürzung für 100 MBit/s 100BASE-X : Abkürzung für 100 MBit/s twisted pair oder Glasfaser 100BASE-TX: 100 MBit/s über 2 Paar Cat 5 twisted pair Kabeladern 100BASE-FX: 100 MBit/s über Multi-mode Glasfaser 100BASE-T4: 100 MBit/s über 4 Paar Cat 3 twisted pair Kabeladern
Hier ist eigentlich nicht viel anders als bei 10 MBit/s, im wesentlichen kommen hier nur noch TP Kabel zum Einsatz. Die Glasfaser Varianten sind eigentlich analog zu TP, es ist nur eine andere Art von Kabel.
Dadurch, dass 2 Paar Kabeladern für die Übertragung verwendet werden kann ein Paar für das Senden und eines für das Empfangen zum Einsatz kommen. Dies kann also zeitgleich und parallel erfolgen, was wiederum zahlreiche Händler auf die Idee brachte Werbung mit Geschwindigkeiten von 200 MBit/s zu machen. 100 MBit/s senden, 100 MBit/s empfangen, das macht dann wohl 200 MBit/s.
Die GBit/s oder gar 10 GBit/s spare ich mir hier, diese sollten wohl bei den meisten nicht zum Einsatz kommen und machen derzeit nur in Firmenbackbones Sinn. Ein Backbone ist das Rückgrat eines Netzwerkes. Es verbindet in der Regel verschiedene Abteilungen entweder untereinander oder mit den zentralen Servern, so dass entsprechend viel Datenaufkommen hierfür auftreten kann und von daher meist der schnellste Netzwerkbereich sein sollte.
Das einzige Bemerkenswerte ist, dass es diesen Standart überhaupt gibt. Da Ethernet aber sehr weit verbreitet ist und damit auch das Wissen darüber, war es leichter dies zu etablieren als andere Protokolle/Verfahren die effektiver und preiswerter waren. Aber mittlerweile ist auch Gigabit-Ethernet via Kupfer im bezahlbaren Rahmen.
Der Aufbau ist nicht sonderlich kompliziert. Allerdings gibt es zwei verschiedene Standards, DIX (Digital, Intel, Xerox) und vom IEEE. Der Unterschied lag eigentlich nur im Typ-Feld, hier hatte IEEE die Länge des Ethernetpaketes notiert, DIX aber den Typ des darüberliegenden, eingebetteten, Protokolls.
Die Typen fangen bei hexadezimal 0x600 an. Die Maximalgröße eines Frames (Ethernetpaketes) ist 1500 Bytes = 0x5DC und liegt damit deutlich unterhalb der Protokollnummern. Dadurch war die Verwendung beider Typen parallel möglich. Aber mittlerweile hat die IEEE ihr Protokoll angepasst, sie verwenden nun auch den Typen des höheren Protokolls an dieser Stelle.
Für die verschiedenen Protokolle siehe http://www.iana.org/assignments/ethernet-numbers
Der Aufbau ist nun:
+---------+---------+---------+---------------------------------+ | 64 Bit | 48 Bits | 48 Bits | 16 Bits | 46-1500 Bytes |32 Bits| +---------+---------+---------+---------+---------------+-------+ |Präambel | Dst-MAC | Src-MAC | Typ | DATA | FCS | +---------+---------+---------+---------+---------------+-------+
Als erstes kommt ein 64-Bit Präambel, dies ist nur als Einschwingvorgang für Netzwerkkarten gedacht damit sie zu einem stabilen Signal kommen. Dieses Präambel selber tritt eigentlich nie in Erscheinung und kann auch mit Programmen wie tcpdump nicht ausgelesen werden.
Danach folgt die Ziel-MAC-Adresse (destination). MAC ist der Media Access Code und ist normalerweise mit der Ethernetkarte verknüpft. Diese identifiziert den Absender des Paketes eindeutig. Anschließend folgt die MAC-Adresse des Absenders (source, Quelle). Diese Adressen bestehen aus jeweils 6 Bytes.
Der nachfolgende Typ ist bei Ethernet 0x800 bzw. für das Address Resolution Protocol (ARP) 0x806. ARP dient dem Finden einer MAC-Adresse wenn nur die IP-Adresse bekannt ist, dazu später mehr.
Die eigentliche Payload muss eine Mindestlänge von 46 Bytes haben. Zusammen mit dem Ethernet-Header und -Tail ergibt dies eine Mindestgröße des Paketes von 64 Bytes.) Die Maximalgröße wird als Maximum Transfer Unit (MTU) bezeichnet und ist bei Ethernet immer 1500 Bytes. Bei Gigabit Ethernet gibt es sogenannte Jumbo-Frames mit einer MTU von 9000 Bytes. Aber das sparen wir uns hier einmal aus.
Den Abschluss bildet der Frame Sequence Check (FCS). Das ist lediglich eine CRC, Cyclic Redundancy Checksum, über das gesamte Ethernetpaket und ermöglicht die Integrität des Paketes sicherzustellen.
Für die MAC-Adressen gilt:
Sie werden gewöhnlich in Hexadezimaldarstellung, getrennt durch Doppelpunkte dargestellt, z.B.: 00:E0:4C:00:82:9F
Die ersten drei Paare bezeichnen den Hersteller, z.B.: 00:A0:C9 entspricht Intel, die anderen Bytes identifizieren die Karte bezüglich des Herstellers eindeutig. Allerdings gibt es mittlerweile mehrere Herstelleradressen für einen Hersteller und ältere Nummern werden langsam recycled. Wobei z.B. die 1 MBit/s Adressen heute wohl noch schwerlich anzutreffen sein dürften.
Es gibt Broadcast-Adressen auf Ethernet-Ebene: FF:FF:FF:FF:FF:FF Pakete mit dieser Ziel-Adresse sind für alle angeschlossenen Stationen bestimmt.
Ferner existieren auch Multicast-Adressen auf Ethernet-Ebene. Diese sind herstellerunabhängig und ebenfalls dokumentiert, siehe oben.
Zur Begriffserklärung:
Im Detail, da das vermutlich gelegentlich noch auftritt:
Ein Broadcast ist ein Senden an alle Stationen. Zum Beispiel vergleichbar mit einer Megafon-Durchsage, jeder bekommt es mit.
Ein Multicast ist ein Senden an mehrere Stationen. Vergleichbar mit dem Radio, jeder kann es hören, muss es aber nicht. Durch Einschalten des richtigen Radiosenders kann an einem bestimmten Multicast teilgenommen werden. Analog zu verschiedenen Radiosendern gibt es auch verschiedene Multicasts.
Ein Unicast ist der Normalfall einer Kommunikation, zwei und nur zwei Geräte kommunizieren miteinander. Das ist so normal, dass es eigentlich niemand separat aufführt.
Ein Anycast wären bei Ethernet zwei Netzwerkkarten mit der gleichen MAC Adresse, also eine Adresse mehrfach vergeben. Diese gibt es auf Ethernet-Ebene nicht, wohl aber auf IP-Ebene. Zum Beispiel ist ein Root-DNS Server in den USA und in Frankfurt mit der gleichen IP-Adresse erreichbar. Die ISP's, Internet Service Provider, routen einen immer zu der nahegelegensten Adresse.
Mit CARP, Common Address Redundancy Protocol, eine Variante des VRRP, Virtual Router Redundency Protocol RFC 2338/3768, letzteres kollidiert mit einem Cisco-Patent, geht dies auch. Hier bekommen zwei Server eine gemeinsame virtuelle IP-Adresse und virtuelle MAC-Adresse. Wenn ein Server ausfällt, so springt automatisch der andere in die entstandene Lücke und übernimmt die Dienste. Da sich hierbei weder die IP-Adresse noch die MAC-Adresse ändert ist das eigentlich eine feine Sache. Eine Linux-Version dieses Protokolls gibt es auch unter http://www.ucarp.org/
Da jetzt die MAC-Adressen ins Spiel gekommen sind: Diese werden von Switchen ausgewertet um zu entscheiden welche Pakete an welchen Anschluss gesendet werden müssen.
Dazu protokolliert der Switch intern mit welche Absende MAC-Adresse er auf welchem Interface Daten empfangen hat. Tritt diese Adresse irgendwo als Ziel auf, so weiß der Switch das passende Interface. Dafür haben die Switche intern einen Puffer in dem diese Adressen und Ports (also Interfaces) gespeichert werden.
Wenn das Ziel nicht im Puffer steht, so wird das Paket an alle Interfaces weitergereicht, gleiches gilt für Broadcasts und Multicasts. Wenn der entsprechende Kommunikationspartner antwortet, so wird dieser dann im Puffer vermerkt und die Kommunikation kann nun nur noch zwischen den beiden Ports erfolgen.
Zum Thema Netzwerksicherheit durch Switches:
Das Kommando ifconfig liefert u.a. die MAC-Adresse (HWaddr), die MTU, Maximum Transfer Unit sowie Statistik der Netzwerkkarte. Letzteres ist aber linuxspezifisch, andere Unix-Systeme geben diese nicht bei ifconfig aus. Zusätzlich werden auch IP-Adresse, Netzmaske und Broadcast-Adresse ausgegeben, siehe dazu das nächstes Kapitel.
majestix:~$ /sbin/ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:E0:4C:00:82:9F
inet addr:192.168.1.5 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2269963 errors:7 dropped:0 overruns:0 frame:0
TX packets:3413912 errors:0 dropped:0 overruns:37 carrier:0
collisions:0 txqueuelen:1000
RX bytes:831160951 (792.6 MiB) TX bytes:3750140940 (3.4 GiB)
Interrupt:10 Base address:0x4000
In diesem Fall ist die MAC-Adresse 00:E0:4C:00:82:9F, die MTU ist für Ethernet typische 1500 Bytes. Die Ethernet-Karte reagiert ist aktiv (UP), antwortet auf Broadcasts (BROADCAST) und Multicasts (MULTICAST)
Zu den Statistiken siehe: netstat
Sofern es von der Karte unterstützt wird gibt mii-tool die ausgehandelte bzw. eingestellten Übertragungsparameter aus:
dg4:~# /sbin/mii-tool eth0 eth0: negotiated 100baseTx-FD, link ok
In diesem Fall ist die Geschwindigkeit 100 MBit/s ausgehandelt (negotiated) worden, es wird Full-Duplex (FD) verwendet und der Link-Status ist ok, d.h. ein Kabel ist angeschlossen und ein Signal ist verfügbar.
Mit den Optionen -F (für force, erzwingen) bzw. -A (advertise, anbieten) können die Parameter entweder fest eingestellt werden oder die für das Autonegotitation bestimmten Werte festgelegt werden.
Unterstützt die Karte nicht die Verwendung von mii-tool, so kann nur auf die Ausgabe des Kernels bezüglich der Ethernetkartenparameter zurückgegriffen werden. Der Befehl dmesg liest den Ringpuffer der Kernel-Meldungen aus. Da dies ein Ringpuffer ist werden diese Angaben mit der Zeit überschrieben. Die Werte werden aber nur bei der Aktivierung oder Statusänderung der Karte ausgegeben, also in der Regel wenn Autonegotiation stattfindet oder ein Link-Signal erkannt wird:
dg4:~# dmesg |grep eth0 eth0: VIA Rhine II at 0xdffff700, 00:a0:cc:d8:ac:17, IRQ 9. eth0: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 0000. eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
Mit der Option -ni (-n für numerische Ausgabe ) werden die Statistiken der Interfaces ausgegeben. Diese kann bei Linux auch via ifconfig erhalten werden. Allgemeingültig bei allen Unix-Systemen ist aber netstat -ni.
Hier werden Eigenschaften des Interfaces (MTU, Flags) sowie die Zahl der übertragenen bzw. empfangenen Pakete, entdeckte Kollisionen oder verlorene Pakete sowie I/O Fehler ausgegeben:
majestix:~$ netstat -ni Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 2269963 7 0 0 3413912 0 0 37 BMRU eth1 1500 0 1550888 0 0 0 1634116 0 0 0 BMRU lo 16436 0 813476 0 0 0 813476 0 0 0 LRU
ERR-Pakete sollten eigentlich nie auftreten, falls doch dann sollten diese niemals zunehmen! Fehler können beim Aktivieren der Karte oder Verkabeln im laufenden Betrieb entstehen.
Gibt es dennoch eine zunehmende Zahl von RX-ERR oder TX-ERR (R: receive, empfangene Pakete, T: transmit, gesendete Pakete) so ist entweder an der Verkabelung etwas verkehrt oder eine Station arbeitet falsch. Oft ist dies der Fall wenn eine Station im Half-Duplex Modus und die andere im Full-Duplex Modus läuft.
Da es bei Full-Duplex per Definition keine Kollisionen geben kann, so wird hier auch nicht auf solche geachtet. Kollisionen können nur am Anfang einer Übertragung auftreten wenn zwei Stationen gleichzeitig senden. Da vorher geprüft wird ob das Kabel frei ist, kann es zu einem späteren Zeitpunkt keine Kollisionen mehr geben. Bei Full-Duplex entfällt diese Prüfung und es wird gesendet, sobald Daten übertragen werden müssen.
OVR (Overruns, Überläufe) treten auf, wenn die Pakete nicht schnell genug vom Kernel bei der Karte abgeholt werden können. Das System ist einfach überlastet oder überfordert. Ältere PC's mit Gigabit Ethernet dürften dafür prädestiniert sein. Der klassische PCI-Bus ist nicht in der Lage 1 GBit/s zum Prozessor zu befördern.
Eine ganze andere Frage wäre auch was ein solcher Prozessor mit soviel Daten tun sollte sofern es kein Serversystem ist.
DRP (drop, "fallenlassen") ist der umgekehrte Fall, die Karte kann die Daten nicht schnell genug ausliefern.
Das Protokoll ist in RFC 791 definiert, erweitert wurde es in RFC 1122. Es stellt ein Adressierschema bereit: die IP-Adressen. Das Protokoll ist ferner eine Abstraktionsschicht oberhalb des physikalischen Netzwerkes, d.h. es ist unabhängig von dem darunterliegenden Netzwerk, sei es Ethernet, DSL, Token-Ring oder FDDI.
Der Linux-Kernel stellt die Daten entweder lokal zu oder leitet sie zu einem Router weiter. Hier kommen die Netzmasken ins Spiel, diese werden dazu verwendet um festzustellen ob ein IP-Paket lokal zugestellt werden kann oder ob die Routing-Tabelle befragt werden muss.
Ferner verwendet der Kernel die Netzmaske um die Broadcast-Adressen zu bestimmen. Ansonsten werden Netzmasken im Internet Protocol überhaupt nicht verwendet, sie kommen im IP-Header auch nicht vor.
IP garantiert keinerlei Integrität oder Zustellung der Pakete, es gewährleistet lediglich die Zustellung zum nächsten Anlaufpunk, Hop, d.h. in der Regel einem Router oder eine direkt angeschlossene Station. Es wird also weder ein Weg für die einzelnen Pakete vorgegeben noch bestimmt. Es ist jeweils Aufgabe des nächsten Routers den nächsten Hop zu ermitteln.
Daher kann auch keine korrekte Reihenfolge oder Eindeutigkeit der Pakete garantiert werden. Diese können durchaus in unterschiedlicher Reihenfolge eintreffen oder das gleiche IP Paket sogar mehrfach.
Für die richtige Reihenfolge und Integrität der Daten sind, soweit erforderlich, die höheren Protokolle zuständig.
Der IP-Header kann 20-40 Bytes groß sein. Die oberen Zahlen stellen das jeweilige Bit pro Word (32 Bit) dar.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------+-------+---------------+-------------------------------+ |Version| IHL |Type of Service| Total Length | +-------+-------+---------------+-----+-------------------------+ | Identification |Flags| Fragment Offset | +---------------+---------------+-----+-------------------------+ | Time to Live | Protocol | Header Checksum | +---------------+---------------+-------------------------------+ | Source Address | +---------------------------------------------------------------+ | Destination Address | +-----------------------------------------------+---------------+ | Options | Padding | +-----------------------------------------------+---------------+
Die ersten 4 Bits geben die Version des Protokolls wieder. Dies ist derzeit Version 4. Die nächsten 4 Bytes bestimmend die Länge des IP-Headers in Vielfachen von 32 Bits. Minimal sind dies 20 Bytes, also 5*4. Größer wird der IP-Header nur durch Verwendung von Optionen. Diese sollten aber normalerweise nicht in Gebrauch sein.
Da die Daten meist hexadezimal dargestellt werden kann man einen Beginn des IP-Headers gewöhnlich an der 45 (hexadezimal!) erkennen.
Das folgende Byte bestimmt den Type of Service, ToS des Paketes (auch Datagramm genannt). Die Priorität wird über die ersten 3 Bits bestimmt mit Werten von 0 (normal) bis 7 (höchste Priorität). Dies wird heute aber eigentlich nicht mehr so verwendet. Die nächsten 4 Bits dienen einer Einstufung nach Kategorien von maximaler Zuverlässigkeit, minimaler Kosten oder maximaler Sicherheit. Das letzte Bit des Bytes ist reserviert. Heute wird dieses Byte oft als Quality of Servive, QoS interpretiert und verwendet.
Die letzten 2 Bytes des ersten Wortes gibt die Gesamtgröße des Datagramms inklusive IP-Header in Bytes wieder. Das ergibt ein Maximum von 64 kB.
Identification ist eine eindeutige Nummer des IP-Datagramms. Diese ist wichtig wenn das Paket auf dem Weg zum Ziel fragmentiert, also in kleinere Datagramme zerlegt werden muss, z.B. weil die MTU auf einem Zwischenstück des Übermittlungsweges kleiner ist als das Datagramm.
Die Flags bestimmen ob ein Paket fragmentiert werden darf oder ob noch weitere Fragmente zu diesem IP-Datagramm gehören.
Der nachfolgende Fragment Offset zeigt auf die Stelle im Original IP-Paket wo das Fragment einsortiert werden muss. D.h. durch den Identifier, die Flags und den Fragment Offset kann ein IP Paket wieder vollständig rekonstruiert werden.
Die Time to Live (TTL) gibt die Lebensdauer des Paketes an. Dieser Wert wird bei jedem Hop um eins verringert. Erreicht der Wert die Null, so wird das Paket verworfen. Die TTL wird ferner um eins reduziert für jede Sekunde die das Paket in einem Router verweilt. Dies dient in erster Linie dazu keine Endlosschleifen zu ermöglichen bei denen das Paket über mehrere Router im Kreis läuft.
Das Protocol gibt an welches höhere Protokoll beherbergt wird. Die registrierten Protokolle können bei IANA http://www.iana.org/assignments/protocol-numbers gefunden werden oder unter Linux in der Datei /etc/protocols.
Die Header Checksumme ist eine Prüfsumme nur über den IP-Header. Der Grund ist relativ einfach: Der IP-Header ist zu einem deutlich kürzer als das gesamte Paket. Zudem muss diese Prüfsumme aufgrund der sich ändernden TTL von jedem Router neu berechnet werden. Da ist es von Vorteil den Aufwand gering zu halten. Zudem können höhere Protokolle durchaus mit Fehlern in den Daten leben, z.B. stört ein umgekipptes Bit in einem Audio-Stream nicht sonderlich, ein fehlendes Datagramm hingegen schon.
Was dann folgt ist die Absende-IP-Adresse und die Ziel-IP-Adresse. Diese sind jeweils 32 Bit lang, d.h 4 Bytes. Diese werden gewöhnlich als einzelne Bytes getrennt durch Punkte dargestellt, z.B.: 192.168.1.1
Den Abschluss bilden die möglichen IP-Optionen sowie ein Padding, d.h. ein Auffüllen auf 32-Bit Grenzen.
Klassisch gesehen werden die 32-Bit IP-Adressen in Netzwerke eingeteilt. Die Idee war das Routing hierdurch zu vereinfachen. Dabei gibt es verschieden große Netze, die Netze werden über die ersten Bits der IP-Adresse definiert. Aus den Urzeiten des Netzwerkes wurde ein vernetzter Server (Clients gab es nicht im eigentlichen Sinne, das waren nur Terminals) als Host (Gastgeber) bezeichnet. Dieser Name (Host) wird auch heute noch für ein vernetztes Gerät im Internet verwendet.
Hier sind die entsprechenden Netzmasken:
Class| Netzwerkanteil der Adresse | Hostanteil der Adresse -----+----------------------------+---------------------------- A | 11111111 | 00000000 00000000 00000000 -----+----------------------------+---------------------------- B | 11111111 11111111 | 00000000 00000000 -----+----------------------------+---------------------------- C | 11111111 11111111 11111111 | 00000000 -----+----------------------------+----------------------------
(Eine logische UND Verknüpfung der Netzmaske mit der IP-Adresse liefert die Netzwerkadresse.)
Dieses liefert dann die mögliche Zahl der Systeme pro Netzwerk:
Class| Netzwerkbits | Zahl der Netze | Hostbits | Hosts pro Netz -----+--------------+----------------+----------+----------------- A | 7 | 126 | 24 | 16777214 -----+--------------+----------------+----------+----------------- B | 14 | 16382 | 16 | 65534 -----+--------------+----------------+----------+----------------- C | 21 | 2097150 | 8 | 254 -----+--------------+----------------+----------+-----------------
Bei den Hosts pro Netz ist jeweils die reine Netzwerkadresse sowie die Broadcastadresse ausgenommen.
Eine Erweiterung des Schemas führt zu:
Class| ersten Bits | Adressbereich -----+-------------+---------------------------------------------- A | 0xxxxxxx | 0.0.0.0 bis 127.255.255.255 -----+-------------+---------------------------------------------- B | 10xxxxxx | 128.0.0.0 bis 191.255.255.255 -----+-------------+---------------------------------------------- C | 110xxxxx | 192.0.0.0 bis 223.255.255.255 -----+-------------+---------------------------------------------- D | 1110xxxx | 224.0.0.0 bis 239.255.255.255 (multicasts) -----+-------------+---------------------------------------------- E | 1111xxxx | 240.0.0.0 bis 255.255.255.255 (experimentell)
Dies sollte das Routing aufgrund der ersten Bits erleichtern. Heutzutage werden diese Netze aber weiter unterteilt, das sind die sogenannten Subnetzwerke.
In diesem Zusammenhang gibt es für Netzwerkmasken noch die Cisco-Notation bei der die Zahl der relevanten Bits durch ein Schrägstrich (slash) an die Adresse angehängt werden, z.B.: 192.168.1.0/24 besagt, dass die ersten 24 Bit das Netzwerk beschreiben. Demzufolge sind noch 32-24 = 8 Bit für Hostadressen frei. Das sind 2^8=256, zieht man noch die Netzwerk- und die Broadcastadresse ab so bleiben 254 Adressen übrig, ein Class-C Netz also.
IP-Broadcast Adressen sind nun Adressen bei denen alle Host-Bits gesetzt sind. Im obigen Beispiel also 192.168.1.255.
Multicast-Adressen liegen im Bereich von 224.0.0.0 bis 239.255.255.255.
Neben den offiziell vergebenen Adressen und den reservierten Class-E Netzen gibt es noch private Adressen. Diese können Privat vergeben werden und dürfen im Internet nicht weitergeleitet werden. Die Adressbereiche sind laut RFC 1918 (daher auch oft RFC-Adressen genannt):
Class| Adressbereich -----+------------------------------- A | Alle 10.x.x.x Adressen -----+------------------------------- B | 172.16.x.x bis 172.31.x.x -----+------------------------------- C | 192.168.0.x bis 192.168.255.x -----+-------------------------------
Aber wie bereits gesagt, Netzmasken haben eigentlich mit dem IP-Protokoll nichts zu tun sondern haben nur Auswirkungen darauf wie der nächste Hop ermittelt wird.
Es gibt diverse Optionen die gesetzt werden können, sie sollten aber eigentlich nie vorkommen. Die einen sind unsicher, die anderen wenig sinnvoll bzw. es gibt bessere Methoden um das gleiche Ziel zu erreichen.
Jedes IP-Paket kann mehrere Optionen haben, allerdings dürfen insgesamt nicht mehr als 40 Bytes belegt werden. Diese Grenze ist durch das IHL-Feld (IP Header Length) auferlegt, der Maximalwert für ein IP-Paket beträgt 60 Bytes, der reine IP-Header ohne Optionen belegt bereits 20 Bytes.
Optionen bestehen aus drei Teilen:
Ferner gibt es noch das Padding, d.h die einzelnen Optionen werden, sofern erforderlich, auf 32-Bit Grenzen aufgefüllt.
Der Optionstyp setzt sich ebenfalls aus drei Teilen zusammen:
Das Copy-Bit gibt dabei an, ob die Optionen auch in die Fragmente eines IP-Paketes kopiert werden sollen. Wenn es nicht gesetzt ist, so sind die Optionen nur Bestandteil des ersten Fragmentes.
Theoretisch gibt es vier Klassen wobei zwei unbenutzt sind. Klasse 0 ist für die Netzwerk-Optionen, Klasse 2 für die Fehlersuche.
Eine vollständige Liste aller IP-Optionen gibt es unter http://www.iana.org/assignments/ip-parameters
Die am Häufigsten verwendeten Optionen sind:
Copy Class Number Value Name Reference ---- ----- ------ ----- ------------------------------- --------- 0 0 0 0 EOOL - End of Options List [RFC791,JBP] 0 0 1 1 NOP - No Operation [RFC791,JBP] 1 0 2 130 SEC - Security [RFC1108] 1 0 3 131 LSR - Loose Source Route [RFC791,JBP] 0 2 4 68 TS - Time Stamp [RFC791,JBP] 0 0 7 7 RR - Record Route [RFC791,JBP] 1 0 9 137 SSR - Strict Source Route [RFC791,JBP] 1 0 20 148 RTRALT - Router Alert [RFC2113]
End of Option List kennzeichnet das Ende aller Optionen, No Operation wird für das Padding, also das Auffüllen auf 32-Bit Grenzen verwendet.
Die Security Option wird nur in militärischen Netzwerken verwendet und dient der Klassifizierung von Daten. Diese Option legt auch fest, dass nur entsprechend klassifizierte Router diese IP-Pakete weiterleiten dürfen. Spätestens hier ist klar, warum dies nur in militärischen Netzwerken relevant ist, normalen Providern ist diese Security egal.
Loose Source Route dient dazu eine Route vorzugeben. Dabei kann eine Liste von Routern angegeben werden die von den IP-Paketen durchlaufen werden müssen. D.h. jede angegebene IP-Adresse muss während des Transfers besucht werden.
Strict Source Route ist ähnlich, hier dürfen nur die angegebenen IP-Adressen als Router verwendet werden.
Die Record Route Option dient dazu den Weg eines IP-Paketes aufzuzeichnen. Jeder besuchte Router setzt seine IP-Adresse in den Datenbereich der Option. Dazu muss bereits der Platz im IP-Header reserviert sein. Zusätzlich gibt es ein Pointer-Feld das auf den nächsten freien Eintrag in der Liste zeigt.
Allerdings ist der Platz für diese IP-Adressen aufgrund der Maximalgröße des IP-Headers recht klein. Passen nicht alle Router-IP's in das Optionsfeld, so wird das IP-Paket verworfen. Es ist also wenig sinnvoll, abgesehen davon, dass dann nur der Empfänger wüßte wo das Paket langlief.
Die Timestamp Option ist ähnlich, sie protokolliert je nach einem angegeben Flag die Zeitstempel der Router, die Router-Adresse mit Zeitstempel oder die Zeitstempel zu vorgegebenen Routern. Die Zeit wird dabei in Millisekunden seit Mitternacht UTC (Coordinated Universal Time) angegeben.
Passen nicht all gewünschten Informationen in das vorgegebene Optionsfeld, so wird das Paket verworfen. Diese Option macht also eigentlich ebenfalls keinen Sinn.
Router Alert dient dazu einen Router darauf hinzuweisen, dass dieses Paket Besonderheiten enthält, die vor der Weiterleitung ausgewertet werden sollten. Hierdurch können spezielle Informationen an die Router weitergeleitet werden.
Insgesamt gesehen, sind diese Optionen eigentlich nicht wirklich brauchbar, Source Routing kann verwendet werden um über einen anderen Weg ans Ziel zu kommen. Alleine deshalb sollte man dies mit Vorsicht behandeln, sollte einem so ein Paket begegnen.
ifconfig dient in diesem Bereich zum Setzen von IP-Adressen, Netzmasken und Broadcast-Adressen. Ferner können Flags wie UP, BROADCAST und MULTICAST gesetzt werden oder auch die MTU.
Das setzen einer IP-Adresse und das Setzen der MTU erfolgt z.B. via:
debix:~# ifconfig eth0 inet 192.168.1.18 netmask 255.255.255.0 mtu 1492
debix:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:A0:CC:D8:AC:17
inet addr:192.168.1.18 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1
RX packets:12871 errors:0 dropped:0 overruns:0 frame:0
TX packets:12030 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:8465165 (8.0 MiB) TX bytes:1922024 (1.8 MiB)
Interrupt:9 Base address:0x4700
1492 wird bei PPPoE verwendet, die fehlenden 8 Bytes werden dabei für die PPP-Informationen verwendet.
Mit der Option -r kann die Routing-Tabelle ausgelesen werden. Die Option -n bewirkt dabei, dass die IP-Adressen (numerical) anstelle der DNS-Namen ausgeben werden. Bei Linux hat route -n den gleichen Effekt aber netstat -rn funktioniert bei allen Unix-Systemen.
majestix:~$ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.178.1 0.0.0.0 UG 0 0 0 eth1
Interessant ist hierbei die Ziel-Adresse 0.0.0.0, dies gibt die default-Route an, dorthin wird alles gesendet, für das es keine spezifischere Route gibt. Ferner ist Iface nicht uninteressant, dies gibt an über welches Interface ein Pakete entsprechend der Route gesendet wird.
Flags gibt weitere Informationen aus. U bedeute Up, aktiv. H ist eine Host-Route, G heißt es geht über einen Router (Gateway).
Dieses Programm dient der Manipulation der Routing-Tabelle. Das Ändern, Hinzufügen, Manipulieren und Löschen von Routen sowie das Setzen der MTU, MSS (siehe TCP), metric sowie des Interfaces ist hiermit möglich. Es können auch explizit Routen verboten werden, allerdings dient dies nicht der Sicherheit!
Ein Beispiel zum Setzen einer Route wäre z.B.:
debix:~# route add 192.168.2.1 gw 192.168.1.1
Löschen geht via:
debix:~# route del 192.168.2.1 gw 192.168.1.1
Besonderheiten bei Linux sind, dass explizit das Wort gw für Gateway angegeben werden muss, im Gegensatz z.B. zu BSD-Systemen. Ferner verwendet Linux zum Löschen das Wort del statt delete.
Wichtig ist: Das Gateway muss in einem angeschlossenen Netz liegen, d.h. man kann keine Gateway's in anderen Netzen angeben. Der Router muss also im gleichen Subnetz liegen!
Dieses Kapitel wird wieder etwas länger. Wer daran nicht interessiert ist, der kann es sich auch sparen. Es ist für die Fehlersuche bei Netzwerkproblemen oft relevant und verdeutlicht zudem auch warum es manchmal zu Verzögerungen beim ersten IP-Paket gibt.
Kurz gesagt: ARP dient dazu die Gegenstelle im lokalen Netzwerk zu finden.
Definiert ist dieses Protokoll und Varianten davon in RFC 826 sowie RFC 903 (RARP), RFC 1122, RFC 1868 (UnARP), RFC 2131 (DHCP ARP) und RFC 2390 (Inverse ARP). Der Ethernetprotokolltyp ist 0x806, es ist also kein IP-Paket.
ARP dient dazu in einem lokalen Netzwerksegment die MAC-Adresse der Gegenstelle anhand der IP-Adresse zu ermitteln. In einem lokalen Netzwerk ist kein Router involviert, falls ein Router involviert ist, dann muss via ARP die MAC-Adresse des Routers erfragt werden.
Für die Zustellung im lokalen Netz muss also die MAC Adresse der Gegenstelle bekannt sein. Diese kann statisch gesetzt sein oder im ARP-Cache vorhanden sein. Ist dies nicht der Fall, so muss ein ARP-Request als Ethernet-Broadcast gesendet werden mit der Bitte, dass die Station mit der zugehörigen IP-Adresse sich melde.
Die entsprechende Station sendet via Unicast, d.h. direkt an den Anfragenden mit dessen MAC-Adresse, eine ARP-Antwort. Danach kann die eigentliche Kommunikation auf IP-Ebene erfolgen.
Die MAC-Adresse aus diesem Request wird in den lokalen ARP-Cache eines Computers hinterlegt. So können einige ARP-Anfragen gespart werden, wenn mehrere Pakete an die Gegenstelle gesendet werden, was nicht unwahrscheinlich ist.
Relevante Einträge eines ARP-Paketes gibt es eigentlich nur fünf, die Hardware (MAC) Adresse des Senders, dessen IP-Adresse, die Hardware Adresse des Ziels sowie dessen IP-Adresse und den Typ des Paketes, d.h. Frage- oder Antwort-Paket.
Bei einem ARP-Request werden nur 3 Felder gesetzt, die eigenen Adressen und die gewünschte IP-Adresse, der Typ steht auf Fragepaket und die MAC-Adresse des Zielsystems ist die Hardware-Broadcast-Adresse des Mediums. Dadurch sollten alle angeschlossenen Stationen diesen Request sehen können.
Diese Stationen müssen den ARP-Broadcast-Verkehr überwachen und wenn sie darin ihre eigene IP-Adresse erkennen auch antworten.
Wichtig dabei ist: Es gibt keinen Timeout, entweder es kommt eine Antwort oder nicht. Da aber der IP-Stack wenn er das Paket nicht senden kann dies nach kurzer Zeit erneut versucht wird dann ein neuer ARP-Request generiert.
Der nächste Abschnitt befasst sich mit dem ARP-Cache, nicht-geforderten ARP-Antworten und Proxy-ARP.
Der ARP-Cache hat eigentlich nichts mit dem Protokoll zu tun hat. Auf der anderen Seite ist dies meist eine Fehlerquelle bei Neztwerkproblemen. Zu wissen was sich dahinter verbirgt schadet jedenfalls nicht. Gratuitous ARP und Proxy-ARP schlagen in die gleiche Kerbe.
Da jede angeschlossene Station die Broadcast-Anfragen sieht können diese ihren Cache anhand der abgesendeten MAC-Adresse und IP-Adresse aktualisieren. Theoretisch ist auch ein Auffüllen möglich aber um unnötiges Aufblähen des Caches zu vermeiden werden nur bereits im Cache befindliche IP-Adressen aktualisiert.
Es kann natürlich zu Problemen führen wenn sich bei einem System die MAC-Adresse z.B. durch Austausch der Netzwerkkarte ändert oder bei Einwahlsystemen bei denen ein Teilnehmer eine IP-Adresse zugewiesen bekommt die kurz vorher ein anderes System hatte. Bei DHCP kann dies gleichfalls auftreten, die IP-Adresse hat vielleicht kurz vorher noch ein anderes System besessen. Das Problem existiert z.B. auch bei HA-Systemen, High Available also hochverfügbare System, bei der z.B. das 2. System die IP-Adresse des ersten übernimmt. Hier wird wieder deutlich wo CARP bereits einen Schritt weiter ist!
Aus diesem Grund wurde Gratuitous ARP (grundloses, überflüssiges ARP) eingeführt. Dabei sendet eine Station mit der eigenen MAC einen Broadcast-ARP auf das Netzwerk mit der eigenen IP-Adresse im Quell- und Zielfeld.
Kein Gerät sollte auf diesen ARP-Request antworten da die einzige Station, die dies könnte, diesen Request gesendet hat. Auf der anderen Seite sollten aber alle System die diese IP-Adresse in ihrem ARP-Cache haben die MAC-Adresse aktualisieren.
Bei Cisco-Routern ist dies häufig notwendig da diese einen ARP-Cache Timeout von 4 Stunden haben und erst dann wieder einen ARP-Request senden:
ARP type: ARPA, ARP Timeout 04:00:00
Normalerweise liegt der Timeout aber im Bereich weniger Minuten bzw. Sekunden. Wobei dieser Timeout zurückgesetzt wird wenn aktiv Pakete ausgetauscht werden.
Es besteht aber auch die Möglichkeit statische ARP-Einträge vorzunehmen. Diese werden weder aktualisiert noch entfernt. Auf der einen Seite kann dies hilfreich sein da einige ARP-Pakete gespart werden können. Auf der anderen Seite jedoch können diese Systeme nicht auf Änderungen von MAC-Adressen reagieren!
Manchmal ist es hilfreich wenn eine andere Station einen ARP-Request beantwortet. Dies kann z.B. bei Einwahlroutern hilfreich sein, man muss dann keine ARP-Pakete über die Telefonleitung senden. Durch z.B. PPP glauben die anderen Stationen dass der angeschlossen Einwahlcomputer lokal erreichbar ist.
Bridges trennen zwei Collision Domains und müssen daher entweder ARP-Pakete von einem Netzwerksegement in das andere weiterleiten oder Proxy-ARP verwenden.
Ein Problem kann entstehen, wenn sich z.B. ein Benutzer mehrfach innerhalb von kurzer Zeit einwählt und dabei die gleiche IP-Adresse aber einen anderen Einwahlrouter verwendet. Dann hat sich weder die IP-Adresse noch die MAC-Adresse geändert. Daher wird sich dann der erste Einwahlrouter noch immer zuständig fühlen.
Dies ist der umgekehrte Fall, eine Station kennt die MAC-Adresse der Gegenstelle, weiß aber nicht welche IP-Adresse dazu gehört. Dies kommt häufig bei Netzwerken vor, die sich die Datenverbindungsschicht teilen wie z.B. Frame-Relay oder ATM.
In diesem Fall kennt das System nur die eigenen MAC-Adresse. Dies sind z.B. diskless Clients die via BOOTP starten wollen oder ein PC der via DHCP seine Einstellungen erhalten will. Diese müssen erst einen reverse ARP-Request senden um die eigene IP-Adresse zu erhalten. Diese Anfragen haben den eigenen Ethernettyp 0x8035.
Reverse ARP funktioniert, indem der Client einen Broadcast-ARP-Request sendet der die eigene MAC-Adresse im Sender und Empfängerfeld eingetragen hat, die Felder für die IP-Adressen sind mit Nullen ausgefüllt. Ein RARP-Server, z.B. ein BOOTP-Server, reagiert auf solche Anfragen und sieht in der eigenen Tabelle nach ob die MAC-Adresse passt. Ist dem so, wird an den Sender ein Antwortpaket mit der IP-Adresse gesendet.
Ein DHCP-Server hat gewöhnlich keine feste Zuordnung zwischen MAC- und IP-Adressen sondern verteilt eine Adresse aus einem gemeinsamen Vorrat. So können viele Stationen einen kleineren Vorrat an IP-Adressen verwenden. Im Zeitalter knapper werdender IP-Adressen ist das nicht so verkehrt. Allerdings ist dies bei Verwendung von RFC 1918 Adressen eigentlich unnötig. Probleme gibt es deswegen genug aber meist nur mit einem ganz speziellen Betriebssystem das davon massiv Gebrauch macht.
Ein DHCP-Server antwortet daher auf einen RARP-Request einfach mit einer IP-Adresse unabhängig davon welche MAC-Adresse vorliegt.
Nun kann es passieren, dass die IP-Adresse aus dem Pool z.B. bereits statisch vergeben wurde. D.h. es würden zwei Stationen mit gleicher IP-Adresse existieren. Um dies zu vermeiden gibt des DHCP-ARP.
Der DHCP-Client sendet in einem solchen Fall einen normalen ARP-Request mit der Absendeadresse 0.0.0.0 und der Frage, wem diese gerade erhaltene IP-Adresse gehört. Die Ziel-MAC-Adresse besteht in diesem Fall nur aus Nullen. Idealerweise sollte darauf niemand antworten, es sei denn, die IP-Adresse ist bereits vergeben.
Der Absender 0.0.0.0 soll verhindern, dass Stationen ihren ARP-Cache mit der neuen IP-Adresse aktualisieren. Bis hier ist schließlich noch nicht sichergestellt, dass diese Adresse auch frei ist.
Die Quell-MAC-Adresse gewährleistet aber, dass eine Station mit der IP-Adresse direkt antworten kann. Bleibt die Antwort aus, so kann davon ausgegangen werden, dass die IP-Adresse noch frei ist und kann daher in Zukunft verwendet werden.
Ein Problem besteht dabei natürlich darin, dass ein Computer mit dieser IP-Adresse durchaus existieren kann aber im Moment nicht antworten kann, weil er z.B. gerade einen Bluescreen anzeigt.
Es kann auch vorkommen, dass ältere Implementationen diese DHCP-ARP's nicht kennen und daher ignorieren.
Wenn aber 2 Computer mit der gleichen IP-Adresse in Betrieb genommen werden, so wird es chaotisch. Je nachdem welche Station antwortet kann es seltsame Verbindungsabbrüche (Resets, siehe TCP) oder unerwartete ICMP Meldungen, siehe nächstes Kapitel für ICMP, geben.
Die Probleme mit doppelt vergebenen IP-Adressen oder veralteten ARP-Einträgen kommen meist von DHCP-Clients. Aus diesem Grund wurde UnARP, unsolicited ARP, unaufgeforderter, unerbetener ARP, eingeführt.
Hierbei meldet sich eine Station explizit über einen ARP-Response ab. Dadurch kann z.B. eine DHCP-Adresse sofort wieder verwendet werden. Das setzt allerdings voraus, dass alle Systeme UnARP verstehen und korrekt darauf reagieren.
Diese ARP-Pakete haben als Quell- und Zieladresse Nullen und werden via Broadcast versendet. Diese Nullen bedeuten, dass keine Hardwareadresse mit dieser IP-Adresse assoziiert ist.
Eine Anmerkung noch zum Schluss, um ein paar mögliche Verwirrungen zu vermeiden: Die Quell- und Ziel-MAC-Adressen die hier erwähnt werden sind Bestandteil des ARP-Paketes. Das sind nicht unbedingt die gleichen, wie sie im Ethernet-Header verwendet werden. Das wäre sonst auch etwas schwierig, eine Absende- und Empfangs-MAC-Adresse als Broadcast, das ist in diesem Fall ein Ethernet-Broadcast an FF:FF:FF:FF:FF:FF, zu versenden.
Hiermit kann die eigene MAC-Adresse ausgeben oder verändert werden:
majestix:~# ifconfig eth0 |grep HWaddr eth0 Link encap:Ethernet HWaddr 00:E0:4C:00:82:9F majestix:~# ifconfig eth0 down majestix:~# ifconfig eth0 hw ether 00:11:22:33:44:55 majestix:~# ifconfig eth0 |grep HWaddr eth0 Link encap:Ethernet HWaddr 00:11:22:33:44:55
Es ist also, entgegen einer vielverbreiteten Meinung, durchaus möglich die MAC-Adresse zu ändern!
Dieses Programm dient dazu den Netzwerkverkehr mitzuschneiden. Um auch Pakete zu sehen, die nicht für den eigenen Computer bestimmt sind muss die Ethernetkarte in den sogenannten promiscuous, vermischten, Modus gesetzt werden. Dies macht tcpdump bei Linux automatisch. Das kann z.B. mit dmesg beobachtet werden, z.B.:
device eth1 entered promiscuous mode
Entgegen den Namensteil tcp zeigt tcpdump eigentlich alle Pakete an die über das Netzwerk laufen. Bei der Option arp werden dabei nur ARP Pakete angezeigt, z.B.:
majestix:~# tcpdump arp tcpdump: listening on eth0 21:49:15.585612 arp who-has debix-1.physik.home tell majestix.physik.home 21:49:15.585756 arp reply debix-1.physik.home is-at 0:a0:cc:d8:ac:17
arp listet mit der Option -a den ARP-Cache auf, Mit der Option -d können Einträge gelöscht werden. Die Option -s setzt ARP-Einträge:
majestix:~# arp -an ? (192.168.1.198) at 00:10:83:F4:F2:C1 [ether] on eth0 ? (192.168.178.1) at 00:04:0E:21:0A:EB [ether] on eth1 majestix:~# arp -d 192.168.1.198; arp -a ? (192.168.1.198) at <incomplete> on eth0 dslbox.physik.home (192.168.178.1) at 00:04:0E:21:0A:EB [ether] on eth1 majestix:~# arp -n -s 192.168.1.198 00:10:83:F4:F2:C1 majestix:~# arp -an ? (192.168.1.198) at 00:10:83:F4:F2:C1 [ether] PERM on eth0 ? (192.168.178.1) at 00:04:0E:21:0A:EB [ether] on eth1
Die Option -n bewirkt, dass keine Namensauflösung der IP-Adressen durchgeführt wird. Daher erscheint dann an der Stelle des DNS Namens ein Fragezeichen.
PERM besagt, dass diese Adresse permanent gesetzt ist, d.h. sie kann auch nicht via ARP-Requests überschrieben werden.
Was Multicasts sind wurde schon vorher einmal erwähnt. Es ist die Möglichkeit Daten parallel an mehrere, nicht notwendigerweise alle, das wäre dann ein Broadcast, zu versenden.
Durch die Verwendung mehrerer Multicast-IP-Adressen, sogenannter Gruppenadressen, können mehrere Multicasts gleichzeitig und unabhängig voneinander verwendet werden. Diese Adressen sind auch als Class-D Netz bekannt:
224.0.0.0 - 239.255.255.255
Einige von diesen Adressen sind laut IANA reserviert, so sind die Adressen 224.0.0.1 - 224.0.0.255 für Routing-Protokolle, diese verwenden meist auch Multicasts, bzw. die einfachen Basisdienste reserviert. Siehe z.B. http://www.iana.org/assignments/multicast-addresses
Einige häufig verwendete Adressen sind:
Adresse | Beschreibung ----------+----------------------------------------------- 224.0.0.1 | Alle Systeme des Subnetzes, niemals gerouted 224.0.0.2 | Alle Router des Subnetzes, niemals gerouted 224.0.0.9 | RIP2 Router, Routing Information Protocol 2 224.0.1.1 | NTP Network Time Protocol 224.0.1.24| microsoft-ds, WINS Lokalisierungsdienst
Broadcast-Adressen und einige Multicast-Adressen (s.o.) sollten niemals gerouted werden, diese sollen im Subnetz bleiben um das Datenaufkommen gering zu halten. Dies wird meist zusätzlich dadurch erreicht, dass die TTL auf eins gesetzt wird.
Einige Multicast-Adressen können aber durchaus auch in andere Netze gerouted werden, z.B. kann es notwendig sein einen Audiostream mit der Ansprache des Chefs in mehrere Netze zu verteilen.
Router sollen aber nur Multicasts in Subnetze weiterleiten die auch diese wünschen. Um das wiederum festzustellen gibt es das Internet Group Management Protocol, definiert in RFC 1112 (IGMPv1) sowie die Version 2 in RFC 2236 (IGMPv2).
Die wesentliche Aufgabe dieses Protokolls ist, dass die Router nach Hosts fragen die Multicasts empfangen wollen und Hosts den Routern mitteilen, welche Multicasts sie haben wollen.
Dazu gibt es sogenannte Membership Reports, also Berichte wer in welcher Multicast-Gruppe ist, sowie Membership Queries: Wer ist (noch) Mitglied dieser Multicast-Gruppe?
Die wesentliche Neuerung von IGMP Version 2 sind die Leave Reports, d.h. ein Teilnehmer kann explizit mitteilen, dass er an der abonnierten Multicast-Gruppe nicht mehr interessiert ist.
Das ist im wesentlichen alles. Relevant sind die Multicasts gerade hinsichtlich der Kommunikation zwischen Routern die dem aktiven Austausch von Routen dienen.
Wie üblich zuerst der Klassiker im Netzwerkbereich:
Die Option -g listet die Gruppenzugehörigkeit auf, alle multicastfähigen Computer sind in der Gruppe 224.0.0.1:
geschke@dg4:~$ netstat -g IPv6/IPv4 Group Memberships Interface RefCnt Group --------------- ------ --------------------- eth0 1 ALL-SYSTEMS.MCAST.NET lo 1 ALL-SYSTEMS.MCAST.NET
Die Option -n zeigt wieder alles numerisch an:
geschke@dg4:~$ netstat -gn IPv6/IPv4 Group Memberships Interface RefCnt Group --------------- ------ --------------------- eth0 1 224.0.0.1 lo 1 224.0.0.1
Dieses Programm gehört eigentlich in die ICMP-Sektion, also dem nächsten Kapitel. Es dient dazu über Echo-Requests und Echo-Replies festzustellen ob die Gegenstelle netzwerktechnisch erreichbar ist.
Ein ping auf die Multicast-Adresse 224.0.0.1 sollte alle multicastfähigen Systeme auflisten, z.B.:
geschke@dg4:~$ ping 224.0.0.1 PING 224.0.0.1 (224.0.0.1): 56 data bytes 64 bytes from 10.1.22.4: icmp_seq=0 ttl=64 time=0.2 ms 64 bytes from 10.0.1.34: icmp_seq=0 ttl=64 time=1.0 ms (DUP!) 64 bytes from 10.0.1.18: icmp_seq=0 ttl=64 time=1.2 ms (DUP!) 64 bytes from 10.1.9.47: icmp_seq=0 ttl=255 time=1.4 ms (DUP!) 64 bytes from 10.0.1.40: icmp_seq=0 ttl=255 time=1.5 ms (DUP!) 64 bytes from 10.2.2.2: icmp_seq=0 ttl=64 time=1.6 ms (DUP!) 64 bytes from 10.0.1.11: icmp_seq=0 ttl=64 time=1.7 ms (DUP!) 64 bytes from 10.0.5.8: icmp_seq=0 ttl=255 time=1.8 ms (DUP!) 64 bytes from 10.0.5.19: icmp_seq=0 ttl=255 time=1.9 ms (DUP!) 64 bytes from 10.0.1.4: icmp_seq=0 ttl=255 time=2.1 ms (DUP!) 64 bytes from 10.0.99.50: icmp_seq=0 ttl=255 time=2.2 ms (DUP!) 64 bytes from 10.0.1.20: icmp_seq=0 ttl=64 time=2.3 ms (DUP!) ...
Das IP-Protokoll garantiert eigentlich nur ein Hop-zu-Hop Weiterleitung. Was nach dem ersten Hop passiert ist nicht mehr Aufgabe des lokalen IP-Stacks, das ist die IP-Implementation im Kernel.
Weder der Weg des IP-Paketes noch der sichere Transport sind gewährleistet. Es können Pakete unterschiedliche Routen nehmen, sich gegenseitig überholen, verdoppelt werden oder sie gehen einfach verloren.
All diese Ereignisse werden vom IP-Protokoll nicht abgedeckt bzw. überwacht.
Es ist daher klar, dass noch ein Mechanismus benötigt wird, der hierauf reagieren kann, d.h. z.B. Fehlermeldungen generiert. Dies wird durch das Internet Control Message Protocol, ICMP, realisiert.
ICMP ist ein höheres Protokoll, d.h. es baut selber auf IP auf, die IP-Protokollnummer ist 1.
Es gibt zwei Arten von ICMP-Paketen: Fehler- und Fragemeldungen. Die Fehlermeldungen werden an die höhere Protokollschicht weitergeleitet, die ICMP-Fragemeldungen werden direkt via ICMP beantwortet.
ICMP-Fehlermeldungen sollten niemals auf ICMP-Fehlermeldungen generiert werden. Ferner sollen ICMP's nicht als Antwort auf Broadcasts oder Multicasts verwendet werden. Gleiches gilt für unspezifierte Adressen, die nur aus Nullen bestehen, loopback-Adressen, etc. sowie auf data-link Broadcasts oder Multicasts.
Bei fragmentierten IP-Paketen wird, wenn überhaupt, nur auf das erste Fragment eine ICMP Fehlermeldung generiert.
ICMP Typen und ihre Verwendung sind:
Typ | Mitteilung | Familie | RFC ----+-------------------------+-----------------+----- 0 | Echo Reply | Query (Reply) | 792 3 | Destination unreachable | Error | 1122 4 | Source Quench | Error | 792 5 | Redirect | Error | 792 8 | Echo Request | Query (Request) | 792 9 | Router Advertisement | Query (Reply) | 1256 10 | Router Soliciation | Query (Request) | 1256 11 | Timer Exceeded | Error | 1122 12 | Parameter Problem | Error | 792 13 | Timestamp Request | Query (Request) | 792 14 | Timestamp Reply | Query (Reply) | 792 17 | Address Mask Request | Query (Request) | 950 18 | Address Mask Reply | Query (Reply) | 950
DEr Aufbau von ICMP-Fehlerpaketen ist:
Der Message Type legt fest welcher Art der Fehler ist, der Message Code spezifiziert diesen näher. Die Checksumme dient der Integrität der Daten, das Message Datenfeld kann von einigen Message Typen verwendet werden um weitere Informationen zu übertragen.
Der Original Header ist der IP-Header des Paketes auf das diese Fehlermeldung sich bezieht. Diese dient der Zuordnung der Meldung. Die ersten 8 Bytes der Original IP-Payload sind meistens ebenfalls sehr hilfreich bei der Lokalisierung des Fehlers. Sowohl UDP als auch TCP speichern in den ersten 8 Bytes die Quell- und Zielports.
Die wohl häufigste Fehlermeldung ist die Nummer 3.
Hier wird deutlich warum es noch den Message Code gibt, dieser gibt hier an warum das Ziel nicht erreichbar ist:
Code | Bedeutung -----+----------------------- 0 | Network Unreachable 1 | Host Unreachable 2 | Protocol Unreachable 3 | Port Unreachable 4 | Fragmentation required but DF Bit is Set 5 | Source Route Failed 6 | Destination Network Unknown 7 | Destination Host Unknown 8 | Source Host Isolated (obsolete) 9 | Destination Network Administratively Prohibited (obsolete) 10 | Destination Host Administratively Prohibited (obsolete) 11 | Destination Network Unreachable for Type-of-Service 12 | Destination Host Unreachable for Type-of-Service 13 | Communication Administratively Pohibited 14 | Host Precedence Violation 15 | Precedence Cutoff in Effect
Das Message Datenfeld ist bei dieser Art von Fehlermeldung unbenutzt und muss gleich Null gesetzt sein. Allerdings gibt es eine Ausnahme, bei Code 4, Fragmentation required but DF Bit is Set, steht hier die MTU des nächsten Hops.
Das Don't Fragment Bit wird gewöhnlich zur Erkennung der Path-MTU verwendet. Dies dient dazu die größtmögliche MTU zwischen Sender und Empfänger zu ermitteln. Dabei wird das erste Paket mit der MTU des Interfaces und dem DF-Bit gesetzt versendet. Der erste Router, der aufgrund einer kleineren MTU fragmentieren müßte, generiert daraufhin die ICMP-Fehlermeldung mit der MTU die maximal möglich ist.
Daraufhin kann der Sender die MTU bezüglich des Empfängers anpassen und zwar an die größtmögliche MTU, d.h. mit dem kleinsten Overhead an Protokoll-Headern. Dies kann aber häufig im Zusammenhang mit Paketfiltern zu Problemen führen. Manche Paketfilter sind nicht in der Lage diese ICMP-Meldungen als zu einer Verbindung gehörend einzustufen und entsprechend durchzulassen. In dem IP-Header der des ICMP-Paketes steht die Absende-IP-Adresse des Routers der das Problem berichtet, nicht die des Ziel-Systems!
Bei Linux kann man die PMTU Erkennung via
/proc/sys/net/ipv4/ip_no_pmtu_disc
aktivieren oder abschalten. Ein
echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
schaltet die PMTU Erkennung ab, d.h. das DF-Bit wird nicht gesetzt.
Die ersten Fehlermeldungen sind eigentlich recht klar: Network unreachable meldet ein Router wenn er das Netzwerk nicht ansprechen kann, es gibt keine Route dorthin. Host unreachable hingegen wird gewöhnlich erzeugt, wenn der Zielrechner entweder nicht existiert oder abgeschaltet ist.
Protocol unreachable heißt, dass das verwendete höhere Protokoll auf dem Zielsystem nicht unterstützt wird.
Port unreachable bedeutet, dass der gewünschte Dienst auf dem Zielsystem nicht läuft bzw. nicht auf diesem Port. Bei TCP wird in diesem Fall kein ICMP-Paket generiert, hier wird ein TCP-Reset-Paket gesendet. Aber das kommt später beim Kapitel über TCP.
Source Route failed ist wohl selbsterklärend, die vorgegebene Route kann nicht eingehalten werden.
Destination Network/Host unknown besagt, dass das Netzwerk bzw. das Zielsystem nicht existieren.
Network/Host unreachable for Type-of-Service ist wohl auch offensichtlich.
Communication Administratively Prohibited bedeutet, dass die Kommunikation auf höherer Ebene untersagt wurde. Paketfilter sollten Pakete hiermit zurückweisen, wenn eine Datenverbindung nicht erlaubt ist. Allerdings droppen die meisten Paketfilter einfach die Pakete, d.h. es wird keine ICMP-Meldung generiert und der Client läuft einfach in einen Timeout. Als Anwender ist dieses Verhalten unschön, es muss einige Zeit gewartet werden bis ein Timeout zuschlägt, bei einer ICMP-Fehlermeldung wär schneller klar warum etwas nicht geht.
Die Fehlercodes 9 und 10 sind nicht wirklich veraltet sondern für das US-Militär reserviert, d.h. normale Menschen sollten diese Art von ICMP-Fehlermeldungen nicht mehr verwenden.
Die letzten beiden Meldungen sind wieder recht einfach. Host Precedence Violation besagt, dass die gewünschte Precedence, d.h. Priorität, Sicherheit, Kosten oder Zuverlässigkeit, kann nicht erfüllt werden. Precedence Cutoff in Effect besagt wiederum das Gegenteil, die gewünschte Precedence ist nicht hoch genug für das Netzwerk. Das dürfte einem wohl nur auf recht exklusiven, also teuren Netzwerken, begegnen.
Diese Art von Fehlermeldungen werden von Routern generiert wenn die Netzwerklast zu hoch ist, d.h. der Router kommt mit dem Weiterleiten der Pakete nicht nach. Das kann z.B. passieren, wenn ein routen über ein deutlich langsameres Netzwerk erfolgt als Daten übermittelt werden sollen. Der Sender sollte daraufhin die Senderate heruntersetzen.
Der Message Type ist 4, Message Codes werden nicht verwendet, gleiches gilt für die Message Daten.
In RFC 1812 wird festgehalten, dass diese Art der Fehlermeldung nicht sehr effektiv ist und Router diese daher auch im Falle einer Verstopfung der Leitung nicht senden brauchen. TCP hat eigene Verfahren um auf soetwas zu reagieren, UDP jedoch nicht.
Diese Meldung wird von einem Router versendet wenn dieser einen besseren Weg zum Ziel weiß. Der Message Code gibt dabei an worauf sich der Redirect bezieht:
Code | Bedeutung -----+---------------------------------- 0 | Redirect for Destination Network 1 | Redirect for Destination Host 2 | Redirect for Destination Network Based on Type-of-Service 3 | Redirect for Destination Host Based on Type-of-Service
Hierbei wird das Message Datenfeld verwendet um den besseren Router mitzuteilen. Daher ist dieses Feld auch 4 Bytes groß, es passt eine IP-Adresse hinein.
Anzumerken ist hier, dass das erste IP-Paket von diesem Router an den besseren weitergeleitet wird. Der Sender muss also das erste Paket nicht erneut senden.
Diese Meldung wird generiert wenn ein IP-Paket die TTL (Time-to-Live) überschritten hat und das Paket noch nicht am Ziel ist. Der Router verwirft das IP-Paket und sendet diese Fehlermeldung zurück an den Absender.
Diese Meldung kann auch generiert werden wenn nicht alle Fragmente in einer vorbestimmten Zeit eingetroffen sind. Von daher hat der Message Type 11 zwei Message Codes:
Code | Bedeutung -----+---------------------------------- 0 | Time-to-Live Exceeded in Transit 1 | Fragment Reassembly Time Exceeded
Das Message Datenfeld wird nicht verwendet und muss Null sein.
Laut RFC 1122 sollte diese Art von Fehlermeldung nur generiert werden wenn es keine bessere gibt!
Diese werden meist bei fehlerhafter Verwendung von IP-Optionen erzeugt.
Der Message Type ist 12, der Message Code ist einer von:
Code | Bedeutung -----+---------------------------------- 0 | Pointer Indicates the Error 1 | Required Option is Missing 2 | Bad Length
Die Bedeutung des Message Datenfeld hängt vom Message Code ab:
Code | Bedeutung -----+----------------------------------------------------- 0 | 1 Byte, zeigt auf den Anfang des Problems 1 | 1 Byte, fehlende Option 2 | wird nicht verwendet, muss Null sein
Das waren jetzt die Fehlermeldungen, als nächstes kommen die Fragemeldungen. Diese bestehen meist aus zwei Teilen, einer Anforderung (Request) und einer Antwort (Reply).
ICMP Fragemeldungen dienen zum Testen von Netzwerken auf bestimmte Eigenschaften, wie z.B. Verfügbarkeit oder Latenz. Sie können auch verwendet werden um Router zu lokalisieren.
Aufbau der ICMP-Frage-Pakete ist:
Der Aufbau ist zu den Fehlerpaketen recht identisch. Es gibt allerdings keinen Original-Header, woher auch?, und kein Message Datenfeld. Dafür existiert aber ein mögliches Feld variabler Länge.
Die wohl wichtigsten und bekanntesten Message Typen sind wohl:
Beide Typen gehören zusammen, der Fragetyp (Echo Request) ist 8, der Antworttyp (Echo Reply) ist 0. Beide haben keinen Message Code.
Der Aufbau des zusätzlichen Feldes ist:
Dieses Protokoll wird von dem Programm ping verwendet um zu testen ob die Gegenstelle erreichbar ist. Dazu wird ein Echo Request gesendet, ist die Gegenstelle erreichbar so wird ein Echo Reply zurückgesendet.
Hier wird dann deutlich wozu die zusätzlichen Felder dienen. Der Identifier legt fest welche ICMP-Antwort-Pakete zu welcher ping-Anfrage gehören, es ist durchaus möglich mehrere pings parallel laufen zu lassen.
Die Sequenznummer gibt dann wiederum an das wievielte Paket gesendet wurde bzw. auf welches die Antwort erfolgte. Diese Nummer ist wichtig um festzustellen welche Fragen und Antworten zusammengehören und dienen der Bestimmung der Dauer.
Die Optionalen Daten können dazu verwendet werden Testdaten zu versenden. Im Zusammenhang mit ping kann dies auch dazu verwendet werden Pakete unterschiedlicher Größe zu generieren. Diese Daten müssen im Antwortpaket enthalten sein.
Damit kann dann z.B. auch Fragmentierung von IP-Paketen getestet werden, es muss einfach nur ein Paket größer als die MTU versendet werden.
Diese Meldungen können verwendet werden um die Prozessdauer von IP-Paketen zu bestimmen. Dies ist hilfreich um Latenzen zu messen. Allerdings können dadurch auch Details über das eigene LAN preisgeben werden weshalb RFC 1122 dies als optionale ICMP-Pakete deklariert.
Dabei wird im Request die lokale Zeit eingetragen, in der Antwort sind diese Zeit, die lokale Empfangszeit sowie der Sendezeit der Antwort enthalten. Die Zeit wird in Millisekunden seit Mitternacht in UTC angegeben.
Damit ist dann offensichtlich, wie lange das Paket bei der Gegenstelle verweilte.
Es können auch verschiedene Type-of-Service Werte verwendet werden womit die Latenz der Gegenstelle anhand dieser Werte ausgemessen werden kann.
Wird zusätzlich Source Routing verwendet, so muss die Antwort den umgekehrten Weg der Hinrichtung nehmen. Damit lassen sich die Latenzen auch noch entlang verschiedener Routen ausmessen.
Der Message Type ist 13 (Request) bzw 14 (Reply), beide benutzen keinen Message Code wohl aber verwenden beide die gleiche Struktur:
Feld | Bytes | Beschreibung ---------------------+-------+--------------------------------------- Identifier | 2 | Session Identifier Sequenznummer | 2 | Zähler bzgl. Identifier Original Zeitstempel | 4 | Zeitstempel des Requests vom Fragenden Emfpangs-Zeitstempel | 4 | Zeitstempel des Empfangs der Frage Sende-Zeitsetmpel | 4 | Zeitstempel des Sendens der Antwort
Dadurch, dass jetzt bekannt ist wie lange das Paket unterwegs war und wie lange es bei der Gegenstelle verweilte kann klar bestimmt werden welche Verzögerung vom Netzwerk herrührt.
Dieses Paar dient dazu, dass ein Host die eigene Netzmaske herausfinden kann. Dazu wird eine Adress Mask Anforderung an die Broadcast-Adresse 255.255.255.255 gesendet. Die Antwort hierauf enthält die Netzmaske des lokalen Subnetzes.
Der Message Type ist 17 (Request) bzw. 18 (Response), ein Message Code wird nicht verwendet. Das zusätzliche Feld besteht aus drei Teilen:
Feld | Bytes | --------------+-------+--------------------------- Identifier | 2 | Session Identifier Sequenznummer | 2 | Zähler bzgl. Identifier Subnetzmaske | 4 | Netzmask des loaken Netzes
Diese ICMP-Pakete werden heute nur noch selten benutzt, die meisten Geräte erhalten die Netzmasken gewöhnlich via DHCP oder manuell.
Geräte die das Router Discovery Protocol (RDP) beherrschen können mit diesem Fragetyp via Router Advertisement die verfügbaren Router mit- geteilt bekommen.
Der Message Type ist 10, ein Message Code wird nicht verwendet. Als zusätzliches Feld gibt es ein unbenutztes 4 Byte großes Feld das mit Nullen aufgefüllt sein muss.
Das Router Discovery Protocol bietet einen dynamischen Router-Dienst an. Ein entsprechendes Gerät sendet wenn es online geht eine ICMP Router Solicitation Mitteilung an die all-routers Multicast Adresse 224.0.0.2 (-> siehe NG7: Mulitcasts und IGMP).
Aktive Router sollten darauf via unicast mit einem Router Advertisement antworten. Das tun sie übrigens periodisch auch ungefragt über die all-hosts Multicast Adresse 224.0.0.1 (alle 7-10 Minuten).
Der Message Type ist 9, ein Message Code wird nicht verwendet. Dies wird verwendet bei einer Mitteilung eines RDP Routers, dass er verfügbar ist.
Der Aufbau des zusätzlichen Datenfeldes ist:
Feld | Bytes | Beschreibung
-------------------+-------+--------------------------------------------
Zahl der Adressen | 1 | Adressen in der Ankündigung (Advertisment)
Adressgröße | 1 | Zahl der 4 Byte Wörter um die Adressen
| | zu beschreiben
Lebenszeit | 2 | Sekunden wie lange die Informationen
| | gültig sind.
Addresse Eintrag N | 4 | IP-Adresse von Interface N, N = 1 - Zahl
| | der Adressen (s.o.)
Präferenz für N | 4 | Präferenz für diese Schnittstelle
Das meistverwendete Programm dürfte wohl ping sein:
ping sendet einen ICMP Echo Request an die angegebene Gegenstelle. Wenn diese netzwerktechnisch erreichbar ist, so antwortet diese mit ICMP Echo Reply.
Da das Programm direkt ICMP-Pakete erzeugt muss es übrigens Set-UID root laufen.
Mit der Option -s kann die Größe der ICMP-Pakete festegelegt werden. Durch Verwendung großer Werte kann auch getestet werden ob Fragmente das Ziel erreichen. Manchmal offenbaren sich hierdurch Netzwerkprobleme. Kleinere Datenmengen funktionieren problemlos, Fragmente werden jedoch verworfen:
majestix:~# ping -s 4000 -c 3 61.172.194.154 PING 61.172.194.154 (61.172.194.154): 4000 data bytes 4008 bytes from 61.172.194.154: icmp_seq=0 ttl=242 time=1387.8 ms 4008 bytes from 61.172.194.154: icmp_seq=1 ttl=242 time=1398.7 ms 4008 bytes from 61.172.194.154: icmp_seq=2 ttl=242 time=1400.5 ms
Interessant sind hierbei auch die icmpseq_-Einträge. Hier kann erkannt werden ob z.B. ein Paket verloren gegangen ist oder ob sie eventuell in falscher Reihenfolge eintreffen.
ttl gibt dabei die TTL im IP-Header der Antwort an, d.h. hier kann leicht erkannt werden, dass vermutlich die TTL der Gegenstelle per default 255 ist und es 13 Router auf dem Weg gibt.
Interessant ist auch ein ping an die Broadcast-Adresse:
geschke@librarian 103 > ping -b 10.255.255.255 WARNING: pinging broadcast address PING 10.255.255.255 (10.255.255.255) from 10.0.1.20 : 56(84) bytes of data. 64 bytes from 10.0.1.20: icmp_seq=1 ttl=64 time=0.174 ms 64 bytes from 10.0.1.4: icmp_seq=1 ttl=255 time=0.362 ms (DUP!) 64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=0.614 ms (DUP!) 64 bytes from 10.1.9.47: icmp_seq=1 ttl=255 time=0.665 ms (DUP!) 64 bytes from 10.0.1.34: icmp_seq=1 ttl=64 time=0.760 ms (DUP!) 64 bytes from 10.0.1.40: icmp_seq=1 ttl=255 time=0.777 ms (DUP!) 64 bytes from 10.0.1.11: icmp_seq=1 ttl=64 time=0.850 ms (DUP!) 64 bytes from 10.2.2.2: icmp_seq=1 ttl=64 time=0.863 ms (DUP!) 64 bytes from 10.1.28.3: icmp_seq=1 ttl=64 time=0.927 ms (DUP!) 64 bytes from 10.0.1.18: icmp_seq=1 ttl=64 time=0.953 ms (DUP!) 64 bytes from 10.0.1.15: icmp_seq=1 ttl=255 time=0.957 ms (DUP!) 64 bytes from 10.0.1.8: icmp_seq=1 ttl=255 time=1.05 ms (DUP!) 64 bytes from 10.1.51.1: icmp_seq=1 ttl=64 time=1.08 ms (DUP!)
Hierbei gibt es DUP!, also doppelte Antworten. Das ist bei Broadcasts klar, da hier mehr als einer antworten kann. Die unterschiedlichen TTLs deuten auf unterschiedliche Betriebssysteme hin. Diese haben per default unterschiedliche TTL's. Das kann u.a. zum Fingerprinting, also dem Erkennen des Betriebsystems, verwendet werden, natürlich nur in Verbindung mit anderen Daten.
traceroute ist ein anderes Programm, dass mit ICMP-Meldungen arbeitet. Das Programm versucht die Route herauszufinden die ein Paket zum Zielsystem verwendet. Dazu werden entweder ICMP Echo Requests, mit der Option -I, oder UDP-Pakete, das ist die Voreinstellung, mit steigender TTL versendet.
Jeder Router auf dem Weg muss, bzw. sollte, eine Time Exceeded ICMP-Meldung zurücksenden wenn die TTL auf Null gesetzt werden muss bevor das Ziel erreicht wurde.
Wird mit einer TTL von 1 angefangen, so antwortet der erste Router. Danach wird die TTL auf 2 gesetzt und es antwortet der zweite Router. Dies geht solange weiter bis statt eines Time Exceeded ein Echo Reply, bei der ICMP Variante oder ein Port Unreachable, bei der UDP-Variante, zurückkommt.
majestix:~# traceroute -I -n www.heise.de traceroute to www.heise.de (193.99.144.85), 30 hops max, 38 byte packets 1 192.168.178.1 1.380 ms 2.525 ms 1.682 ms 2 217.0.116.77 53.247 ms 51.613 ms 51.648 ms 3 217.0.69.130 48.285 ms 46.613 ms 47.662 ms 4 62.154.27.234 47.258 ms 47.631 ms 48.679 ms 5 212.19.63.105 49.232 ms 46.629 ms 47.651 ms 6 213.83.57.57 55.259 ms 53.622 ms 57.652 ms 7 193.99.144.85 58.311 ms 57.567 ms 56.661 ms
Es werden jeweils drei Pakete gesendet und die Zeit gemessen bis eine Antwort eintrifft. Drei Pakete deshalb, weil einzelne Pakete durchaus verloren gehen können.
Bei der UDP-Variante werden auch drei verschiedene UDP-Ports verwendet, normalerweise 33434 und aufsteigend.
Dieses Protokoll ist eigentlich jünger als TCP, das besagt schon die Protokoll-Nummer: 17, TCP hat die Protokoll-Nummer 6. Definiert ist dieses Protokoll in RFC 768 bzw. in RFC 1122.
TCP ist ein recht aufwendiges und umfangreiches Protokoll. Als eine Alternative hierzu war UDP gedacht. Dieses Protokoll ist unzuverlässig, was die Zustellung von Daten betrifft. Im Gegenzug ist es dafür sehr schnell mit wenig Overhead.
Es verwendet wie TCP Ports um Verbindungen zu definieren. Die Absendeadresse, der Absendeport, die Zieladresse sowie der Zielport charakterisieren eine UDP Verbindung vollständig. UDP-Pakete die dieses Quadrupel enthalten gehören alle zu der einen, gleichen, Verbindung.
Der Aufbau eines UDP-Paketes ist sehr einfach:
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| Source Port | Destination Port|
+--------+--------+--------+--------+
| Length | Checksum |
+--------+--------+--------+--------+
| data octets ...
+---------------- ...
Es gibt wie bereits erwähnt einen Quellport, Source Port, und einen Zielport, Destination Port. Ferner wird die Gesamtlänge des Paketes sowie die Checksumme über das UDP-Paket mit angegeben. Danach folgen bereits die Nutzdaten des Protokolls.
Ports kleiner 1024 werden als priveligierte Ports bezeichnet. Als Ziel- bzw. Absendeport können diese unter Unix nur vom Benutzer root geöffnet werden.
Bekannte UDP Dienste und Ports sind z.B.: DNS (53), DHCP (67/68), TFTP (69), NTP (123), WINS (137) oder SNMP (161).
In der Regel wird UDP für kleine Datenmengen eingesetzt bei der keine zuverlässige Verbindung notwendig ist oder bei großen Datenmengen, die schnell transportiert werden müssen und/oder der Verlust einzelner Pakete kein Problem darstellt.
So ist z.B. der Verlust eines UDP-Paketes bei Streaming Audio eher unwichtig, es gibt vielleicht einen kleinen Aussetzer/Knack in der Übertragung. Eine Verzögerung aufgrund eines Neusendens des Paketes wäre hier nicht akzeptabel.
Das ist wohl das komplexeste Protokoll im Rahmen von TCP/IP.
Genau wie UDP verwendet TCP Ports um Verbindungen zuzuordnen. Es ist ein verbindungsorientiertes und zuverlässiges Netzwerkprotokoll mit der Nummer 6. Diese Eigenschaften führen aber auch zu der Komplexität.
Definiert ist dieses Protokoll u.a. in RFC 793, RFC 896 (Nagle Algorithmus), RFC 1122, RFC 1323 (Window Scale und Timestamp), RFC 2018 (SACK), RFC 2581 (TCP Congestion Control), RFC 3168 (ECN).
TCP verwendet ein sogenanntes Handshake-Verfahren zum Verbindungsaufbau. Dabei verwendet es spezielle Bits, Flags genannt, aus dem TCP-Header.
TCP-Pakete werden von der Gegenstelle mit einem speziellen Flag dem ACK, acknowledgement, Bestätigung, quittiert. Der Aufbau erfolgt durch ein SYN-Flag, synchronize:
Da drei Schritte involviert sind heißt das auch Three-Way-Handshake.
Der Abbau einer Verbindung erfolgt ähnlich, diesmal kommt das FIN-Flag, finalize, zum Einsatz:
Sollte die Gegenstelle noch kein ACK gesendet haben, so ist die Verbindung noch halboffen, d.h. in eine Richtung können noch Daten fließen. Das kommt z.B. bei Webbrowsern durchaus vor: Nachdem der Request, also die Mitteilung welche Seite gewünscht ist, abgesetzt ist, kann die Verbindung vom Client geschlossen werden. Es kommen danach nur noch Daten vom Server über die halboffene Verbindung.
TCP besitzt verschiedene Verbindungszustände und kann dynamisch den Datenfluss kontrollieren. Verbindungen werden entweder aktiv, d.h. vom Client, oder passiv, d.h. vom Server, geöffnet.
hier ist jetzt der TCP-Header, er ist ein wenig komplexer als der von UDP:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Source Port | Destination Port |
+-------------------------------+-------------------------------+
| Sequence Number |
+---------------------------------------------------------------+
| Acknowledgment Number |
+-------+-------+-+-+-+-+-+-+-+-+-------------------------------+
| Data | |C|E|U|A|P|R|S|F| |
| Offset| Reserv|W|C|R|C|S|S|Y|I| Window |
| | |R|N|G|K|H|T|N|N| |
+-------+-------+-+-+-----------+-------------------------------+
| Checksum | Urgent Pointer |
+-------------------------------+---------------+---------------+
| Options | Padding |
+-----------------------------------------------+---------------+
| data |
+---------------------------------------------------------------+
Die Zahlen geben die Bit-Positionen an.
Als erstes kommen der Source und Destination Port genau wie bei UDP. Daher werden bei ICMP Fehlermeldungen immer die ersten 8 Bytes der ursprünglichen IP-Payload mitgesendet, diese enthalten die UDP oder TCP Ports.
Danach folgt eine Sequenznummer gefolgt von der Acknowledgementnummer, diese sind wichtig für die Dateneinordnung.
Der Data Offset beinhaltet einen Zeiger auf den Anfang der Nutzdaten, Payload, des TCP-Paketes. Dann folgen ein paar reservierte Bits. Von diesen sind zwei freigegeben worden: CWR, Congestion Window Reduce, und ECN, Explicit Congestion Notificaton, diese dienen der Erkennung und der Reaktion auf verstopfte, congestion, Leitungen.
Danach folgen die klassischen Flags:
Es folgt ein Receive Window, Empfangsfenster, dieses gibt an wie groß der Empfangspuffer ist. Hiermit kann der Datenfluss aktiv gesteuert werden.
Die folgende Checksumme bezieht sich auf das komplette TCP-Paket, also TCP-Header und Payload.
Der Urgent Pointer wird nur beachtet, wenn das URG-Flag gesetzt ist. In diesem Fall zeigt es auf die eiligen Daten der Payload.
Letztendlich folgen noch mögliche TCP-Optionen sowie ein eventuelles Padding auf 32-Bit Grenzen. Den Abschluss bilden dann die Nutzdaten.
Eine TCP-Verbindung kann mehrere Zustände besitzen.
Dies wurde bereits kurz angedeutet, es geschieht durch den Three-Way-Handshake. Dabei muss aber noch einiges mehr beachtet werden als nur der Austausch von Flags:
Ab diesem Zeitpunkt ist die Verbindung eingerichtet, Zustand: ESTABLISHED.
Wichtig beim Aufbau ist die Zufälligkeit der anfänglichen Sequenznummer. Ist diese Vorhersagbar, so kann eine Verbindung leicht manipuliert werden.
empfangen worden sind, sie ist idealerweise gleich der gesendeten
_Sequenznummer_+_Payload-Länge_+1. *Diese Sichtweise gilt in beide Richtungen, es handelt sich um eine _Voll-Duplex_-Verbindung. *Durch die Bestätigungen via _Acknowledgmentnummer_ wird eine Übertragung garantiert, hieraus folgt die Zuverlässigkeit des Protokolls!
Beim Datenaustausch spielt das Window-Feld eine besondere Rolle. Diese gibt an wie groß der Empfangspuffer der Gegenstelle ist. Gleichzeitig besagt diese Größe aber auch wieviele Daten gesendet werden können bevor auf ein ACK-Flag der Gegenstelle zu den Daten gewartet werden muss. D.h. nicht jedes TCP-Paket muss mit einem ACK bestätigt werden.
Dazu mehr im Abschnitt Flusskontrolle.
Das ist jetzt leicht zu verstehen:
+---------+ ---------\ active OPEN
| CLOSED | \ -----------
+---------+<---------\ \ create TCB
| ^ \ \ snd SYN
passive OPEN | | CLOSE \ \
------------ | | ---------- \ \
create TCB | | delete TCB \ \
V | \ \
+---------+ CLOSE | \
| LISTEN | ---------- | |
+---------+ delete TCB | |
rcv SYN | | SEND | |
----------- | | ------- | V
+---------+ snd SYN,ACK / \ snd SYN +---------+
| |<----------------- ------------------>| |
| SYN | rcv SYN | SYN |
| RCVD |<-----------------------------------------------| SENT |
| | snd ACK | |
| |------------------ -------------------| |
+---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+
| -------------- | | -----------
| x | | snd ACK
| V V
| CLOSE +---------+
| ------- | ESTAB |
| snd FIN +---------+
| CLOSE | | rcv FIN
V ------- | | -------
+---------+ snd FIN / \ snd ACK +---------+
| FIN |<----------------- ------------------>| CLOSE |
| WAIT-1 |------------------ | WAIT |
+---------+ rcv FIN \ +---------+
| rcv ACK of FIN ------- | CLOSE |
| -------------- snd ACK | ------- |
V x V snd FIN V
+---------+ +---------+ +---------+
|FINWAIT-2| | CLOSING | | LAST-ACK|
+---------+ +---------+ +---------+
| rcv ACK of FIN | rcv ACK of FIN |
| rcv FIN -------------- | Timeout=2MSL -------------- |
| ------- x V ------------ x V
\ snd ACK +---------+delete TCB +---------+
------------------------>|TIME WAIT|------------------>| CLOSED |
+---------+ +---------+
Das Bild deutet schon ein wenig die Komplexität von TCP an.
TCP kann Keep Alives verwenden, d.h. wenn in einer vorgegebenen Zeitspanne, meistens 2 Stunden, keine Pakete auf einer Verbindung ausgetauscht werden kann getestet werden ob die Gegenstelle überhaupt noch aktiv ist. Dazu wird ein leeres TCP-Paket mit der letzten gültigen Sequenznummer gesendet. Reagiert die Gegenstelle hierauf, so ist die Verbindung noch aktiv, im anderen Fall kann sie geschlossen werden.
TCP kennt noch die Maximum Segment Size, MSS, diese ist analog der MTU bei z.B. Ethernet. Dies ist normalerweise die maximale Größe die an Nutzdaten transferiert werden können. Abhängig ist dieser Wert zum einen von der MTU des lokalen Netzwerkes bzw. der MRU, der Maximum Receive Unit, das entspricht der MTU der Gegenstelle. In diesem Fall wäre die MSS gleich
min(MTU,MRU) - Größe des IP-Headers - Größe des TCP-Headers
also bei Ethernet meist 1460 Bytes, 20 Bytes für den IP-Header ohne Optionen und 20 Bytes für den TCP-Header ohne Optionen.
Ferner hängt die MSS vom dem verfügbaren Sendepuffer, dem Empfangspuffer sowie der zu transportierenden Datenmenge oder der Häufigkeit der Daten ab. Es kann z.B. sein, dass geringere Datenmengen mit einer höheren Häufigkeit benötigt werden.
Den eigenen Sendepuffer kennt ein jedes System, den Empfangspuffer der Gegenstelle wird im Window Feld des TCP-Headers angegeben.
Die optimale MSS ist somit das Minimum all dieser Werte (buffer, MTU, MRU) oder gleich der Menge der gewünschten Daten pro Übertragung.
Da die MTU/MRU Werte hier nicht unwichtig sind macht TCP in der Regel von der Path-MTU discovery Gebrauch, hierbei wird die optimale MTU entlang des Weges ermittelt. Die optimale MTU gewährleistet, dass auf dem Weg zum Ziel auf IP-Ebene keine Fragmentation erfolgt.
Nun kann es natürlich vorkommen, das weniger Daten zu Senden sind als die MSS vorgibt. TCP sendet die Daten normalerweise erst wenn eine Maximum Segment Size voll ist.
Wenn die Applikation dem TCP-Stack mitteilt, dass die Daten vollständig sind und gesendet werden sollen so wird das zum Einen auch erledigt und zum Anderen wird das PSH-Flag gesetzt. So weiß die Gegenstelle, dass die Daten vollständig sind und an die Applikation weitergereicht werden können. Dies ist nicht gleichbedeutend mit dem Ende der Verbindung sondern eher damit, dass z.B. eine Anforderung vollständig formuliert worden ist und die Anwendung jetzt eine Antwort erwartet. Anderenfalls hätte man einen sogenannten dead-lock, d.h. die Anwendung wartet auf die Antwort dabei ist die Anforderung vom lokalen TCP-Stack noch nicht gesendet worden.
Gleiches gilt natürlich für die Gegenseite, hier könnte ein TCP-Stack einfach auf mehr Daten warten ohne die Anforderung, also die bereits empfangenen Daten, weiterzuleiten. Das PSH-Flag bewirkt dann, dass diese Daten bereits an die Applikation weiterzureichen sind. Theoretisch kann ein TCP-Stack solange mit der Weiterreichung warten bis der Empfangspuffer, also die Window Size, voll ist oder die Verbindung beendet wird.
Eine der Besonderheiten von TCP ist die Möglichkeit den Datenfluss zu kontrollieren. Der Empfangspuffer im Window-Feld des TCP-Headers spielt hierbei eine wichtige Rolle, gibt er doch an, wieviele Daten an die Gegenstelle gesendet werden können ohne das explizit auf ein ACK gewartet werden muss.
Zusätzlich gibt es aber noch die Technik des Sliding Windows. Dabei wird das nächste Segment bereits gesendet bevor das vorherige bestätigt wurde. Es wird also in Vertrauen auf ein noch eintreffendes ACK-Flag gesendet.
In diesem Zusammenhang gibt es noch das Delayed Acknowledgment. Hierbei wird dann nur ein ACK auf alle bisher erhaltenen Pakete gesendet. Die Acknowledgmentnummer besagt schließlich wieviele Daten schon angekommen sind. Das erhöht ebenfalls die Geschwindigkeit.
Wenn der Sender aber kein ACK bekommt, so geht er davon aus, dass das entsprechende TCP-Paket verloren gegangen ist und sendet es erneut. Um dies zu vermeiden schreibt RFC 1122 vor, dass ein ACK innerhalb von 0.5 Sekunden gesendet werden muss. Ferner sollte jedes zweite vollständige Segment via ACK bestätigt werden. Hier darf nicht vergessen werden, dass der Sendepuffer erst gelöscht werden darf wenn die Daten via ACK bestätigt wurden. Ansonsten müssen sie für einen möglichen Retransmit, also erneutem Senden, aufgehoben werden.
Das Silly Window Syndrom entsteht wenn aus dem Empfangspuffer von der Applikation immer nur ein paar Byte entnommen werden. Das würde dazu führen, dass ein sehr kleines Window verwendet wird. Dadurch können nur tröpfchenweise Daten übertragen werden wobei dann der Overhead durch die Protokoll-Header enorm ist.
Um dies zu vermeiden besagt RFC 1122, dass Systeme nur dann ein Fenster, Window, größer Null anbieten dürfen wenn der Empfangspuffer mindestens ein volles MSS groß ist oder mindestens die Hälfte einer normalen Fenstergröße hat. Wenn keiner dieser beiden Bedingungen erfüllt ist muss im Window-Feld der Wert Null stehen, d.h. es wird keine Datenübertragung an das System erlaubt.
Ähnliche Probleme kann es auch beim Sender der Daten geben wenn z.B. die Daten nur in kleinen Stücken gesendet werden, z.B. bei einer telnet-Sitzung. Dies führt ebenfalls zu erheblichem Protokolloverhead und kann gerade auf langsamen Leitungen zu Engpässen führen.
Eine Lösung für dieses Problem ist der in RFC 896 beschriebene Nagle Algorithmus. Hierbei sollen Segmente die kleiner als die MSS der Gegenstelle oder der PMTU sind solange zurückgehalten werden bis entweder alle vorherigen Segmente bestätigt sind oder ein volles MSS Segment versendet werden kann.
Deaktiviert wird der Nagle Algorithmus auf Applikationsebene indem beim Öffnen des Sockets die Option TCP_NODELAY angegeben wird. Dies wird also nicht global ein- oder ausgeschaltet und auch nicht basierend auf der Gegenstelle.
Leider kann dies aber auch zu Problemen führen wenn schneller Datenaustausch erforderlich ist, wie z.B. im LAN. Insbesondere bei Delayed Acknowledgments besteht hier oft ein Problem, hier wird das ACK erst gesendet, wenn zwei volle Segmente erhalten wurden oder der Timer abgelaufen ist oder Daten in Gegenrichtung gesendet werden.
Das kann auch zu einem Problem führen wenn große Datenmengen übertragen werden aber das letzte Paket klein ist. In diesem Fall wäre es gut, wenn z.B. die Applikation einer Bestätigung der erhaltenen Daten senden würde, denn dann ist das ACK automatisch inbegriffen.
Normalerweise enthält das Window-Feld die Größe des Empfangspuffers. Dadurch kann der Datenfluss aufgrund der eigenen Möglichkeiten gesteuert werden. Was passiert aber wenn der Engpass auf dem Weg liegt, z.B. eine langsame Modem-Verbindung ist involviert?
Dies kann an mehreren Faktoren erkannt werden:
Das deutet auf eine Verstopfung der Leitung hin. Aus diesem Grund führen die Systeme ein zweites Fenster: Congestion Window. Ähnlich dem Fenster für den Empfangspuffer beschreibt dieses wieviele Daten gesendet werden können bevor auf ein ACK gewartet werden muss. Dieses Fenster wird von der sendenden Station verwaltet.
Normalerweise sind die Fenster gleich groß, treten jedoch die oben beschriebenen Probleme auf, so muss das Congestion Window reduziert werden. Der begrenzende Faktor ist dann nicht der Empfangspuffer der Gegenstelle sondern die mögliche Sendegeschwindigkeit bei der keine Probleme auftreten.
Wie dieses Fenster verkleinert wird hängt vom Ereignis ab:
Slow Start ähnelt stark der Congestion Avoidance, der Unterschied liegt in der Geschwindigkeit der Vergrößerung des Congestion Windows.
Bei Slow Start wird mit einem MSS gestartet, wenn dieses bestätigt wird erhöht sich das Congestion Window um eine MSS. Danach werden zwei MSS Segmente gesendet. Wenn beide bestätigt werden vergrößert sich das Fenster jeweils um weitere bestätigte MSS, also in diesem Fall auf vier.
Handelt es sich um eine neue Verbindung so endet dieses Verfahren bei der Größe des Empfangspuffers. Wird dieses Verfahren aufgrund einer congestion angewendet, so endet es bei der Hälfte des Empfangspuffers. Dann geht das Verfahren in das der Congestion Avoidance über.
Die Congestion Avoidance arbeitet ähnlich, allerdings wird dabei das Congestion Window nur jeweils um ein MSS vergrößert wenn alle ACK's eingetroffen sind. In diesem Fall wächst das Fenster nur langsam und somit wird sich nur langsam an die Problemstelle der Verstopfung herangetastet.
Die Möglichkeiten der Flusskontrolle werden noch durch zwei weitere Verfahren ergänzt:
Wenn mehrere Pakete versendet werden aber nur für eines dreimal das gleiche ACK-Paket zurückkommt, so muss davon ausgegangen werden, dass nur dieses eine Paket verloren ging. Im Fall von Fast Retransmit wird dann nur diese eine erneut gesendet.
Wenn also z.B. die Pakete 1, 2, 3, 4 versendet werden, für Paket 1 ein ACK empfangen wird und danach zwei weitere ACK's gesendet werden, dass auf Paket 2 zeigt, also der ACK auf Paket 1 wird dreimal gesendet, so muss beim Fast Retransmit nur das Paket 2 erneut gesendet werden. Danach kann mit Paket 5 fortgefahren werden.
Die Idee hierbei ist, dass IP als Unterbau verwendet wird und es daher durchaus möglich ist, dass lediglich ein Paket verloren geht.
Beim Fast Recovery sendet die Gegenstelle in diesem Fall nach Erhalt des erneut gesendeten Paketes 2 ein ACK, dass auf Paket 5 zeigt, es werden dann also gleich die ersten 4 Pakete bestätigt.
Dies bedeutet aber auch, dass die Gegenstelle die Daten zwischenspeichern muss, die nicht sequentiell auf die alten Folgen. Dies kann durch die Verwendung von Selective Acknowledment, SACK, explizit bestätigt werden. Mehr dazu kommt später bei den TCP-Optionen.
Jetzt wird es ein wenig kniffelig: Acknowledgment Timer
TCP baut auf IP auf, d.h. alle Probleme die IP haben kann, betreffen auch TCP. Daher muss TCP um als zuverlässiges Protokoll Gültigkeit zu haben hierauf reagieren können.
Ein Problem ist dabei: Was tun, wenn ein IP-Paket verloren geht?
Die Antwort ist natürlich einfach, das Paket wird erneut gesendet. Damit kommen wir aber zur nächsten spannenden Frage:
Wann soll dann ein Paket neu gesendet werden?
Auch hier ist die Antwort scheinbar einfach: Wenn das ACK-Paket nicht eintrifft!
Nun ist klar worauf das hinausläuft, es muss ein Timer gepflegt werden, der wenn er abläuft dafür sorgt, dass ein Paket erneut gesendet wird, wenn das ACK ausbleibt.
Bei schnellen Leitungen ist ein kurzer Timer von großem Vorteil, bei langsamen Leitungen jedoch eher ein großer Timer. Schließlich gibt es, wie oben angedeutet, mehrere Verfahren die ein ACK bewusst verzögern werden kann.
Wie die Überlegungen schon verdeutlichen, ein globaler Timer für alle Verbindungen scheint nicht sinnvoll zu sein. Im LAN sollte der Timer deutlich kleiner sein als z.B. bei Internetverbindungen um den halben Globus.
Es gibt zwei Verfahren die dies wirklich pro Verbindung durchführen. Das eine nennt sich Van Jacobsen Algorithmus, das andere Karn Algorithmus.
Van Jacobsen verwendet Umlaufzeiten von Paketen. Ursprünglich wurden hierfür die Zeiten gemessen bis ein ACK eintrifft. Neuere Implementierungen verwenden die Timestamp-Optionen von TCP um diese Zeiten zu bestimmen.
Der Karn Algorithmus legt Wert darauf, dass aufgrund des zugrundeliegenden IP's es durchaus vorkommen kann, dass einzelne Pakete verloren gehen können. D.h. es ist durchaus normal, dass ein Paket abhanden kommt und es sollte deswegen der Timer nicht angepaßt werden.
Wird jedoch ein Paket aufgrund eines abgelaufenen Timers erneut gesendet, so schlägt Karn vor den Timer zu verdoppeln.
Es gibt gewöhnlich zwei Maxima, einmal für den maximalen Timerwert und einmal für die maximale Zahl der erneuten Zustellversuche. Bei Linux ist die maximale Zeit gewöhnlich 2 Minuten. Die maximalen Antwortpakete sind in /proc/sys/net/ipv4/ in den zwei Variablen tcp_retries1, dies sind meist 3 Antworten auf SYN-Anfragen und tcp_retries2, dies sind meistens 15 Antworten, danach wird aufgegeben.
Zur Übersicht gibt es noch einmal die Verfahren für die Flusskontrolle:
Spätestens jetzt sollte klar sein, warum TCP als ein komplexes Protokoll gilt. Dass TCP überhaupt funktioniert hängt vermutlich damit zusammen, dass; es am Anfang nur wirklich im BSD-Unix realisiert wurde und alle neueren Implementationen, sofern sie nicht direkt von BSD abstammen, sich gegen dieses bewähren mussten.
Die Größe des Optionenfeldes schwankt zwischen 0 und 40 Bytes. Die maximale Größe ist dabei durch dass TCP-Headerlength-Feld bestimmt. Dieses Feld kann einen Maximalwert von 15 * 32 Bit = 60 Bytes aufnehmen. Es können beliebig viele Optionen verwendet werden solange die Gesamtgröße die 40 Bytes nicht sprengt.
Alle definierten Optionen sind hier zu finden: http://www.iana.org/assignments/tcp-parameters
Alle Optionen haben ein Byte für die Art der Option gefolgt von einem Byte für die Länge der Option, außer den Optionen 0 und 1, die bestehen nur aus einem Byte der Art. Bei der Länge wird das Feld für die Art und das Längenfeld selber ebenfalls mitgezählt.
Die wichtigsten Optionen sind:
Art | Länge | Bedeutung | Referenz -----+-------+----------------------------+---------- 0 | - | End of Option List | [RFC793] 1 | - | No-Operation | [RFC793] 2 | 4 | Maximum Segment Size | [RFC793] 3 | 3 | WSOPT - Window Scale | [RFC1323] 4 | 2 | SACK Permitted | [RFC2018] 5 | N | SACK | [RFC2018] 8 | 10 | TSOPT - Time Stamp Option | [RFC1323]
Die Optionen 0 und 1 sind selbsterklärend, letztere wird für das Padding verwendet.
Die Funktion der MSS-Option sollte mittlerweile auch klar geworden sein, sie wird verwendet um die eigene MSS zu übertragen.
Die Window Scale Option dient dazu eine Skalierung des Window-Feldes einzuführen. Dieses kann normalerweise aufgrund der Feldgröße nur Werte bis 64 kB aufnehmen. Der Wert dieser Option wird verwendet um die Window Größe um entsprechend Zahl an Stellen nach links zu verschieben. D.h. ein Wert von 4 würde das Window um 4 Bits shiften, die Größe ist dann um den Faktor 2^4=16 größer als angegeben. Diese Option ergibt natürlich nur in Highspeed-Netzen wirklich Sinn.
SACK Permitted gibt an, ob das selective Acknowledgment verwendet werden darf oder nicht. Beim selective Acknowledgment können Daten bestätigt werden, die bereits empfangen wurden aber beim Einsortieren eine Lücke offenlassen, also ein Datenpaket davor fehlt.
Der Aufbau der eigentlichen SACK Option ist einfach, erst der Typ, in diesem Fall 5, dann folgt die Länge. Diese ist abhängig davon wieviele Blöcke bestätigt werden. Danach kommt der Start des ersten SACK-Blocks, gefolgt von dem Ende.
Zum Schluss gibt es dann noch die Timestamp-Option die besonders wichtig für den Acknowledgment Timer ist. Hier wird neben Typen und Größe der Option mit 4 Bytes ein Zeitstempel angegeben. Dies wird vom Sender des Paketes ausgefüllt, danach kommt der Zeitstempel der Gegenstelle, der im vorherigen Paket an erster Stelle stand.
Da jeder seine eigene Zeit selber hineinschreibt und diese im Antwortpaket wieder enthalten ist, kann jedes System die Latenz selber bestimmen. Die Zeiten müssen dafür nicht synchron sein.
Mit der Option -a und -t kann netstat alle TCP Ports auflisten die in Gebrauch sind:
majestix:~# netstat -an -t Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 192.168.178.2:53 0.0.0.0:* LISTEN tcp 0 0 192.168.1.5:53 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN tcp 0 0 192.168.178.2:37467 212.227.15.147:110 TIME_WAIT tcp 0 0 192.168.178.2:37466 212.227.15.147:110 TIME_WAIT tcp 0 0 127.0.0.1:37051 127.0.0.1:6010 ESTABLISHED tcp 0 0 127.0.0.1:6010 127.0.0.1:37051 ESTABLISHED tcp 0 0 192.168.1.5:22 192.168.1.18:46979 ESTABLISHED
In diesem Fall gibt es einige Server-Dienste die am Zustand LISTEN zu erkennen sind. Diese können unspezifiziert gebunden sein, d.h. die Local Address ist 0.0.0.0. Diese Dienste antworten auf allen verfügbaren Adressen.
Andere wiederum sind auf ein Interface gebunden, d.h. sie antworten nur wenn sie auch auf dieser Adresse angesprochen werden.
TIME_WAIT sind beendete Verbindungen. Dieser Zustand soll verhindern, dass diese Kombination an IP-Adressen und Ports zu schnell wiederverwendet werden können. Anderenfalls könnten Irrläufer der alten Verbindung die neue stören.
Die ESTABLISHED Verbindungen sind aktive, also derzeit in Gebrauch. Die Foreign Address gibt dabei die Gegenstelle an. Hier ist eine Besonderheit zu sehen: 127.0.0.1 zu 127.0.0.1, dies ist eine über ssh getunnelte X11-Sitzung.
Recv-Q gibt an wieviele Bytes empfangen wurden aber noch nicht von der Applikation abgerufen worden sind. Send-Q ist der umgekehrte Fall, es gibt die Zahl der Bytes an die von der Applikation in den Netzwerk-Stack geschrieben aber noch nicht gesendet worden sind.
Lsof zeigt z.B. an welches Programm einen Port geöffnet hat. Unter Unix ist fast alles eine Datei und list open files kann somit auch Daten über Verbindungen bzw. offene Ports ausgeben.
majestix:~# lsof -i TCP:25 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME sendmail 597 root 4u IPv4 1745 TCP *:smtp (LISTEN)
In diesem Fall listet lsof auf, welches Programm den TCP-Port 25 geöffnet hat. Es dürfte nicht erstaunlich sein, dass dies sendmail ist bzw. ein anderer Mailserver.
Schneidet den Datenverkehr über ein Interface mit. Ein extrem wichtiges und mächtiges Tool. Um allen Datenverkehr, der an der Karte vorbeikommt, lesen zu können muss die Ethernetkarte in den sogenannten promiscuous Modus versetzt werden. Ansonsten würde sie nur Daten lesen die für die Karte selber bestimmt sind. Dies erfolgt bei Linux aber mit dem Aufruf von tcpdump automatisch oder es muss explizit mit der Option -p deaktiviert werden.
Ähnlich wie tcpdump, nur graphisch, kann einige insbesondere höhere Protokolle mehr aufschüsseln. Das kann allerdings auch zu Sicherheitsproblemen führen. Ethereal kann tcpdump-Dateien verarbeiten, daher bietet es sich an diese mit tcpdump zu sniffen und dann unter einer nicht-root UID mit ethereal zu analysieren. Hier kann dann ein möglicher Exploit im Datenstream nicht mehr viel anrichten. Zum einen ist die Netzwerkverbindung nicht mehr aktiv, ethereal hat das Netzwerkinterface nicht geöffnet, noch kann viel angerichtet werden, da die UID ungleich 0 ist.
Diverse Parameter zu Netzwerken insbesondere TCP-Parameter wie Timer können hier eingestellt oder überprüft werden. Näheres steht bei der Kerneldokumentation im Quellbaum unter
linux/Documentation/filesystems/proc.txt
Es gibt zum Einen das telnet-Protokoll für Verbindungen zu entfernten Systemen. Der Client ist aber viel weitreichender einsetzbar. Insbesondere kann ein Port mit angegeben werden. Die meisten TCP-Verbindungen sprechen Klartext: Unix-Philosophie!
Ansonsten gibt die Aussage Connected immerhin an, dass eine Verbindung hergestellt werden konnte, d.h. auf der Gegenseite läuft auch ein Dienst der Verbindungen akzeptiert.
Ein Connection refused bedeutet dagegen, dass vermutlich kein Dienst läuft. Es kann auch passieren, dass der Verbindungsaufbau in einen Timeout läuft, dies deutet gewöhnlich darauf hin, dass entweder die Gegenstelle nicht online ist oder ein Paketfilter die Pakete verwirft.
Wie bereits erwähnt verwenden die meisten Protokolle Klartext. Hier ist z.B. der Test einer Verbindung zu einem Mailserver:
majestix:~# telnet mx00.schlund.de 25 Trying 212.227.15.150... Connected to mx-b.kundenserver.de. Escape character is '^]'. 220 mx-b.kundenserver.de (mxeu10) Welcome to Nemesis ESMTP server EHLO lug-erding.de 250-mxeu10.kundenserver.de pleased to meet you 250-PIPELINING 250-8BITMIME 250-SIZE 20971520 250 HELP QUIT
Das gehört irgendwie sowohl in den Bereich von IP als auch in den von TCP. Auf alle Fälle ist es etwas, was in den meisten Büchern über TCP/IP noch nicht erwähnt wird.
Definiert ist ECN, Explicit Congestion Notification, in RFC 3168. ECN ist sowohl Teil des IP-Headers als auch des TCP-Headers. Dazu sind zwei Bits (Bit 6 und Bit 7) aus dem Type-of-Service-Feld des IP-Headers umbenannt worden:
+-----+-----+
| ECN FIELD |
+-----+-----+
ECT CE [Obsolete] RFC 2481 names for the ECN bits.
0 0 Not-ECT
0 1 ECT(1)
1 0 ECT(0)
1 1 CE
Die Abkürzungen bedeuten hierbei:
Ein System, dass ECN unterstützt setzt entweder die Bits auf 01 bzw 10, je nach ECT Typ (1 oder 0). Wird ECN nicht unterstützt so müssen diese beiden Bits auf Null gesetzt sein. Diesen Wert benutzen die meisten alten, nicht-ECN Systeme für diese Bits und somit sollten keine Probleme zu erwarten sein.
Ein Router der einer Verstopfung unterliegt, also mehr Pakete eintreffen als er weiterleiten kann, muss diese in der Regel einfach löschen. Die einzige Möglichkeit bislang angemessen darauf zu reagieren besteht in der Generierung von ICMP Source Quench Mitteilungen an den Sender.
Mit ECN besteht jetzt die Möglichkeit gezielter zu reagieren bzw. den beteiligten Systemen eine bessere Möglichkeit einzuräumen darauf zu reagieren.
Erfährt ein Router in einem solchen Fall einen Überlauf an Paketen, so kann er anstatt es einfach zu Löschen das CE-Bit setzen und das an das Zielsystem weiterleiten.
Das Zielsystem erkennt nun, dass es auf dem Weg eine Verstopfung existiert. Allerdings betrifft dies den Sender und nicht den Empfänger, die Rückroute muss nicht gleich der Hinroute sein!
Damit der Absender informiert werden kann kommt jetzt der TCP-Header ins Spiel. Hier gibt es zwei Bits:
Das Zielsystem, dass das gesendete CE empfangen hat setzt im ACK-Paket das ECE-Bit. Damit wird der ursprüngliche Absender darüber informiert, dass auf dem Weg eine Congestion vorliegt. Dieses System kann nun darauf reagieren, vermutlich dadurch, dass das Congestion Window verkleinert wird. Um das Zielsystem darüber zu informieren, dass das ECE-Bit angekommen ist und darauf reagiert wurde setzt es in dem nächsten Paket das CWR-Bit.
Ist doch ganz einfach, oder?
Abschalten kann man ECN unter Linux via
echo 0 > /proc/sys/net/ipv4/tcp_ecn
Da hier sowohl im IP-Header als auch TCP-Header Bits gesetzt werden, die normalerweise nicht gesetzt sind, kann es bei einigen Paketfiltern oder Firewalls zu Problemen kommen.
Aber mittlerweile sollten sich alle darauf eingestellt haben, dass diese Eigenschaft existiert, das RFC ist vom September 2001.
Dirk Geschke, dirk@lug-erding.de
