Robotics in the cloud - netzwerk und infrastruktur -> interfaces konfig

magnum

Member
Aug 31, 2021
42
0
11
35
Guten Tag miteinander,

ich habe da ein Problem. Es geht um die Bereitstellung eines (vorerst) kleinen Clusters bestehend aus aktuell einer Node mit Proxmox. Es sollen bis zu 15 Roboter (Kuka, UR, Mitsubishi, Selbstbau) im Roboternetzwerk sein. In Zukunft kommen weitere hinzu.
Kurz zu mir: ich bin kein Profi in der IT, aber Elektronikingenieur mit Linux- und Software-Hintergrund. Das ganze Projekt ist ein Forschungsprojekt und ich bin als Masterand- und Werkstudent daran beteiligt.

Die Node soll Windows und Linux VMs ausliefern um mit ROS2 und Kubernetes zu arbeiten. Auch sollen die Roboter über etwaige IDEs programmiert werden können. Die IDEs werden über vnc, rdp o.ä. abgerufen.

Nun suche ich nach der best Practice oder State of the Art Methode um die Kommunikation sicherzustellen. Ich habe euch hier einen kleinen Netzplan erstellt:
https://drive.google.com/file/d/1_TInmg50r-shek6ZpSgXXJ8h2QVhIHzA/view?usp=sharing

Wie zu sehen hat der Proxmox Host 3 Netzwerkkarten: eno1, eno2 und eno3. 1 und 2 sind sicht- und konfigurierbar im Proxmox. eno3 dient nur dem Wartungszugriff (ipmi). Eno1 ist das Interface zum Campus/Internet, welches mit wpasupplicant angeschlossen ist. Eno2 ist an den unmanaged Switch des Robonets angeschlossen.

Die Virtuellen Anwendungen sollen, wenn möglich, ins Internet kommen können und sich gegenseitig erreichen. Auch die realen Arbeitsplätze sollen das Robonetz und in das VMNetz erreichen können. Dabei soll die effizienzeste Route verwendet werden. Die Route über das Campus-Netz ist aktuell vlan tagged und unterbindet nicht autorisierte Kommunikation. Da kann ich teilweise die Maschinen nicht anpingen obwohl ich am selben Tisch-Switch hänge. Das Datenpaket geht gemäß VLAN immer über den Switch im Serverraum.


Nun habe ich bereits ein paar Versuche unternommen und bin mir noch nicht super sicher ob das bestPractice ist. Eno1 rühre ich erstmal nicht an. Vorerst ist mein Ziel eine astreine Interkommunikation innerhalb der VMs, der VMs mit den realen Workstations und mit den Robotern zu haben.

Wenn dies funktioniert würde ich versuchen gewisse VM ins Campusnetz zu holen. Unser Admin hat mir vor seinem Urlaub noch was mit NAT an ENO1 gesagt.

Bash:
auto lo
13 iface lo inet loopback
14
15 auto eno2
16 iface eno2 inet static
17
18 auto eno1
19 iface eno1 inet dhcp
20   pre-up /etc/network/preup.sh
21   post-down /etc/network/postdown.sh
22
23 auto vmbr200
24 iface vmbr200 inet static
25     address 172.31.1.25/24
26   bridge-ports none
27   bridge-stp off
28   bridge-fd 0
29 #Robolan
30
31 auto vmbr100
32 iface vmbr100 inet static
33   bridge-ports none
34   bridge-stp off
35   bridge-fd 0
36 #externADS
37
38 auto vmbr300
39 iface vmbr300 inet static
40   bridge_ports none
41   bridge_stp off
42   bridge_fd 0
43 #vmintern host only
44
45 auto vmbr400
46 iface vmbr400 inet static
47     address 172.31.4.25/24
48   bridge-ports none
49   bridge-stp off
50   bridge-fd 0
51 #robolan 2
52
53 auto vmbr500
54 iface vmbr500 inet static
55   address 172.31.1.24/24
56   address 192.168.1.25/24
57   bridge_ports eno2
58   bridge_stp  off
59   bridge_fd 0
60 # virtual bridge to let vms communicate with robonet


vmbr100 - externe Brücke für die Verbindung in die Welt
vmbr200 - Brücke testweise - wird durch vmbr500 ersetzt, oder? Nur mit 500 kann ich ausserhalb des Hostes kommunizieren
vmbr300 - interne VM Komm
vmbr400 - robonet2 - selbes Problem wie vmbr200
vmbr500 - hier habe ich mal die eno2 miteingehängt und damit scheint die Kommunikation zwischen den VMs und Robonet zu funktionieren.

