16
Windows: Gleiches IP subnetz an zwei verschiedenen Netzwerkkarten
Ich weiss, die Frage ist absolut bescheuert, aber ich bin im Umgang mit einem Geschäftspartner mit meinem Latein am Ende.
Wir entwickeln für einen Kunden eine Software, die zwei black boxes eines anderen Herstellers über Ethernet (IPv4/UDP) steuern soll. Wir haben auf den Hersteller der black box wenig Einfluss, bekommen von ihm nur die boxen zum Entwickeln zur Verfügung gestellt.
Das Problem ist:
Die Kommunikation mit der Box verläuft über 2 channels, einen "Command Channel", über den wir der Box Befehle senden und die direkten Antworten auf diese Befehle bekommen sowie einen "Subscribe Channel", über den die Box uns permanent Statusmeldungen schickt.
Das eigentliche Problem ist jetzt, dass sowohl die IP Adresse der Box als auch die Ziel-Adresse für den subscribe channel in der Box hart gecoded sind. Bis jetzt wurde immer nur eine Box von einem Computer aus gesteuert, somit war das kein Problem.
Dem Hersteller ist jetzt zwar klar, dass die zweite Box eine andere Adresse haben muss, damit wir beide steuern können, eine andere IP-Adresse haben muss, er hat aber eine sehr eigene Vorstellung, wie das ganze aussehen soll:
Die Originale Firmware der Box hört auf die 192.168.22.3 und schickt ihren Status an die 192.168.22.2.
Wir sollen jetzt eine Prototypfirmware bekommen, die auf die 192.168.22.5 hört und ihren Status an die 192.168.22.4 sendet. Subnetmask für alle ist die 255.255.255.0.
Ich bin der Meinung, dass das so nicht funktionieren kann, der Hersteller sieht das aber irgendwie völlig anders.
Wenn ich "ganz normal" die beiden Blackboxen über einen Switch mit einer Netzwerkkarte in meinem System verbinde, müsste ich meiner Netzwerkkarte ja 2 IP-Adressen (192.168.22.2 und 192.168.22.4) zuweisen, damit die Statusmeldungen beider Generatoren bei mir ankämen. Mir ist in windows aber nur die möglichkeit einer "alternativen IPv4 configuration" bekannt, die ich zB bei einem Laptop verwenden kann, wenn es wechselweise in verschiedenen Netzwerken eingesetzt wird. *Gleichzeitig* kann ich meiner Meinung nach nicht zwei verschiedene IP-Adressen einer Karte zuweisen.
Der Hersteller sagt allerdings sowieso, wir sollen aus performancegründen zwei Netzwerkkarten verwenden und jede Box direkt mit einer Karte verbinden. Da sehe ich aber noch weit größere Schwierigkeiten auf uns zukommen, denn dann habe ich zwei Netzwerkkarten, die laut Konfiguration beide im gleichen Subnetz (192.168.22.0/24) liegen. Woher soll der Windows IP Stack denn jetzt wissen, über welche Netzwerkkarte die Datagramme an die 192.168.22.5 rausgehen sollen?
Anstatt meiner Bitte nachzukommen, mir einfach eine Firmware mit IP-Adressen in einem anderen Subnetz zu schicken, diskutiert der Hersteller jetzt schon seit Wochen mit mir. Rückt allerdings auch die bisher schon existierende Firmware nicht raus, so dass ich es nicht einfach selbst ausprobieren kann. Und ich habe auch nicht das Gefühl, dass der Hersteller es selbst einmal ausprobiert hat. Sicherlich wurde die Firmware mit der veränderten IP-Adresse auf einer einzelnen Box getestet, aber ich glaube nicht, dass man mal eine zweite Box mit der Standardfirmware dazugesteckt hat.
Kann mir irgendjemand definitiv sagen, ob ich mit meinen befürchteten Problemen recht habe oder ob das so funktionieren kann mit den zwei NIC im gleichen Subnetz?
Danke,
Thomas
Wir entwickeln für einen Kunden eine Software, die zwei black boxes eines anderen Herstellers über Ethernet (IPv4/UDP) steuern soll. Wir haben auf den Hersteller der black box wenig Einfluss, bekommen von ihm nur die boxen zum Entwickeln zur Verfügung gestellt.
Das Problem ist:
Die Kommunikation mit der Box verläuft über 2 channels, einen "Command Channel", über den wir der Box Befehle senden und die direkten Antworten auf diese Befehle bekommen sowie einen "Subscribe Channel", über den die Box uns permanent Statusmeldungen schickt.
Das eigentliche Problem ist jetzt, dass sowohl die IP Adresse der Box als auch die Ziel-Adresse für den subscribe channel in der Box hart gecoded sind. Bis jetzt wurde immer nur eine Box von einem Computer aus gesteuert, somit war das kein Problem.
Dem Hersteller ist jetzt zwar klar, dass die zweite Box eine andere Adresse haben muss, damit wir beide steuern können, eine andere IP-Adresse haben muss, er hat aber eine sehr eigene Vorstellung, wie das ganze aussehen soll:
Die Originale Firmware der Box hört auf die 192.168.22.3 und schickt ihren Status an die 192.168.22.2.
Wir sollen jetzt eine Prototypfirmware bekommen, die auf die 192.168.22.5 hört und ihren Status an die 192.168.22.4 sendet. Subnetmask für alle ist die 255.255.255.0.
Ich bin der Meinung, dass das so nicht funktionieren kann, der Hersteller sieht das aber irgendwie völlig anders.
Wenn ich "ganz normal" die beiden Blackboxen über einen Switch mit einer Netzwerkkarte in meinem System verbinde, müsste ich meiner Netzwerkkarte ja 2 IP-Adressen (192.168.22.2 und 192.168.22.4) zuweisen, damit die Statusmeldungen beider Generatoren bei mir ankämen. Mir ist in windows aber nur die möglichkeit einer "alternativen IPv4 configuration" bekannt, die ich zB bei einem Laptop verwenden kann, wenn es wechselweise in verschiedenen Netzwerken eingesetzt wird. *Gleichzeitig* kann ich meiner Meinung nach nicht zwei verschiedene IP-Adressen einer Karte zuweisen.
Der Hersteller sagt allerdings sowieso, wir sollen aus performancegründen zwei Netzwerkkarten verwenden und jede Box direkt mit einer Karte verbinden. Da sehe ich aber noch weit größere Schwierigkeiten auf uns zukommen, denn dann habe ich zwei Netzwerkkarten, die laut Konfiguration beide im gleichen Subnetz (192.168.22.0/24) liegen. Woher soll der Windows IP Stack denn jetzt wissen, über welche Netzwerkkarte die Datagramme an die 192.168.22.5 rausgehen sollen?
Anstatt meiner Bitte nachzukommen, mir einfach eine Firmware mit IP-Adressen in einem anderen Subnetz zu schicken, diskutiert der Hersteller jetzt schon seit Wochen mit mir. Rückt allerdings auch die bisher schon existierende Firmware nicht raus, so dass ich es nicht einfach selbst ausprobieren kann. Und ich habe auch nicht das Gefühl, dass der Hersteller es selbst einmal ausprobiert hat. Sicherlich wurde die Firmware mit der veränderten IP-Adresse auf einer einzelnen Box getestet, aber ich glaube nicht, dass man mal eine zweite Box mit der Standardfirmware dazugesteckt hat.
Kann mir irgendjemand definitiv sagen, ob ich mit meinen befürchteten Problemen recht habe oder ob das so funktionieren kann mit den zwei NIC im gleichen Subnetz?
Danke,
Thomas
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1361292052
Url: https://administrator.de/forum/windows-gleiches-ip-subnetz-an-zwei-verschiedenen-netzwerkkarten-1361292052.html
Ausgedruckt am: 25.12.2024 um 07:12 Uhr
16 Kommentare
Neuester Kommentar
Hi,
man kann auch unter Windows mehrere IP-Adressen an eine Netzkarte binden. Das ginge sogar mit verschiedenen Masken.
Spannender wäre es, zu wissen, ob mit der vorhandenen Software dann auch zwei IP-Adressen gleichzeitig getrennt abgehört werden können.
Zwei Karten würde ich mir verkneifen, wenn an diese Adressen aus dem selben Subnetz gebunden werden sollen. Das bringt früher oder später Probleme. Und ausgehende Pakete würden dann sowie immer nur über nur eine Karte rausgehen.
Könntest Du nicht auch zwei VM's aufsetzen, welche dann jeweils nur eine NIC haben mit den Adressen für jeweils eine der Boxen? Und dann in diesen VM's testen und entwickeln?
E.
man kann auch unter Windows mehrere IP-Adressen an eine Netzkarte binden. Das ginge sogar mit verschiedenen Masken.
Spannender wäre es, zu wissen, ob mit der vorhandenen Software dann auch zwei IP-Adressen gleichzeitig getrennt abgehört werden können.
Zwei Karten würde ich mir verkneifen, wenn an diese Adressen aus dem selben Subnetz gebunden werden sollen. Das bringt früher oder später Probleme. Und ausgehende Pakete würden dann sowie immer nur über nur eine Karte rausgehen.
Könntest Du nicht auch zwei VM's aufsetzen, welche dann jeweils nur eine NIC haben mit den Adressen für jeweils eine der Boxen? Und dann in diesen VM's testen und entwickeln?
E.
1
Moin,
eine zweite Adresse zum Empfangen geht auf einer NIC. Aber wie man die "sendende" IP je nach Ziel im selben Netz festlegen soll, wäre mir auch schleierhaft. Man könnte versuchen dem PC die 192.168.22.2/31 (Mask 255.255.255.254) und 192.168.22.4/31 zuzuweisen. Dann hätte man je nach Ziel die Absender-IP getrennt. Aber dann gibts eigentlich keine Host-Adressen mehr in dem Netz. (Ääähhh, blöde Idee, aber ich lass sie mal stehen, vielleicht hat ja jemand eine Bessere)
/pp
eine zweite Adresse zum Empfangen geht auf einer NIC. Aber wie man die "sendende" IP je nach Ziel im selben Netz festlegen soll, wäre mir auch schleierhaft. Man könnte versuchen dem PC die 192.168.22.2/31 (Mask 255.255.255.254) und 192.168.22.4/31 zuzuweisen. Dann hätte man je nach Ziel die Absender-IP getrennt. Aber dann gibts eigentlich keine Host-Adressen mehr in dem Netz. (Ääähhh, blöde Idee, aber ich lass sie mal stehen, vielleicht hat ja jemand eine Bessere)
/pp
1
Hmm - wenn's bei einem PC bleiben soll, fiele mir noch die Möglichkeit ein, neben dem physischen PC mit der ersten IP
Eine Hyper-VM mit der 2ten IP in Top des physischen PC zu nutzen.
Wenn man in der SW einstellen kann, auf welche IPs diese hören und senden soll, könnte man evtl. Eine 2te Instanz mit z.B. Sandboxie versuchen (??)
.
Eine Hyper-VM mit der 2ten IP in Top des physischen PC zu nutzen.
Wenn man in der SW einstellen kann, auf welche IPs diese hören und senden soll, könnte man evtl. Eine 2te Instanz mit z.B. Sandboxie versuchen (??)
.
1
Hallo,
das ist doch ein Standard-Zenario, das erst vor einigen Tagen hier diskutiert wurde:
Ein Werkzeugmaschinen-Hersteller produziert eine Anlage mit meheren Steuerungen, die alle vernetzt sind und jeweils eine eigene IP im gemeinsamen Subnetz haben. Alle Anlagen sind immer gleich konfiguriert und können/sollen nicht umkonfiguriert werden.
Der Käufer beschafft mehere Anlagen dieses Typs und hat nun das Problem, das die Anlagen alle das gleiche Subnetz und die gleichen IPs haben.
Lösung: Vor jede Anlage kommt ein Router mit NAT. Jeder Router hat eine eigene IP in einem gemeinsamen Subnetz, in dem auch der Management-PC steht.
Ist die Standard-Lösung und wird von allen Herstellern so empfohlen. Gibt auch entsprechende Industrie-Router genau für diesen Einsatz-Zweck. (zB. https://www.phoenixcontact.com/online/portal/de?1dmy&urile=wcm%3apat ... ) Die können allerdings noch mehr.
Also: Die Boxen können alle die gleiche IP haben; vor jede Box ein NAT-Router und der PC auf der anderen Seite der Router. Problem normkonform und mit Funktionsgarantie gelöst.
Jürgen
das ist doch ein Standard-Zenario, das erst vor einigen Tagen hier diskutiert wurde:
Ein Werkzeugmaschinen-Hersteller produziert eine Anlage mit meheren Steuerungen, die alle vernetzt sind und jeweils eine eigene IP im gemeinsamen Subnetz haben. Alle Anlagen sind immer gleich konfiguriert und können/sollen nicht umkonfiguriert werden.
Der Käufer beschafft mehere Anlagen dieses Typs und hat nun das Problem, das die Anlagen alle das gleiche Subnetz und die gleichen IPs haben.
Lösung: Vor jede Anlage kommt ein Router mit NAT. Jeder Router hat eine eigene IP in einem gemeinsamen Subnetz, in dem auch der Management-PC steht.
Ist die Standard-Lösung und wird von allen Herstellern so empfohlen. Gibt auch entsprechende Industrie-Router genau für diesen Einsatz-Zweck. (zB. https://www.phoenixcontact.com/online/portal/de?1dmy&urile=wcm%3apat ... ) Die können allerdings noch mehr.
Also: Die Boxen können alle die gleiche IP haben; vor jede Box ein NAT-Router und der PC auf der anderen Seite der Router. Problem normkonform und mit Funktionsgarantie gelöst.
Jürgen
1
steh ich auf'm Schlauch? Sollte das nicht mit /22er Netzmasken auf den Netzwerkkarten funktionieren? Somit hast du 0-3 in einem Subnetz und 4-7 in dem anderen?
1Zitat von @chiefteddy:
Lösung: Vor jede Anlage kommt ein Router mit NAT. Jeder Router hat eine eigene IP in einem gemeinsamen Subnetz, in dem auch der Management-PC steht.
Lösung: Vor jede Anlage kommt ein Router mit NAT. Jeder Router hat eine eigene IP in einem gemeinsamen Subnetz, in dem auch der Management-PC steht.
Soweit. So gut - aber TE hat Geräte, die explizit jeweils eine andere Host-Adresse ansprechen, die beide auf dem selben PC verwaltet werden sollen.
Somit hast du wieder 2 IPs auf einer Netzwerkkarte
Zitat von @c-webber
Sollte das nicht mit /22er Netzmasken auf den Netzwerkkarten funktionieren? Somit hast du 0-3 in einem Subnetz und 4-7 in dem anderen?
Sollte das nicht mit /22er Netzmasken auf den Netzwerkkarten funktionieren? Somit hast du 0-3 in einem Subnetz und 4-7 in dem anderen?
Interessanter Ansatz für den Hersteller, denke ich:
Hier haben wir jedoch:
Zitat von @zimbosmurf
Die Originale Firmware der Box hört auf die 192.168.22.3 und schickt ihren Status an die 192.168.22.2.
Wir sollen jetzt eine Prototypfirmware bekommen, die auf die 192.168.22.5 hört und ihren Status an die 192.168.22.4 sendet. Subnetmask für alle ist die 255.255.255.0.
Die Originale Firmware der Box hört auf die 192.168.22.3 und schickt ihren Status an die 192.168.22.2.
Wir sollen jetzt eine Prototypfirmware bekommen, die auf die 192.168.22.5 hört und ihren Status an die 192.168.22.4 sendet. Subnetmask für alle ist die 255.255.255.0.
.2 = BlackBox-1: Senden an Host .3
.3 = BlackBox-1: Empfangen von Host .2
.4.= BlackBox-2: Senden an Host .5
.5 = BlackBox-2: Empfangen von Host .4
Bei beiden /24
Nachtrag:
Zitat von @zombosmurf :
Wir entwickeln für einen Kunden eine Software, die zwei black boxes eines anderen Herstellers über Ethernet (IPv4/UDP) steuern soll.
Wir entwickeln für einen Kunden eine Software, die zwei black boxes eines anderen Herstellers über Ethernet (IPv4/UDP) steuern soll.
Wie soll eure Software den die beiden Hostadressen steuern?
Per Absender-IP auf einer NIC oder per Bindung einer von 2 NICs je BlackBox?
1
Ich Versuche Mal eine Zusammenfassung:
Das Zuweisen mehrerer IPs im selben Subnetz ist sowohl an eine NIC oder auch je eine an mehrere NICs möglich - letzteres ist aber unüblicher.
Du kannst also der EINEN NIC
192.168.22.2/24 und
192.168.22.4/24
zuweisen.
Eure Software soll nun 2 verschiedene BlackBox's ansprechen mit 192.168.22.3 und 192.168.22.5.
Das wird ja sicherlich dann in Profile eurer Software geschrieben und stellt keine Herausforderung dar.
Schwieriger ist, die Sitzungen der Profile an die jeweilige Absender/Empfangs-IPs zu binden, also 192.168.22.2 bzw 192.168.22.4.
Das liegt dann bei Euch ob Ihr das mit einer NIC und multiple IPs macht oder in den Profilen eine von mehreren NICs bindet.
Multiple IPs auf einer NIC sind da sicher zukunftsweisender, da man ja viele IPs an eine NIC binden kann, aber kaum viele NICs in eine PC einbauen kann - mal abgesehen von virtuellen Switchen, was aber aufwendiger ist...
.
Das Zuweisen mehrerer IPs im selben Subnetz ist sowohl an eine NIC oder auch je eine an mehrere NICs möglich - letzteres ist aber unüblicher.
Du kannst also der EINEN NIC
192.168.22.2/24 und
192.168.22.4/24
zuweisen.
Eure Software soll nun 2 verschiedene BlackBox's ansprechen mit 192.168.22.3 und 192.168.22.5.
Das wird ja sicherlich dann in Profile eurer Software geschrieben und stellt keine Herausforderung dar.
Schwieriger ist, die Sitzungen der Profile an die jeweilige Absender/Empfangs-IPs zu binden, also 192.168.22.2 bzw 192.168.22.4.
Das liegt dann bei Euch ob Ihr das mit einer NIC und multiple IPs macht oder in den Profilen eine von mehreren NICs bindet.
Multiple IPs auf einer NIC sind da sicher zukunftsweisender, da man ja viele IPs an eine NIC binden kann, aber kaum viele NICs in eine PC einbauen kann - mal abgesehen von virtuellen Switchen, was aber aufwendiger ist...
.
1Zitat von @c-webber:
steh ich auf'm Schlauch? Sollte das nicht mit /22er Netzmasken auf den Netzwerkkarten funktionieren? Somit hast du 0-3 in einem Subnetz und 4-7 in dem anderen?
steh ich auf'm Schlauch? Sollte das nicht mit /22er Netzmasken auf den Netzwerkkarten funktionieren? Somit hast du 0-3 in einem Subnetz und 4-7 in dem anderen?
Mit ner 22' wird das nichts.
Selbst mit einer 30' Maske ginge das nicht, weil dann die 3 die Broadcast-Adresse im 1. Netz und die 4 die Netzadresse des 2. Netz wären.
1
Hallo @MirkoKR
NAT-Regel auf Router:
Router1:
. IP1:Port_x auf IPA:Port_a
. IP2:Port_y auf IPA:Port_b
Router2:
. IP1:Port_x auf IPB:Port_a
. IP2:Port_y auf IPB:Port_b
usw.
PC mit IPC - kann über IPB mit der 2. Box und mit IPA mit der 1. Box kommunizieren (jeweils Port_a oder Port_B für Data und Control)
Das Design der Box ist eh etwas eigenwillig: Wenn ich den Steuerkanal und den Datenkanal trennen will, benutze ich eine Netzwerkkarte mit einer IP und unterschiedliche Ports für Daten und Steuerung und nicht ein Konstrukt mit 2 unterschiedlichen IPs auf einer Netzwerkkarte.
Siehe zB. FTP-Protokoll: Control über Port 21 und Data über Port 20
Jürgen
Soweit. So gut - aber TE hat Geräte, die explizit jeweils eine andere Host-Adresse ansprechen, die beide auf
dem selben PC verwaltet werden sollen.
Somit hast du wieder 2 IPs auf einer Netzwerkkarte
dem selben PC verwaltet werden sollen.
Somit hast du wieder 2 IPs auf einer Netzwerkkarte
NAT-Regel auf Router:
Router1:
. IP1:Port_x auf IPA:Port_a
. IP2:Port_y auf IPA:Port_b
Router2:
. IP1:Port_x auf IPB:Port_a
. IP2:Port_y auf IPB:Port_b
usw.
PC mit IPC - kann über IPB mit der 2. Box und mit IPA mit der 1. Box kommunizieren (jeweils Port_a oder Port_B für Data und Control)
Das Design der Box ist eh etwas eigenwillig: Wenn ich den Steuerkanal und den Datenkanal trennen will, benutze ich eine Netzwerkkarte mit einer IP und unterschiedliche Ports für Daten und Steuerung und nicht ein Konstrukt mit 2 unterschiedlichen IPs auf einer Netzwerkkarte.
Siehe zB. FTP-Protokoll: Control über Port 21 und Data über Port 20
Jürgen
1Zitat von @emeriks:
Mit ner 22' wird das nichts.
Selbst mit einer 30' Maske ginge das nicht, weil dann die 3 die Broadcast-Adresse im 1. Netz und die 4 die Netzadresse des 2. Netz wären.
Zitat von @c-webber:
steh ich auf'm Schlauch? Sollte das nicht mit /22er Netzmasken auf den Netzwerkkarten funktionieren? Somit hast du 0-3 in einem Subnetz und 4-7 in dem anderen?
steh ich auf'm Schlauch? Sollte das nicht mit /22er Netzmasken auf den Netzwerkkarten funktionieren? Somit hast du 0-3 in einem Subnetz und 4-7 in dem anderen?
Mit ner 22' wird das nichts.
Selbst mit einer 30' Maske ginge das nicht, weil dann die 3 die Broadcast-Adresse im 1. Netz und die 4 die Netzadresse des 2. Netz wären.
Hast recht, meinte auch /30. War n langer Tag gestern...
1da bin ich mit.
Hier ist m.E. der Hersteller gefragt, seine BlackBoxes in Bezug auf IPs und Ports konfigurierbar zu machen.
das ist doch ein Standard-Zenario, das erst vor einigen Tagen hier diskutiert wurde:
Lösung: Vor jede Anlage kommt ein Router mit NAT. Jeder Router hat eine eigene IP in einem gemeinsamen Subnetz, in dem auch der Management-PC steht.
Lösung: Vor jede Anlage kommt ein Router mit NAT. Jeder Router hat eine eigene IP in einem gemeinsamen Subnetz, in dem auch der Management-PC steht.
Diese "Standardlösung" ist je nach Anzahl Clients sehr aufwendig und mit vielen potenziellen Fehlerquellen behaftet...
Wenn der Hersteller der BlackBox's da nichts sinnvolleres ohne diesen Aufwand bringt, würde ich mich nach einem anderen umsehen.
Ich hatte nicht lange her einen Fall wo 12+ RFID Scanner jeweils mit selber IP an einen lokalen PC mit 2 NICs angeschlossen waren, dieser wiederum im LAn des Unternehmens.
Auf den PCs eine SW zur Übertragung der gescannten RFIDs an eine SQL-Server
Lösung: Die RFID-Scanner könnten "doch!" umkonfiguriert werde, sitzen jetzt in einem eigenen VLAN - auch zum gescannten RFID könnte ein Flag hinzugefügt werden sodass EINE Schnittstelle sauber die Daten in den SQL-Server einfügt...
Geht doch ...
1
Hallo @MirkoKR,
Ersterem stimme ich zu. Allerdings sind `n Paar hundert Euro bei einer 5, 6 oder 7 stelligen Investition für die Anlage wohl nur "Peanuts" (in meinem Beispiel). Für einen Scanner oder , wie hier, eine "BlackBox" sieht das sicher anders aus.
Mit deiner 2. Anmerkung kann ich nicht mitgehen. Ich setze ein solches Konstrukt regelmäßig bei der Inbetriebnahme und Prüfung von bei uns entwickelten und gebauten Anlagen ein: Mein PC ist im Firmem-LAN und am Prüfstand ist ein Router, der ein abgetrenntes Netzwerk für die Anlage und ihre Steuerung bereit stellt. Damit kann ich jede IP-Konfiguration der Anlage erreichen, ohne meinem PC umzukonfigurieren und nicht mehr ins Firmennetz zu gelange (nur die NAT-Regel im Router wird angepasst). Gleichzeitig ist das Firmennetz vor einer "Amok laufenden" Steuerung geschützt.
Jürgen
Diese "Standardlösung" ist je nach Anzahl Clients sehr aufwendig und mit vielen potenziellen Fehlerquellen behaftet...
Ersterem stimme ich zu. Allerdings sind `n Paar hundert Euro bei einer 5, 6 oder 7 stelligen Investition für die Anlage wohl nur "Peanuts" (in meinem Beispiel). Für einen Scanner oder , wie hier, eine "BlackBox" sieht das sicher anders aus.
Mit deiner 2. Anmerkung kann ich nicht mitgehen. Ich setze ein solches Konstrukt regelmäßig bei der Inbetriebnahme und Prüfung von bei uns entwickelten und gebauten Anlagen ein: Mein PC ist im Firmem-LAN und am Prüfstand ist ein Router, der ein abgetrenntes Netzwerk für die Anlage und ihre Steuerung bereit stellt. Damit kann ich jede IP-Konfiguration der Anlage erreichen, ohne meinem PC umzukonfigurieren und nicht mehr ins Firmennetz zu gelange (nur die NAT-Regel im Router wird angepasst). Gleichzeitig ist das Firmennetz vor einer "Amok laufenden" Steuerung geschützt.
Jürgen
1
Danke für die vielen Anregungen, ich ziehe hier für mich raus, dass ich mit genügend Verrenkungen das ganze tatsächlich so hinbekommen könnte. Die Geschichte mit den Routern war eine Idee, auf die ich gar nicht gekommen bin, die das ganze tatsächlich relativ einfach lösen könnte.
Wie es jetzt weitergeht muss ich wohl weiter mit dem Hersteller verwursten, denn letztenendes diskutiert er mit mir seit Wochen darüber, ob seine Lösung jetzt funktioniert oder nicht, hat mir aber noch nicht einmal die Firmware, die er angeblich schon längst gebaut hat, geschickt, damit ich es ausprobieren kann.
Letztenendes hängt unser gemeinsamer Kunde als Bindeglied dazwischen, und dem predige ich, dass er riesige Probleme bekommen wird, wenn der Hersteller die Box nicht konfigurierbar macht, aber so lange der Kunde das vom Hersteller nicht verlangt, ist es für mich ein PAL. Ich muss nur eine Konfiguration aufbauen, die grundsätzlich funktionieren kann, und für die entwickeln meine Kollegen dann.
Wie es jetzt weitergeht muss ich wohl weiter mit dem Hersteller verwursten, denn letztenendes diskutiert er mit mir seit Wochen darüber, ob seine Lösung jetzt funktioniert oder nicht, hat mir aber noch nicht einmal die Firmware, die er angeblich schon längst gebaut hat, geschickt, damit ich es ausprobieren kann.
Letztenendes hängt unser gemeinsamer Kunde als Bindeglied dazwischen, und dem predige ich, dass er riesige Probleme bekommen wird, wenn der Hersteller die Box nicht konfigurierbar macht, aber so lange der Kunde das vom Hersteller nicht verlangt, ist es für mich ein PAL. Ich muss nur eine Konfiguration aufbauen, die grundsätzlich funktionieren kann, und für die entwickeln meine Kollegen dann.
Zitat von @zimbosmurf
Ich muss nur eine Konfiguration aufbauen, die grundsätzlich funktionieren kann, und für die entwickeln meine Kollegen dann.
Ich muss nur eine Konfiguration aufbauen, die grundsätzlich funktionieren kann, und für die entwickeln meine Kollegen dann.
Schön, wenn wir Euch einer Lösung näher gebracht haben...
Aber bist du nicht der Meinung, das Ihr effektiver zum Ziel kommt, wenn du und Eure Entwickler schon beim ausloten ZUSAMMEN die HW und SW Möglichkeiten zusammen ausarbeitet?
.
Ich bin schon dieser Meinung. Unser Kunde (der gemeinsame Kunde von uns und dem Hersteller der Black Box, Kunde kauft dort Black box, stellt sie uns hin und sagt: "Macht mal!") geht da jedoch sehr blauäugig ran.
Dass man zum Beispiel die IP-Adressen der Black Box nicht ändern kann kam erst heraus, als der Hersteller uns den zweiten Prototyp der Box geschickt hat und wir gefragt haben, wie man dort denn jetzt die IP ändern kann. Dann hat er uns erklärt, dass man sie nicht ändern kann und dass er uns eine neue Firmware schicken muss und dann hat er drauf bestanden, dass er die IP in der neuen Firmware genau so ändert, wie er das jetzt tut. Und seitdem diskutiert er mit mir, dass das problemlos funktionieren muss - ich denke aber, dass er die neue Firmware nur mit einer Black box getestet hat.
Nach zwei Monaten Diskussion habe ich gestern dann endlich die neue Firmware bekommen und kann es jetzt selbst testen.
Dass man zum Beispiel die IP-Adressen der Black Box nicht ändern kann kam erst heraus, als der Hersteller uns den zweiten Prototyp der Box geschickt hat und wir gefragt haben, wie man dort denn jetzt die IP ändern kann. Dann hat er uns erklärt, dass man sie nicht ändern kann und dass er uns eine neue Firmware schicken muss und dann hat er drauf bestanden, dass er die IP in der neuen Firmware genau so ändert, wie er das jetzt tut. Und seitdem diskutiert er mit mir, dass das problemlos funktionieren muss - ich denke aber, dass er die neue Firmware nur mit einer Black box getestet hat.
Nach zwei Monaten Diskussion habe ich gestern dann endlich die neue Firmware bekommen und kann es jetzt selbst testen.
Hallo,
da zeigt sich mal wieder, wenn man kein "richtiges" Lasten- oder Pflichtenheft (welches alle!! Anforderungen definiert) erstellt und zum Bestandteil des Vertrags/ Auftrags macht, gibt es hinterher nur Streit.
Aber um ein "richtiges" Lasten- bzw. Pflichtenheft zu erstellen, muss man von dem Problem mindestens so viel Ahnung haben wie der, der später die Leistung erbringen soll. Und daran scheiter es meistens beim Auftraggeber.
Wenn überhaupt, schreibt der spätere Auftragnehmer ein "Pflichtenheft" (natürlich nur aus seiner Sicht
) und der Auftraggeber nickt es nur ab (weil er keine Ahnung hat). Eigentlich müsste der Auftraggeber ein Planungsbüro (das Ahnung hat) mit der Erstellung des Pflichtenheftes beauftragen. Aber das Geld spart man sich lieber.
Und hinterher ist dann das Geschrei groß, wenn nicht alles so ausfällt, wie der Auftraggeber es sich vorgestellt hat. Und der Auftragnehmer sagt dann einfach: "Stand doch nicht im Pflichtenheft."
Jürgen
da zeigt sich mal wieder, wenn man kein "richtiges" Lasten- oder Pflichtenheft (welches alle!! Anforderungen definiert) erstellt und zum Bestandteil des Vertrags/ Auftrags macht, gibt es hinterher nur Streit.
Aber um ein "richtiges" Lasten- bzw. Pflichtenheft zu erstellen, muss man von dem Problem mindestens so viel Ahnung haben wie der, der später die Leistung erbringen soll. Und daran scheiter es meistens beim Auftraggeber.
Wenn überhaupt, schreibt der spätere Auftragnehmer ein "Pflichtenheft" (natürlich nur aus seiner Sicht
) und der Auftraggeber nickt es nur ab (weil er keine Ahnung hat). Eigentlich müsste der Auftraggeber ein Planungsbüro (das Ahnung hat) mit der Erstellung des Pflichtenheftes beauftragen. Aber das Geld spart man sich lieber.Und hinterher ist dann das Geschrei groß, wenn nicht alles so ausfällt, wie der Auftraggeber es sich vorgestellt hat. Und der Auftragnehmer sagt dann einfach: "Stand doch nicht im Pflichtenheft."
Jürgen
