vlan tag - oder Stämme, Etiketten, Brücken ...

Meine Fritzbox ist nur DSL Anschluss und Telefonanlage, meine Netzwerkzentrale ist ein OpenWrt Router und dazwischen gibt es ein paar Kabel - immer zu wenige. Mein Haupt Switch hat 24 Ports, auf dem wollte ich gern auch ein paar wenige Anschlüsse von dem Netz zwischen Fritzbox und OpenWrt Router, räumlich in Nähe der Fritzbox braucht es auch noch ein paar Ports vom internen Netzwerk.

Aufgabenstellung

• 2 VLANs, ein Trunk zwischen zwei Switches einrichten und 
• kann man eigentlich auf einem Linux Host für VMs mit einer Netzwerkkarte beide Netzwerke haben - also einen Trunk direkt zuführen?

Mit yEd Live erstellt.

Begriffe und Vorbereitung im Netzwerk

Ich will jetzt nicht die gesamte Theorie zum Netzwerk erklären (besser als hier könnte ich das nicht), nur das aller wichtigste:

• Trunk Port - alle Frames sind mit ihrem VLAN gekennzeichnet. Mehrere VLANs auf einem Kabel möglich. Ein normales Endgerät kann hier nicht betrieben werden.
• Device Port - kein Frame ist mit einem VLAN gekennzeichnet

Bei meinem netgear Switch heißt der Menüpunkt "Erweiterte 802.1Q-VLAN-Konfiguration"

1. VLAN-ID hinzufügen (erzeugen), z.B. 1090 und 1056 (VLAN 1 ist reserviert)
2. VLAN-Mitgliedschaft den Ports zuweisen. U- untagged - normales Device Port, T - tagged - für einen Trunk Port, leer - kein Port für diese VLAN
3. Den Ports eine PVID zuweisen - jedes Port bekommt die bzw. eine der zugewiesenen VLAN-ID als PVID.

Jetzt hat mein zwei Switche mit je zwei getrennten Netzwerk Bereichen, die über eine Trunk Verbindung am Port 1 kommunizieren. Soweit so einfach ...

Trunk mit dem Linux Host verbinden

Dazu muss man etwas in die Konfiguration der Netzwerkschnittstelle einsteigen. Zuerst die Konfiguration im laufenden Betrieb. Ich habe zur Übung einen zusätzlichen USB Ethernet Adapter angeschlossen. Den nimmt Linux zwar in Betrieb (Treiber muss vorhanden sein) aber aktiviert die Netzwerkschnittstelle nicht. Man kann die Konfiguration des Netzwerkes und den Syntax der Befehle auch gut in einer virtuellen Maschine testen. 

Zur live Konfiguration kann man ziemlich unabhängig von der konkreten Linux Distribution den Befehl ip verwenden.

Zunächst mal einen Überblick verschaffen, entweder nur mit ip a oder gezielt:

ip link show|grep DOWN

Mit beiden Befehlen (auch in Abwandlung) kann man sich nach jedem der folgenden Schritte vom Ergebnis überzeugen. Nach der laufenden Nummer steht der Interface Name, ein USB Adapter beginnt häufig mit enx gefolgt von einer 12 stelligen Ziffer (MAC Adresse?). 

Für die weitere Arbeit notiert man den Namen des Adapters den man in Betrieb nehmen möchte in einer Variablen. 

if_name=enx010203040506

Jetzt nimmt man das Interface in Betrieb

sudo ip link set dev $if_name up

Pro VLAN erzeugt man ein virtuelles Interface (Beispiel: vlan1056 vlan1090), aktiviert das Interface und versorgt es mit einer IPv4 Adresse. Die Netzkarte selbst erhält keine IP Adresse!

vlan_id=1090
sudo ip link add link $if_name name vlan${vlan_id} type vlan id ${vlan_id}
sudo ip link set dev vlan${vlan_id} up
sudo dhclient -4 vlan${vlan_id}

