Danke, mir fällt aber gerade auf, dass ich wohl eine entscheidende Info unterschlagen hab: Das ganze soll mit Open vSwitch eingerichtet werden.
Die verlinkte Anleitung bezieht sich, wenn ich mich nicht irre, auf das klassissche Linux bridging. Trotzdem danke!
Das Grundkonzept ist mir klar, ich bin Netzwerker, ich hadere nur etwas mit den Feinheiten, scheinbar sind ja OVS Ports standardmässig
Trunks, aber z.B. Default VLAN tagged oder untagged, und solche Dinge.
Ich hab mittlerweile einfach mal VMs eingerichtet, und siehe da, die VLANs scheinen bereits zu funktionieren. Meine ersten Tests
hatte ich immer mit IP Adressen auf internal OVS Bridge Interfaces versucht, scheinbar hab ich da noch nen Bug drin. Ich werde
das mit den VMs jetzt mal weiter testen, mehrere in die entsprechenden VLANs und auch auf der physischen Switch Seite mal
was in die entsprechenden VLANs packen, um zu verifizieren dass es tatsächlich so geht wie erwartet. Danach mach ich mich
dann noch mal dran, das Proxmox Mgmt Interface auch auf den Channel umzuziehen, das läuft momentan noch über die dritte
NIC in der default Linux vmbr0 Bridge.
Noch mal grob, was ich bisher eingerichtet hab:
Einen OVS Bond (bond0) mit eth1 & eth2. Zuerst kam der Channel nicht hoch, daher hab ich per Command-Line
(ovs-vsctl set port bond0 lacp=active) LACP noch aktiviert. Das hat keinen Reboot überlebt, also die option lacp=active
noch per Hand in die /etc/network/interfaces hinzugefügt. Leider scheint er diese Dinge nicht im GUI wiederzuspiegeln,
denn wenn ich dort jetzt den Bond bearbeiten will, ist das Feld für OVS Options leer.
Dann eine OVS bridge vmbr1 eingerichtet, mit bond0 als Port.
Wenn ich jetzt ne VM anlege, wähle ich vmbr1 aus, setze das entsprechende VLAN tag (also 1, 10 oder 11) und hab damit die
virtuelle Maschine im entsprechenden VLAN.
'ovs-vsctl show' zeigt mir die vmbr1 bridge an, mit den entpsrechenden Ports. Wenn nichts dabei steht sind das dann
Trunks (wie z.B. bond0 und das internal vmbr1) bei den anderen steht z.B. tag: 1, damit sind das dann Access Ports
ohne trunking (z.B. tap106i0 für das virtuelle Interface der VM106).
Was mich nach wie vor irritiert... man kann OVS auch als Parameter eine Liste der VLANs auf dem Trunk mitgeben
(ist in vielen Config-Beispielen auch so gezeigt). Beim anlegen über das Proxmox GUI gibts da aber kein Feld für (ausser evt.
man gibt es als zusätzlich Option im entsprechenden Freitextfeld ein). Ein 'ovs-vsctl get port bond0 trunks' liefert
mir '[]' zurück, also ein leeres Feld. Damit scheint er einfach alles anzunehmen was kommt, d.h. wenn ich etwas spezifiziere,
schränke ich damit ein.
Nach etwas lesen scheint mir auch klar zu sein, dass die Default Einstellung eines OVS Trunk Port 'vlan_mode=tagged'
zu sein scheint, dass er also alles tagged und kein untagged (native) VLAN zulässt (Muss man einfach wissen, um den Switch
auf der anderen Seite entsprechend einzurichten).
Was ich bisher mitnehme: Die GUI Unterstützung in Proxmox für Open vSwitch deckt die Basics ab, aber für die Feinheiten
muss man doch runter auf die Commandline. Interessant wäre, ob der die manuellen Änderungen überschreibt, wenn ich später
noch mal was über's GUI verändere... das muss ich noch mal probieren.
Die verlinkte Anleitung bezieht sich, wenn ich mich nicht irre, auf das klassissche Linux bridging. Trotzdem danke!
Das Grundkonzept ist mir klar, ich bin Netzwerker, ich hadere nur etwas mit den Feinheiten, scheinbar sind ja OVS Ports standardmässig
Trunks, aber z.B. Default VLAN tagged oder untagged, und solche Dinge.
Ich hab mittlerweile einfach mal VMs eingerichtet, und siehe da, die VLANs scheinen bereits zu funktionieren. Meine ersten Tests
hatte ich immer mit IP Adressen auf internal OVS Bridge Interfaces versucht, scheinbar hab ich da noch nen Bug drin. Ich werde
das mit den VMs jetzt mal weiter testen, mehrere in die entsprechenden VLANs und auch auf der physischen Switch Seite mal
was in die entsprechenden VLANs packen, um zu verifizieren dass es tatsächlich so geht wie erwartet. Danach mach ich mich
dann noch mal dran, das Proxmox Mgmt Interface auch auf den Channel umzuziehen, das läuft momentan noch über die dritte
NIC in der default Linux vmbr0 Bridge.
Noch mal grob, was ich bisher eingerichtet hab:
Einen OVS Bond (bond0) mit eth1 & eth2. Zuerst kam der Channel nicht hoch, daher hab ich per Command-Line
(ovs-vsctl set port bond0 lacp=active) LACP noch aktiviert. Das hat keinen Reboot überlebt, also die option lacp=active
noch per Hand in die /etc/network/interfaces hinzugefügt. Leider scheint er diese Dinge nicht im GUI wiederzuspiegeln,
denn wenn ich dort jetzt den Bond bearbeiten will, ist das Feld für OVS Options leer.
Dann eine OVS bridge vmbr1 eingerichtet, mit bond0 als Port.
Wenn ich jetzt ne VM anlege, wähle ich vmbr1 aus, setze das entsprechende VLAN tag (also 1, 10 oder 11) und hab damit die
virtuelle Maschine im entsprechenden VLAN.
'ovs-vsctl show' zeigt mir die vmbr1 bridge an, mit den entpsrechenden Ports. Wenn nichts dabei steht sind das dann
Trunks (wie z.B. bond0 und das internal vmbr1) bei den anderen steht z.B. tag: 1, damit sind das dann Access Ports
ohne trunking (z.B. tap106i0 für das virtuelle Interface der VM106).
Was mich nach wie vor irritiert... man kann OVS auch als Parameter eine Liste der VLANs auf dem Trunk mitgeben
(ist in vielen Config-Beispielen auch so gezeigt). Beim anlegen über das Proxmox GUI gibts da aber kein Feld für (ausser evt.
man gibt es als zusätzlich Option im entsprechenden Freitextfeld ein). Ein 'ovs-vsctl get port bond0 trunks' liefert
mir '[]' zurück, also ein leeres Feld. Damit scheint er einfach alles anzunehmen was kommt, d.h. wenn ich etwas spezifiziere,
schränke ich damit ein.
Nach etwas lesen scheint mir auch klar zu sein, dass die Default Einstellung eines OVS Trunk Port 'vlan_mode=tagged'
zu sein scheint, dass er also alles tagged und kein untagged (native) VLAN zulässt (Muss man einfach wissen, um den Switch
auf der anderen Seite entsprechend einzurichten).
Was ich bisher mitnehme: Die GUI Unterstützung in Proxmox für Open vSwitch deckt die Basics ab, aber für die Feinheiten
muss man doch runter auf die Commandline. Interessant wäre, ob der die manuellen Änderungen überschreibt, wenn ich später
noch mal was über's GUI verändere... das muss ich noch mal probieren.
Zuletzt bearbeitet: