Ich habe ein Szenario wie unten dargestellt.
Hier sind zwei Host-Rechner über einen Hub verbunden:
Ok, also Host-1 möchte Host-2 anpingen und ich habe Wireshark auf einem dritten Host eingerichtet, der mit demselben Hub verbunden ist. Jetzt sehe ich überraschenderweise 6 Pakete, damit ein einzelner Ping-Befehl funktioniert, obwohl es eigentlich 4 sein sollten. Hier ist, was ich von Wireshark sehe:
Was ich jetzt nicht verstehe, ist, warum die Pakete 5 und 6 generiert werden, obwohl das Ziel der ARP-Antwort den Absender-Mac bereits kennt.
Oder habe ich da etwas falsch verstanden, bitte helfen Sie mir.
Antwort1
Ursprüngliche Antwort
Die erste Antwort kommt von der Hub-Schnittstelle, nicht von der Host-1-Schnittstelle. Beim Zurücksenden müssen Sie immer noch den Mac der Schnittstelle mit der IP von Host-1 kennen. Einige Switches tun dies automatisch, andere nicht.
Verbesserte Antwort:
.-----------.
| hub |
| |
[host-1 i1]+--+hi1 hi2+--+[i2 host-2]
| |
`-----------´
network interfaces:
i1, i2, hi1, hi2
Nachdem über eine IP-Adresse in der Anwendungsschicht etwas von Host 2 an Host 1 gesendet wurde, kommt die erste Antwort an Host 2 (und alle nachfolgenden Antworten) von der hi2
Schnittstelle und nicht von der i1
Schnittstelle in Host 1.
Um irgendetwas an die bereits bekannte IP von Host-1 zu senden, muss Host-2 noch wissen, wohin Pakete auf der Verbindungsschicht gesendet werden sollen. Dazu muss Host-2 die MAC-Adresse der Schnittstelle anfordern, die die IP von Host-1 enthält.
Einige Switches führen diese Art der Übersetzung automatisch durch - sie merken sich den Mac-Pfadrückwärts. Die meisten Hubs tun dies nicht, daher die zweite Anfrage.
Antwort2
Ich glaube, die gegebene Antwort ist falsch. Meiner Meinung nach tritt das Phänomen aufgrund der ARP-Implementierung des Linux-Kernels auf, um veraltete ARP-Einträge zu finden/vermeiden. Sobald die MAC-Adresse des Absenders bekannt ist, aktualisiert es den lokalen ARP-Cache beim Empfänger und setzt den Eintrag mit dem Status „VERZÖGERT“ ab. Nach einer Wartezeit von ca. 5 Sekunden (Standard, kann in geändert werden delay_first_probe_time
) prüft der Empfänger die Erreichbarkeit und stellt dann fest, dass der Host nun als „ERREICHBAR“ gilt.
Weitere Details finden Sie hier:
https://osqa-ask.wireshark.org/questions/15792/arp-replies-appear-with-delay-in-wireshark-output/