Korrekte Einbindung IP-Router in Bestandsanlage mit TP Bereichs-/Linienkopplern

[sb4820]

Hallo zusammen,

ich habe letztes Jahr eine 15 Jahre alte Anlage in einem Zweckbau übernommen. Es funktioniert alles ordnungsgemäß, dennoch: Je tiefer ich mich in die Anlage reindenke, desto mehr Fragen tauchen auf. Bei einigen Punkten musste ich die Stirn runzeln und wundere mich ehrlich gesagt ein bisschen, dass sich das überhaupt so in der Form damals in Betrieb hat nehmen lassen. Vielleicht kann hier jemand Licht ins Dunkel bringen, wo - auch im Sinne einer späteren Erweiterbarkeit - eventuell Handlungsbedarf besteht.

Aber der Reihe nach. Folgende Ausgangssituation:

Bestandsanlage aus 2005 mit damals 2 Bereichen à jeweils 9 Linien.
Um die alte Hager-Visu zeitgemäß zu ersetzen und Logikfunktionen implementieren zu können, wurde vor einigen Jahren ein GIRA Homeserver aufgesetzt. Dieser kommuniziert ja bekanntlich über einen IP-Router mit der Anlage.

Nun folgt die erste Kuriosität: Dieser IP-Router 216700 sitzt in der Linie 1.4 als "regulärer Teilnehmer" mit der physikalischen Adresse 1.4.250. Warum funktioniert das? Bei MDT beispielsweise heißt es ja ausdrücklich, dass der IP-Router gar nicht als solcher arbeitet, wenn er nicht eine Adresse in der Form x.0.x oder x.x.0 hat (Bereichs- oder Linienkoppler zum IP-Backbone).

Später wurde auch ein weiterer Bereich 3 mit der (bislang einzigen) Linie 3.1 geschaffen, dieser ist rein per IP angebunden und der dortige IP-Router (gleiches Modell) hat seltsamerweise zwei physikalische Adressen, 3.1.1 und 3.1.2 (auch hier also keine 3.1.0 dabei). Wahrscheinlich dient eine davon rein der Routing-Applikation. Verstehe nur nicht, warum der zuerst installierte Router nur eine einzige PA hat. Firmware?

Da Telegramme von Linie 3.1 (diverse BEs für Störmeldungen) auf Linie 1.3 ankommen (dort befindet sich ein vorsintflutliches, modulares Visu-Tableau) gehe ich davon aus, dass beide Router korrekt auf der Multicast-IP 224.0.23.12 kommunizieren - obwohl offensichtlich die Adressierung hinten und vorne nicht passt.

Wie könnte man das möglichst minimalinvasiv "normgerecht" lösen? Aus meiner Sicht könnte ich den Bereichskoppler 1.0.0 rausschmeißen und diesen durch den IP-Router, der jetzt in der 1.4 hängt, ersetzen. Dann bräuchte es nur einen weiteren BK für den Bereich 2. Muss halt schauen, wo die BKs eigentlich sitzen und ob ich da Netzwerk in der Nähe habe.

Oder ist das, was da jetzt aktuell in Betrieb ist, eine "akzeptierte Krückenlösung" bei Nachrüstung einer solchen Anlage? Es würde mich generell interessieren, was in solchen Fällen "best practice" ist. Also bestehende Anlage mit voll ausgebautem TP-Backbone inkl. Bereichskopplern, und da soll jetzt irgendwie ein Homeserver rein.

Ich gehe ja mal davon aus, dass der HS selbst direkt per Multicast kommuniziert und nicht per Tunneling zu einer einzelnen Schnittstelle. Sonst würde das jetzt ja auch schon nicht funktionieren mit dem zusätzlichen Bereich 3.

Wenn ich das wirklich so umbauen würde, wie angedacht, hätte ich aber das "Problem", dass ich bei Diagnose und/oder Programmierung jeweils eine Tunneling-Verbindung zum IP-Router des entsprechenden Bereichs aufbauen muss, oder? Oder gibt es eine Möglichkeit, mit der ETS direkt per Multicast, ohne Tunneling komplett auf den IP-Backbone zu lauschen? Ich hatte zwar mal irgendwo in einem Testaufbau eine solche Verbindung angezeigt bekommen, meine ich (da war dann statt dem "Knoten" das "Netzwerkkarten-Symbol" in der Verbindungsübersicht - ich hoffe, ihr wisst, was ich meine), aber das kann ich nicht mehr nachvollziehen. Ich kann ja auch nur neue Tunneling-Verbindungen anlegen, Routing gibt es gar nicht als Option.


Gruß Stephan

[EugenDo]

Was für Router (Modell) sind denn da im Einsatz?

[sb4820]

Ups, dachte, ich hätte das dazugeschrieben.
Es handelt sich um GIRA 216700.

[approximate]

gira 216700, schreibt er doch

[sb4820]

Ich war dieser Tage mal wieder an dem Projekt dran. Das Grund-"Problem" ist wohl, dass natürlich aufgrund der Bestandsanlage sowohl sämtliche Linientypen, als auch der Backbone auf TP stehen. Dementsprechend lässt sich natürlich gar kein IP-Router als x.0.x oder x.x.0 hinzufügen. Für den neuen Anlagenteil wurde zwar die Hauptlinie 3 als IP-Linie erstellt; da es aber in Wirklichkeit ja keinen IP-Backbone gibt (müsste da nicht sogar eine Fehlermeldung kommen, wenn man die Hauptlinie so konfigurieren will?), lässt sich auch der IP-Router in Linie 3.1 dann nicht als 3.1.0 einbinden sondern nur als 3.1.1.

Genau so sieht es momentan ja auch aus.

Das kriege ich zwangläufig nur vernünftig glattgezogen, indem ich beide BKs rausschmeiße und noch einen zusätzlichen IP-Router einbaue. Die sitzen dann auf 1.0.0 und 2.0.0 und der, der mit dem zuerst beschafften Router auf 1.4.250 einen "Pseudo-IP-Backbone" aufbaut wandert entweder auf 3.1.0 oder 3.0.0 und die zwei, drei Gerätschaften die dahinter hängen, wandern in letzterem Fall auf Hauptlinie 3. Topologisch sollte beides sauber sein.

Ich glaube, so werde ich das mal anbieten. Räumt zumindest das ganze System ordentlich auf. Momentan müssen Telegramme ja im schlimmsten Fall fünf Geräte passieren, bevor sie den HS erreichen. Da in der HV wo die zwei BKs sitzen auch schon CAT liegt, war wahrscheinlich genau das auch irgendwann mal die Idee meines Vorgängers, die dann aber nie umgesetzt wurde.

Einziges Problem könnte werden, dass ich zum Programmieren dann immer die Schnittstellen wechseln muss, zumindest wenn ich mobil programmiere. Da die ne recht eigenwillige IT-Abteilung haben ist Multicast-Traffic auf den WLANs deaktviert, sodass ich dann nur per Tunneling den jeweiligen Bereich programmieren kann...

[gbglace]

Ja eine ordentliche Topologie und du wirst glücklich werden.