Hallo in die Runde,
Bevor ich mein Problem beschreibe, möchte ich meinen aktuellen Aufbau
skizzieren:
Ein 5-Port Ethernet Switch auf Basis des IC KSZ8895 verbindet ein µC
Board mittels dem xPico von Lantronix, ein RPi Compute Modul (mit
Touch-Display) mit dem LAN9514 IC, sowie ein weiteres ethernetfähiges
Gerät miteinander. Ein weiterer Port des KSZ8895 steht für ein externes
Netzwerk bereit. Das Compute Modul mit dem Display ist optional
(abnehmbar, verbunden via PoE, ein Port vom KSZ8895 hat einen PoE
Injektor) und dient der Steuerung und Visualisierung. Die Visualisierung
wird hierbei durch eine Weboberfläche realisiert, sodass man auch den µC
von einem anderen PC im Netzwerk aus einfach via der Webseite steuern
kann.
Nun ist es so, dass das Ganze zu einem Gerät verschmelzen soll, mit der
Anforderung, dass das Gerät insgesamt nach außen hin nur eine IP-Adresse
besitzen soll.
Meiner Meinung nach benötige ich jetzt hier eine NAT (NAT-PMP) Lösung,
die das externe Netzwerk mit meinem kleinen "internen" Netzwerk
zusammenführt. Die Applikationen bzw. Datenschnittstellen aller eingangs
erläuterten Komponenten arbeiten auf jeweils anderen Ports, sodass
NAT-PMP hier ein richtiger Ansatz sein sollte?
Die Frage ist nun aber weiterhin, wie bringe ich ein Peripherie hinein,
die NAT unterstützt bzw. welche Gerätschaft kommt hier in Frage? Die
Lösung sollte in Richtung embedded gehen und idealerweise Platz auf der
aktuellen µC Platine finden.
Ich hatte die Hoffnung, nach dem Vorbild des xPicos ein Modul zu finden.
Dem ist jedoch nicht so. Hat hier jemand vielleicht einen Tipp? Das
Ganze sollte industrietauglich sein.
Zum anderen war meine Überlegung, das bereits verwendete Compute Module
umzusetzen und als NAT Gateway zwischen externen Ethernet-Port und dem
KSZ8895 einzusetzen. Das Dispaly soll natürlich optional und abnehmbar
bleiben, daher stellt sich mir die Frage, ob man die Datenleitungen des
DSI Ports über Kabel laufen lassen kann (Kabelänge ca. 1,5 Meter),
sodass es natürlich noch funktioniert.
Soweit erstmal.
Ich freue mich über Ratschläge oder alternative Ansätze :)
Mach VLANs nach 802.1q auf. Dein Switch kann das.
Dein Microcontroller und das externe Gerät kommen in VLAN 1, untagged
Der externe Port kommt in VLAN 2, untagged
Das Compute Module kommt in VLAN 1 und 2, und diese Switch Port muss
tagged Pakete (also mit 802.1p/q Tag) senden und empfangen. Das Compute
Modul natürlich auch. Das spielt dann Router bzw Proxy.
Damit ist der zusätzliche Hardwareaufwand gleich 0.
DSI müsste begrenzt verlängerbar sein, wenn Du geeignete Kabel und
Stecker verwendest. Das ist übelste Hochfrequenztechnik.
Probiere mal DisplayPort Kabel aus, ansonsten SAS-Kabel. Das müsste
zumindest von der Bandbreite her einigermaßen passen.
fchk
Frank K. schrieb:> Mach VLANs nach 802.1q auf. Dein Switch kann das.>> Dein Microcontroller und das externe Gerät kommen in VLAN 1, untagged> Der externe Port kommt in VLAN 2, untagged> Das Compute Module kommt in VLAN 1 und 2, und diese Switch Port muss> tagged Pakete (also mit 802.1p/q Tag) senden und empfangen. Das Compute> Modul natürlich auch. Das spielt dann Router bzw Proxy
Hallo Frank,
vielen Dank für dein Feedback! Ich möchte zunächst noch hinzufügen, dass
der µC mit xPico ebenfalls aus den externen Netzwerk gesteuert werden
soll. Sprich, aus dem externen Netzwerk und gleichermaßen das CM reden
mit einem eigenen Protokoll mit dem xPico und damit mit dem µC.
Die Geschichte mit den VLANs hatte ich auch schon mehrmals mir durch den
Kopf gehen lassen, jedoch fehlt mir hier das Fachwissen wie das Ganze
genau funktioniert. Konkret meine ich damit, wie ich mit einer
IP-Adresse von extern die unterschiedlichen Geräte via VLANs jeweils
erreiche.
Meine Vorstellung sieht so aus:
- xPico hat IP A
- RPi CM hat IP B
- Gerät X hat IP C
-> "universelle" xPico IP durch die alle Komponenten von extern
angesprochen werden können
-> Anfrage an IP A Port 80 weiter zu CM
-> Anfrage an IP A Port xx weiter zu xPico / seriell zum µC
-> Anfrage an IP A Port yy weiter zu Gerät X
Ich werde mich mal in die VLAN-geschichte tiefer einarbeiten. hast du
hier ein Link zu einem Beispiel?
EDIT: Das Ganze funktioniert auch dann, wenn das CM nicht am Switch
angeschlossen ist.
VLAN ist sicherlich der eleganteste Weg.
Dabei hat dein RaspberryPi so viele logische Ethernet-Schnittstellen,
wie du VLANs konfiguriert hat.
Auf dem RPi ein NAT zwischen 2 Schnittstellen zu schalten ist die
leichteste Übung.
Entspricht eigentlich genau dem im Eingangspost geforderten Scenario,
nur eben ohne zusätzliche Hardware.
Frank K. schrieb:> Mach VLANs nach 802.1q auf. Dein Switch kann das.>> Dein Microcontroller und das externe Gerät kommen in VLAN 1, untagged> Der externe Port kommt in VLAN 2, untagged> Das Compute Module kommt in VLAN 1 und 2, und diese Switch Port muss> tagged Pakete (also mit 802.1p/q Tag) senden und empfangen. Das Compute> Modul natürlich auch. Das spielt dann Router bzw Proxy.
Ich nochmal dazu. Hatte gerade einen kleinen Denkfehler und hatte deinen
Vorschlag nochmal richtig gelesen:
Nach deinem Vorschlag bedeutet das aber, dass das CM hier das Routing
(NAT) macht. Sprich in meinem jetzigen Aufbau ist das nicht möglich
(alleine nur mit VLANs vom KSZ8895) dies zu realisieren, da das CM mit
Display nur optional ist. Möglich wäre es wieder dann, wenn das CM
fester Bestandteil des Hardwareaufbaus ist und das Display lediglich
optional ist, jedoch aber nicht das CM selbst.
Harry L. schrieb:> VLAN ist sicherlich der eleganteste Weg.> Dabei hat dein RaspberryPi so viele logische Ethernet-Schnittstellen,> wie du VLANs konfiguriert hat.> Auf dem RPi ein NAT zwischen 2 Schnittstellen zu schalten ist die> leichteste Übung.>> Entspricht eigentlich genau dem im Eingangspost geforderten Scenario,> nur eben ohne zusätzliche Hardware.
Hallo Harry,
auch dir vielen Dank für deine Rückmeldung. Wie ich hier gerade in
diesem Post bezüglich Franks Aussage nochmal berichtigt habe, ist also
das CM mindestend notwendig, da nur mit VLANs durch den KSZ8895 und ohne
das CM die Geschichte mit einer IP für alles nicht möglich ist,
entsprechend:
Tony S. schrieb:> Meine Vorstellung sieht so aus:>> - xPico hat IP A> - RPi CM hat IP B> - Gerät X hat IP C>> -> "universelle" xPico IP durch die alle Komponenten von extern> angesprochen werden können> -> Anfrage an IP A Port 80 weiter zu CM> -> Anfrage an IP A Port xx weiter zu xPico / seriell zum µC> -> Anfrage an IP A Port yy weiter zu Gerät X
Also unterm Strich muss das CM fester Bestandteil der Anordnung werden
und nur das Display am CM wird optional. Bedeutet weiterhin das ein
Umbau so hier sinnvoll ist:
Externes Ethernet <-> ETH A CM // ETH B CM <-> KSZ8895 <-> µC, GerätX,..
Im CM dann die entsprechenden NAT Regel aufstellen und fertig. Da wäre
dann ja eigentlich auch kein VLAN Setup im KSZ8895 nötig, wenn das CM
das Routet(?).
Geht ihr so mit?
Tony S. schrieb:> Frank K. schrieb:>> Mach VLANs nach 802.1q auf. Dein Switch kann das.>>>> Dein Microcontroller und das externe Gerät kommen in VLAN 1, untagged>> Der externe Port kommt in VLAN 2, untagged>> Das Compute Module kommt in VLAN 1 und 2, und diese Switch Port muss>> tagged Pakete (also mit 802.1p/q Tag) senden und empfangen. Das Compute>> Modul natürlich auch. Das spielt dann Router bzw Proxy.>> Ich nochmal dazu. Hatte gerade einen kleinen Denkfehler und hatte deinen> Vorschlag nochmal richtig gelesen:>> Nach deinem Vorschlag bedeutet das aber, dass das CM hier das Routing> (NAT) macht. Sprich in meinem jetzigen Aufbau ist das nicht möglich> (alleine nur mit VLANs vom KSZ8895) dies zu realisieren, da das CM mit> Display nur optional ist. Möglich wäre es wieder dann, wenn das CM> fester Bestandteil des Hardwareaufbaus ist und das Display lediglich> optional ist, jedoch aber nicht das CM selbst.
Genau so ist es. Alles andere wäre aber mehr Aufwand.
> Externes Ethernet <-> ETH A CM // ETH B CM <-> KSZ8895 <-> µC, GerätX,..>> Im CM dann die entsprechenden NAT Regel aufstellen und fertig. Da wäre> dann ja eigentlich auch kein VLAN Setup im KSZ8895 nötig, wenn das CM> das Routet(?).>> Geht ihr so mit?
Das CM hat kein Ethernet eingebaut. Wie realisierst Du das, und wieviele
Ethernet-Interfaces hast Du?
Wenn Du zwei unabhängige Ethernet-Interfaces hast, brauchst Du kein
VLAN. Nur wenn Du nur ein physikalisches Ethernet am CM hast, brauchst
Du VLAN, damit die anderen Geräte unter allen Umständen nur und
ausschließlich über das CM und dessen IP-Adresse erreichbar ist. Du
musst damit nur ein Gerät gegen Angriffe von außen sichern.
fchk
Frank K. schrieb:> Das CM hat kein Ethernet eingebaut. Wie realisierst Du das, und wieviele> Ethernet-Interfaces hast Du?>> Wenn Du zwei unabhängige Ethernet-Interfaces hast, brauchst Du kein> VLAN. Nur wenn Du nur ein physikalisches Ethernet am CM hast, brauchst> Du VLAN, damit die anderen Geräte unter allen Umständen nur und> ausschließlich über das CM und dessen IP-Adresse erreichbar ist. Du> musst damit nur ein Gerät gegen Angriffe von außen sichern.
Vielen Dank, jetzt bin ich im Bilde :)
Jetzt habe ich einen LAN9514 am RPi CM, sodass der Pi dadruch an Netz
kommt, sowie PoE für den Saft. Kurz gesagt, das CM mit PoE / LAN und
Display ist eine Einheit für sich. Jetzt würde ich das CM mit auf die µC
Platine verlagern.
Ob ich den RPi mit einem Netzwerkinterface und dann entsprechenden VLANs
betreibe oder mit zwei Netzwerkinterfaces, würde ich mal abhängig vom
größeren Aufwand machen, sowie dem Platz auf der Platine (ist stark
begrenzt). Aktuell tendiere ich zu zwei ETH-Ports am CM durch zwei
LAN9514 Chips. Hier müsste der eine LAN9514 an den USB des anderen
LAN9514 nehme ich an? Sollte der Kernel vom Pi ja problemlos mit umgehen
können?
In ein paar Tagen ist mein Prototypen-Board mit dem KSZ8895 und einem
Atmega328 daneben da, sowie diversen Jumpern für die
Standalone-Variante. Da versuch ich mal mittels SPI dort die
entsprechenden Einstellungen zu setzen für die VLAN Geschichte.
Vielen Dank für eure Hilfe!
Kleiner Nachtrag:
So, ich habe testweise den normalen Raspberry Pi 3 mal als WLAN Router
eingerichtet und mit NAT regeln einen dahinterliegenden Webserver
angesprochen. Funktioniert wunderbar! Also kommen an mein CM 2
Ethernet-Schnittstellen dran.
Tony S. schrieb:> Also kommen an mein CM 2 Ethernet-Schnittstellen dran.
Hättest du VLAN verstanden, (oder versucht, das zu verstehen) wäre das
vollkommen unnötig.
