# Switch stört Kommunikation



## Deep Blue (27 Juni 2016)

Hallo,

ich möchte mit einer externen Steuerung per ModBus TCP kommunizieren. Bei der Inbetriebnahme konnte aber keine Verbindung aufgebaut werden, obwohl die Steuerung "anpingbar" ist und sich alle Teilnehmer im selben IP-Nummernkreis befinden. Nach langer Sucherei ist der Schuldige nun gefunden. Sofern die Kommunikation über den managed Switch läuft geht nichts, stelle ich eine Verbindung direkt her ist alles toll. Auch ein kleiner 8 Port Switch funktioniert.

Der Administrator schiebt die Schuld auf die "billige" Hardware des Steuerungsanbieters. Das stelle ich aber in Frage. Es ist mMn die Unfähigkeit hier eine Lösung herbei zu führen.

Kann mir vielleicht einer von euch erklären, was ich machen könnte bzw. dem überforderten Admin vorschlagen könnte damit ich zum Ziel komme? So bin ich total hilflos. Das ärgert mich enorm das der Admin hier zu dumm ist Hilfestellung zu leisten und es sich so ganz einfach macht.

P.S. Switch wechseln kommt hier nicht in Frage. Da hängt eine ganze Produktion dran. Geschwindigkeit auf 100 MBit Vollduplex brachte auch kein Ergebnis.


----------



## RONIN (27 Juni 2016)

Deep Blue schrieb:


> Der Administrator schiebt die Schuld auf die "billige" Hardware des Steuerungsanbieters.


Dan kannst du den Admin ja fragen warum der "billige" unmanaged Switch etwas kann dass dein teuer Switch nicht kann.... 

Da wird der dir Switch vom Admin irgendwas blockieren.
Wäre allerdings hilfreich wenn du ein paar Informationen zu den verwendeten Komponenten (Steuerungen) nennen würdest, vielleicht über welche Ports ihr die Verbindung aufbauen wollt, etc...

Dann kann dir vielleicht eher geholfen werden.


----------



## Deep Blue (27 Juni 2016)

Habe ich ihn gefragt. Aber da kam dann nur das er nichts blockt und es an der Steuerung des Anbieters liegen würde.

Ich möchte keine Marke nennen. Es handelt sich aber um eine Steuerung eines namhaften Kälteanlagenbauers. Kommuniziert werden soll, wie schon erwähnt, über ModBus TCP über den Port 502. Als Versuchsaufbau benutze ich auf meinem Laptop die Software Baseblock ComTest Pro for Modbus Devices. Ping klappt, wenn mein Laptop direkt am Ethernet Port der Steuerung hängt ist auch alles ok. Leitung bis zum Patchfeld ist ok. Steckt diese im Switch und ich versuche über diesen aus dem Firmennetz zuzugreifen, bekomme ich keine Werte, obwohl Verbindung steht.

P.S. ...und billig ist sowieso gut. Wenn der wüßte wie teuer die Anlage war. Aber das Spielt in der Administration bei uns eher eine untergeordnete Rolle.


----------



## Thomas_v2.1 (27 Juni 2016)

Sind die Teilnehmer in unterschiedlichen Subnetzen? Hast du die Subnetzmaske mit der IT des Kunden abgeglichen? Vielleicht ist das Gerät von ihm nicht nur ein Switch sondern auch ein Router.