Die Funktion kann man mit traceroute gut prüfen. Von einem anderen Gerät kann man die neuen Interfaces mit ping ansprechen.

Bridge

Für die Arbeit mit einer virtuellen Maschine braucht man eine Bridge. Eine Bridge ist so etwas wie ein virtueller Netzwerk Switch, sie verbindet mehrere Netzkarten (physische und virtuelle) zu einem Netzwerk.

Wichtig: Bei der Einrichtung der Bridge muss die IP Adresse vom zugehörigen (VLAN-)Interface entfernt werden. Final darf es nur eine IP Adresse in der Kette Ethernet Adapter - VLAN - Bridge geben!

# vlan_id=1090
sudo ip link add name br${vlan_id} type bridge
sudo ip link set dev br${vlan_id} up
sudo ip link set vlan${vlan_id} up
sudo ip link set vlan${vlan_id} master br${vlan_id}
sudo dhclient -r vlan${vlan_id}
sudo dhclient -4 br${vlan_id}

Die entstandene Bridge br1090 kann man jetzt als Interface für virtuelle Maschinen verwenden.

Die bisherige Konfiguration überlebt einen Neustart nicht, sie ist nur transient. Die vor eingestellte permanente Netzwerkkonfiguration ist von der Linux Distribution abhängig. (debian: interfaces)

Will man mit dem nächsten Abschnitt ohne reboot weitermachen, muss man die bisherige Konfiguration löschen.

sudo ip link delete vlan${vlan_id}
sudo ip link delete br${vlan_id}
sudo ip link set dev $if_name down

Netplan

Ubuntu verwendet netplan und networkd, netplan wird mit yaml Dateien konfiguriert. Man kann diese Datei mit einem Editor oder per cli (mit Syntaxprüfung!) erzeugen. Netplan (Design und FAQ) wendet alle Dateien in /etc/netplan in lexikalischer Reihenfolge an, gleiche Einträge werden dabei überschrieben oder ergänzt (siehe). Netplan hat eine gute Dokumentation, mit Tutorials die man auch in virtuellen Umgebungen (im Tutorial mit Linux Container LXC) ausprobieren kann!

Die wichtigsten Befehle netplan 

• set: schreibt eine netplan Konfiguration (yaml Datei) in /etc/netplan/
• get: liest alle Dateien und zeigt das resultierende Ergebnis an
• generate: erzeugt die Dateien für networkd in /run/systemd/network/
• apply: macht vorab neplan generate und aktiviert die Konfiguration mit networkd
• status: zeigt gut strukturierte Informationen an, erst nach Ubuntu update verfügbar!
• try: probiert die Konfiguration, das revert am Ende hat bei mir nie funktioniert!

Will man hin und wieder einen USB Ethernet Adapter "hot plug" verwendet, braucht man eine entsprechende yaml Datei. Für mich war der USB Adapter zunächst zum Test und später als Rückversicherung gedacht, falls mit dem Trunk etwas schiefgeht.

Dieses Beispiel bringt Adapter mit DHCP online, deren Name mit enx beginnt.

# Inhalt yaml
network:
  version: 2
  ethernets:
    usb0:
      match:
        name: enx*
      dhcp4: true

Mit zwei Zeilen könnte man die yaml Datei erzeugen, würde netplan set richtig arbeiten: 

sudo netplan set --origin-hint 10-USB-interface "ethernets.usb0={dhcp4: true}"
sudo netplan set --origin-hint 10-USB-interface "ethernets.usb0.match={name: enx*}"
sudo sed -i 's/"enx\*"/enx\*/' /etc/netplan/10-USB-interface.yaml

Hinweis: netplan macht hier einen Fehler, es setzt quotes: name: "enx*" - der match funktioniert aber nur ohne! Deshalb braucht man noch eine (unschöne) Korrekturzeile. 

