Konzept für eine Testumgebung - ein TCPIP Gerät sollte über mehrere (virtuelle) IP-Adressen ansprechbar sein - NAT?
Hallo an alle,
unsere Softwareentwicklung bat mich eine Testumgebung bereitzustellen die folgende Anforderung erfüllen sollte:
Die zu testende Software kommuniziert via Ethernet mit TCP/IP fähigen Messgeräten bzw. die IP-Adressen der jeweiligen Geräte werden in der Software eingetragen. Das ganze mit ein paar wenigen Geräten zu testen ist nicht das Problem - logischerweisse muss die Konstellation auch getestet werden wenn mehrere hundert TCP/IP-Teilnehmer in der Software konfiguriert sind (Abbarbeitung der Prozesse, Zykluszeiten etc.). Und das können wir aus mehrere Gründen unmöglich abbilden - deshalb meine Idee:
Ich stelle mir vor das ich eine Art "BlackBox" zwischem dem Netzwerk und einem einizgen TCP/IP fähigen Messgerät integriere. Dies kann z.Bsp. ein PC oder eine virtuelle Maschine mit mindestens zwei Netzwerkkarten sein.
Einer Netzwerkkarte (LAN-seitig) werden mehrere IP-Adresse zugewiesen - diese Adressen "spreche" ich letztlich auch über die Software an.
An die zweite Netzwerkkarte wird lediglich TCP/IP Gerät angeschlossen und adressiert. D
Die Kommunikation findet lediglich über TCP Port 8000 statt.
Wenn ich jetzt auf meiner "BlackBox" eine Adressumsetzung definieren könnte, würde doch die Möglichkeit bestehen das ich über mehrere IP-Adressen (welcher der ersten NIC zugewiesen wurde) letztendlich mit einem TCP/IP Gerät konfigurieren kann. In der Software hätte ich quasi eine Liste mit "virtuellen Geräte-Adresse" und antworten tut trotzdem nur ein Gerät. Das wäre genau das was wir bräuchten - mit wenigen Geräte zahlreiche Segmente nachbilden. Das immer der gleiche antwortet bzw. dadurch die Sache natürlich träge werden würde spielt erst mal keine Rolle.
Wäre so etwas realisierbar oder bin ich komplett auf dem Holzweg??...Für jeden Lösungsvorschlag etc. dankbar!
Grüße
Kollisionskurs
unsere Softwareentwicklung bat mich eine Testumgebung bereitzustellen die folgende Anforderung erfüllen sollte:
Die zu testende Software kommuniziert via Ethernet mit TCP/IP fähigen Messgeräten bzw. die IP-Adressen der jeweiligen Geräte werden in der Software eingetragen. Das ganze mit ein paar wenigen Geräten zu testen ist nicht das Problem - logischerweisse muss die Konstellation auch getestet werden wenn mehrere hundert TCP/IP-Teilnehmer in der Software konfiguriert sind (Abbarbeitung der Prozesse, Zykluszeiten etc.). Und das können wir aus mehrere Gründen unmöglich abbilden - deshalb meine Idee:
Ich stelle mir vor das ich eine Art "BlackBox" zwischem dem Netzwerk und einem einizgen TCP/IP fähigen Messgerät integriere. Dies kann z.Bsp. ein PC oder eine virtuelle Maschine mit mindestens zwei Netzwerkkarten sein.
Einer Netzwerkkarte (LAN-seitig) werden mehrere IP-Adresse zugewiesen - diese Adressen "spreche" ich letztlich auch über die Software an.
An die zweite Netzwerkkarte wird lediglich TCP/IP Gerät angeschlossen und adressiert. D
Die Kommunikation findet lediglich über TCP Port 8000 statt.
Wenn ich jetzt auf meiner "BlackBox" eine Adressumsetzung definieren könnte, würde doch die Möglichkeit bestehen das ich über mehrere IP-Adressen (welcher der ersten NIC zugewiesen wurde) letztendlich mit einem TCP/IP Gerät konfigurieren kann. In der Software hätte ich quasi eine Liste mit "virtuellen Geräte-Adresse" und antworten tut trotzdem nur ein Gerät. Das wäre genau das was wir bräuchten - mit wenigen Geräte zahlreiche Segmente nachbilden. Das immer der gleiche antwortet bzw. dadurch die Sache natürlich träge werden würde spielt erst mal keine Rolle.
Wäre so etwas realisierbar oder bin ich komplett auf dem Holzweg??...Für jeden Lösungsvorschlag etc. dankbar!
Grüße
Kollisionskurs
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 102602
Url: https://administrator.de/contentid/102602
Ausgedruckt am: 13.11.2024 um 11:11 Uhr
2 Kommentare
Neuester Kommentar
Prinzipiell ist die Idee eines "Reverse-NAT" schon denkbar.
Probleme könnte hier nur das Messgerät verursachen, wenn es nicht mehr als eine simultane Verbindung erlaubt (dann ist eben nur eine sequentielle Abarbeitung möglich).
Den Routing-Experten hier fallen aber sicher noch bessere Lösungen ein
Grüße
Max
Probleme könnte hier nur das Messgerät verursachen, wenn es nicht mehr als eine simultane Verbindung erlaubt (dann ist eben nur eine sequentielle Abarbeitung möglich).
Den Routing-Experten hier fallen aber sicher noch bessere Lösungen ein
Grüße
Max