Nun ist die Frage ob ich auf vmbr500 mehrere Adressen für diese Brücke eingebe oder ich mit eno2:1 eno2:2 arbeite und dann mit Brücken?
Empfiehlt sich generell der Einsatz von OPNsense in meinem Fall? Insbesondere wegen dem DHCP und dem Routing (falls ich das brauche).
Welche Probleme seht ihr auf uns zukommen?
Sollte ich über software defined network (als eigenes Subnetz im Campus) nachdenken?
 

Attachments

  • interfaces.txt
    interfaces.txt
    1.3 KB · Views: 3
  • 20210528_robolab-netzwerk(2)(4).jpg
    20210528_robolab-netzwerk(2)(4).jpg
    498.1 KB · Views: 9
Also ich hätte da mehrere Fragen:

1. was soll das ServiceNet sein? Container? Die sollen im gleichen Netz wie die VMs sein?
2. was sollen die Terminals sein. PCs? Wo stehen die? Direkt via WLAN verbunden?
3. soll das PVE-Admininterface im gleichen Netz sein wie deine VMs?
4. mir fehlt der Switch auf der Grafik.
5. Was soll denn ads.ads...../24 sein?

Mir scheint mal wieder, da wird jemand unerfahrenes eine schwierige Aufgabe gestellt und der muss zu sehen, wie er klar kommt.
 
Last edited:
Hallo Floh8,

danke für deine Fragen. Da war ich wohl etwas schludrig und betriebsblind.
Das habe ich vor dem Umzug ins neue Gebäude gezeichnet. Mittlerweile ist es obsolet. Nun sind die verschiedenen Versionen besser beschriftet

Dennoch möchte ich deine Fragen beantworten:

1. Ja, das Servicenet ist mein VMNetz. Da drinnen sind lxc container und vm welche sich untereinander austauschen können müssen.
2 im allgemeinen: Stell dir ein PC-Poolraum mit vielen PCs/Workstations und im Nebenraum sind Roboter. Die Workstations sind an das Campus-Netz angebunden.
3. Das PVE-Admininterface soll von den Workstations als auch meinem Admin-Terminal erreichbar sein. Aktuell besteht die Verbindung über das Campus-Netz an eno1 des Hosts
4. Diesen habe ich nun eingezeichnet
5. das Campus-Netz (active directory service) - ich habe nun den Gebäudeswitch eingezeichnet und das Serversymbol mit ADS und Loginserver beschriftet.


Mir scheint mal wieder, da wird jemand unerfahrenes eine schwierige Aufgabe gestellt und der muss zu sehen, wie er klar kommt.
Willkommen in der Forschung :) - Ohne Herausforderung wird kein Wissen geschaffen. Aber prinzipiell wäre ein sysadmin an meiner Stelle da wohl besser.
 

Attachments

  • 20210528_robolab-netzwerk(2)(6).jpg
    20210528_robolab-netzwerk(2)(6).jpg
    882.4 KB · Views: 9
Last edited:
man merkt, dass du mit netzwerk nicht viel am hut hattest, denn du vermischst zugriffszeiger mit physikalischen verbindungen und logischer struktur - alles in einer skizze. schön für den, der das nachvollziehen soll. zum glück ist die aufgabe nicht so schwierig für einen erfahrenen netzwerker. also ich sprech mal dein prinzipielles probleme an, was du zuerst klären solltest.

deine Terminals sind im campus-LAN via WLAN oder Kabel angeschlossen und sollen darin bleiben? Ich frage das, weil du ja aus dem CampusLAN auf dein VM- LAN zugreifen möchtest und natürlich kannst du deren Netzkonfig nicht ändern. Also, woher soll das Gateway aus dem CampusLAN wissen, wer dein VM-LAN kennt? Ich weiß es und du weißt es, aber das Gateway, das von den Terminals dann mit dieser Frage bombardiert wird, weiß es nicht.
also wie wäre dies zu lösen? entweder du bringst dem Gateway bei, dass dein PVE-Host (VM wegen mir) dies kennt oder du patchst die Terminals in das VM-Netz, falls du das darfst.
Die 3. Variante wäre ein Dest-NAT, aber das willst du dir nicht antun.
 
Bisher hab ich das immer durch eine zweite Netzwerkkarte gelöst. Diese war dann am RoboLan-Switch angeschlossen. Das war aber vor dem Umzug ins neue Gebäude. Hier ist die IT noch vollkommen überfordert oder im Urlaub.. Nun hat jede Netzwerkdose den Anschluss ans Gebäude-Switch und somit ist diese Lösung eh hinfällig.. außer ich leg nochmal Kabel und tangiere den Switch nicht.. Das ist aber nicht das Ziel.

