bnacht schrieb:
Am 11.01.24 um 06:34 schrieb Manfred Haertel, DB3HM:
bnacht schrieb:
Am 10.01.24 um 11:41 schrieb Michael Behrens:
Wobei es mich nicht wundern würde, wenn das Problem wieder auftaucht, sobald das Gerät mit der MAC 48:df:37:67:92:a7 wieder im LAN auftaucht. Ich kann mir kaum vorstellen, dass sich wickedd Phantasie-MACs ausdenkt, um die Arbeit zu verweigern. Das Gerät ist seit gestern weg vom Netz! (Kabel ab) Sollte also nicht passieren.
Der ARP-Eintrag in anderen Systemen FÜR das abgeschaltete System bleibt aber manchmal länger erhalten, teilweise ewig.
Eigentlich sollte er nach einer konfigurierbaren Zeit (Minuten-Bereich) verschwinden, aber unter bestimmten Voraussetzungen scheint das nicht zu funktionieren.
Bislang hatte ich noch nicht die Muße, dem Problem mal nachzugehen. Aber ich habe das auch auf Netzen auf der Arbeit schon öfter beobachtet.
Und dann hilft natürlich ein Durchstarten des Netzwerkes, wenn dabei der ARP-Cache gelöscht wird...
... aber bis man den richtigen Switch findet ;-)
Der Switch hat damit höchstwahrscheinlich gar nichts zu tun. Der führt zwar auch eine Liste von MAC-Adressen, aber dafür, um zu wissen, welche MAC-Adresse er über welchen Port erreichen kann. Sieht er sie einmal "woanders", lernt er sofort um. Und wenn er die MAC-Adresse gar nicht kennt, schickt er die Pakete an selbige über ALLE Ports. Damit verteilt er die Pakete FAST immer so, dass sie am richtigen Ziel ankommen. Der einzig "kritische" Fall ist der, dass eine MAC-Adresse plötzlich an einem anderen Port hängt, sich aber selbst nicht regt. In dem Fall muss man also den "umgehängten" Knoten veranlassen, selber Traffic zu machen, dann ist wieder alles OK. Dein Problem war aber gar nicht auf der MAC-Ebene, sondern einen Layer höher auf der IP-Ebene. Ich vermute stark, dass der ARP-Eintrag für die ALTE IP auf dem Knoten noch da war, der die IP neu gekriegt hat und das die Probleme verursacht hat. Die ARP-Table auf dem Knoten und die MAC-Table auf den Switches sind zwei Dinge, die nichts miteinander zu tun haben. Die ARP-Table ist schlicht eine Zuordnung MAC<->IP und die Switches führen eine Zuordnung MAC<->Port und interessieren sich gar nicht für IPs. Du hattest aber ein Problem mit einer IP.
Wie geschrieben, das Problem hat sich erledigt. Entweder weil ein Cache irgendwo abgelaufen war, oder weil der Wickedd restart es erledigt hat.
Ohne es selber ausprobiert zu haben würde ich annehmen, dass ein Restart von Wicked die ARP-Table löscht.
Cached ESX eigentlich die einkommenden MAC-Adressen?
Kommt drauf an. :-) Das Console-Betriebssystem von ESX ist ja ein Linux und das hat denselben ARP-Cache wie jedes andere Linux auch (auch mit denselben Fehlern :-)). Aber das ist für Deine Frage vermutlich nicht relevant. Ansonsten hat man aber im ESX einen virtuellen Switch. Der läuft unter dem VMKernel von VMware, aber das ist auch kaum relevant, weil es eben ein Switch ist. Also hat der keinen ARP-Cache, aber einen MAC-Adress-Cache, um die Pakete richtig auf die Ports verteilen zu können (also in dem Fall an die richtigen VMs zuzustellen). Somit gilt wieder das oben genannte, also man hat nur ein Problem, wenn eine MAC plötzlich an einem anderen (virtuellen) Port hängt und sich ruhig verhält. Das hat aber mit Deinem Problem wohl wieder nichts zu tun. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel