3.5. ARP

ARP ist das Address Resolution Protocol, wie in RFC 826 beschrieben. ARP wird von Netzwerkgeräten verwendet, um die Hardwareposition/-adresse anderen Geräten im gleichen lokalen Netzwerk aufzulösen bzw. bekannt zu machen. Geräte im Internet werden in der Regel nach der Namensauflösung durch die IP-Adrese bekannt gegeben. Das ermöglicht es, dass ein Gerä,t im foo.com-Netzwerk mit anderen Geräten im bar.net-Netzwerk miteinander kommunizieren kann. Eine IP-Adresse sagt nichts ü,ber den physikalischen Standort des Geräts aus. Das ist der Punkt, an dem ARP ins Spiel kommt.

Benutzen wir ein einfaches Beispiel. Angenommen ich habe ein Netzwerk, zusammengesetzt aus mehreren Computern. Zwei dieser Computer im aktuellen Netzwerk sind Foo mit der IP-Adresse 10.0.0.1 und Bar mit IP-Adresse 10.0.0.2. Nun möchte Foo, mittels ping sehen, ob Bar noch lebt, aber Foo hat keine Ahnung wo sich Bar befindet. Nun wenn Foo beschliesst an Bar zu pingen, sendet er eine ARP-Anfrage (Request). Der ARP-Request ist so als ob Foo im Netzwerk schreien würde: "Bar (10.0.0.2)! Wo bist du?". Nun wird jeder Computer im Netzwerk Foo schreien hören, aber nur Bar (10.0.0.2) reagiert. Bar sendet eine ARP-Antwort (Reply) direkt zurück zu Foo, so in der Art: "Foo (10.0.0.1) Ich bin hier bei 00:60:94:E9:08:12.". Nach dieser einfachen Transaktion, mit der man um seinen Freund im Netzwerk zu findet, ist Foo in der Lage mit Bar zu kommunizieren, bis er (seinen ARP-Cache) vergisst, wo Bar ist (Unter Unix in der Regel nach 15 Minuten).

Nun wollen wir sehen, wie das funktioniert. Du kannst deine Computer so ä,hnlich in der aktuellen ARP(Nachbar)-Tabelle (ARP-Cache) sehen:

[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable

Du kannst sehen, dass mein Computer espa041 (9.3.76.41) weiß, wo er espa042 (9.3.76.42) und espagate (9.3.76.1) findet. Nun lass uns einen anderen Computer zum ARP-Cache hinzufügen.

[root@espa041 /home/paulsch/.gnome-desktop]# ping -c 1 espa043
PING espa043.austin.ibm.com (9.3.76.43) from 9.3.76.41 : 56(84) bytes of data.
64 bytes from 9.3.76.43: icmp_seq=0 ttl=255 time=0.9 ms

--- espa043.austin.ibm.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.9/0.9/0.9 ms

[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0 lladdr 00:06:29:21:80:20 nud reachable
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable

Nachdem espa041 versucht hat espa043 zu kontaktieren, wurde espa043's Hardwareadresse/-standort dem ARP(Nachbar)-Cache hinzugefügt. Also, bist der Eintrag von espa043 verfällt (als Resultat wenn keine Kommunikation zwischen beiden stattfindet), weiß espa041 wo er espa043 findet und muss keinen ARP-Request senden.

Lass uns espa043 aus den ARP-Cache löschen:

[root@espa041 /home/src/iputils]# ip neigh delete 9.3.76.43 dev eth0
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0  nud failed
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud stale

Jetzt hat espa041 wieder vergessen, wo er espa043 findet und muss, wenn er mit espa043 das nächste mal kommunizieren möchte, erneut einen ARP-Request senden. Sie können auch sehen, verglichen mit der obigen Ausgabe, espagate (9.3.76.1) wurde auf den Alt-Status (stale) geändert. Dies bedeutet, dass die angezeigte Stelle noch gültig ist, aber wird bei der ersten Transaktion zu diesem Computer bestätigt werden.