Abgesehen von der CambusLan <> RoboLan Problematik, welches eh nur unsere IT lösen kann, wie sieht es deiner Meinung nach mit den anderen Schnittstellen aus? Das VMLan soll unter sich und auch zum RoboLan kommunizieren können. Wie würde das ein Profi bewerkstelligen?
 
naja, ich weiß nicht, warum du 2 netze machen willst. warum sollen die roboter nicht im selbe netz sein wie die vms und container?
 
ach so, was ich noch erwähnen wollte. das ist eigentlich keine frage für dieses forum, denn es ist nichts proxmox spezifiches.
 
naja, ich weiß nicht, warum du 2 netze machen willst. warum sollen die roboter nicht im selbe netz sein wie die vms und container?
Die Roboter und SPSen sollen nicht ins Internet. Diese sollen über die Workstation, VM und meinetwegen vom Host erreichbar sein. Daher zwei Netze, um schoneinmal die physikalische Trennung zu haben.


ach so, was ich noch erwähnen wollte. das ist eigentlich keine frage für dieses forum, denn es ist nichts proxmox spezifiches.

Sehe ich anders. Proxmox bietet eine halbgare Funktion in der GUI, welche halbgar in der Doku beschrieben wird. Was nun best Practice ist und welche weitere Methoden interessant sein könnten, stehen dort nicht. Daher halte ich meine Frage durchaus berechtigt, da sich auch non-enterprise User hier bewegen und gerne ein Beispiel aus dem großen Umfeld hätten.
Getreu dem Motto: Think Big, no matter how small you are.
Natürlich bekomme ich meine Konfiguration zum Laufen. Ich maße mir an zu sagen, dass ich intelligent genug bin, das zu verstehen. Da ich aber kein SysAdmin werden möchte, hätte ich gerne einfach ein paar Tipps, um die Sache korrekt anzugehen. Sinnhaftig und Verständlich - damit in 2 Jahren der nächste Mitarbeiter, fluchfrei, daran weiterarbeiten kann.

Nun ist die Frage ob ich auf vmbr500 mehrere Adressen für diese Brücke eingebe oder ich mit eno2:1 eno2:2 arbeite und dann mit Brücken?
Empfiehlt sich generell der Einsatz von OPNsense in meinem Fall? Insbesondere wegen dem DHCP und dem Routing (falls ich das brauche).
Welche Probleme seht ihr auf uns zukommen?
Sollte ich über software defined network (als eigenes Subnetz im Campus) nachdenken?
Ich möcht keine fertige Lösung, sondern nur eine Bestätigung oder Weisung eines Profi an dieser Stelle.
zugriffszeiger mit physikalischen verbindungen und logischer struktur - alles in einer skizze. schön für den, der das nachvollziehen soll.
Kannst mir hierzu die Norm nennen? Dann les ich da mal rein und mach es uns ggf. richtig
 
Last edited:
also, ich finde trotzdem nicht, dass das eine proxmox frage ist. proxmox hat viele halbgar funktionen in der gui sowie microsoft und andere anbieter auch, weil du einfach nicht alle funktionalitäten, die die tools, die im hintergrund benutzt werden, abbilden kannst. da wirst du einfach nicht fertig mit der programmierarbeit. proxmox konzentriert sich auf die sinnvollen und öfter genutzten und das machen sie nicht schlecht. klar fehlt dem ein oder anderen immer mal was, aber dafür gibt es ja auch kritik im forum.
du meinst hier sicherlich die netzwerkfunktionalität? Dein Motto lebe ich genauso.

kurzum zu deinem problem:
wenn du von den terminals auf die vms zugreifen möchtest, dann musst du ohne NAT am eno1 arbeiten. Ohne NAT am eno1 kommst du aber nicht ins Internet, da im CampusLAN nur für diese Adressen der Zugriff frei geschaltet ist. Dein Admin, müßte also dein VM-Netz im CampusLAN (ich nehm mal an ihr seid groß und nutzt ein Routingprotokoll) bekannt machen und an der Firewall freigeben.
Das führt dazu, dass du dir über die Sicherheit noch Gedanken machen müßtest, dass nicht jeder aus dem Campus auf deine VMs zugreifen könnte. Deshalb ist eine opnsense VM dazwischen der richtige Weg, aber nicht hilfreich, wenn die Terminals dhcp einsetzen, es sei denn, sie sind in der selben Broadcast-Domain, was hier der Fall wäre. Dann könntest du die MAC-Adressen für Firewallregeln nutzen. Opnsense unterstützt auch DNS-Hosts, so weit ich weiß. Die Frage wäre hier, werden die Terminals im DNS registriert. es gibt also wie du siehst viele Abhängigkeiten und Möglichkeiten.
.
Wie löst man also hier dieses beschissene Dilemma?

Meine idee unter deinen Vorgaben wäre:

- du benutzt deinen unmanaged Switch für das Robonetz und nutzt eno2 an vbridge2 dafür.
- vmnetz für container + vms an vbridge3
- du setzt 2 statische IPs im CampusLAN an eno1 (vbridge0) ein, die du dir vom Admin zuteilen läßt (eine für proxmox, die andere für die opnsense VM))
- für das VM-netz+RoboNetz läßt eine Route beim nächsten Gateway eintragen auf die statische IP der opnsense
- du nutzt ne opnsense vm mit 4 Netzwerkschnittstellen; int1mit statischen IP über vbridge0, int4 via dhcp an vbridge0 und die vbridges3+2 über int3+2 (vielleicht musst du auch 2 opnsense VMs nehmen, um dies abzubilden)
- ausgehender Verkehr ins Internet leitest du über NAT und int4 d. opnsense
- Verkehr für das CampusLAN leitest du über int1 d. opnsense
- verkehr zw. Robo und Vm-Netz dann via opnsense VM

vorteile bei dieser Lösung:

- dein admin brauch für den Internetzugriff nix an der Firewall ändern
- robo und vm-Netz getrennt
- firewallregeln für CampusLAN+RoboNetz auch per MAC umsetzbar (via DNS,wenn möglich)
- keine Änderung für terminals notwendig
- ip konfiguration auf PVE-Host nur für Portalzugriff

Doch was wohl am meisten unlogisch ist bei euch. Ihr plant nen Cluster und wartet mit gerade mal 2 Netzwerkschnttstellen auf? wie wollt ihr den Cluster dann bauen. Da fangt ihr an wieder alles neu zu konfigurieren. Wäre nicht meins.
 
Last edited:
proxmox hat viele halbgar funktionen in der gui
Das sehe ich natürlich anderst und solche Behauptungen bei neuen Anwendern aufzustellen trägt wenig dazu bei, irgendwas zu verbessern.

Verbesserungsvorschläge bitte an den richtigen Stellen konkret einbringen!
 
Das sehe ich natürlich anderst und solche Behauptungen bei neuen Anwendern aufzustellen trägt wenig dazu bei, irgendwas zu verbessern.

Verbesserungsvorschläge bitte an den richtigen Stellen konkret einbringen!
War von ihm nicht so gemeint - ist eher ein rhetorischer Stil um mein Argument zu verharmlosen. Proxmox ist in vielen Dingen echt gut. Aber das Networkmanagement, für Laien, wenn auch nicht die Zielgruppe, etwas trocken
 
mir gings hier nicht um etwas zu verharmlosen, sondern meinen standpunkt wiederzugeben. wenn proxmox dinge schlecht macht, dann sollte man das auch sagen dürfen. verstehe dich tom an der stelle aber auch nicht wirklich. mir scheint, du hast da ein sehr dünnes fell, wenn es um die qualität etc. von proxmox geht. lies dir bitte mein statement doch nochmal durch. ich nehme hier proxmox wahrlich in schutz. ich mag proxmox, aber ich kritisiere, damit es besser wird und wenn ich mal falsch liege wie gestern, dann darfst du mich da gern korrigieren. dafür bist du doch da. ich kenne das produkt nicht so genau wie du, deshalb gebe ich hier meine erfahrungen wieder und bewerte meine erfahrungen auch. ich denke, das ist völlig legitim. und schön, dass du mich followst. wenigstens ein leser habe ich immer. ;)
ach so tom. noch eine kritik an dich. du sollst dich ja schließlich auch verbessern. du kritisierst immer viel wie hier auch, dass das hier falsch wäre zu posten oder das es falschaussagen sind etc., aber du gibst keine hinweise, wo es denn deiner meinung nach besser wäre oder wie es denn richtig ist. vielleicht denkst du mal drüber nach, ob mehr manchmal hilfreicher ist. ich will ja auch dazu lernen genauso wie alle anderen, die meine posts lesen.
 
Last edited:
Moin @floh8,

danke für deinen Input soweit. Ich habe den Thread an die Admins weitergeleitet. Die sollen mir die Richtung weisen. Darüber hinaus muss ich über deine Posts nochmal nachdenken.
 
alles klar, ich hab den obigen post von mir nochmal mehr mit dem robo-netz verbunden, weil für dich der zugriff ja auch sehr wichtig war. das kam nicht ganz so klar rüber zu erst. viel erfolg bei der umsetzung.