19
VLAN-Übergreifend sind Siemens-Netzwerkgeräte unerreichbar
Wir benutzen in unserer Firma diverse Siemens-Produkte, welche an das Netzwerk angehängt werden können, um konfortablere Administration zu ermöglichen. Dazu gehören neben CNC-Maschinen auch Steuerungen für Klimaanlagen. Der Zugriff über ein anderes Subnetz ist jedoch nicht möglich.
Das ganze hat eigentlich schon vor einem Jahr begonnen, als wir erste CNC-Maschinen mit Siemens-Steuerungen erworben haben. Nach unzähligen Versuchen zur Anbindung an das Netzwerk wurde das Problem endlich erkannt: Solange sich der PC im gleichen Subnetz befindet wie die CNC-Maschine, funktioniert der Zugriff problemlos. Sprich: PC hat die IP 192.168.50.101 und die Maschine 192.168.50.201. Wenn sich der PC jetzt aber im Subnetz 10 (also 192.168.10.x) befindet, ist nicht mal ein pingen auf die Maschine (IP 192.168.50.201) erfolgreich. Ein Ping auf einen anderen PC im 50-er Subnetz (z.B. 192.168.50.105) funktioniert problemlos. Da damals auch vom Hersteller der Maschine keine Lösung (ja, nicht mal eine Ursache) gefunden werden konnte, wurde das Vorhaben damals aufgegeben.
Nun stehen wir wieder vor dem gleichen Problem, geht es diesmal jedoch um einen Klimaregler - auch von Siemens. Das exakt gleiche Problem!
Beispiel:
Controller IP: 192.168.70.88
Test-PC 1: 192.168.70.101
Test-PC 2: 192.168.50.101
Ping-Testversuche:
Test-PC 1 -> Controller (OK)
Test-PC 2 -> Controller (Geht nicht)
Test-PC 2 -> Test-PC 1 (OK)
Das Pingen funktioniert also Subnetzübergreifend - jedoch nur nicht auf Siemens-Netzwerkgeräte!
An was könnte das liegen? Benutzen die noch ein spezielles Protokoll?
Ich wäre für jede Antwort dankbar. Denn wie sagt man so schön: "Ich bin mit dem Latein am Ende". Für mich unerklärlich sowas.
Danke im voraus und einen schönen Abend.
Nun stehen wir wieder vor dem gleichen Problem, geht es diesmal jedoch um einen Klimaregler - auch von Siemens. Das exakt gleiche Problem!
Beispiel:
Controller IP: 192.168.70.88
Test-PC 1: 192.168.70.101
Test-PC 2: 192.168.50.101
Ping-Testversuche:
Test-PC 1 -> Controller (OK)
Test-PC 2 -> Controller (Geht nicht)
Test-PC 2 -> Test-PC 1 (OK)
Das Pingen funktioniert also Subnetzübergreifend - jedoch nur nicht auf Siemens-Netzwerkgeräte!
An was könnte das liegen? Benutzen die noch ein spezielles Protokoll?
Ich wäre für jede Antwort dankbar. Denn wie sagt man so schön: "Ich bin mit dem Latein am Ende". Für mich unerklärlich sowas.
Danke im voraus und einen schönen Abend.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 96014
Url: https://administrator.de/contentid/96014
Printed on: April 19, 2024 at 21:04 o'clock
19 Comments
Latest comment
VLANs sind nix anderes als Subnetze. Jedem VLAN wird ein Subnetz zugeordnet.
Zwischen den Subnetzen oder VLANs muss ein Router stehen der Pakete von einem ins andere Subnetz hieven kann.
Z. B. "Router on a stick". Siehe tante google. Router---802.1QTrunkport-------------------------Switch
Zwischen den Subnetzen oder VLANs muss ein Router stehen der Pakete von einem ins andere Subnetz hieven kann.
Z. B. "Router on a stick". Siehe tante google. Router---802.1QTrunkport-------------------------Switch
Normalerweise ist das was du beschreibst 1. Klasse Grundschule IP Subnetting und auch ein vollkommen normales Verhalten !
192.168.n.x sind normale Class C IP Adressen die eine feste 24 Bit Subnetzmaske haben und da ist es logisch das man auf dem gleichen Segment natürlich NICHT mit Geräten kommunizieren kann die sich in einem vollkommen anderen IP Netzwerk befinden.
Schon gar nicht wenn diese Segmente in separaten VLANs befinden (physische Trennung durch VLANs), denn das würde einen Layer 3 (Routing) Switch erfordern um zwischen den VLANs zu kommunizieren !
Genau das beschreibt spacyfreak auch sehr richtig in seinem Kommentar oben.
Nebenbei gesprochen routest du ja scheinbar auch gar nicht, denn dann würde es das Problem gar nicht erst geben. Du nutzt nur vollkommen falsche IP Adressen bzw. Masken auf einem IP Segment so wie es nach deiner Beschreibung aussieht und wunderst dich das nichts klappt was auch nie klappen kann !
Auch eine Lösung zwischen der von dir beschriebenen älteren Problematik der Kommunikation zw. Subnetz 192.168.10 und Subnetz 192.168.50 wäre mit dem Einsatz eines einfachen Routers kinderleicht und in Minuten lösbar gewesen. Ein simpler PC mit 2 Netzwerkkarten hätte das Problem ebenfalls sofort in 3 Minuten gelöst.
Scheinbar waren da wohl keine Netzwerker am Werk (sowohl auf Siemens als auch deiner Seite)...was das Scheitern bei dieser simplen Aufgabenstellung ja mehr als deutlich zeigt !
Banal gesprochen kann man also niemals zwischen 2 PCs an einem Switch kommunizieren wenn der eine PC die 192.168.70.101 hat und der andere PC die 192.168.50.101 jeweils bei einer 24 Bit Subnetzmaske wie es sich für eine Class C IP Adresse auch gehört. Denn der Unterschied im 3ten Byte zeigt ja ganz klar das diese Rechner in unterschiedlichen IP Netzen liegen und ohne einen Router dazwischen können diese IP Adressen NICHT miteinander kommunizieren !
Das vermeintliche fehlerhafte Verhalten von Siemens ist also lediglich normales IP Verhalten wie es im Lehrbuch steht. Warum man da keine Lösung findet die eigentlich auf sofort der Hand liegt ist vollkommen unverständlich ?!
Der Fehler liegt vielmehr in deinen verwendeten IP Adressen, da du immer nur RFC 1918 Class C IP Adressen ala 192.168.x kennst bzw. verwendest.
Scheinbar ist dein Horizont da etwas beschränkt, denn mit etwas Recherche siehst du das der RFC 1918 (Private IP Adressen:
http://de.wikipedia.org/wiki/Private_IP-Adresse
auch einen Class B Bereich von 172.16.0.0 bis 172.32.255.255 hat der dein Problem sofort löst. Vom 10er Netz mal ganz zu schweigen....
In deinem Beispiel können alle PCs und die Siemens Maschine mit der folgenden IP Adressierung sehr wohl problemlos miteinander reden:
Controller IP: 172.16.70.88
Test-PC 1: 172.16.70.101
Test-PC 2: 172.16.50.101
Bei einer Netzmaske von 16 Bit (255.255.0.0)
Hättest du also nur eine etwas intelligentere IP Adresswahl getroffen, wäre es gar nicht erst zu diesem Problem gekommen, denn das 172er Netz hat eine Standard Class B Maske mit 16 Bit.
Der Fehler liegt nicht an Siemens sondern an nur deiner falschen IP Adresswahl !!!
Klar ist mit der CIDR Initiative die starre Class A, B und C Kategorisierung der IP Adressen aufgehoben worden was aber primär für CIDR (Classless Inter Domain Routing) gilt, weniger aber für Endgeräte wie du sie ausnahmslos betreibst.
Du müsstest ja bei deinen verwendeten Class C Adressen die normalerweise eine 24 Bit Maske haben (255.255.255.0) eine Class B, 16 Bit Maske verwenden (255.255.0.0) in deiner Konfig.
Dies lässt sich meist aber nicht konfigurieren da viele Hersteller mit den Standardmasken zur IP Adressklasse arbeiten und sich die Masken zwar verkleinern lassen aber niemals vergrößern.
Auch wenn es denn bei Einzelnen geht, funktioniert das im Zusammenspiel mit anderen Geräten meist nicht sauber, da eben nicht alle CIDR Subnetting auf Endgeräten wie PCs usw. supporten wie vermutlich auch die Siemensgeräte. Eine Netzmaske muss aber innerhalb eines IP Segments IMMER konsitent sein !!
Siemens ist damit aber absolut TCP/IP standardkonform, denn nirgends steht geschrieben das ein IP Stack CIDR Masken supporten MUSS !!!
Wie gesagt...mehr oder weniger deine ungeschickte IP Adresswahl oder du wusstest mit Netzwerkmasken vermutlich nicht richtig umzugehen ?!
192.168.n.x sind normale Class C IP Adressen die eine feste 24 Bit Subnetzmaske haben und da ist es logisch das man auf dem gleichen Segment natürlich NICHT mit Geräten kommunizieren kann die sich in einem vollkommen anderen IP Netzwerk befinden.
Schon gar nicht wenn diese Segmente in separaten VLANs befinden (physische Trennung durch VLANs), denn das würde einen Layer 3 (Routing) Switch erfordern um zwischen den VLANs zu kommunizieren !
Genau das beschreibt spacyfreak auch sehr richtig in seinem Kommentar oben.
Nebenbei gesprochen routest du ja scheinbar auch gar nicht, denn dann würde es das Problem gar nicht erst geben. Du nutzt nur vollkommen falsche IP Adressen bzw. Masken auf einem IP Segment so wie es nach deiner Beschreibung aussieht und wunderst dich das nichts klappt was auch nie klappen kann !
Auch eine Lösung zwischen der von dir beschriebenen älteren Problematik der Kommunikation zw. Subnetz 192.168.10 und Subnetz 192.168.50 wäre mit dem Einsatz eines einfachen Routers kinderleicht und in Minuten lösbar gewesen. Ein simpler PC mit 2 Netzwerkkarten hätte das Problem ebenfalls sofort in 3 Minuten gelöst.
Scheinbar waren da wohl keine Netzwerker am Werk (sowohl auf Siemens als auch deiner Seite)...was das Scheitern bei dieser simplen Aufgabenstellung ja mehr als deutlich zeigt !
Banal gesprochen kann man also niemals zwischen 2 PCs an einem Switch kommunizieren wenn der eine PC die 192.168.70.101 hat und der andere PC die 192.168.50.101 jeweils bei einer 24 Bit Subnetzmaske wie es sich für eine Class C IP Adresse auch gehört. Denn der Unterschied im 3ten Byte zeigt ja ganz klar das diese Rechner in unterschiedlichen IP Netzen liegen und ohne einen Router dazwischen können diese IP Adressen NICHT miteinander kommunizieren !
Das vermeintliche fehlerhafte Verhalten von Siemens ist also lediglich normales IP Verhalten wie es im Lehrbuch steht. Warum man da keine Lösung findet die eigentlich auf sofort der Hand liegt ist vollkommen unverständlich ?!
Der Fehler liegt vielmehr in deinen verwendeten IP Adressen, da du immer nur RFC 1918 Class C IP Adressen ala 192.168.x kennst bzw. verwendest.
Scheinbar ist dein Horizont da etwas beschränkt, denn mit etwas Recherche siehst du das der RFC 1918 (Private IP Adressen:
http://de.wikipedia.org/wiki/Private_IP-Adresse
auch einen Class B Bereich von 172.16.0.0 bis 172.32.255.255 hat der dein Problem sofort löst. Vom 10er Netz mal ganz zu schweigen....
In deinem Beispiel können alle PCs und die Siemens Maschine mit der folgenden IP Adressierung sehr wohl problemlos miteinander reden:
Controller IP: 172.16.70.88
Test-PC 1: 172.16.70.101
Test-PC 2: 172.16.50.101
Bei einer Netzmaske von 16 Bit (255.255.0.0)
Hättest du also nur eine etwas intelligentere IP Adresswahl getroffen, wäre es gar nicht erst zu diesem Problem gekommen, denn das 172er Netz hat eine Standard Class B Maske mit 16 Bit.
Der Fehler liegt nicht an Siemens sondern an nur deiner falschen IP Adresswahl !!!
Klar ist mit der CIDR Initiative die starre Class A, B und C Kategorisierung der IP Adressen aufgehoben worden was aber primär für CIDR (Classless Inter Domain Routing) gilt, weniger aber für Endgeräte wie du sie ausnahmslos betreibst.
Du müsstest ja bei deinen verwendeten Class C Adressen die normalerweise eine 24 Bit Maske haben (255.255.255.0) eine Class B, 16 Bit Maske verwenden (255.255.0.0) in deiner Konfig.
Dies lässt sich meist aber nicht konfigurieren da viele Hersteller mit den Standardmasken zur IP Adressklasse arbeiten und sich die Masken zwar verkleinern lassen aber niemals vergrößern.
Auch wenn es denn bei Einzelnen geht, funktioniert das im Zusammenspiel mit anderen Geräten meist nicht sauber, da eben nicht alle CIDR Subnetting auf Endgeräten wie PCs usw. supporten wie vermutlich auch die Siemensgeräte. Eine Netzmaske muss aber innerhalb eines IP Segments IMMER konsitent sein !!
Siemens ist damit aber absolut TCP/IP standardkonform, denn nirgends steht geschrieben das ein IP Stack CIDR Masken supporten MUSS !!!
Wie gesagt...mehr oder weniger deine ungeschickte IP Adresswahl oder du wusstest mit Netzwerkmasken vermutlich nicht richtig umzugehen ?!
Hallo
Also erstmal: Ich schiebe hier niemandem irgendetwas in die Schuhe! Ich sage lediglich, dass wir nur mit Siemens-Geräten diese Probleme haben.
Für meinen Beitrag muss ich mich insofern entschuldigen, da wir tatsächlich 172.16.x.x-Adressen verwenden und nicht wie angegeben 192.168.x.x! Mein Fehler!
Somit heisst es:
Controller IP: 172.16.70.88
Test-PC 1: 172.16.70.101
Test-PC 2: 172.16.50.101
Ping-Testversuche:
Test-PC 1 -> Controller (OK)
Test-PC 2 -> Controller (Geht nicht)
Test-PC 2 -> Test-PC 1 (OK)
Danke für eure Inputs.
Also erstmal: Ich schiebe hier niemandem irgendetwas in die Schuhe! Ich sage lediglich, dass wir nur mit Siemens-Geräten diese Probleme haben.
Für meinen Beitrag muss ich mich insofern entschuldigen, da wir tatsächlich 172.16.x.x-Adressen verwenden und nicht wie angegeben 192.168.x.x! Mein Fehler!
Somit heisst es:
Controller IP: 172.16.70.88
Test-PC 1: 172.16.70.101
Test-PC 2: 172.16.50.101
Ping-Testversuche:
Test-PC 1 -> Controller (OK)
Test-PC 2 -> Controller (Geht nicht)
Test-PC 2 -> Test-PC 1 (OK)
Danke für eure Inputs.
OK, dann ist der Fehler eindeutig, denn dann nutzt du vermutlich KEINE 16 Bit Masken (255.255.0.0) !!!
Du musst sicherstellen, das diese konsistent auf allen Geräten eingetragen ist, dann klappt es auch.
Beim Pingen eines PCs musst du ferner darauf achten das in den Firewall Settings ICMP Echo (Ping) erlaubt ist und nicht ausgeschaltet !!!
Du musst sicherstellen, das diese konsistent auf allen Geräten eingetragen ist, dann klappt es auch.
Beim Pingen eines PCs musst du ferner darauf achten das in den Firewall Settings ICMP Echo (Ping) erlaubt ist und nicht ausgeschaltet !!!
Hallo Zusammen,
mein erster Gedanke nach dem Lesen des Beitrags, und später auch nach dem Lesen der Kommentare ist, auf den Siemens-Controllern ist kein Default Gateway gesetzt...
Grüße, Steffen
mein erster Gedanke nach dem Lesen des Beitrags, und später auch nach dem Lesen der Kommentare ist, auf den Siemens-Controllern ist kein Default Gateway gesetzt...
Grüße, Steffen
wenn alle ip's im gleichen subnetz liegen, was sie ja scheinbar sollen, dann ist auch kein default gateway nötig.
unterbinden diese siemens geräte einfach nur den ping bzw. antworten nicht darauf ?
poste doch mal bitte alle subnetzmasken und evtl gateway's, damit es etwas leichter wird und wir nicht mutmaßen müssen
unterbinden diese siemens geräte einfach nur den ping bzw. antworten nicht darauf ?
poste doch mal bitte alle subnetzmasken und evtl gateway's, damit es etwas leichter wird und wir nicht mutmaßen müssen
Hallo schleusenBratze,
wie kommst du darauf, daß alle IP's im gleichen Subnet liegen ('VLAN-Übergreifend')? Übrigens ist deine Shift-Taste defekt.
Grüße, Steffen
wie kommst du darauf, daß alle IP's im gleichen Subnet liegen ('VLAN-Übergreifend')? Übrigens ist deine Shift-Taste defekt.
Grüße, Steffen
Hallo, nee shifty Shift funktioniert tadellos ;)
Wenn VLAN übergeifend gepingt werden soll, dann ist ein Layer 3 Switch oder Router nötig. Falls das nicht vorhanden ist, dann müssen die IP's im gleichen Subnetz liegen, sonst funktioniert einfach keine Kommunikation.
Entweder sie liegen im gleichen Subnetz und es funktioniert nicht, dann stellt sich die Frage: warum ? oder aber sie liegen nicht im gleichen Subnetz und es muss ne Routing Funktion her. Evtl ist ja auch die Subnetzmaske des Steuergerätes weiter eingeschränkt, als die der beiden PC's, weshalb diese sich untereinander Verständigen können, aber eben mir dem Steuergerät nicht klarkommen.
Vielleicht hat schleusi auch ein winziges Detail übersehen
Wenn VLAN übergeifend gepingt werden soll, dann ist ein Layer 3 Switch oder Router nötig. Falls das nicht vorhanden ist, dann müssen die IP's im gleichen Subnetz liegen, sonst funktioniert einfach keine Kommunikation.
Entweder sie liegen im gleichen Subnetz und es funktioniert nicht, dann stellt sich die Frage: warum ? oder aber sie liegen nicht im gleichen Subnetz und es muss ne Routing Funktion her. Evtl ist ja auch die Subnetzmaske des Steuergerätes weiter eingeschränkt, als die der beiden PC's, weshalb diese sich untereinander Verständigen können, aber eben mir dem Steuergerät nicht klarkommen.
Vielleicht hat schleusi auch ein winziges Detail übersehen
Hallo schleusenBratze,
das denke ich auch
Grüße, Steffen
Vielleicht hat schleusi auch ein winziges Detail übersehen
das denke ich auch
Grüße, Steffen
aber nur was ? denn er hat noch gar nicht die subnetzmasken angegeben!
Hallo schleusenBratze,
aus dem OP geht klar hervor, daß ein Problem bei der Kommunikation zwischen unterschiedlichen Subnets besteht, wozu benötigs du dann noch die Masken?
Zitat:
Grüße, Steffen
aus dem OP geht klar hervor, daß ein Problem bei der Kommunikation zwischen unterschiedlichen Subnets besteht, wozu benötigs du dann noch die Masken?
Zitat:
Das Pingen funktioniert also Subnetzübergreifend - jedoch nur nicht auf Siemens-Netzwerkgeräte!
Grüße, Steffen
weil ich gern den gesamten kontext sehen würde. warum also der ping zwischen unterschiedlichen subnetzen funktionieren soll und gerade mit den siemens geräten nicht.
das pingen auf diese ging ja scheinbar nur, wenn der pc im gleichen subnetz wie das siemens gerät war......deshalb würde mich die maske des siemensgerätes interessieren (vielleicht ist diese ja restricted)
ferner muss ich dazu sagen, dass aqui schon alles wesentliche dazu beschrieben hat.
das pingen auf diese ging ja scheinbar nur, wenn der pc im gleichen subnetz wie das siemens gerät war......deshalb würde mich die maske des siemensgerätes interessieren (vielleicht ist diese ja restricted)
ferner muss ich dazu sagen, dass aqui schon alles wesentliche dazu beschrieben hat.
Zitat von @schleusenBRATZE:
weil ich gern den gesamten kontext sehen würde. warum also der
ping zwischen unterschiedlichen subnetzen funktionieren soll und
gerade mit den siemens geräten nicht.
das pingen auf diese ging ja scheinbar nur, wenn der pc im gleichen
subnetz wie das siemens gerät war......deshalb
weil ich gern den gesamten kontext sehen würde. warum also der
ping zwischen unterschiedlichen subnetzen funktionieren soll und
gerade mit den siemens geräten nicht.
das pingen auf diese ging ja scheinbar nur, wenn der pc im gleichen
subnetz wie das siemens gerät war......deshalb
tippe ich auf ein fehlendes Gateway...
gut ich glaube unsere diskussion ist nicht wirklich hilfreich.....wie gesagt, hat aqui schon alles wesentliche dazu gesagt.
somit ist der author am zug!
damit die frage der subnetze und gateways geklärt wird ;)
Zitat von @aqui:
OK, dann ist der Fehler eindeutig, denn dann nutzt du vermutlich KEINE
16 Bit Masken (255.255.0.0) !!!
Du musst sicherstellen, das diese konsistent auf allen Geräten
eingetragen ist, dann klappt es auch.
Beim Pingen eines PCs musst du ferner darauf achten das in den
Firewall Settings ICMP Echo (Ping) erlaubt ist und nicht ausgeschaltet
!!!
OK, dann ist der Fehler eindeutig, denn dann nutzt du vermutlich KEINE
16 Bit Masken (255.255.0.0) !!!
Du musst sicherstellen, das diese konsistent auf allen Geräten
eingetragen ist, dann klappt es auch.
Beim Pingen eines PCs musst du ferner darauf achten das in den
Firewall Settings ICMP Echo (Ping) erlaubt ist und nicht ausgeschaltet
!!!
Zitat von @schleusenBRATZE:
poste doch mal bitte alle subnetzmasken und evtl gateway's,
damit es etwas leichter wird und wir nicht mutmaßen müssen
poste doch mal bitte alle subnetzmasken und evtl gateway's,
damit es etwas leichter wird und wir nicht mutmaßen müssen
somit ist der author am zug!
damit die frage der subnetze und gateways geklärt wird ;)
Ich glaube, Aqui hat genau den Punkt übersehen (sorry Aqui), welchen auch du ignorierst.
Grüße Steffen
Grüße Steffen
Hallo Zusammen
Erstmal danke für die vielen Antworten.
Die Subnetze werden bei uns geroutet (Layer 3). Die Konfigs bei den Netzwerkdevices sieht so aus:
Siemens-Controller:
IP: 172.16.70.88
SN: 255.255.255.0
GW: 172.16.70.254
Test-PC 1:
IP: 172.16.70.101
SN: 255.255.255.0
GW: 172.16.70.254
Test-PC 2:
IP: 172.16.50.101
SN: 255.255.255.0
GW: 172.16.50.254
Ping-Testversuche:
Test-PC 1 -> Controller (OK)
Test-PC 2 -> Controller (Geht nicht)
Test-PC 2 -> Test-PC 1 (OK)
Erstmal danke für die vielen Antworten.
Die Subnetze werden bei uns geroutet (Layer 3). Die Konfigs bei den Netzwerkdevices sieht so aus:
Siemens-Controller:
IP: 172.16.70.88
SN: 255.255.255.0
GW: 172.16.70.254
Test-PC 1:
IP: 172.16.70.101
SN: 255.255.255.0
GW: 172.16.70.254
Test-PC 2:
IP: 172.16.50.101
SN: 255.255.255.0
GW: 172.16.50.254
Ping-Testversuche:
Test-PC 1 -> Controller (OK)
Test-PC 2 -> Controller (Geht nicht)
Test-PC 2 -> Test-PC 1 (OK)
aqui hat es nicht übersehen... Zitat Schmidmajer:
Somit heisst es:
Controller IP: 172.16.70.88
Test-PC 1: 172.16.70.101
Test-PC 2: 172.16.50.101
Ping-Testversuche:
Test-PC 1 -> Controller (OK)
Test-PC 2 -> Controller (Geht nicht)
Test-PC 2 -> Test-PC 1 (OK)
Aus dem obigen Posting von ihm kann man aber mal wieder sehen das er es nicht für nötig gehalten hat den oder die Antworten in diesem Thread zu lesen !!!
Er verwendet auf mit den 172er Adressen wiederum Class C Subnetzmasken das er sein Problem schon wieder hat.
Im Beitrag steht ganz klar das hier Class B Subnetzmasken verwendet werden sollten und dann hat er das Problem nicht !!!
Er muss dann auch keine Gateway Adressen konfigurieren !!!
Richtig wäre dann also folgende Konfig:
Siemens-Controller:
IP: 172.16.70.88
SN: 255.255.0.0
Test-PC 1:
IP: 172.16.70.101
SN: 255.255.0.0
Test-PC 2:
IP: 172.16.50.101
SN: 255.255.0.0
Nur so wird ein Schuh draus denn er routet ja de facto gar nicht da er weder einen Router noch einen Layer-3 Switch (Routing Switch) betreibt !!!
Eine VLAN Konfiguration OHNE Router oder Layer-3 (Routing) Switch würde eine Kommunikation ja so oder so vollständig unterbinden. Dann würden ihm nicht einmal Gateway Adressen nützen !!! Wahrscheinlich ist das bei ihm auch noch der Fall das das gesamte IP Design so oder so von Anfang an zum Scheitern veruteilt ist !
Alle IP Adressen befinden sich nach seinen Aussagen ja auf einem Draht und dann funktioniert es nicht anders !!! Die Gateway Adressen sind dann natürlich Makulatur...das ist klar !
Erst in einer sauberen gerouteten VLAN Infrastruktur würde es mit Class C Masken (24 Bit, 255.255.255.0) funktionieren. (Da hat smerlin dann absolut Recht mit seinen gateways !) NICHT aber wenn wie hier scheinbar keinerlei Router vorhanden sind um die VLANs zu koppeln, dann bleibt nur die Verwendung von 16 Bit, 255.255.0.0 Masken !!!
Somit heisst es:
Controller IP: 172.16.70.88
Test-PC 1: 172.16.70.101
Test-PC 2: 172.16.50.101
Ping-Testversuche:
Test-PC 1 -> Controller (OK)
Test-PC 2 -> Controller (Geht nicht)
Test-PC 2 -> Test-PC 1 (OK)
Aus dem obigen Posting von ihm kann man aber mal wieder sehen das er es nicht für nötig gehalten hat den oder die Antworten in diesem Thread zu lesen !!!
Er verwendet auf mit den 172er Adressen wiederum Class C Subnetzmasken das er sein Problem schon wieder hat.
Im Beitrag steht ganz klar das hier Class B Subnetzmasken verwendet werden sollten und dann hat er das Problem nicht !!!
Er muss dann auch keine Gateway Adressen konfigurieren !!!
Richtig wäre dann also folgende Konfig:
Siemens-Controller:
IP: 172.16.70.88
SN: 255.255.0.0
Test-PC 1:
IP: 172.16.70.101
SN: 255.255.0.0
Test-PC 2:
IP: 172.16.50.101
SN: 255.255.0.0
Nur so wird ein Schuh draus denn er routet ja de facto gar nicht da er weder einen Router noch einen Layer-3 Switch (Routing Switch) betreibt !!!
Eine VLAN Konfiguration OHNE Router oder Layer-3 (Routing) Switch würde eine Kommunikation ja so oder so vollständig unterbinden. Dann würden ihm nicht einmal Gateway Adressen nützen !!! Wahrscheinlich ist das bei ihm auch noch der Fall das das gesamte IP Design so oder so von Anfang an zum Scheitern veruteilt ist !
Alle IP Adressen befinden sich nach seinen Aussagen ja auf einem Draht und dann funktioniert es nicht anders !!! Die Gateway Adressen sind dann natürlich Makulatur...das ist klar !
Erst in einer sauberen gerouteten VLAN Infrastruktur würde es mit Class C Masken (24 Bit, 255.255.255.0) funktionieren. (Da hat smerlin dann absolut Recht mit seinen gateways !) NICHT aber wenn wie hier scheinbar keinerlei Router vorhanden sind um die VLANs zu koppeln, dann bleibt nur die Verwendung von 16 Bit, 255.255.0.0 Masken !!!
Hallo Aqui,
in dem von dir beantworteten Beitrag lese ich:
...
in dem von dir beantworteten Beitrag lese ich:
Die Subnetze werden bei uns geroutet
...
Wenn das wirklich der Fall sein sollte, dann müsste Schmidtmajer einmal genau das WIE beschreiben, sonst ist eine detailierte Hilfe nicht möglich und wir zereissen uns hier wieder gegenseitig mit Raterei...
