[Verständnisfrage] Bridges und VLAN

[Lookbehind]

Hallo zusammen,

ich hab mal ne Verständnisfrage. Ich hab auf einem Interface mehrere VLANs. VLAN 1220 liegt untagged direkt auf dem Interface, die VLANs 1221, 1222 und 1225 kommen dort tagged an. Das ist auch so weit alles konfiguriert und funktioniert.

Code: Alles auswählen

auto eno1
allow-hotplug eno1
iface eno1 inet static
    address ...

auto eno1.1221
allow-hotplug eno1.1221
iface eno1.1221 inet static
    vlan-raw-device eno1
    address ...

Wöllte ich jetzt eine Bridge für das 1221 VLAN bauen um da einige VMs rein zu hängen, wäre der weg klar. eno1.1221 ist ein eigenes Interface mit nur diesem VLAN drauf, das wird in die Bridge gehangen und alles ist gut.

Code: Alles auswählen

auto brvlan1221
allow-hotplug brvlan1221
iface brvlan1221 inet static
    bridge_ports eno1.1221
    bridge_stp off
    address ...

Allerdings würde ich gerne eine Bridge mit dem untagged VLAN bauen. In der Theorie auch ganz einfach:

Code: Alles auswählen

auto brvlan1220
allow-hotplug brvlan1220
iface brvlan1220 inet static
    bridge_ports eno1
    bridge_stp off
    address ...

Allerdings, wie is dass denn nun? Habe ich dann alle VLANs auf dieser Bridge, weil ich ja das native Interface für die Bridge verwende? Oder nur das untagged VLAN, weil die VLANs ja eigentlich an anderen Meta-Interfaces gebunden sind? Und wenn ersteres zutrifft, wie bekomme ich letzteres hin?
Auf welche VLANs könnten die VMs mit dem Setup zugreifen?

TIA

Look

[bluestar]

Allerdings würde ich gerne eine Bridge mit dem untagged VLAN bauen. In der Theorie auch ganz einfach:

Kannst du auch erklären, warum du das tun möchtest.

Allerdings, wie is dass denn nun? Habe ich dann alle VLANs auf dieser Bridge, weil ich ja das native Interface für die Bridge verwende? Oder nur das untagged VLAN, weil die VLANs ja eigentlich an anderen Meta-Interfaces gebunden sind? Und wenn ersteres zutrifft, wie bekomme ich letzteres hin?
Auf welche VLANs könnten die VMs mit dem Setup zugreifen?

Ich adaptiere zur besseren Erklärung mal deinen Code und spreche hier

Code: Alles auswählen

auto br-raw
iface  br-eno1 inet static
    bridge_ports eno1
    bridge_stp off
    address ...

Wenn du eno1 als Device in deine Bridge einbaust, dann müsstest du deine IP-Konfiguration von eno1 auf br-eno1 verschieben und die anderen VLANs kannst du dann über die Bridge als Raw-Device anlegen, z.B. br-raw1221.

Das wird allerdings ein recht wackeliges Setup, daher wäre es gut zu wissen, warum du diesen Weg wählen möchtest. Du kannst ja abseits von klassischen Bridges auch mit openvswitch einen komplexen Switch bauen, wo du für jeden Port definieren kannst welches VLAN untagged und welche VLANs tagged anliegen sollen.

[Lookbehind]

Allerdings würde ich gerne eine Bridge mit dem untagged VLAN bauen. In der Theorie auch ganz einfach:

Kannst du auch erklären, warum du das tun möchtest.

Ja. Auf dem Host kommen besagte vier VLANs an. Eine als Untagged und 3 als Tagged-VLAN. Die Tagged-VLANs werden vornehmlich auf dem Host selbst gebraucht, das Untagged VLAN auch. Allerdings sollen nun auch ein paar VMs auf dem Host gestartet werden. Diese sollen nur über das untagged VLAN (1220) erreichbar sein, nicht über die Tagged VLANs.

Wenn die Bridge jetzt grundsätzlich alle VLANs durch reicht, dann könnte eine VM sich da theoretisch drauf verbinden, indem in der VM einfach die passende VLAN-Config angelegt wird. Das sollte zwar theoretisch nicht so ohne weiteres passieren. Aber könnte, sollte und hätte sind Konjunktive.

Allerdings, wie is dass denn nun? Habe ich dann alle VLANs auf dieser Bridge, weil ich ja das native Interface für die Bridge verwende? Oder nur das untagged VLAN, weil die VLANs ja eigentlich an anderen Meta-Interfaces gebunden sind? Und wenn ersteres zutrifft, wie bekomme ich letzteres hin?
Auf welche VLANs könnten die VMs mit dem Setup zugreifen?

Ich adaptiere zur besseren Erklärung mal deinen Code und spreche hier

Code: Alles auswählen

auto br-raw
iface  br-eno1 inet static
    bridge_ports eno1
    bridge_stp off
    address ...

Wenn du eno1 als Device in deine Bridge einbaust, dann müsstest du deine IP-Konfiguration von eno1 auf br-eno1 verschieben und die anderen VLANs kannst du dann über die Bridge als Raw-Device anlegen, z.B. br-raw1221.

Stimmt, die VLAN-Interfaces auf dem Host könnte man dann auch aus der Bridge ziehen. Aber muss man das? *kratz* Ich hätte gedacht ich kann eno1 einzeln in die Bridge hängen und en1.1221 trotzdem noch aus dem direkten Device ableiten.

Das wird allerdings ein recht wackeliges Setup, daher wäre es gut zu wissen, warum du diesen Weg wählen möchtest.

In wie weit ist das wackelig? Würde mich mal interessieren. (Ernst gemeinte Frage! Ich merke ja an deinen Ausführungen zu den VLAN-Devices aus der Bridge schon, dass mir hier dann doch die Erfahrung fehlt.)

Du kannst ja abseits von klassischen Bridges auch mit openvswitch einen komplexen Switch bauen, wo du für jeden Port definieren kannst welches VLAN untagged und welche VLANs tagged anliegen sollen.

Hm, tja ... wirkt ein bisschen wie die Tomahawk-Rakete welche einen Ameisenhaufen zerstören soll. Aber effektiv wäre es natürlich. Ich hatte nur gehofft nicht in diese Komplexitäts-Stufen hinab steigen zu müssen.


Danke schon mal für die Ausführungen bisher.

Look

[bluestar]

Wenn die Bridge jetzt grundsätzlich alle VLANs durch reicht, dann könnte eine VM sich da theoretisch drauf verbinden, indem in der VM einfach die passende VLAN-Config angelegt wird. Das sollte zwar theoretisch nicht so ohne weiteres passieren. Aber könnte, sollte und hätte sind Konjunktive.

Du kannst mit VLAN filtering (ip link set br-eno1 type bridge vlan_filtering 1) steuern ob die Bridge Tagged Pakete weiterreichen soll, das ist - Ich weis ad hoc nicht, welcher Modus bei welcher Kernel-Version der Standard ist.

Stimmt, die VLAN-Interfaces auf dem Host könnte man dann auch aus der Bridge ziehen. Aber muss man das? *kratz* Ich hätte gedacht ich kann eno1 einzeln in die Bridge hängen und en1.1221 trotzdem noch aus dem direkten Device ableiten.

Das könn(te) mit einem neueren Kernel ggfs. auch funktionieren, ausprobiert habe ich es noch nicht. Der Buster Kernel ist da etwas zickig, was die Reihenfolge der Netzwerkschnittstellen angeht, zumindest bei uns im Zusammenspiel mit Intel 10G Karten und der GBic Initialisierung.

In wie weit ist das wackelig? Würde mich mal interessieren. (Ernst gemeinte Frage! Ich merke ja an deinen Ausführungen zu den VLAN-Devices aus der Bridge schon, dass mir hier dann doch die Erfahrung fehlt.)

Wenn in der Bridge der Port eno1 auf den Link State down geht, dann gehen die eno1.xxxx Schnittstellen halt auch runter - Zumindest hat uns das in der Vergangenheit bei Bridge Setups immer genervt.

[Lookbehind]

Wenn die Bridge jetzt grundsätzlich alle VLANs durch reicht, dann könnte eine VM sich da theoretisch drauf verbinden, indem in der VM einfach die passende VLAN-Config angelegt wird. Das sollte zwar theoretisch nicht so ohne weiteres passieren. Aber könnte, sollte und hätte sind Konjunktive.

Du kannst mit VLAN filtering (ip link set br-eno1 type bridge vlan_filtering 1) steuern ob die Bridge Tagged Pakete weiterreichen soll, das ist - Ich weis ad hoc nicht, welcher Modus bei welcher Kernel-Version der Standard ist.

Hm, das klingt nach einem gangbaren Weg.

Stimmt, die VLAN-Interfaces auf dem Host könnte man dann auch aus der Bridge ziehen. Aber muss man das? *kratz* Ich hätte gedacht ich kann eno1 einzeln in die Bridge hängen und en1.1221 trotzdem noch aus dem direkten Device ableiten.

Das könn(te) mit einem neueren Kernel ggfs. auch funktionieren, ausprobiert habe ich es noch nicht. Der Buster Kernel ist da etwas zickig, was die Reihenfolge der Netzwerkschnittstellen angeht, zumindest bei uns im Zusammenspiel mit Intel 10G Karten und der GBic Initialisierung.

Mit anderen Worten, das sollte man vorher mal auf einem System testen, bei dem es nicht so drauf ankommt.

In wie weit ist das wackelig? Würde mich mal interessieren. (Ernst gemeinte Frage! Ich merke ja an deinen Ausführungen zu den VLAN-Devices aus der Bridge schon, dass mir hier dann doch die Erfahrung fehlt.)

Wenn in der Bridge der Port eno1 auf den Link State down geht, dann gehen die eno1.xxxx Schnittstellen halt auch runter - Zumindest hat uns das in der Vergangenheit bei Bridge Setups immer genervt.

Ok, das wäre hier nicht so das Problem. Wenn eno1 (bzw. das Interface mit dem untagged VLAN) down geht, haben wir auf der Kiste ganze andere Probleme, da helfen dann die VLAN-Interfaces auch nicht mehr. Oder anders: Das sollte ohnehin nur in absoluten Ausnahmefällen passieren. Für die Umstellung müsste ich also eh eine Downtime einplanen. Das war aber zu erwarten.