IT-Academy Logo
Sign Up Login Help
Home - Netzwerke - Protokolle - Adress Resolution Protocol



Adress Resolution Protocol

Das ARP Protokoll ist neben vielen andereren sehr elementär für Netzwerke. Hier werden Ip-Adressen in sogenannte MAC-Adressen umgewandelt. Dadurch werden Datenübertragungen in einem lokalen Segment ermöglicht.


Autor: Martin Puaschitz (onestone)
Datum: 23-01-2002, 19:05:54
Referenzen: Hall, Eric. A - Internet Core Protocols; O'Reily 2000
Schwierigkeit: Fortgeschrittene
Ansichten: 10931x
Rating: 5.7 (10x bewertet)

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]



3

1.1 Einführung

Sobald zwei Rechner in einem lokalen physischen Netzwerksegment miteinander kommunizieren wollen tritt das ARP Protokoll auf. Das ARP Protokoll ist also bei jeder wie immer geartenen Verbindung, auch wenn nur UDP-Pakete verschickt werden, in Aktion.

Um das Senden von Daten zu ermöglichen, muss die Hardware-Adresse der Netzwerkkarte herausgefunden werden, an die die Daten geschickt werden sollen. Jede Hardwareadresse ist weltweit einmalig und in der Netzwerkkarte fix verankert. Sie kann nicht geändert oder gelöscht werden und existiert jeweils nur einmal.

Sobald ein Gerät Daten an ein anderes Gerät senden möchte, welches im lokalen Segment liegt (was anhand der Subnetmask zu erkennen ist), wird eine Anfrage an alle Rechner im Segment geschickt. In dieser wird gefragt, wer die entsprechende IP-Adresse verwendet. Sobald der Rechner, der eben diese Adresse verwendet, diesen Broadcast empfängt, antwortet er mit einem weiteren ARP-Paket und teilt dem Broadcast-Sender seine Hardware-Adresse mit. Dies kann er dadurch, weil der Broadcast-Sender innerhalb des ARP-Paketes seine eigene Hardware-Adresse angibt, damit der Empfänger auch direkt zurückschicken kann (macht er dies nicht, entsteht eine Endlosschleife zwischen den beiden Rechnern da jeder ständig den anderen um die IP-Adresse bittet). Alle anderen Rechner die den Broadcast erhalten, aber nicht die eingetragene IP-Adresse verwenden, müssen dieses Paket ohne Antwort löschen.

Dieser Prozess ist in der Abbildung 3.7 nochmals dargestellt.

Hier schickt Ferret einen ARP-Request für die Hardware-Adresse von 192.168.10.40 über die Netzwerkspezifische Broadcast-Adresse 192.168.10.255. Sobald Froggy diese Anfrage empfängt, überprüft er ob er selbst 192.168.10.40 ist. Falls dies der Fall ist, schickt er ein Unicast an Ferret zurück (die ARP-Adresse hat er aus dem Broadcast) und teilt seine eigene Hardware-Adresse mit. Sobald Ferret diese Daten hat, können die beiden ohne weitere ARP-Pakete miteinander Daten austauschen.

ARP-Pakete beinhalten verschiedene Felder, wobei nur fünf davon genutzt werden, um das Grundprinzip von ARP zu ermöglichen: Die Hardware-Adresse des Senders, die IP-Adresse des Senders, die Hardware-Adresse des Empfängers, die IP-Adresse des Senders sowie ein Feld “Message-Type”, um Anfragen und Antworten zu unterscheiden.

Wenn ein Device eine Anfrage stellt, füllt es drei dieser Felder aus. Das leerstehende, die Hardware-Adresse des Empfängers, besteht bei dieser Art des Paketes nur aus Nullen.

Grafik 3.7

Wichtig zu erwähnen ist, dass es keine Timeouts für ARP-Pakete gibt. ARP kümmert sich um nichts anderes, als dass das Paket gesendet wurde. Erreicht es seinen Empfänger nicht, kümmert sich ARP nicht darum. Falls höhere Protkolle diese Anfragen gestellt haben, wie z.B. bei TCP, wird der Fehler sehr wohl bemerkt und ausgebessert (durch erneutes Schicken der Anfrage).

1.2. ARP Cache

Sobald das System des Senders die Hardware-Adresse des anderen Rechnern erhalten hat, wird sie lokal zwischengespeichert. Dies dient dem Vorbeugen von erneuten Anfragen, wenn IP wiederum Daten an dasselbe System senden möchte. Sobald dieser Fall eintritt, verwendet ARP nur die Daten aus dem lokalen Speicher.

Bei einer Anfrage sehen ja alle Empfänger die Hardware-Adresse des Senders. Die Systeme können hierbei vor dem Löschen des Datenpakets (welches ja nicht für sie direkt bestimmt ist) die IP-Adresse mit zugehöriger ARP-Adresse in ihrem lokalen Cache-Speicher sichern. Dies könnte auch das Löschen von anderen Einträgen aus Platzmangel hervorrufen. Aus diesem Grund werden nur bereits eingetragene Hardware-Adressen aktualisiert falls dies notwendig ist.

1.3. Cache size

