ARP - Address Resolution Protocol
|
 |
Für das Verständnis sollte man vorher die beiden Themen
IP-Adressen
und
MAC-Adressen
durchlesen.
Zu spät, schon geht es ins Eingemachte (grins). Das ARP-Protokoll ist absolut notwendig
um überhaupt andere PCs im Ethernet-LAN erreichen zu können. Wie aus den beiden
anderen Themen schon bekannt, ist die MAC-Adresse für die physikalische Adressierung der
Netzwerkkarte und die IP-Adresse für die logische Adressierung des PCs zuständig.
Nun nutzt einem eine IP-Adresse recht wenig, wenn man den PC nicht über die Physik
adressieren kann. Aber im PC wird nun leider nur die IP-Adresse eingetragen. Wie kommt man
also an die MAC-Adresse? Antwort: über das Address Resolution Protocol.
Wenn man einen PC mit einem Ping erreichen will, so ist die Antwortszeit beim ersten Paket
etwas länger.
<![CDATA[shogun:~ # ping -c4 10.10.0.23
PING 10.10.0.23 (10.10.0.23) 56(84) bytes of data.
64 bytes from 10.10.0.23: icmp_seq=1 ttl=64 time=0.232 ms
64 bytes from 10.10.0.23: icmp_seq=2 ttl=64 time=0.107 ms
64 bytes from 10.10.0.23: icmp_seq=3 ttl=64 time=0.102 ms
64 bytes from 10.10.0.23: icmp_seq=4 ttl=64 time=0.109 ms
--- 10.10.0.23 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.102/0.137/0.232/0.055 ms]]>
Wenn man danach noch einmal pingt, ist das Phänomen allerdings verschwunden
<![CDATA[shogun:~ # ping -c2 10.10.0.23
PING 10.10.0.23 (10.10.0.23) 56(84) bytes of data.
64 bytes from 10.10.0.23: icmp_seq=1 ttl=64 time=0.114 ms
64 bytes from 10.10.0.23: icmp_seq=2 ttl=64 time=0.111 ms
--- 10.10.0.23 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.111/0.112/0.114/0.010 ms]]>
Das liegt daran, das der Quell-PC erst einmal die MAC-Adresse des Ziel-PCs herausfinden muß.
Auf dem Netzwerk sieht das dann so aus ..
<![CDATA[shogun:~ # tcpdump -v -i eth0
tcpdump: listening on eth0
19:56:38.761950 arp who-has 10.10.0.23 tell 10.10.0.20
19:56:38.762039 arp reply 10.10.0.23 is-at 0:c:76:6c:91:86
19:56:38.762057 10.10.0.20 > 10.10.0.23: icmp: echo request (DF) (ttl 64, id 539, len 84)
19:56:38.762149 10.10.0.23 > 10.10.0.20: icmp: echo reply (ttl 64, id 62772, len 84)]]>
Das sind die Datenpakete in der kurzen Form (Ich hab ja gesagt, es geht ins Eingemachte ;-) .
Etwas ausführlicher mit Ethereal mitgelesen sieht das dann so aus ...
<![CDATA[Frame Number: 1 (Packet Length: 42 bytes)
|
`-- Ethernet II
Destination: ff:ff:ff:ff:ff:ff (Broadcast)
Source: 00:02:3f:bd:c6:44 (CompalEl_bd:c6:44)
Type: ARP (0x0806)
|
`-- Address Resolution Protocol (request)
Sender MAC address: 00:02:3f:bd:c6:44 (CompalEl_bd:c6:44)
Sender IP address: 10.10.0.20 (10.10.0.20)
Target MAC address: 00:00:00:00:00:00 (00:00:00_00:00:00)
Target IP address: 10.10.0.23 (10.10.0.23)
Frame Number: 2 (Packet Length: 60 bytes)
|
`-- Ethernet II
Destination: 00:02:3f:bd:c6:44 (CompalEl_bd:c6:44)
Source: 00:0c:76:6c:91:86 (Micro-St_6c:91:86)
Type: ARP (0x0806)
|
`-- Address Resolution Protocol (reply)
Sender MAC address: 00:0c:76:6c:91:86 (Micro-St_6c:91:86)
Sender IP address: 10.10.0.23 (10.10.0.23)
Target MAC address: 00:02:3f:bd:c6:44 (CompalEl_bd:c6:44)
Target IP address: 10.10.0.20 (10.10.0.20)
Frame Number: 3 (Packet Length: 98 bytes)
|
`-- Ethernet II
Destination: 00:0c:76:6c:91:86 (Micro-St_6c:91:86)
Source: 00:02:3f:bd:c6:44 (CompalEl_bd:c6:44)
Type: IP (0x0800)
|
`-- Internet Protocol, Src Addr: 10.10.0.20 (10.10.0.20), Dst Addr: 10.10.0.23 (10.10.0.23)
Protocol: ICMP (0x01)
|
`-- Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Data (56 bytes)
Frame Number: 4 (Packet Length: 98 bytes)
|
`-- Ethernet II
Destination: 00:02:3f:bd:c6:44 (CompalEl_bd:c6:44)
Source: 00:0c:76:6c:91:86 (Micro-St_6c:91:86)
Type: IP (0x0800)
|
`-- Internet Protocol, Src Addr: 10.10.0.23 (10.10.0.23), Dst Addr: 10.10.0.20 (10.10.0.20)
Protocol: ICMP (0x01)
|
`-- Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Data (56 bytes)]]>
Vor dem ersten Ping wird also eine Anfrage als Broadcast (Rundruf) auf das Netz geworfen um nachzufragen, wer
die IP-Adresse 10.10.0.23 hat. Eine Netzwerkkarte nimmt ja außer an ihre eigene MAC-Adresse auch Pakete
an, die an die Broadcast-Adresse FF:FF:FF:FF:FF:FF gehen. Im Anhang des Anfragepaketes (Request) ist die
Ziel-IP-Adresse noch mit der MAC-Adresse 00:00:00:00:00:00 verzeichnet (unbekannt). Die Quell-IP und Quell-MAC
sind aber vollständig eingetragen.
Der Ziel-PC liest diese ARP-Anfrage jetzt mit und erkennt seine eigene IP-Adresse in der Anfrage. Darauf generiert
er aus dem Anfrage-Paket ein Antwort-Paket (Reply) in dem er die Quell- und Ziel-Adressen vertauscht. Nachdem der
Ziel-PC das Feld mit der MAC-Adresse 00:00:00:00:00:00 durch seine eigene MAC ersetzt hat, wird das ARP-Paket
zurückgesendet. Nun weiß der Quell-PC die MAC-Adresse, die zur Ziel-IP 10.10.0.23 gehört. Der
Ziel-PC hat sich natürlich auch gleich die MAC des Quell-PCs in seiner ARP-Tabelle gemerkt. Abfragen
kann man die Tabelle wie folgt ...
<![CDATA[shogun:~ # arp -an
? (10.10.0.23) at 00:0C:76:6C:91:86 [ether] on eth0]]>
Dieser Eintrag bleibt je nach Konfiguration des Hosts (PC, Router, Printserver, ...) zwischen 5 Minuten
und mehrere Stunden erhalten und ist eine Quelle für wunderbare Fehler. Wenn eine Ziel-IP im flachen
(nicht gerouteten) Netz mit einem Ping im Netz von manchen PCs erreichbar ist und von manchen anderen nicht,
liegt das mit hoher Wahrscheinlichkeit an der ARP-Tabelle der Systeme. Dann sind wohl noch Einträge
vorhanden die einer IP-Adresse eine nicht mehr vorhandene MAC-Adresse zuordnen. Entweder man bootet das
oder die entsprechenden Systeme dann neu durch (relativ drastisch) oder entfernt die Einträge von
Hand mit "arp -d"...
<![CDATA[shogun:~ # arp -an
? (10.10.0.23) at 00:0C:76:6C:91:86 [ether] on eth0
shogun:~ # arp -d 10.10.0.23
shogun:~ # arp -an
? (10.10.0.23) at <incomplete> on eth0]]>
Und schon ist der Eintrag gelöscht.
Noch einmal zum Verständnis: Die MAC-Adresse ist nur auf dem jeweiligen Netzwerk-Segment gültig!
Wenn man also ein Ziel in einem Netz auf der anderen Seite eines Routers erreichen will, so muß auf
jeder Seite des Router einmal eine ARP-Auflösung stattfinden. Was genau passiert, sieht man jetzt ...
<![CDATA[ __________ ______________________ ___________
| | | Router | | |
| Quell-PC |_______________| LAN-A LAN-B |_______________| Ziel-PC |
|10.10.0.20| |10.10.0.1 192.168.1.2| |192.168.1.9|
|__________| |______________________| |___________|
ping 192.168.1.9
(1) ARP-Request ---------->
<-------- (2) ARP-Reply
(3) Ping-Request -------------> (4) ARP-Request -------->
<-------- (5) ARP-Reply
(6) Ping-Request ------------->
<---------------- (8) Ping-Reply <------------------(7) Ping-Reply
Ziel erreicht]]>
Und hier alles nochmal im Netzwerk mitgelesen (Achtung! Es sind die Pakete von beiden Segmenten zu
sehen. Also nicht durcheinanderkommen.) ...
<![CDATA[(1) 11:11:07.420914 arp who-has 10.10.0.1 tell 10.10.0.20
(2) 11:11:07.422405 arp reply 10.10.0.1 is-at 0:20:af:e0:65:b8
(3) 11:11:07.422425 10.10.0.20 > 192.168.1.9: icmp: echo request (DF) (ttl 64, id 5765, len 84)
(4) 11:11:07.427219 arp who-has 192.168.1.9 tell 192.168.1.2
(5) 11:11:07.428531 arp reply 192.168.1.9 is-at 0:20:af:ef:4d:6c
(6) 11:11:08.437772 10.10.0.20 > 192.168.1.9: icmp: echo request (DF) (ttl 63, id 5766, len 84)
(7) 11:11:08.441372 192.168.1.9 > 10.10.0.20: icmp: echo reply (DF) (ttl 255, id 5766, len 84)
(8) 11:11:08.446421 192.168.1.9 > 10.10.0.20: icmp: echo reply (DF) (ttl 254, id 5766, len 84)
11:11:09.447778 10.10.0.20 > 192.168.1.9: icmp: echo request (DF) (ttl 64, id 5767, len 84)
11:11:09.450230 10.10.0.20 > 192.168.1.9: icmp: echo request (DF) (ttl 63, id 5767, len 84)
11:11:09.451534 192.168.1.9 > 10.10.0.20: icmp: echo reply (DF) (ttl 255, id 5767, len 84)
11:11:09.452476 192.168.1.9 > 10.10.0.20: icmp: echo reply (DF) (ttl 254, id 5767, len 84)
11:11:10.457780 10.10.0.20 > 192.168.1.9: icmp: echo request (DF) (ttl 64, id 5768, len 84)
11:11:10.460146 10.10.0.20 > 192.168.1.9: icmp: echo request (DF) (ttl 63, id 5768, len 84)
11:11:10.461448 192.168.1.9 > 10.10.0.20: icmp: echo reply (DF) (ttl 255, id 5768, len 84)
11:11:10.462390 192.168.1.9 > 10.10.0.20: icmp: echo reply (DF) (ttl 254, id 5768, len 84)]]>
Der Quell-PC erkennt anhand der Netzwerkmaske, daß das Ziel in einem anderen Netzsegment
liegt. Er holt sich also über die IP des Default-Gateways die zugehörige MAC-Adresse
(1+2). Die Ping-Anfrage ist dann allerdings Ende-zu-Ende-adressiert. Das Paket (3) hat also die
Quell-IP und Quell-MAC des Quell-PCs, die Ziel-IP des Ziel-PCs und die Ziel-MAC des Default-Gateways.
Die IP-Adressierung läft also von einem Ende der Verbindung zum anderen (Layer 3). Die
MAC-Adressierung ist dagegen nur auf dem jeweiligen Netzwerk-Segment (Layer2) gültig.
Ein Ping-Befehl setzt also schon einen relativ komplizierten Ablauf in Gang. Ich hoffe, ich habe damit
etwas mehr Licht in die Abläufe auf den Netzwerken gebracht.
Ein paar weitere Erklärungen auf sccweb.de :
Weitere empfehlenswerte Links :
Viel Spaß beim pingen und analysieren.
Erstellt am 06.08.2004