|
|
Zeile 27: |
Zeile 27: |
|
| |
|
|
| |
|
|
| |
| = TMP =
| |
| == Beschreibung ==
| |
| * Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebige Pfade.
| |
| * Treten dabei Fehler auf, kann ICMP den Absender informieren
| |
|
| |
| ; Mögliche Probleme
| |
| * Gerät oder Dienst ist nicht erreichbar
| |
| * Header-Daten wurden verfälscht
| |
| * die Lebenszeit (TTL) eines Datagramms ist abgelaufen
| |
| * die Pufferkapazität des Empfängers ist erschöpft
| |
|
| |
| ; OSI-Schicht 3
| |
| * Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist.
| |
| * ICMP nutzt somit das IP-Protokoll, als wäre es ein Protokoll einer höheren Schicht (im OSI-Modell), obwohl es eigentlich integraler Bestandteil des IP-Protokolls ist.
| |
|
| |
| ; Fehlerermittlung
| |
| {| class="wikitable sortable"
| |
| |+ Situationen, die eine ICMP-Fehlermeldung auslösen
| |
| |-
| |
| ! Grund !! Auslöser
| |
| |-
| |
| | Ziel nicht erreichbar (''Destination Unreachable'') || Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.
| |
| |-
| |
| | Zeit überschritten (''Time Exceeded'') ||
| |
| |-
| |
| | Ungültige Parameter (''Parameter Problem'') ||
| |
| |-
| |
| | Senderate reduzieren (''Source Quench'') ||
| |
| |-
| |
| | Umleitung im Netzwerk (''Redirect'') ||
| |
| |-
| |
| | Prüfung auf die Erreichbarkeit eines Gerätes ||
| |
| |-
| |
| | Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet ||
| |
| |-
| |
| | Ermittlung der maximalen Größe des Datagramms auf diesem Pfad ||
| |
| |}
| |
|
| |
| == Paketstruktur ==
| |
| === ICMP-Header ===
| |
| [[File:ICMP4.png|750px]]
| |
|
| |
|
| |
| ; Der ICMP-Header folgt direkt auf den IPv4-Header
| |
| * wird an der Protokollnummer erkannt
| |
| * Erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
| |
| * Länge: 8 Byte + Datenabschnitt variabler Größe
| |
|
| |
| : Format der ersten vier Bytes
| |
| * Mit dem ersten Byte wird der Typ der Nachricht kodiert.
| |
| * Das zweite Byte enthält einen, vom jeweiligen Typ abhängigen Code
| |
| * Das dritte und vierte Byte bilden eine Prüfsumme des Headers
| |
|
| |
| Die folgenden vier Bytes sind vom Typ der ICMP-Nachricht abhängig.
| |
|
| |
| {| class="wikitable toptextcells"
| |
| |-
| |
| ! Typ !! Typname !! Code !! Bedeutung
| |
| |-
| |
| | 0 || Echo Reply || 0 || Echo-Antwort
| |
| |-
| |
| |rowspan="7"| 3 || rowspan="7"| Destination Unreachable || 0 || Netzwerk nicht erreichbar
| |
| |-
| |
| | 1 || Host (Zielstation) nicht erreichbar
| |
| |-
| |
| | 2 || Protokoll nicht erreichbar
| |
| |-
| |
| | 3 || Port nicht erreichbar
| |
| |-
| |
| | 4 || Fragmentierung nötig, '''D'''on’t '''F'''ragment aber gesetzt
| |
| |-
| |
| | 5 || Route nicht möglich
| |
| |-
| |
| | 13 || Paket wird von der Firewall des Empfängers geblockt
| |
| |-
| |
| | 4 || Source Quench || 0 || Datagramm verworfen, da Warteschlange voll
| |
| |-
| |
| |rowspan="4"| 5 || rowspan="4"| Redirect Message || 0 || Benachrichtigung über eine Umleitung für das angegebene Netzwerk
| |
| |-
| |
| | 1 || Benachrichtigung über eine Umleitung für den ausgewählten Host
| |
| |-
| |
| | 2 || Umleitung für den angegebenen Dienst & das Netz
| |
| |-
| |
| | 3 || Umleitung für den angegebenen Dienst & den Host
| |
| |-
| |
| | 8 || Echo Request || 0 || Echo-Anfrage (Ping)
| |
| |-
| |
| | 9 || Router Solicitation || 0 || Suche nach einem Router
| |
| |-
| |
| | 10 || Router Advertisement || 0 || Bekanntmachung eines Routers
| |
| |-
| |
| |rowspan="2"| 11 || rowspan="2"| Time Exceeded || 0 || TTL (Time To Live, Lebensdauer) abgelaufen
| |
| |-
| |
| | 1 || Zeitlimit während der Defragmentierung überschritten
| |
| |}
| |
|
| |
| === ICMP-Daten ===
| |
| * Je nach Typ der ICMP-Nachricht haben die, sich dem ICMP-Header anschließenden Daten, einen unterschiedlichen Inhalt und sind verschieden strukturiert.
| |
| * Oft wird der IP-Header wiederholt und im Anschluss daran die ersten 64 Bit des ursprünglichen Datagramms.
| |
| * Damit wird dem Zielrechner die Zuordnung der Nachricht ermöglicht.
| |
|
| |
| == Anwendung ==
| |
| === ping ===
| |
| '''[[ping]]''' prüft die Verbindung zu einem Zielsystem, indem es einen '''Echo Request''' sendet und einen '''Echo Reply''' erwartet
| |
|
| |
| $ '''ping google.de'''
| |
| PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
| |
| 64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
| |
| 64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
| |
| 64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
| |
| 64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
| |
| 64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
| |
| ^C
| |
| --- google.de ping statistics ---
| |
| 5 packets transmitted, 5 received, 0% packet loss, time 4006ms
| |
| rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms
| |
|
| |
|
| |
| [[File:Ping.png|750px|none]]
| |
|
| |
| === Trace Route ===
| |
| Mit '''[[traceroute]]''' kann der Weg eine IP-Datagramms ermittelt werden
| |
| $ '''traceroute google.de'''
| |
| traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
| |
| 1 fritz.box (192.168.100.1) 0.450 ms 0.593 ms 0.743 ms
| |
| 2 ber1005dihr001.versatel.de (62.214.63.92) 12.670 ms 12.750 ms 12.693 ms
| |
| 3 62.214.37.245 (62.214.37.245) 13.746 ms 13.787 ms 13.825 ms
| |
| 4 62.214.37.130 (62.214.37.130) 23.674 ms 23.716 ms 62.214.37.158 (62.214.37.158) 41.595 ms
| |
| 5 72.14.222.28 (72.14.222.28) 22.010 ms 22.063 ms 89.246.109.250 (89.246.109.250) 29.791 ms
| |
| 6 108.170.251.145 (108.170.251.145) 26.073 ms 108.170.252.18 (108.170.252.18) 37.669 ms 108.170.252.19 (108.170.252.19) 24.852 ms
| |
| 7 209.85.245.203 (209.85.245.203) 18.491 ms 209.85.242.79 (209.85.242.79) 44.834 ms 209.85.244.219 (209.85.244.219) 23.396 ms
| |
| 8 ham02s17-in-f3.1e100.net (172.217.19.67) 18.911 ms 17.654 ms 19.136 ms
| |
|
| |
| Das Programm kann zur Analyse von Netzwerkproblemen genutzt werden
| |
| * Nimmt ein Paket den erwarteten Weg, oder kommt es über Umwege dorthin?
| |
| * Welche alternativen Wege beschreitet ein Paket beim Ausfall eines Netzknotens?
| |
| Es werden die Laufzeiten zwischen den einzelnen Stationen (Hops) ermittelt, so dass überprüft werden kann, ob es auf dem Weg zum Ziel zu Engpässen oder Überlastungen kommt.
| |
|
| |
| ==== Funktionsweise ====
| |
| [[File:ICMP-traceroute.png| 600px |right]]
| |
| Der Absender sendet eine ICMP-Nachricht vom Typ ''Echo Request'' an den Zielrechner.
| |
| * Von besonderer Bedeutung ist hierbei die Lebenszeit der Nachricht von eins (''TTL=1'').
| |
| Die nächste Station auf dem Weg zum Zielrechner vermindert den Wert von ''TTL'' um eins, so daß dieser Wert jetzt Null beträgt und die Nachricht daraufhin verworfen wird.
| |
| * Der Absender wird jedoch über diesen Vorgang informiert und erhält eine ICMP-Nachricht vom Typ ''time to live exceeded in transit'', die auch die IP-Adresse der Zwischenstation enthält.
| |
| Der Absender verschickt daraufhin erneut ein ''Echo Request'' an den Zielrechner - dieses Mal jedoch mit einer ''TTL'' von zwei.
| |
| * Somit erreicht die Nachricht die zweite Zwischenstation auf dem Weg zum Ziel, bevor auch diese verworfen und der Absender benachrichtigt wird.
| |
| Der Absender versendet nun weitere Nachrichten vom Typ ''Echo Request'' - und erhöht jeweils den Wert der Lebenszeit - bis der Zielrechner erreicht wird und eine ICMP-Nachricht vom Typ ''Echo Reply'' erhalten wird.
| |
|
| |
| Am Ende des Programmablaufs wird von ''traceroute'' eine nummerierte Liste erhalten, die die IP-Adressen der durchlaufenen Zwischenstationen und der dazugehörigen Laufzeiten enthält.
| |
|
| |
| === Path MTU Discovery ===
| |
| * Ermittlung der '''''M'''aximum '''T'''ransfer '''U'''nit'' zu einem entfernten IP-Netzwerk
| |
| * Muss von jedem Router unterstützt werden
| |
|
| |
| ''' Ermittlung der MTU '''
| |
| * Der Sender generiert ein IP-Paket mit der MTU des lokalen Netzes und gesetztem ''Don't Fragment''-Bit
| |
| * Wird auf dem Weg ein Transfernetz erreicht, dessen MTU überschritten wird, sodass dessen Router das Paket fragmentieren müsste, wird das Paket verworfen und der Absender durch eine ICMP-Nachricht vom Typ 3 Code 4 (''Destination Unreachable'',''Fragmentation required, and DF flag set'') benachrichtigt.
| |
| * Da der Absender nun die MTU der Gegenseite kennt, kann er die seine entsprechend anpassen und die Daten erneut versenden.
| |
|
| |
| === Umleitung im Netzwerk ===
| |
| [[File:ICMP-Redirect.png|600px|right]]
| |
|
| |
| Wird von einem Router bemerkt, daß es für ein IP-Paket einen schnelleren Weg zum Ziel gibt, kann er den Absender darüber informieren. Dies geschieht mit einer ICMP-Nachricht vom Typ ''Redirect'':
| |
| * Rechner '''B''' möchte Daten an Rechner '''A''' versenden und sendet diese an seinen Standard-Router '''R2''' (1)
| |
| * Router '''R2''' übergibt die Daten an Router '''R1''', der diese an den Zielrechner '''A''' weiterleitet (2)
| |
| * Router '''R2''' erkennt jedoch, daß es für Rechner '''A''' günstiger wäre, sich gleich an Router '''R1''' zu wenden und teilt ihm dieses durch eine ICMP-Nachricht vom Typ ''Redirect'' mit (3)
| |
| * Rechner '''B''' sendet fortan die Daten direkt zu Router '''R1''' (4)
| |
|
| |
|
| [[Kategorie:IPv4]] | | [[Kategorie:IPv4]] |
| </noinclude> | | </noinclude> |