Du könntest die vermeintlich "billige" Steuerungshardware als Fehlerursache ausschließen, wenn du anstelle der Steuerung mal eine PC/Notebook mit einem Modbus-TCP Server oder einem anderen Serverprogramm (ich verwende dazu gerne Hercules http://www.hw-group.com/products/hercules/index_de.html oder auch das Microsoft telnet Programm) was auf dem Modbus Port lauscht anschließt, und dann versuchst ob du dazu eine Verbindung aufgebaut bekommst. Von PC zu PC lässt sich die Verbindung einfacher diagnostizieren, bei der Steuerung müsstest du dich erst leitungstechnisch dazwischenhängen.

Aber diese sogenannten "Admins" kenne ich auch. In der Branche nach meiner Erfahrung größtenteils Nichtsblicker unterwegs.


----------



## Deep Blue (27 Juni 2016)

Thomas_v2.1 schrieb:


> Sind die Teilnehmer in unterschiedlichen Subnetzen?


 -> Nein, beide 255.255.255.0



> Hast du die Subnetzmaske mit der IT des Kunden abgeglichen?


 -> Ja, er nutzt auch noch den selben Standardgateway



> Vielleicht ist das Gerät von ihm nicht nur ein Switch sondern auch ein Router.


 -> Was wäre dann?



> Du könntest die vermeintlich "billige" Steuerungshardware als Fehlerursache ausschließen, wenn du anstelle der Steuerung mal eine PC/Notebook mit einem Modbus-TCP Server oder einem anderen Serverprogramm (ich verwende dazu gerne Hercules http://www.hw-group.com/products/hercules/index_de.html oder auch das Microsoft telnet Programm) was auf dem Modbus Port lauscht anschließt, und dann versuchst ob du dazu eine Verbindung aufgebaut bekommst. Von PC zu PC lässt sich die Verbindung einfacher diagnostizieren, bei der Steuerung müsstest du dich erst leitungstechnisch dazwischenhängen.



Wie ich schon erwähnte habe ich vernünftige Werte, sobald ich den 48Port-Switch raus lasse und entweder direkt oder über einen kleinen 8Port-Switch gehe.


----------



## Knaller (27 Juni 2016)

Moin
Die gemanagten Switches sollten immer mit einer festen IP versehen werden. Ansonsten hören die auf alles und versuchen da Daten für sich zu finden. Multicast und die schöne IP Adresse 192.168.0.254     Daher aufpassen.   Cisco ist so ein Teil.   Sobald irgendwie die Adresse 192.168.0.254 auf taucht bricht das SYstem weg


Sent from my iPhone using Tapatalk


----------



## Thomas_v2.1 (27 Juni 2016)

Diese "Baumarktswitche" arbeiten normalerweilse nur auf Osi-Schicht 2. Das heißt sie achten nur auf die MAC-Adressen der Datenpakete, und die IP-Adresse ist dem Switch intern egal, um den Port auszuwählen an den er das Paket weiterleitet.

Ist der Switch vom Kunden ein Router oder auch Layer 3 Switch, dann kommen in diesem auch die IP-Adressen und Subnetzmasken zum tragen.
Wenn du bei deinen Teilnehmern von einem 255.255.255.0 Subnetz ausgehst, im Switch steht aber für den Port 255.255.255.128 und das eine Gerät eine IP hat z.B. 192.168.1.10 und das andere 192.168.1.200, dann würde da intern etwas geroutet werden müssen. Das siehst du von außerhalb aber nicht, außer dass deine Pakete nicht am gewünschten Teilnehmer ankommen.

Vielleicht hat der Kunde auf seinem Switch auch Vlans eingerichtet, und auf dem Port zu deiner Steuerung wird das Vlan-Tag nicht entfernt, und deine Steuerung kommt damit dann nicht mehr klar. Aber das kannst du alles nur mutmaßen. Darum würde ich zwei PCs anschließen und wenn's damit nicht funktioniert, kannst du es dem "Admin" zeigen, ohne dass er sich mit für ihn exotischen Geräten rumärgern muss und es immer wieder auf das Gerät schieben kann.


----------



## Fabpicard (27 Juni 2016)

Deep Blue schrieb:


> Steckt diese im Switch und ich versuche über diesen aus dem Firmennetz zuzugreifen,





Thomas_v2.1 schrieb:


> Vielleicht hat der Kunde auf seinem Switch auch Vlans eingerichtet, und auf dem Port zu deiner Steuerung wird das Vlan-Tag nicht entfernt, und deine Steuerung kommt damit dann nicht mehr klar.



Das klingt ganz arg nach VLans...

Häng mit der gleichen IP und SNM mal je einen PC/Laptop für die beiden Steuerungen an die jeweiligen Ports. Ist wirklich der beste Weg um deinem Problem auf die Schliche zu kommen 
Denn wenn Ping geht, aber sonst nix, beide allerdings ein Gateway des Firmennetzwerkes haben. Dann kann es dir auch gut passieren, dass das vermeintliche "Gateway" eine Firewall ist die für dich halt eben nur Ping zulässt 

MfG Fabsi


----------



## Thomas_v2.1 (27 Juni 2016)

Fabpicard schrieb:


> Denn wenn Ping geht, aber sonst nix, beide allerdings ein Gateway des Firmennetzwerkes haben. Dann kann es dir auch gut passieren, dass das vermeintliche "Gateway" eine Firewall ist die für dich halt eben nur Ping zulässt



Dass ein Ping geht hatte ich überlesen. Das würde dann wirklich eher für eine Firewall / Paketfilter sprechen, denn die Ping-Pakete werden ja ebenfalls ggf. geroutet. Vielleicht mal die Steuerung abziehen und prüfen ob dann ein Ping wirklich nicht mehr funktioniert, nicht dass da ein anderes Gerät antwortet.


----------



## Deep Blue (28 Juni 2016)

Um die Topologie noch einmal zu verdeutlichen habe ich mal laienhaft ein Bild erstellt.

Nun ist der Admin aber erst mal krank :shock:

Wahrscheinlich hat ihn das Gespräch gestern so mitgenommen das er außer Gefecht ist. Ich würde ihm den Vorschlag mit der Firewall weiter geben. Habe leider keine Möglichkeit dem managed Switch zu editieren.


----------



## ducati (6 Juli 2016)

Thomas_v2.1 schrieb:


> Aber diese sogenannten "Admins" kenne ich auch. In der Branche nach meiner Erfahrung größtenteils Nichtsblicker unterwegs.



Interessanterweise wird ja immer genau das Gegenteil behauptet, nämlich dass die Automatisierer ja keine Ahnung von Netzwerken haben und nur die IT-Admins dass ordentlich (vor allem in Bezug auf Sicherheit) konfigurieren können.

M.M. nach liegt das Problem aber schon viel früher, beim Planer oder Vertriebler. (Aus Kostengründen oder Unwissenheit) wird da gerne mal alles was nen RJ45-Stecker hat in einen Topf (ein Netzwerk) geworfen. Nach dem Motto da gibt's ja schon irgendwo nen Büronetzswitch, da hängen wir jetzt alles andere auch mit drauf vom Profinet-IO-Feldbus über die AS-AS-Kommunikation-Anlagenbus bis zur Visu-Terminalbus ... Ist doch alles "Profinet" und der Techniker wird's schon hinbekommen...

Der Oberbegriff "Profinet" ist auch sehr unglücklich gewählt. Ich verwende den so gut wie nie, da er nur Verwirrung stiftet. Feldbus ist bei mir Profinet-IO und den Rest bezeichne ich als Industrial-Ethernet. Das Büronetz ist dann "normales" Ethernet bzw. LAN ...

Also meine Meinung eine ordentliche Trennung der Netze mit verschiedenen CPs in der SPS vermeidet viele Probleme und spart somit sogar Geld!

Zum TE: wenn die Kopplung zwischen deinen 2 Teilnehmern nicht über den (Büronetz)-Switch sondern ein separates  Automatisierungsnetz (in dem Fall also nur ein Kabel) ablaufen würde, hätte man die Sorgen auch nicht.

Gruß.


----------



## Slaine (6 Juli 2016)

Wir hatten bei uns gerade ein ähnliches Problem, dass wir in meinem  Fernwartungsnetz die HP 1810G gegen Cisco 2960 getauscht  haben, um firmenintern auf einen Standard zu kommen. Danach  funktionierte dann plötzlich die Funktion "Online erreichbare Teilnehmer  suchen" nicht mehr richtig, obwohl die VLANs alle sauber konfiguriert  waren. Meine Router wurden alle gefunden, aber SPS, CP und  Panel...Fehlanzeige. Die Kommunikation zwischen den Geräten selbst und  auch das online beobachten der Steuerung ging ohne Probleme.
Der Grund  dafür war, dass Cisco bei den Büro-Switches in den Standardeinstellungen mit VLAN 0 getaggte Pakete  verwirft, was die Switches von HP nicht gemacht haben (die Industrial-Serie von Cisco macht das übrigens auch nicht und unmanaged Switches sind die VLAN-Tags eh egal). Daher würde ich  empfehlen, mal in die Richtung zu forschen und im Zweifelsfall mal WireShark ins Netz zu hängen um zu sehen, was tatsächlich passiert. Dass die Kommunikation aufgrund billiger Komponenten nicht funktionieren soll, halte ich jedenfalls für völligen Unsinn. Der Verursacher ist höchstwahrscheinlich der managed Switch.


----------



## Deep Blue (7 Juli 2016)

Danke für eure super Anregungen und Tipps. Wir werden am Mittwoch auf neue Switch und VLan umstellen. Da wird mir schon ziemlich mulmig. Aber vielleicht hat sich dann das Problem erübrigt oder es kommen neue dazu?


----------