Tipp: Man könnte das entstehende Interface auch einheitlich umbenennen: {dhcp4: true, set-name: usb0}

Bisher sind nur Dateien erzeugt und die Konfiguration ist noch nicht aktiv, ein  

netplan apply

aktiviert die Konfiguration sofort, wenn man unsicher ist kann man vorher mit einem netplan get die resultierende Konfiguration aus allen Dateien anschauen.

Eine yaml Konfiguration, die dem obigen vlan und der Bridge entspricht, sieht so aus.

network:
  version: 2
  ethernets:
    enx010203040506:
      dhcp4: false
  bridges:
    br1090:
      dhcp4: true
      interfaces:
      - vlan1090
  vlans:
    vlan1090:
      dhcp4: false
      id: 1090
      link: "enx010203040506"

Hinweis: Mit der Option --origin-hint behandelt der Befehl exakt diese Datei. Lässt man diese Option weg, erkennt netplan zwar die richtige Datei, räumt aber die Konfiguration auf: nicht verwendete Konfigurationsdateien werden gelöscht, ergänzende Dateien in der "letzten" konsolidiert.

if_name=enx010203040506
vlan_id=1090
YAML=40-vlan-interface
sudo rm /etc/netplan/$YAML.yaml
sudo netplan set --origin-hint $YAML "ethernets.${if_name}={dhcp4: false}"
sudo netplan set --origin-hint $YAML "vlans.vlan${vlan_id}={id: ${vlan_id}, link: ${if_name}, dhcp4: false}"
sudo netplan set --origin-hint $YAML "bridges.br${vlan_id}={interfaces: [vlan${vlan_id}], dhcp4: true}"

Finale Umstellung

Die folgende netplan Konfiguration schaltet DHCP am Adapter enp2s0 ab, verbindet darauf das vlan1056 und vlan1090, erzeugt ein Bridge br0 und eine Bridge br1090 mit DHCP Konfiguration. Eine existierende Bridge br0 (wie in meinem Fall) bleibt dabei erhalten und wird lediglich modifiziert. Alle meine virtuellen Maschinen bekommen davon nichts mit.  

if_name=enp2s0
vlan_id=1056
YAML=40-vlan-interface
sudo rm /etc/netplan/$YAML.yaml
sudo netplan set --origin-hint $YAML "ethernets.${if_name}={dhcp4: false}"
sudo netplan set --origin-hint $YAML "vlans.vlan${vlan_id}={id: ${vlan_id}, link: ${if_name}, dhcp4: false}"
sudo netplan set --origin-hint $YAML "bridges.br0={interfaces: [vlan${vlan_id}], dhcp4: true}"
vlan_id=1090
sudo netplan set --origin-hint $YAML "vlans.vlan${vlan_id}={id: ${vlan_id}, link: ${if_name}, dhcp4: false}"
sudo netplan set --origin-hint $YAML "bridges.br${vlan_id}={interfaces: [vlan${vlan_id}], dhcp4: true}"

Hinweis: Ich hatte bisher den Empfehlungen folgend für virsh ein virtuelles Netzwerk "host-bridge" mit br0 erzeugt. Ich habe aber mittlerweile festgestellt: Man kann die br1090 auch direkt bei Netzwerkquelle als Bridge Device eintragen. 

Diese Kommandozeile erzeugt in der laufenden VM temporär (bis zum nächsten Shutdown) eine neue Netzwerkverbindung zu einer existierenden Bridge.

virsh attach-interface --type bridge --source $YOUR_HOST_BRIDGE --model virtio $YOUR_VM

Mit der Option --config wird das Interface dauerhaft gespeichert.

Man kann die Netzwerkschnittstelle auch per Kommando umstellen:

virt-xml --edit --update --network bridge=$YOUR_HOST_BRIDGE $YOUR_VM

Ohne die option --update , ist die Änderungen erst nach einem shutdown & restart (kein reboot) aktiv.

ToDo?

Code Block

Ende