IP bzw. Mac Probleme in einem Automatisierungs-Netzwerk

    Liebe Kollegen,

    ich bräuchte mal Euer Schwarmwissen und bin am Verzweifeln, da ich keine Idee mehr habe. Es geht in diesem Fall nicht um VT. Aber Netzwerktechnik bzw. Windows und Netzwerktechnik.

    Ich habe leider kein passendes Unterforum gefunden. Falls jemand einen besseren Platz dafür hat, gerne dahin verschieben – Danke!

    Da das in einem VT Netzwerk auch passieren kann, würde mich interessieren, ob das jemand von Euch schon mal gesehen hat, oder eine Idee, von was es kommen könnte.

    Folgende Fakten: Netzwerk in einem Gebäude für die Automatisierungstechnik

    Ein Windows Server 2019 als Host auf dem läuft eine Hyper-V VM ebenfalls mit Windows Server 2019

    An beiden Servern sind über einen L2 Switch ca. 40 SPSen (Embedded PCs mit Windows CE) über IP Verbunden.

    Nun das Problem:

    Nach jedem Neustart der VM ist die ARP Tabelle am A……

    Dann haben immer ein paar der SPSen die selbe Mac wie eine andere SPS im Netz.

    Aber die Mac-Adresse der betroffenen SPS ist in Ordnung.

    Nach dem Löschen der ARP Tabelle (ARP -D) geht das so lange, bis man die VM wieder neu startet.

    Der Fehler sieht dann so aus:

    Nach dem löschen der ARP Tabelle:


    Was habe ich schon alles versucht:

    Hardware-Switch neu gestartet (der ist Managebar, aber ist nichts konfiguriert)

    Netzwerkkarte der VM gelöscht und neu hinzugefügt

    Virtuellen Switch in Hyper-V gelöscht und neu hinzugefügt

    Aktuelle Windows Updates installiert

    Mit mehreren Personen, denen ihr Hauptjob die Netzwerktechnik ist, gesprochen. Von denen hat das noch keiner gehört und keiner hatte so richtig eine Idee.

    Ach ja, dass Beste ist, das die Probleme nur in der VM bestehen. Auf dem Host auf dem die VM läuft, passiert das nicht.

    Mir fällt nichts mehr ein. Über eine Idee oder einen Tipp wäre ich mehr als dankbar!

    Ich würde auf den Netzwerktreiber in der VM oder den vSwitch im HyperV tippen.

    Nun muss ich sagen, dass ich mit HyperV normalerweise nicht arbeite, sondern mit VMware. Aber versuch doch mal, ob HyperV für die VM einen anderen Typ Netzwerkkarte zu emulieren und wechsle entsprechen den Treiber im Gast.

    ARP (MAC Adressen) ist Layer 2.

    Den Switch (Hardware) hast du schon getauscht auf Verdacht? Könnte sein, dass der eine Macke hat.

    Schon mal dort die Ports und da die MAC ausgelessen was da angeschlossen ist? Was passiert wenn man dort nach und nach die Geräte einsteckt?

    Wie ist der virtuelle Switch auf dem Hyper-V konfiguriert? Man kann im VSwitch MAC für die virtuellen Netzwerkadapter am Host vergeben. Evtl. gibt es da eine Kollision?

    Welche virtuelle Karte mit welchen Treibern?

    Hast du schon mal einen Host mit einer anderen VM aufgesetzt, z.B. Proxmox oder VMware?

    Letztendlich ist das OS des Host egal, solange die VM darauf läuft und das macht was sie soll.

    Funktioniert das auf einer nativen Maschine?

    Ich würde als erstes eine native Maschine aufsetzen und damit prüfen, ob das Netzwerk generell funktional ist oder ob es irgendwo eine Macke hat.

    Dann das ganze als VM und da dann eben andere, direkt auf dem Host aufsetzende VMs testen, wie z.B. VirtualBox. Kommt dem Hyper-V recht nahe. EInfach um zu sehen ob es da funktional wäre.

    Laut heisst nicht immer gleich gut und toll und wer schreit ist meist im Unrecht.

    Erstmal vielen Dank für die Antworten!

    Zitat von robert müller

    Ich würde auf den Netzwerktreiber in der VM oder den vSwitch im HyperV tippen.

    Nun muss ich sagen, dass ich mit HyperV normalerweise nicht arbeite, sondern mit VMware. Aber versuch doch mal, ob HyperV für die VM einen anderen Typ Netzwerkkarte zu emulieren und wechsle entsprechen den Treiber im Gast.

    Das geht bei HyperV meines Wissens nicht. Da gibt es nur einen virtuellen Adapter.

    Ich arbeite auch viel mit VMware (ESXi und Workstation). Und da kann man ja verschiedene Emualtionen verwenden.

    Zitat von yamaha4711

    ARP (MAC Adressen) ist Layer 2.

    Richtig

    Zitat von yamaha4711

    Den Switch (Hardware) hast du schon getauscht auf Verdacht? Könnte sein, dass der eine Macke hat.

    Schon mal dort die Ports und da die MAC ausgelessen was da angeschlossen ist? Was passiert wenn man dort nach und nach die Geräte einsteckt?

    Nein, das ist ein 24 Port SFP Switch. Habe keinen solchen Typen rumstehen. Und der Kunde ist öffentlich. Da kann ich nicht mal kurz einen auf Verdacht verkaufen.

    Die ganze Installation ist nicht von mir. Hat jemand anders gemacht.
    Und mal alles ausstecken wäre schon mal hilfreich. Muss ich aber an einem passenden Tag machen.

    Zitat von yamaha4711

    Wie ist der virtuelle Switch auf dem Hyper-V konfiguriert? Man kann im VSwitch MAC für die virtuellen Netzwerkadapter am Host vergeben. Evtl. gibt es da eine Kollision?

    Welche virtuelle Karte mit welchen Treibern?

    Sehr viel kann man da nicht einstellen. Auf welche physikalische Netzwerkkarte der Switch schaut, ob er auch vom Host gesehen wird. Solche Dinge. Aber nichts spezielles.

    Zitat von yamaha4711

    Hast du schon mal einen Host mit einer anderen VM aufgesetzt, z.B. Proxmox oder VMware?

    Letztendlich ist das OS des Host egal, solange die VM darauf läuft und das macht was sie soll.

    Nein, ist ein produktives System. Aber ich habe nochmal zwei weitere Server mit der selben Konfiguration in zwei benachbarten Gebäuden. Da funktioniert alles.

    Jetzt geht das Zitat einfügen nicht mehr. Komisch.

    Dann halt so:

    Funktioniert das auf einer nativen Maschine?

    Ja, auf dem Host auf dem die VM läuft, funktioniert es.

    Ah, falls du Wireshark auf der VM installieren kannst, schneide doch mal den ARP-Traffic nach dem Start mit

    Das wäre auf jeden Fall eine Idee.

    Hängen die 5 Endgeräte alle an ein- und demselben Switch oder sind da Switche kaskadiert oder gibt es einen zentralen Switch auf welchen andere per Uplink verbunden sind?

    Ich hatte schon das Problem dass eben in solchen Konstellationen ein Fehler in der Firmware die ARP Tabelle durcheinander brachte. Switch bzw. Firmware auf den Switchen upgedatet und Ruhe war.

    Laut heisst nicht immer gleich gut und toll und wer schreit ist meist im Unrecht.

    Die Geräte haben nahezu alle noch einen kleinen Hutschienen-Switch davor geschaltet.

    Die sind aber nicht managebar.

    Und von da geht es auf einen zentralen Switch.

    Da hängt auch der Server dran.

    Ich finde es halt merkwürdig, dass das Problem nur in der VM besteht.

    Der Host der VM hat damit keine Probleme.

    Es gibt da noch einen Service PC im Netz.

    Da muss ich mal schauen, wie es sich da verhält.

    Deswegen ja der Versuch mit einem anderen Hostsystem, also VirtualBox, Proxmox, VMware.

    Wurde der Host schon upgedatete oder eben eine 2. Maschine neu aufsetzen Die VM selbst kann man ja locker durch die gegend schieben.

    Laut heisst nicht immer gleich gut und toll und wer schreit ist meist im Unrecht.

    Ich hatte gestern noch mit meinem Kunden gesprochen. Der meinte, dass war früher auch schon so. Mit früher meinte er, bevor der Rechner virtualisiert wurde.

    Was hat das alte und das neue System gemeinsam?

    Die VM hat nach dem Wechsel auf das neue System die selbe IP bekommen, wie vorher der alte Server. Könnte es irgendwie an der IP hängen?

    Das muss ich auch testen. Ich gebe der VM mal eine andere IP.

    Mal sehen, ob der Fehler dann noch auftritt.

    Ich habe zwar von diesem Teufelszeug keine Ahnung, kann aber vielleicht ein paar ??? dazu steuern (verzeiht mir wenn das zu profan gedacht ist):

    Zitat von MiFa1969

    Der meinte, dass war früher auch schon so. Mit früher meinte er, bevor der Rechner virtualisiert wurde.

    • wurde der alte Rechner in die VM geklont, so dass evtl. der Fehler mitgewandert ist? Oder wurde die VM von Grund auf neu konfiguriert?
    • Wie sehen die Speicherroutinen für diese ARP-Tabellen aus? Verschluckt sich da etwas etwas? Kann man vllt. eine Initialisierung bei Neustart konfigurieren, wenn das als Workaround funktioniert?

    Ist jetzt ein Schuss ins Dunkle - aber hast du mal an allen Geräten die Uhrzeiten geprüft?

    Ich hatte da schonmal Fälle, bei denen eine arg verstellte Uhr bzw. welche, die sich selbst im Betrieb aufgrund Fehlkonstruktion verstellt haben komische Nebeneffekte hatten.

    Gerade in Verbindung mit DHCP und der gleichen kann das schon wirr werden.

    Du hast vollkommen recht, Uhrzeit ist in Netzwerken tatsächlich sehr wichtig.

    Da habe ich auch schon die tollsten Dinge erlebt.

    DNS und auch DHCP sind da sehr empfindlich, wenn die Uhren nicht synchron sind.

    Aber das passt. Daran liegt es leider nicht.

    Ich finde es gut, wenn ihr eure Ideen mitteilt. Irgendwann geht bestimmt die Lampe an und bringt Licht ins dunkle :) :thumbup: dafür*

    DNS und DHCP reagieren allergisch auf falsch gehende Uhren? Hab ich so noch nie erlebt, wüsste auch nicht, wieso.

    Haarig wird es eher bei so Sachen wie Kerberos-Tickets, Zertifikaten etc.

    Aber je nachdem, welche Subsysteme wo mit reinspielen, strahlt das tatsächlich manchmal in Bereiche aus, bei denen man es auf den ersten Blick nicht denken würde.

    Aber bei ARP fällt mir da selbst bei angrestrengtem Nachdenken kein Zusammenhang zur Uhr ein.

    Aber jetzt mal ein Gedanke:

    Wenn das früher schon so war bei einem quasi komplett anderen System, liegt der Schluss natürlich nahe, dass es irgendwo in den nicht veränderten Umständen liegt. IP-Adresse wäre da natürlich ein heißer Kandidat.

    Hängt zwischen dem betroffenen System und den Clients irgendeine Middlebox? Transparente Firewall auf L2 oder sowas? Oder ist vielleicht auf dem Router / der Firewall / whatever irgendwas konfiguriert a la wenn IP vom Server fragt, gib schon mal Antwort aus einer vordefinierten Liste?

    Zitat von robert müller

    DNS und DHCP reagieren allergisch auf falsch gehende Uhren? Hab ich so noch nie erlebt, wüsste auch nicht, wieso

    Es ist genau genommen DNS in Verbindung mit AD.

    AD ist da extrem empfindlich.

    Wir hatten mal in unserem Büro extreme Probleme mit Zugriffen auf Dateifreigaben der Server.

    Nach langer Fehlersuche lag es an einer falschen Uhrzeit im L2 Switch.

    Auf dem Switch sind mehrere VLANs und ein DNS Relay leitet die DNS Anfragen der Clients weiter.

    Und durch die falsch Uhrzeit im Switch wurden die DNS Anfragen vom AD abgelehnt.

    Das hat aber mit dem ARP Problem sicher nichts zu tun.

    Zitat von robert müller

    Hängt zwischen dem betroffenen System und den Clients irgendeine Middlebox? Transparente Firewall auf L2 oder sowas? Oder ist vielleicht auf dem Router / der Firewall / whatever irgendwas konfiguriert a la wenn IP vom Server fragt, gib schon mal Antwort aus einer vordefinierten Liste?

    Nein, das ist ein ganz flaches Netz. Ich habe auf den Servern auch schon alles abgeschaltet, was da eventuell reinspuken könnte.

    Aber das mit der IP Adresse kommt mir verdächtig vor.

    Ich würde auch gerne zum Test mal den zentralen Switch tauschen. Aber da fehlt es zur Zeit an einem passenden Gerät.