Falsche MAC-Adresse in der ARP-Tabelle von Windows

Question

In letzter Zeit hatte ich Probleme, bei denen falsche MAC-Adressen die ARP-Tabellen einiger Windows-VMs füllen, die in der Cloud eines Cloud-Anbieters laufen. Wenn ich beispielsweise 10.1.2.3 anpinge, zeigen einige Windows-VMs eine andere MAC-Adresse an als die Mehrheit der anderen VMs. Das Ergebnis ist, dass diese wenigen Windows-VMs 10.1.2.3 nicht erreichen können, der Rest der VMs (sowohl Windows als auch Linux) jedoch schon.

Nach dem Ausführen von Packet Captures scheint die Quelle der falschen MAC-Adressen MS-NLB-PhysServer-XX_ zu sein, das inWiresharks veröffentlichte Liste. Ich verwende allerdings keine Art von MS-NLB, daher ist es sehr verwirrend, was die Quelle ist. Mein Cloud-Anbieter sagt, dass es nicht von ihm kommt. Meine Fragen sind:

1. Gibt es eine gute Möglichkeit, das Quellgerät anhand seiner MAC-Adresse zu identifizieren, wenn mir das Gerät nicht gehört? Ich frage mich beispielsweise, ob es von den Lastenausgleichsmodulen unseres Cloud-Anbieters kommt.
2. Aus welchen Gründen sendet dieses Quellgerät falsche MAC-Adressen an andere Geräte? Warum hat es beispielsweise die falsche MAC-Adresse für 10.1.2.3 und andere neu erstellte Netzwerkschnittstellen?
3. Was sind die Gründe dafür, dass nur eine Teilmenge der VMs die falschen MAC-Adressen aus dieser Quelle erhält, andere VMs im selben Subnetz aber gute MAC-Adressen aus anderen Quellen erhalten?

Answer 1

Wir sind auch darauf gestoßen, es passiert auf unseren EKS-Windows-Knoten, nachdem sie neu gestartet wurden. Wir haben Knoten, die einer Domäne für GMSA beitreten, was einen Neustart erfordert, sodass diese Instanzen das Problem sofort erkannten.

Ich habe ein Support-Ticket eröffnet und der angebotene Workaround besteht darin, ein Shutdown-Skript auszuführen, das Folgendes beinhaltet:

powershell.exe /c "get-hnsendpoint | remove-hnsendpoint"
exit

Der Ausgang sei wichtig, da er ein Hängenbleiben beim Herunterfahren für eine gewisse Zeit verhindere, hieß es.

Ich habe diese Antwort als Grundlage für die Automatisierung dieses Prozesses verwendet -https://stackoverflow.com/a/47709154

Answer 2

Wenn Ihnen das andere Gerät nicht gehört, gehe ich davon aus, dass es sich in einem völlig anderen Netzwerk befindet. In diesem Fall wird Ihnen nicht seine MAC-Adresse angezeigt, sondern die des Ihnen am nächsten gelegenen Geräts, das den Datenverkehr an das andere Endgerät weiterleitet.

Denken Sie daran, dass die End-to-End-Kommunikation nicht auf der Datenverbindungsebene (also Ebene 2) stattfindet.

Das wahrscheinlichste Szenario könnte sein, dass Ihr Routing falsch eingerichtet ist inmancheIhrer VMs und auf Betriebssystemebene und nicht in der Netzwerk-Routingtabelle Ihres Cloud-Anbieters ... oder sie befinden sich in unterschiedlichen Netzwerken (vielleicht AWS-Subnetz?) und haben unterschiedliche Routingtabellen.

Answer 3

Ich füge dies auch als Antwort hinzu.

Mehrere Cloud-Anbieter haben eineganzSie haben eine eigentümliche Sicht auf die Vernetzung und handhaben sie auf eine Art und Weise, die ein Netzwerkprofi einfach empörend finden würde; so arbeiten sie jedoch nun einmal und wir müssen damit einfach klarkommen.

In Azure ergeben MAC-Adressen einfach keinen Sinn; alle ARP-Tabelleneinträge verweisen immer auf 12-34-56-78-9a-bc, da das gesamte Azure-Netzwerk auf der IP-Ebene abgewickelt wird und ARP nicht existiert oder überhaupt nicht funktioniert; eine Azure-VM kann nicht einfach „Ich habe diese IP-Adresse“ (auch bekannt als „gratuitous ARP“) rufen, da die Azure-Plattform davon wissen muss, um den Verkehr an diese VM weiterzuleiten. Azure-Clustering funktioniert auf so seltsame Weise, dass Sie einen sehr ungewöhnlichen Lastenausgleich vor Ihren Cluster setzen müssen.

Ich weiß ehrlich gesagt nicht, wie das in AWS funktioniert, aber ich schätze, es ist genauso seltsam, wenn nicht sogar noch seltsamer.