Optimierung VLAN Network Konfig

S

SteffenDE

Member
Feb 10, 2021
30
4
13
53
Hi,

ich probiere einiges im Homelab aus und habe Mini-PC's mit zwei NIC's.

Diese habe ich zu einem Bond gebunden und diesen wieder rum an eine VLAN aware Linux Bridge. Damit kommt der Trunk des HW-Switches inkl. der PVID 1 auch im Proxmox an. Um nicht alle VM's zu taggen habe ich auch noch VLANs an das Bond gebunden und dann separate Bridges für ein VLAN (z.B. DMZ gebaut).

Das ganze sieht dann so aus:

Code: 
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual
    mtu 1500

auto enp1s0
iface enp1s0 inet manual
    mtu 1500

auto bond0
iface bond0 inet manual
    bond-slaves eno1 enp1s0
    bond-miimon 100
    bond-mode balance-tlb
    mtu 1500
    bond-updelay 500
    bond-downdelay 250

auto bond0.10
iface bond0.10 inet static
    address 10.0.0.41/24
    mtu 1500
#Storage

auto bond0.1
iface bond0.1 inet manual
#Intranet

auto bond0.25
iface bond0.25 inet manual
#MM

auto bond0.99
iface bond0.99 inet manual
#DMZ

auto vmbr0
iface vmbr0 inet static
    address 192.168.168.41/24
    gateway 192.168.168.250
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2 25 40 50 60
    brigde-pvid 1
#Trunk

auto vmbr25
iface vmbr25 inet manual
    bridge-ports bond0.25
    bridge-stp off
    bridge-fd 0
#MM

auto vmbr99
iface vmbr99 inet manual
    bridge-ports bond0.99
    bridge-stp off
    bridge-fd 0
#DMZ

