Mehrere MACVLAN Problem mit Virtual Manager

azazel

Benutzer
Mitglied seit
16. Sep 2010
Beiträge
21
Punkte für Reaktionen
1
Punkte
3
Hallo liebes Forum,

Ausgangssituation:
Virtual Manager installiert und es läuft VDSM drauf. Angeschlossen an ovs_eth2
Auf der Docker läuft bisher nur ein Container auf einem MACVLAN, welches direkt an ovs_eth2 gekoppelt ist.
# docker network create -d macvlan --subnet=172.16.11.0/24 --gateway=172.16.11.1 --ip-range=172.16.11.112/31 -o parent=ovs_eth2 macvlan3

Alles läuft super. Ich habe insgesamt 5 Subnetze, welche alle durch eine UTM gesteuert werden incl. VLAN-Tag etc...
ovs_eth0 ist nur intern. ovs_eth1 dient als Backup für ovs_eth0. ovs_eth2 ist meine DMZ und ovs_eth3 dient als backup für ovs_eth2. Ausweichen auf einen anderen Anschluss als ovs_eth2 möchte ich also vermeiden um mein Problem zu lösen.

Gewünscht:
ich brauche nun einen neuen Container, der in einem anderem MACVLAN mit anderem Subnetz arbeiten soll. Also kann ich nicht mehr direkt "parent=ovs_eth2" für den ersten und den zweiten Container nutzen, sondern muss mir was anderes "basteln" (Basteln trifft bei mir mit meinen rudimentären Linux-Kenntnissen zu. Also seht es mir nach, wenn ich das ein oder andere nicht richtig benenne).

Verstanden habe ich, dass ich also mindestens 2 MACVLAN brauche. Also habe ich folgendes gemacht.

ip link add dmacvlan3 link ovs_eth2 type macvlan mode bridge
ip link add dmacvlan4 link ovs_eth2 type macvlan mode bridge
ip link set dmacvlan3 up
ip link set dmacvlan4 up
docker network create -d macvlan --subnet=172.16.11.0/24 --gateway=172.16.11.1 --ip-range=172.16.11.112/31 -o parent=dmacvlan3 macvlan3
docker network create -d macvlan --subnet=172.16.12.0/24 --gateway=172.16.12.1 --ip-range=172.16.12.112/31 -o parent=dmacvlan4 macvlan4

Ergebnis:
VDSM in VM funktioniert gut, Docker auf macvlan3 läuft und ansprechbar. Docker auf macvlan4 läuft, aber ist nicht ansprechbar.
Mal davon ab, dass bei einem Neustart mir die MACLAN (dmacvlan3 und 4) bei einem Neustart flöten gehen und ich im Aufgabebplaner ein entsprechendes Script laufen lassen muss. Dies funktioniert aber auch nicht wirklich, da mir dann Docker meldet, mir dann die verlorene network id ...
Error,2023/01/19 14:30:40,syno-admin,Start container embyserver-4.7.11 failed: {"message":"failed to create endpoint embyserver-4.7.11 on network macvlan3: network id \"a7372a4d899ead385d3099eede1a15cb55efca21a30258c422f8512676d045e4\" not found"}.

Also was neues probiert und als Basis diese Hilfe genutzt http://www.stueben.de/mehrere-vlans-mit-einem-netzwerkadapter-auf-der-synology/ (Ja, "mit einem Netzwerkadapter" ist deswegen richtig, weil ich im Grunde auch nur den ovs_eth2 zur Verfügung habe)

Datei ifcfg-ovs_eth2.3 erstellt und in /etc/sysconfig/network-scripts eingefügt (das gleiche mit VLAN 4 und Subnetz 40 anstatt 30)

DEVICE=ovs_eth2.3
VLAN_ROW_DEVICE=ovs_eth2
VLAN_ID=3
BOOTPROTO=static
ONBOOT=yes
IPV6INIT=off
IPADDR=192.168.30.1
NETMASK=255.255.255.252

Ergebnis:
Ich habe zwei neue eth vorliegen, die aber die gleiche MAC Adresse wie der ovs_eth2 hat. Weiter brauche ich gar nicht zu probieren, weil mir dann nämlich die VDSM wegen Netzwerkfehler abschmiert und nicht mehr ansprechbar ist.