Jedes System hat verschieden großen Speicher für seinen lokalen Cache. Manche Geräte werden sehr viele Einträge benötigen, also auch einen großen Speicher, damit nicht ständig die Einträge überschrieben werden. Andere hingegen werden nicht viele ARP-Einträge speichern müssen, weil sie nicht viele Geräte anfragen (z.B. in einem LAN mit wenigen Rechnern). Wenn ein Router einen großen Cache für diese Einträge hat, kann die Umsetzung natürlich viel schneller geschehen.

1.4. Cache timeouts

Sobald Einträge im Cache eine Zeitlang nicht genutzt wurden, löscht sie das Gerät automatisch aus seinem Speicher heraus. Dies ist deshalb so, weil Systeme IP-Adressen oder Netzwerkkarten getauscht bzw. geändert bekommen könnten. Dann würde der Router oder ein anderes Gerät Daten an die falsche Hardwareadresse und somit an den falschen Rechner schicken.

Diese Timeouts sollten allerdings auch nicht zu kurz gehalten werden, da sonst bei stark frequentierten Netzen eine große Netzwerkbelastung durch ARP-Pakete entsteht. Auch wenn jedes nur sehr klein ist, in Summe können Netzwerkadministratoren schnell bemerken, wie störend sie werden können.

1.5. Static caching

Eine weitere Möglichkeit ist, ARP-Einträge manuell in eine Datenbank zu schreiben. Somit müssten keine ARP-Pakete versendet werden. Allerdings funktioniert dann teilweise das Netzwerk (wenn es z.B. nur an einem Router angeschlossen ist) nicht mehr, sobald IP-Adressen oder Netzwerkkarten ausgetauscht werden und die Datenbank nicht dementsprechend geändert wird.

1.6. Proxy ARP

Manchmal ist es durchaus sinnvoll ein Gerät zwischen dem eigenen und dem restlichen Netzwerk zu haben, welches die ARP-Pakete für das eigene Gerät verwaltet. Dies könnte zum Beispiel ein Wähl-Rechner sein, welcher sich nur mit einem Router innerhalb des Netzwerkes verbindet. Dieser User würde die ARP-Anfragen innerhalb des Netzwerkes, die auch ihn betreffen, nicht sehen, da Sasquatch (siehe Abbildung 3.8) diese nicht weiterleitet (außer dieser Router wäre auch eine Bridge). Hier muss der Router oder Dial-In Server diese Arbeit übernehmen und dann intern die Daten korrekt an den jeweiligen User weiterleiten. Abbildung 3.8 verdeutlicht dies.

Der Dial-Client mit der IP 192.168.10.6 wählt sich über ein Modem ein. Sasquatch verwaltet seine Verbindung und gibt innerhalb des Netzes an, die IP-Adresse 192.168.10.6 zu haben, da er diese ja betreut. Sobald Daten für den Dial-Client von Ferret, Arachnid, Greywolf oder Froggy gesendet werden, erhält Sasquatch diese. Sasquatch leitet die Daten dann an den Dial-Client weiter. Dieses System funktioniert natürlich auch umgekehrt.

Ein Problem, welches hierbei auftreten könnte, stellt sich dann ein, wenn viele verschiedene Dial-Clients sich abwechselnd einwählen. Würde Rechner A eingewählt sein, die Verbindung aber wieder trennen (z.B. nach einem Mailaustausch) und sich an einem anderen Router erneut einwählen (mit gleicher IP-Adresse), würden alle Rechner im lokalen Segment die Daten an eine falsche Hardware-Adresse schicken wollen (nämlich an die von dessen erster Einwahl).

Grafik 3.8

1.7. Variationen

Bei ARP existieren verschiedene Arten, wie dieses Protokoll genutzt werden kann.

1.8. Inverse ARP

Inverse ARP funktioniert genauso wie das reguläre ARP, nur umgekehrt. Hier möchte ein Device die IP-Adresse zu einer Hardware-Adresse herausfinden.

1.9. Reverse ARP

Reverse ARP kann dafür verwendet werden, Rechner ohne Festplatte (die nur mit Diskette gestartet werden) mit ihrer eigenen Hardware-Adresse eine Anfrage bei einem zentralen Server stellen zu lassen, um eine gültige IP-Adresse zu erhalten.

1.10. DHCP ARP

Dies wird von Devices verwendet, die eine IP-Adresse von einem DHCP-Protokoll zugewiesen bekommen haben. Hier wird lediglich überprüft, ob nicht bereits ein anderes Gerät diese Adresse verwendet. Erhält der Sender keine Antwort, übernimmt er die Adresse. Erhält er eine Antwort, stellt er fest, dass ein Fehler vorliegt und sendet eine erneute Anfrage an seinen DHCP-Server.

1.11. Gratuitous ARP

Gratuitous ARP wird verwendet, um anderen Devices im lokalen Segment mitzuteilen, dass das sendende Device immer noch online ist. Hierbei werden keine besonderen Informationen außer den jeweiligen Adressen übertragen. Geräte, die die Adresse des Senders bereits in ihrem Cache haben, aktualisieren diese Daten, falls notwendig.

1.12. UnARP

UnARP bietet die Möglichkeit zur De-Registration von ARP-Einträgen. Wenn ein Device das Netzwerk verlassen möchte, kann es ein UnARP versenden (Broadcast), damit alle anderen Devices ihre Einträge über diesen Rechner aus deren Cache löschen.



[back to top]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04506
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16552
Queueeinträge:06241
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1140
Comments: 0