Warum erfordert eine PING-Antwort eine ARP-Anfrage für die MAC des ursprünglichen Hosts?

Warum erfordert eine PING-Antwort eine ARP-Anfrage für die MAC des ursprünglichen Hosts?

Ich habe ein Szenario wie unten dargestellt.
Hier sind zwei Host-Rechner über einen Hub verbunden:

Bildbeschreibung hier eingeben

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:

Bildbeschreibung hier eingeben

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 hi2Schnittstelle und nicht von der i1Schnittstelle 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/

verwandte Informationen