Weiteres Probieren ohne VLAN_ROW_DEVICE=ovs_eth2 mit und ohne VLAN_ID=3 aber mit PRIMARY=ovs_eth2 führten auch zu keinem Ergebnis.
habe auch mal jedwede andere Kombination anstelle des ovs_eth2 mit dem eth2 gemacht (Ja, ich weiß, ist keine so gute Idee, aber es hätte ja funktionieren können). Wenn die MAC Adresse nicht die gleiche war wie vom ursprünglichem eth, dann lief die VDSM und ich habe dann weiter nach Webseite mit

ip link add dmacvlan3 link ovs_eth2.3 type macvlan mode bridge
ip link set dmacvlan3 up
docker network create -d macvlan --subnet=172.16.11.0/24 --gateway=172.16.11.1 --ip-range=172.16.11.112/31 -o parent=dmacvlan3 macvlan3

gemacht (gleiche noch mit dem 4er.

1. hat das auch nicht funktioniert und 2. geht mir auch bei einem Neustart die dmacvlan3 flöten bzw. muss im Planer hinterlegt werden mit dem gleichen Problem wie oben beschrieben.
Direktes erstellen des docker Adapters mit
docker network create -d macvlan --subnet=172.16.11.0/24 --gateway=172.16.11.1 --ip-range=172.16.11.112/31 -o parent=ovs_eth2.3 macvlan3
bleibt zwar bei Neustart erhalten, aber das Ergebnis ist auch, dass es nicht funktioniert wie ich es will.

Wie könnt ihr mir weiterhelfen? Erschießen ist eine Lösung, aber wenig praktikabel für meine Frau. Was muss ich in die ifcfg Datei genau reinschreiben und wie bleibt das, wenn es denn dann funktioniert nach einem neustart auch erhalten?

Danke schon einmal
 

plang.pl

Benutzer
Contributor
Sehr erfahren
Mitglied seit
28. Okt 2020
Beiträge
15.028
Punkte für Reaktionen
5.405
Punkte
564
Nach Abschluss deines Scripts den Docker-Container neu zu starten, haut nicht hin?
Inwiefern hängt das mit dem VMM zusammen? Auch ohne den hättest du die gleiche Anzahl an Interfaces.
Und warum brauchst du überhaupt mehrere MACVLANs?
 

azazel

Benutzer
Mitglied seit
16. Sep 2010
Beiträge
21
Punkte für Reaktionen
1
Punkte
3
Nach Abschluss deines Scripts den Docker-Container neu zu starten, haut nicht hin?
Vor jedem Script Container runter. nach jedem Script wieder hochfahren. Einzig was hinhaut ist, wenn ich die Ursprungsconfiguration habe, dann aber nur ein MACVLAN mit ein oder mehreren Container im selben Netz.

Inwiefern hängt das mit dem VMM zusammen? Auch ohne den hättest du die gleiche Anzahl an Interfaces.
Der eth2 ist ja durch Syno zum virtuellen ovs_eth2 umgestellt. kein Thema. Mache ich jetzt aber zwei neue virtuelle Interfaces mit VLAN und nutze VLAN_ROW_DEVICE=ovs_eth2, so haben die 2.3 und 2.4 die gleiche MAC Adresse wie der ursprüngliche ovs_eth2. In dem Moment schmiert mir die VDSM ab, weil die Portweiterleitung laut Syno nicht mehr funktioniert. Also muss ich irgendwie zwei virtuelle Interfaces haben, die zwar am ovs_eth2 liegen, aber eigene MAC Adressen haben. So glaube ich jedenfalls, dass es funktionieren könnte.

Und warum brauchst du überhaupt mehrere MACVLANs?
Im Grunde brauche ich ja nur in der Docker die zwei MACVLAN. Aber wenn ich

docker network create -d macvlan --subnet=172.16.11.0/24 --gateway=172.16.11.1 --ip-range=172.16.11.112/31 -o parent=ovs_eth2 macvlan3
und
docker network create -d macvlan --subnet=172.16.12.0/24 --gateway=172.16.12.1 --ip-range=172.16.12.112/31 -o parent=ovs_eth2 macvlan4
gibt er mir natürlich die Meldung, dass ovs_eth2 schon in Benutzung ist.
"network dm-0cae603bc75f is already using parent interface ovs_eth2"

Daher brauche ich zwei "parent interfaces", die entweder vorher schon auf Basis des ovs_eth2 als zwei MACVLAN Interfaces mit
"ip link add dmacvlan3 link ovs_eth2 type macvlan mode bridge" und "ip link add dmacvlan4 link ovs_eth2 type macvlan mode bridge" erstelle und damit die docker MACVLAN koppeln.
Oder ich baue mir zwei ifcfg direkt, die den ovs_eth2 als Basis haben, aber so getrennt sind (denke mal wegen der MAC Adresse), dass mir die VDSM nicht abschmiert. Wenn ich es hinbekomme die so zu erstellen, dass mir die VDSM nicht abschmiert, dann kann ich die 2 docker MACVLAN direkt mit den 2.3 und 2.4 koppeln. Aber da habe ich wahrscheinlich in meinen Scripten falsche Parameter drin wegen Unwissenheit was da wirklich rein kommt bzw. was es noch an Parametern gibt. Ich habe ja auch schon versucht den echten eth2 in die Scripte als Basis-Interface zu bringen, was den gleichen Effekt hatte.

Es müssen beide Container in unterschiedlichen Netzen mit dem dazugehörigen V-tag laufen. Das mit dem V-tag kann ich ja noch durch die UTM steuern, aber es müssen schon separate Netze sein, die ich ja nur durch zwei MACVLAN in der Docker hinbekomme.

Eventuell ist mein Grundgedanke ja zu kompliziert, weil nicht das Wissen vorhanden ist, was Docker angeht. Ich bin auch für andere Vorschläge gerne zu haben. Wichtig ist nur, dass ich beide Container in unterschiedlichen Netzen (172.16.11.0/24 und 172.16.12.0/24) in der Docker habe und diese nur über den ursprünglichen ovs_eth2 laufen, der im hausinternen Netz komplett getrennt ist von allem anderen (DMZ).

Von daher bin ich für jeden Vorschlag zu haben, der entweder die richtigen Parameter für mich in den Scripten enthält oder halt in der Docker zwei Interfaces habe, die zwei Netze haben (s.o.). Was ich auch nicht verstehe ist, dass es in vielen Sachen (ESX zum Beispiel) ja ohne Probleme geht virtuelle Interfaces mit unterschiedlichen MAC-Adressen zu haben, die alle auf ein und demselben Ursprungs-Interface basieren. Also was muss ich einfach machen damit das bei mir auch geht?

Danke
 

EDvonSchleck

Gesperrt
Mitglied seit
06. Mrz 2018
Beiträge
4.703
Punkte für Reaktionen
1.120
Punkte
214
Eventuell ist mein Grundgedanke ja zu kompliziert, weil nicht das Wissen vorhanden ist, was Docker angeht.
Das denke ich auch ao.
Ich bin auch für andere Vorschläge gerne zu haben. Wichtig ist nur, dass ich beide Container in unterschiedlichen Netzen (172.16.11.0/24 und 172.16.12.0/24) in der Docker habe und diese nur über den ursprünglichen ovs_eth2 laufen, der im hausinternen Netz komplett getrennt ist von allem anderen (DMZ).
Warum verwendest du nicht eine 2 unterschiedliche Bridgenetzwerke, um die Container zu trennen? Leider gibt es keine Einstellung, Docker eine Netzwerkkarte zuzuweisen. Somit musst du es über die Firewall regeln bzw. ausgrenzen.

MacVLAN ist immer mit erheblichem Aufwand und einem gewissen Ärger zu realisieren.
 

azazel

Benutzer
Mitglied seit
16. Sep 2010
Beiträge
21
Punkte für Reaktionen
1
Punkte
3
Warum verwendest du nicht eine 2 unterschiedliche Bridgenetzwerke, um die Container zu trennen? Leider gibt es keine Einstellung, Docker eine Netzwerkkarte zuzuweisen. Somit musst du es über die Firewall regeln bzw. ausgrenzen.

Auch schon probiert . Aber wie du schon sagst, ich kann Docker nicht sagen welchen eth er nutzen soll beim Bridgenetzwerk. Meines Erachtens nach nimmt er den eth0 (bzw. ovs_eth0), der nicht getaggt ist und dann geht das nicht. Der eth0 soll auch nicht getaggt sein.
 

EDvonSchleck

Gesperrt
Mitglied seit
06. Mrz 2018
Beiträge
4.703
Punkte für Reaktionen
1.120
Punkte
214
Wenn du die Container mit anderen Port in der Bridge mappst, kannst du diese Ports doch in der Firewall steuern. Somit kannst du doch festlegen, über welche NIC die Kommunikation läuft. Container im Synology Bridge-Netzwerk könne sich nicht zusammen „unterhalten“, das würde nur gehen, wenn Container in einem eigens erstellten Bridge-Netzwerk sind.
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat