Broadcast "messen" und SPS

[heuchler 17]

Guten Morgen zusammen,

 

der Titel ist wohl etwas verwirrend, daher eine kurze Beschreibung des Problems.

In der Produktion existiert eine SPS (Siemens S5) die u.a. Verbrauchsdaten abgreift und diese Daten durch ein eigens programmiertes Programm abgegriffen werden.
Das Problem was wir haben ist, dass die Verbindung sporadisch, mal nach ein paar Stunden oder Tagen, abbricht und das Programm somit auf einen Socket Error läuft.

Nun gab es in den letzten Wochen nur eine Änderung:
Es wurden drei neue Switche installiert (HP 1920, alle hintereinander weg über LWL Verbunden) um daran wiederum insgesamt 8 WLAN APs zu stecken (PoE, Sophos APs).
Hintergrund ist dass drei WLAN Handscanner über 4 Hallen eingesetzt werden sollen.
Also meiner Meinung nun wirklichs nichts worüber man sich eigentlich Gedanken machen müsste.
Zeitlich leider auch nicht genau abzuschätzen da die Probleme erst später auffielen und man von einem "einmaligen Fehler" ausging.

Netz ist 172.29.16.0 / 20

Jetzt wäre interessant ob jemand Erfahrungen hat ob die nun auftretenden Broadcasts für solche Probleme sorgen können, gerade in HInblick auf embedded/SPS und wie ich rausfinden kann ob es tatsächlich "zu viel" ist was nun im Netzwerk abgeht.

Ich habe auf jedem Switch STP aktiviert, nun auch auf den jeweils beteiligten Switches Broadcasts max auf 1% gesetzt, FlowControl aktiviert.
Es gibt auch keine Warnungen in den Log Dateien.

Nun habe ich einen Monitoring Port eingerichtet um mir mal die Daten anzuschauen.

Hier fällt schon auf dass die drei Switche (172.29.16.35, 172.29.16.36, 172.29.16.37) rumfeuern. Siehe BIld. Oder ist das normal? So ganz ohne Vergleich ist es natürlich schwer.

Es gibt samt Thinclients und Drucker um die 180 Hosts.
Dann noch ca. 80 Telefone und ca. 20 Server (überwiegend VMs).

Jemand eine Idee?
Das ist ein bisschen Tappen im Dunkeln und ich weiß garnicht ob die Infos überhaupt reichen.
Eine Idee wie ich nun vorgehen könnte würde mir schon reichen ;-)

Viele Grüße udn Danke euch

Daniel
 

bearbeitet 11. Dezember 2015 von heuchler

[DocData 85]

Alles in einem VLAN? Das solltest du ändern. Grundsätzlich kann es schon sein, dass die SPS durch irgendwas aus deinem Netz aus dem Tritt gebracht wird.

[lefg 276]

Was für eine S5(CPU) ist das, wie, womit ist sie mit dem Netz verbunden(CPU oder Modul)? Wer, was greift Daten ab?

 

 

und das Programm somit auf einen Socket Error läuft.

 

 

Wo läuft dieses Programm, auf der S5? Ist es ein Step 5? Was sagt der Programmierer?

 

Stammt das Ethernetinterface von Siemens, ein Originalteil oder stammt es von einem Fremdanbieter?

bearbeitet 11. Dezember 2015 von lefg

[NeMiX 76]

Deine Switche stellen normale ARP Request. Evtl. kannst du den ARP Cache etwas hochdrehen (weiß nicht genau ob das bei den billigen 1920 geht).

Ansonsten die S5 in ein eigenes Vlan packen, hatte mal 2 Netze mit S7 und die sind bei Kleinigkeiten schon aus dem Tritt gekommen, da half nur ein eigenes VLan dann lief das aber auch sehr sauber durch.

[DocData 85]

Switches schicken ARP Requests und haben einen ARP Table? Die Routing Engine oder die Management Plane evtl, aber die Data Plane ganz sicher nicht. Insofern macht es auch gar keinen Sinn an einem ARP Table rumzuschrauben. Davon ab: 280 Devices sind selbst für einen 1920 Kindergeburtstag.

 

Hier liegt eher ein Designfehler vor. Es ist heute wirklich, wirklich, wirklich kein Kunststück mehr drei VLANs zu bauen und Server, Clients und VoIP zu trennen. Das eine VLAN für dieSPS hätte den Barten nicht fetter gemacht.

 

Es ist mir wirklich ein Rätsel warum heute jemand noch bei mehr als 20 Devices ein einziges VLAN und Subnetz verwendet...

[NeMiX 76]

Ich sollte nicht nach 0Uhr schreiben ;)

Hast natürlich Recht, das bei den günstigen Switchen meistens die Management Plane das händelt. Hatte früher bei der 5300´er Serie mal einen Supportcase offen wo von Procurve empfohlen wurde den ARP Cache hochzusetzen (hat aber erst mal nichts mit dem fall hier zu tun)

[heuchler 17]

Hey zusammen,

danke erstmal bis hier hin für eure Antworten :)
Kindergeburstatg fiel mir auch ein. Grundsätzlich läuft es. Keine Ausfälle, keine Loops und alle Switche soweit es geht konfiguriert um das schlimmste abzufangen "Ach, da ist ein Kabelende, das stecke ich jetzt in die Dose...".
Daher kann es nur ein Störfaktor in Bezug auf die SPS sein.
Die Daten kann ich Montag raussuchen. Der Programmierer kommt ebenfalls Montag/Dienstag.

Designfehler? Sehe ich ein. Ein Resultat aus 10 Jahren nahezu Stillstand (HP G5 für PDC und überlebenswichtiges ERP).
Ich habe schon einen Teilbereich der Produktion via VLAN separiert, das funktioniert wunderbar.
"Mal eben" in nichtmal 20 Monaten grundlegende Änderungen vornehmen, ohne zu wissen wo welche Gerät verbaut und wie auch immer konfiguriert sind?
Die 1920er (8 APs) sind bis auf eine weitere Ausnahme (Coreswitch für SAN und XenServer) mit weeeitem Abstand die jüngsten Geräte ;-)

VLAN für diesen Bereich hatte ich schon auf dem Plan, zerbreche mir nur den Kopf über den 2003er Server und die APs. Aber grundsätzlich ist es "die" Lösung auf Dauer, klar.
Dann hätte ich einen Teil der Produktion, die BDE und die APs in einem Netz.

Eigentlich bin ich da auch seit einer Stunde dran bis mir brennend heiß eingefallen ist dass ich den Stecker zu dem Switch in dem Bereich abgezogen habe um am Wochenende keine Daten zu verlieren. Ist halt doof, aber ist ja auch mal schön - so ein Wochenende ;-)

Habe ich Neuigkeiten wende ich mich vertrauensvoll an euch :)

Danke nochmal und euch vorerst ein angenehmes Wchenende!

Viele Grüße
Daniel
 

[lefg 276]

 

Das Problem was wir haben ist, dass die Verbindung sporadisch, mal nach ein paar Stunden oder Tagen, abbricht und das Programm somit auf einen Socket Error läuft.

 

Nochmals dei Frage, was passiert genau, geht die S5 in Stop? Oder wird die Verbindung zur S5 unterbrochen. Ist mit Socket Error am IP-Interface der S5 gemeint?