IP bzw. Mac Probleme in einem Automatisierungs-Netzwerk

  • Nochmal ne andere Idee: Können die Automation Devices vielleicht zwei IP-Adressen haben und manche haben eine Zweitadresse drauf, die eigentlich ein anderes Gerät haben sollte? Das sollte zwar eigentlich allgemein für Chaos sorgen, aber das wäre ja so ne Art Race Condition. Vielleicht ist das Timing in dem Netzwerk zufällig so, dass es nur bei der VM auftritt.

    Ok, weit hergeholt...

  • Die meisten der Geräte haben zwei Netzwerkadapter. Die haben aber in der Regel keine IP Adresse, weil sie entweder nicht verwendet werden oder weil da ein Ethernet-Basierendes Bussystem dranhängt, dass keinen IP Stack verwendet.

    Und durch das es ein separater Netzwerkadapter ist, hat er auch eine andere Macadresse.

  • Vielleicht ist es die Software auf dem Server. Du sagst ja, es ist immer beim Start, nachweisen Refresh der Arp-Tabelle stimmt dann alles.

    Vielleicht hat der Entwickler ja gedacht, es wäre eine gute Idee, die Arp-Tabelle beim Start auf einen bekannten Zustand zu initialisieren, damit die Kommunikation schneller zustande kommt oder sowas.

    Das müsste man prüfen können. Einfach mal alle Endgerät abklemmen und den Server neu starten. Wenn dann die Einträge in der Tabelle auftauchen, weißt du, dass der Server das irgendwie selbst macht.

  • Theoretisch könnte das sein. Aber warum war es auf dem alten Server auch so?

    Jede Idee wird durch einen anderen Umstand wieder zerlegt.

    Ich werde in den nächsten Tagen mal noch ein paar Tests machen.

    Was ich auch nicht verstehe ist, dass es nur ein paar der Geräte sind, bei denen das passiert.

    Eines davon habe ich auch schon mit der aktuellen Firmware versorgt.

    Hat auch nichts geändert.

    Da sitzt irgendwo ein großer Wurm den ich nicht sehe ;(

  • Mal OT, dass System um das es hier geht (die Automatisierungsgeräte) ist von Beckhoff.

    Schätze mal, dass das viele in der VT Branche nicht kennen.

    Die haben sehr interessante Lösungen für den Bereich Licht und Bewegung.

    Hier mal ein Beispiel:



    Ohne hier Werbung machen zu wollen, könnte ich mir vorstellen, dass das viele Möglichkeiten bieten würden.

    Es gibt fast kein Protokoll aus dem Industrie-Umfeld bzw. Signalform wo das System nicht kann.

    Und bei Bedarf kann auch direkt C Code eingebunden werden.


    Wenn da jemand Interesse hat, mache ich gerne mal einen Thread und erkläre das ein wenig.

  • Theoretisch könnte das sein. Aber warum war es auf dem alten Server auch so?

    Configfile. Die wurden doch sicher vom alten Server übernommen.

    Meine Theorie ist: Es gibt die Option, in der Config eine Tabelle oder ähnlich mit Geräten, IP- und MAC-Adressen zu hinterlegen. Ein übereifriger Integrator hat damals bei der Ersteinrichtung des Systems eine solche eingepflegt. Zwischenzeitlich wurden IPs an den Geräten geändert und jetzt beißt dich der Ist-Stand mit der alten Config.


  • Der Extra Thread dafür klingt super.

    Das Haus in dem ich Arbeite soll nächstes Jahr Saniert werden, dafür wäre es also interessant.

    Aktuell wäre die Überlegung komplett auf Geräte von Chamsys zu setzen, vllt. wäre es aber ja so sinnvoller.

  • Der Extra Thread dafür klingt super.

    Das Haus in dem ich Arbeite soll nächstes Jahr Saniert werden, dafür wäre es also interessant.

    Aktuell wäre die Überlegung komplett auf Geräte von Chamsys zu setzen, vllt. wäre es aber ja so sinnvoller.

    Mache ich gerne. Gib mir ein bisschen Zeit, dann stelle ich was zusammen.

    Ich arbeite übrigens nicht bei dem Hersteller.

    Ich setze die Produkte aber seit über 20 Jahren ein.

    Du kannst damit so ziemlich jedes Bussystem anbinden und hin und her schieben.

    So was gibt es sicher auch als kleine Konverter.

    Aber hier kannst du eben viel Intelligenz reinbringen, da die Steuerungen extrem programmierbar sind.

  • Configfile. Die wurden doch sicher vom alten Server übernommen.

    Meine Theorie ist: Es gibt die Option, in der Config eine Tabelle oder ähnlich mit Geräten, IP- und MAC-Adressen zu hinterlegen. Ein übereifriger Integrator hat damals bei der Ersteinrichtung des Systems eine solche eingepflegt. Zwischenzeitlich wurden IPs an den Geräten geändert und jetzt beißt dich der Ist-Stand mit der alten Config.

    Für die ARP Tabelle gibt es kein Configfile. Die baut sich ja über Broadcasts auf.

    Ich schau morgen mal weiter.


    Vielen Dank auf jeden Fall mal bis hier her!

  • Am Switch einen Port auf Monitoring schalten und da mal beim Booten des Servers alles Mitschneiden, was da so rein kommt. Dann an einem gemütlichen Wochenend mit Wireshark analysieren.

  • Am Switch einen Port auf Monitoring schalten und da mal beim Booten des Servers alles Mitschneiden, was da so rein kommt. Dann an einem gemütlichen Wochenend mit Wireshark analysieren.

    Wenn ich nicht weiter komme, wird mir nichts anderes übrig bleiben.

    Danke!

  • Ich arbeite wenig mit Hyper-V und bin auch eher bei Proxmox unterwegs, aber: Mal einen ganz anderen (USB-)Netzwerkadapter direkt in die VM durchreichen? Testweise eine zweite VM mit nem normalen Windows auf dem gleichen Hypervisor und gleichen Vswitch hochziehen und gucken, was dessen ARP-Tabelle nach dem VM start sagt?


    Würde alles bei der weiteren Eingrenzung auf Gastsystem oder Hostkonstellation helfen...

  • Vielen Dank!
    Ich habe gerade eine ganz andere Vermutung. Das kann ich aber erst am Montag testen.

    Genau die SPSen die das Problem haben, verwenden den zweiten Ethernet Port für ein proprietäres Bussystem, dass keinen IP Stack verwendet. Da sind in der Regel abgesetzte I/Os dran.

    Aber genau bei den SPSen hängt als Slave auch eine SPS dran, die ebenfalls mit dem IP Netz verbunden ist. Soweit ist das auch kein Problem.

    Aber genau die SPS ist diejenige wo sich die Mac Adresse doppelt.


    Aber der Hersteller hat bei diesem Bussystem einen IP Tunnel eingebaut, den man bei Bedarf aktivieren kann. Damit kann man an das Bussystem ein IP Gerät anhängen das eventuell keinen physikalischen Zugriff auf das IP Netz hat.

    Und dieser Modus ist eine Voreinstellung.

    Dadurch wird eventuell die Mac Adresse durch den Tunnel dem falschen Gerät zugeordnet.


    Habe deswegen auch schon dem Support des Herstellers geschrieben. Und ich werde den Tunnel einfach mal abschalten. Dann zeigt sich das schnell.


    Wenn es das wäre... Meine Vermutung geht stark in die Richtung, da es genau die Geräte sind, die diese Konstellation haben.


    Ich habe mal eine kleine Skizze gemacht, damit man es besser versteht:


    So wie das hier gemacht ist, macht man das eigentlich nicht. Sinn war wohl, dass der Datenaustausch zwischen SPS1 und SPS2 auch funktioniert, wenn mal das IP Netzwerk weg ist.

    Und wenn meine Vermutung stimmt, müsste das Problem durch abschalten des Tunnels behoben sein. Der Tunnel wird eh nicht verwendet.

    Das würde auch wieder erklären, warum es mit dem alten Server (also ohne VM) auch die selben Probleme gab.

    Nächsten Montag weiß ich mehr.

  • Fehler gefunden. Es war nicht das, was ich vermutet hatte.

    Bei dem System kann man einen Software-Adapter für ein Realtime Protokoll verwenden.

    Den hat der Sys.-Integrator reingemacht und da war eine falsche IP drin.

    Also nicht die, die zum Gerät gehört hat.

    Dadurch hat der Software-Adapter mit einer IP gepusht. die nicht zu ihm gehört.

    Und diese IP war ja auch vergeben.

    Dadurch ist in dem Rechner die Mac-Tabelle durcheinander gekommen.

    Das hat mich mindestens 1000 graue Haare gekostet.


    Vielen Dank an Alle, die mitgeholfen haben!