source /etc/network/interfaces.d/*

Folgende Dinge sind mir nicht ganz klar:

- bond0.10 ist für NFS Zugriff und funktioniert auch so, ist das so der richtige Weg möglichst nah an der NIC das VLAn auszukoppeln und die Adresse direkt dort einzutragen um an den NFS Storage zu kommen?

- Die Proxmox Managment IP habe ich jetzt am Trunk (Bridge vmbr0), was nicht so schön ist, aber sobald ich versuche diese an bond0.1 zu hängen kann ich nicht mehr zugreifen. Wie geht man hier vor wenn man nicht die einzelnen VM's taggen will und auch eine Trunk-Switch benötigt um diese an eine VM zu hängen ohne dass dort das Management mit drauf läuft?

- Der Zugriff auf VLAN z.B. 25 MM funktioniert über die vmbr25 aus der VM einwandfrei. Ist das so sinnvoll gemacht?

- Erstelle ich eine Bridge an bond0.1 und hänge dort statt an vmbr0 eine VM, kommt die auch nicht mehr in das VLAN mit der PVID 1. Warum , liegt es an der PVID, sprich ungetagged ist in VLAN 1 und dann werden die Pakete ja getaggt?

Danke.
 
Last edited:
Aus den Dokus bin ich der Meinung dass es auch so funktionieren sollte, aber leider kann ich den Host dann nicht mehr erreichne:

Code: 
auto vmbr0
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2 25 40 50 60
#Trunk


auto vmbr0.1
iface vmbr0.1 inet static
    address 192.168.168.41/24
    gateway 192.168.168.250
#Management

Danke.
 
So, nun noch einiges probiert und geschafft zumindest Proxmox Management an ein eignes VLAN zu hängen. Jetzt habe ich VLANS die über den Bond definiert wurde und eines was über vmbr0 defiiniert wurde.

Was sind die Vorteile und wie sollte man es denn am besten machen?

Außerdem scheint vmbr0 als Trunk in einer VM nicht zu funktioniern. Dazu musste man in VMware einen Switch mit VLAN 4095 erstellen. Wie funktioniert das in Proxmox, finde leider nichts verbindliches dazu, oder bleibet nur jedes VLAn auch zu definieren und dann als separate NICs an die VM zu geben?

Code: 
auto eno1
iface eno1 inet manual
    mtu 1500

auto enp1s0
iface enp1s0 inet manual
    mtu 1500

auto bond0
iface bond0 inet manual
    bond-slaves eno1 enp1s0
    bond-miimon 100
    bond-mode balance-tlb
    mtu 1500
    bond-updelay 500
    bond-downdelay 250

auto vlan10
iface vlan10 inet static
    address 10.0.0.41/24
    mtu 1500
    vlan-raw-device bond0
#Storage NFS

auto vlan25
iface vlan25 inet manual
    mtu 1500
    vlan-raw-device bond0
#MM

auto vmbr0
iface vmbr0 inet manual
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2 25 40 50 60
#Trunk

auto vmbr25
iface vmbr25 inet manual
    bridge-ports vlan25
    bridge-stp off
    bridge-fd 0
#MM

auto Management
iface Management inet static
    address 192.168.168.41/24
    gateway 192.168.168.250
    vlan-id 1
    vlan-raw-device vmbr0
#Intranet Management
 
SteffenDE said:
Was sind die Vorteile und wie sollte man es denn am besten machen?
Click to expand...
Wie bei so vielem...es kommt darauf an. :)

Vor allem aber auch wie dein Workflow so ist und Mensch ist nunmal Gewohnheitstier. Bauchgefühlig finde ich das mit vswitch/OVS ( apt install net-tools openvswitch-switch ) besser, es liegt mir einfach mehr. Zum Ziel führt beides.

Ich kann dir nur sagen, wie ich das für mich am besten gelöst habe und vielleicht kannst du dann was davon adaptieren oder weiter für dich optimieren.

Vlans taggen vermeide ich tunlichst innerhalb der VMs. Warum? Weil ich mir damit nicht für jedes unterschiedliche Betriebssystem merken muss, wie da jetzt das tag gesetzt und geklickt werden muss. Ich kann nicht den Überblick verlieren, wenn es mal wo klemmt mit Verbindungen, denn gedanklich ist proxmox dann nur das Bindeglied zwischen Switch/Außenwelt und nach innen zu den VMs.
Also vlans nur im physischen Switch gesetzt und ausschließlich auf proxmox selbst und nur für die VMs.

Die Erstkonfiguration von den Geräten ist etwas tricky bis hakelig, weil man sich wie du selbst gemerkt hast, dann gerne mal selbst aussperrt, wenn man untagged nicht mehr drauf kommt.

Ein frisch ausgepackter managed Switch verhält sich wie man das vom dummen Switch kennt. Man steckt einfach irgendwo zwei Geräte rein und sie können sich sehen. Diese "Grundfunktion" ist das ganze Hexenwerk hinter vlan1/pvid1 und der Sonderfall. Die meisten Hersteller haben sich der Einfachheit halber auf vlan1 geeinigt (im Zweifel Handbuch!), weil es einfach naheliegend ist, man hätte technisch natürlich auch jedes andere nehmen können.
Es muss auch in einem vlan sein, damit man es "greifen" kann und somit aussperren wo das später nicht gewünscht ist.
Damit du initial überhaupt mit einem Gerät untagged die IP des Switches zur Konfiguration erreichen kannst, ist die managementIP ebenfalls in vlan1 und mehr ist es nicht. ;)

Genereller Tip:
Bei der Inbetriebnahme von Switchen nehme ich immer gern mein Laptop ohne weiteres Gerät angeschlossen. Damit bin ich mobil und flexibel, falls der schon wo verbaut ist, mir pfuscht kein DHCP dazwischen oder ein Router mit Adressenkonflikt, weil der bereits die gleiche IP wie der Switch hat und ich lege nichts ungewollt lahm, weil eben nur die beiden Geräte verbunden sind.
Suche dir am Switch einen besonderen physischen port raus. Das kann der erste port sein, der letzte oder aber dein Geburtstag. Hauptsache du kannst es dir merken und den konfigurierst du zunächst als deinen einzigen Wartungsport.
Nun suchst du dir noch ein besonderes vlan für dich raus, in das du die managementIP dieses Switches verlegst und auch das gut merken. Aus Sicherheitsgründen sollte man defaults die allgemein bekannt sind auf jeden Fall ändern.
Das heißt also als nachvollziehbares Beispiel suche ich mir den physischen port9 aus. Die Login Credentials ändere ich sofort, falls es geht auch beide (admin9/passwort9). Die managementIP ändere ich auf 192.168.9.1 und die lege ich in vlan9.
Der Trick ist dabei die richtige Reihenfolge, damit man sich nicht aussperrt. Also pvid9 auf port9 damit du dann mit deinem danach auf 192.168.9.2 eingestellten Laptop untagged reinkommst. Nicht enttäuscht sein, wenns nicht direkt klappt, ggf. hat man einen Klick übersehen oder erkennt seinen Logikfehler und lernt was dabei.

Proxmox selbst kannst du dann auch komplett tagged betreiben. Das wäre dann z.B. am Switch 4 physische ports (1,2,3,4) aussuchen, die als bond definieren, bestenfalls LACP, wenn der das kann. Auf dem LACP definierst du dein proxmox-admin-vlan (wir nehmen mal die 6) als tagged, aber stöpseln da noch nichts rein.
Auf proxmox gehst du dann auch am einfachsten zunächst mit nem Laptop direkt rein. Alle NICports auf einmal (1,2,3,4), LACP-bond, vlan6. Hast du alles richtig gemacht und beachtet, dann klickst du auf "apply" und danach ist dann deine Verbindung weg. Nun proxmox in den switch rein wo der bond definiert ist und dann kannst du wieder vom Wartungsport aus davon das vlan6 als pvid6 auf switchport6 schalten uswusf.

SteffenDE said:
oder bleibet nur jedes VLAn auch zu definieren und dann als separate NICs an die VM zu geben?
Click to expand...
Mit vswitch definitiv nicht. Da kannst du prinzipiell jedes vlan auf eine bridge legen und dann vom switch aus auch wieder "aufsplitten", egal ob du mit bond oder Einzelkabel physisch dranhängst.
 
Servus und vielen Dank für Deine Erläuterungen.

Ich habe bereits ein funktionierendes Netz mit diversen VLAN's und bisher einen VMware Cluster in meinem Lab. Nun bin beschäftige ich mich Proxmox und will vor der Migration einiges ausprobieren. Unter VMware hatte ich diverse Netzwerke in den VLANs und eines eben mit einem Trunk, der dann als einziges in einer UTM Appliance in der VM das Tagging macht. Alle anderen VMs waren durch die Zuweisung an die VM Netzwerke bereits im richtigen Netz.

Diese VMPort Gruppen, die dann unter VMware an dem vSwitch hängen wollte ich nachbauen und dies passiert dann scheinbar unter Proxmox in der NIC Definition der VM und es wird immer die zentrale entweder VLAN aware Linux Bridge oder die OVS Bridge angegeben (ist ja analog der VMware vSwitche).

Ich habe es nun wie auch von Dir erwähnt mit Open vSwitch gemacht, erscheint mir vom Aufbau logischer und ich konnte auch den Trunk so abbilden wie ich wollte in dem einen Fall UTM in der VM taggen. Wird noch auf LACP umgestellt, hängt noch nicht am richtigen Switch, aber funktioniert wie es soll. Ob es so 'gut' konfiguriert (Optionen) ist, kann ich nicht herausfinden - in Sachen Best Practice findet man leider nicht so viel.

Code: 
auto eno1
iface eno1 inet manual
    mtu 9000

auto enp1s0
iface enp1s0 inet manual
    mtu 9000

auto vlan1
iface vlan1 inet static
    address 192.168.168.41/24
    gateway 192.168.168.250
    ovs_type OVSIntPort
    ovs_bridge vmbr0
    ovs_mtu 1500
    ovs_options vlan_mode=access
    ovs_extra set interface ${IFACE} external-ids:iface-id=$(hostname -s)-${IFACE}-vif
#VLAN1 Intranet Management

auto vlan10
iface vlan10 inet static
    address 10.0.0.41/24
    ovs_type OVSIntPort
    ovs_bridge vmbr0
    ovs_mtu 9000
    ovs_options tag=10
    ovs_extra set interface ${IFACE} external-ids:iface-id=$(hostname -s)-${IFACE}-vif
#VLAN10 Storage NFS (jumbo frames)

auto bond0
iface bond0 inet manual
    ovs_bonds eno1 enp1s0
    ovs_type OVSBond
    ovs_bridge vmbr0
    ovs_mtu 9000
    ovs_options bond_updelay=1000 other_config:bond-miimon-interval=100 bond_mode=balance-slb
#Bond eno1 and enp1s0

auto vmbr0
iface vmbr0 inet manual
    ovs_type OVSBridge
    ovs_ports bond0 vlan1 vlan10
    ovs_mtu 9000
#Trunk
 
SteffenDE said:
Ob es so 'gut' konfiguriert (Optionen) ist, kann ich nicht herausfinden - in Sachen Best Practice findet man leider nicht so viel.
Click to expand...
Doch doch, das ist prima. Die halbe Miete ist, dass das was erreichbar sein soll korrekt pingbar ist und das was nicht erreichbar sein soll, nicht.

Manchmal hilfts auch, dass ich mir das einfach mal schnell auf Papier zeichne, was ich haben will und die Liste dann abklappere:
Alle defaults bei Geräten ändern
Switch gedanklich links <-----> Proxmox gedanklich rechts
vlan34 <-----> nicport?-vswitch (vmbr0)-int port vlan34
vlan56 <-----> nicport?-vswitch (vmbr1)-int port vlan56
...
vlan78 port3,4,5,6(LACP) <-----> vswitch (vmbr?)...usw

Ob du danach alles einmal durchpingst oder nach jedem Hinzufügen von etwas...hängt von deinem workflow ab, aber du kannst es dann abhaken.
Die Logik mit den korrekten vlans auf beiden Seiten ist der schwere Teil. (Entweder kommt das tag korrekt an oder nicht, zumindest da gibts wenig Optimierungsspielraum ;) )
Wenn dir OVS ebenfalls besser liegt, ist das auch eine Optimierung.
balance-slb funktioniert, wenn du das dann auf den anderen Switch umsteckst, ist LACP die Optimierung.
Wenn MTU9000 mit den Geräten klappt, warum nicht.

Die best practice kommt dann von alleine im Alltag, wenn du hier regelmäßig mitliest und fremde configs vergleichst.
 
  • Like
Reactions: SteffenDE
You must log in or register to reply here.
Top Bottom