„You see, there are still faint glimmers of civilization left in this barbaric slaughterhouse that was once known as humanity. Indeed that’s what we provide in our own modest, humble, insignificant … oh, fuck it!“
M.Gustave – The Grand Budapest Hotel
Alles begann, wie so oft, mit einem Versuch.
Ich hatte auf dem VM-Server begonnen, Proxmox VMs aufzusetzen.
Zum einen, weil ich es eh schon lange mal vorhatte, zum zweiten, weil sich ein Ex-Kollege mit einer How-To bei mir gemeldet hatte, und ich so die Möglichkeit hatte, das endlich mal zu probieren und ich mich gleichzeitig ein wenig gefällig erweisen konnte.
Nachdem ich die vierte Maschine aufgesetzt hatte, schoss mir ein Gedanke durch den Kopf:
Du reizt deine Hardware gerade ganz schön aus.
Zugegeben, Paravirtualisierung von einer Virtualisierungsumgebung ist schon was Schickes, aber wenn auf der zugrunde liegenden Hardware deine Produktivumgebung läuft, überlegst du zweimal, ob du das Ding nun Performance-technisch in die Knie zwingen möchtest! 🙂
Da ich eine nahezu identische Hardware-Konfiguration in meinem Arbeitsrechner verbaut war, und die Proxmox VMs sowieso nur zu Testzeiten liefen, beschloss ich, einige der VMs umzuziehen. Nichts leichter als das. Virtuelle Maschine herunterfahren, Dot-qcow2 – Datei über das NAS auf die Linux-SSD meines Arbeitsrechners transferieren, und anschließend wieder hochfahren.
So weit, so gut. Doch jetzt kommunizierten die Maschinen auf einmal nicht mehr untereinander. Nun gut, alle bekamen im Zuge der Installation eine feste IP; vielleicht war der Bridge-Zugang in meiner VM-Umgebung auf dem Arbeitsrechner einfach noch nicht vernünftig konfiguriert, und die Maschinen befanden sich in unterschiedlichen VLANs.
Auf allen Maschinen mal das Gateway pingen …. Was auch funktionierte … was war denn jetzt los? Zwei Desktop-Clients mit DHCP-basierter IP aufgesetzt; auch diese konnten zwar das Gateway, allerdings sich nicht gegenseitig anpingen. Irgendwas lief da schief …
Hatte ich bei der Einrichtung der VLANs etwas verkehrt gemacht? War dies ein typischer Layer 8 Fehler?
Also hieß es: Tutorials gucken.
OpenWrt war die erste Adresse:
https://openwrt.org/docs/guide-user/network/vlan/switch_configuration
Hier wurde das ganze via CLI beschrieben, was ich aber zugegebenermaßen so nicht gemacht hatte.
Ich hatte die VLANs über Luci, das Web-Interface, angelegt. Zum Glück gab es diesbezüglich Tutorials:
Hier wird erklärt, wie man VLANs anlegt …. Aber Moment, das unterscheidet sich doch von meiner Methodik ….
Ich hatte die VLANs via
Network→Interfaces→Devices→„Add device configuration“
angelegt, in dem Video wurde aber die Methode
Network→Interfaces→Devices→named-bridge→configure→“Bridge VLAN filtering“
angelegt …
Der Unterschied sieht nicht spektakulär aus, die letztgenannte Methode hat aber einen entscheidenden Vorteil:
Während ich mit der erstgenannten Methode zwar die VLANs angelegt hatte, hatte ich die Verarbeitung zwischen den Ethernet Ports noch nicht berücksichtigt, d.h. zwar kamen alle Ports in den Genuss der VLANs, die Ethernet Ports untereinander kommunizierten aber nicht via VLAN (nur über VLAN 1 war das möglich).
Kurzum: Ich habe die VLANs angelegt, aber kein Tagging über die Ethernet Ports hinweg angesetzt. Die zweite Methode tut dies sofort, weswegen das Anlegen der entsprechenden VLANs dann auch automatisch geschieht.
Den Schritt nachgezogen, und einen Abend lang war ich glücklich. Als ich am nächsten Morgen aufwachte, wunderte ich mich, warum ich denn kein WLAN auf meinem Handy hatte.
Ein kurzer Blick in die Konfiguration des Routers offenbarte mir, dass mein WLAN mal lief und mal nicht, und selbst wenn es lief, konnte sich mein Smartphone nicht verbinden.
Also forderte ich Google heraus, mir Antworten zu liefern ….
Und das tat es auch, allerdings keine, die ich unbedingt lesen wollte ….
https://github.com/openwrt/openwrt/issues/15529
https://github.com/openwrt/openwrt/issues/10219
Kurzum: VLAN-Tagging über Ethernet-Ports hinweg würde funktionieren, sofern man auf Passwörter bei seinem WLAN verzichtet.
Dies war aber keine Option.
Ich habe es dennoch versucht (es gibt keine Hardware, die nicht von einem verrückten Layer 8 Problem zerstört werden kann).
Nach mehrmaligen Resets verabschiedete sich dann das Wireless-Interface komplett, sodass ich gezwungen war, den Netgear Nighthawk wieder mit seiner Originalfirmware zum Laufen zu bringen. (Gruselig, aber danach lief das Wireless-Interface wieder). Zwischenzeitlich fand dann die DD-WRT Firmware Einzug auf dem Router, wurde aber ganz schnell wieder verworfen, da nur ein DDNS Dienst gestartet werden konnte.
Also stand ich vor dem Dilemma: Entweder du verzichtest aufs WLAN (keine Option, neben dem Gastnetz gab es noch ein IoT Netz), oder aber ich verabschiede mich vom VLAN Tagging über die Ethernet Ports hinweg … Ich kam zur Einsicht, dass dies die bessere Option war.
Ein Gedanke ließ mich allerdings nicht los: Die VLANs kommen ja an allen Ports an, nur über die Ports hinweg wird nicht kommuniziert …
Was passiert, wenn ich da hinter dann einen Switch hänge?
Dann geschaut, ob OpenWrt neben Routern auch Switches unterstützt. Tut es, wenn auch in einer nahezu überschaubaren Menge …
https://openwrt.org/toh/views/switches
Anschließend stürzte ich mich auf Ebay.
Die Anschaffung eines Switches war eh schon länger in Planung, da das Netzwerk z.T. aus kaskadierenden zu Switches umfunktionierten Routern besteht, und ich auf die Konfiguration der Netzwerke über mehrere Knotenpunkte hinweg eigentlich eh keinen Bock mehr hatte ….
Mein erstes Mal bieten (ich wollte jetzt nicht Unmengen an Geld ausgeben, es bestand nach wie vor noch die Option, dass mein Unterfangen scheitern würde) lief noch ins Leere, das zweite Objekt der Begierde wurde dann aber vergleichsweise günstig ergattert.
Ausgepackt, angeschlossen, mit OpenWrt gefüttert, VLANs eingerichtet, zuletzt dann ins Netzwerk integriert und voilà … das Tagging auf der Maschine funktioniert, die VLANs werden durchgereicht, und die beiden Maschinen kommunizieren jetzt auch wunderbar über das VLAN (Sie hängen ja am Router auch noch an einem Port).
Und WLAN habe ich auch noch!
Der Router ist ersten Erkenntnissen nach sogar schneller geworden, scheint so, als wäre das Gerät nicht dafür ausgelegt, dass alle Ethernet Ports belegt sind.
Eigentlich alles gut, aber ….
Auf OpenWrt wird KEINE direkte Kaufempfehlung gegeben.
Ich habe mich damals an den Kapazitäten der Router (CPU, RAM, (Flash- bzw. ROM-))Speicher orientiert, und eine der potenteren Maschinen gekauft. Im direkten Link zu dem Gerät (https://openwrt.org/toh/netgear/r8000) wird zwar über die WLAN-Schwierigkeiten gesprochen, aber auch gleich eine Lösung präsentiert. Die Schwierigkeiten mit dem VLAN werden nicht erwähnt. Und auch wenn es etwas harsch erscheint (es handelt sich immerhin um ein kostenloses Produkt, welches, das Know-how vorausgesetzt, mehr Potenzial aus den Routern holt), ich hätte die Warnung gerne vor dem Neukauf bekommen, dann hätte ich mich gegebenenfalls noch umorientiert.
Der Router davor (D-LINK Dir-825) kommt allmählich in die Jahre und es wird aktiv davor gewarnt, diesen aufgrund der geringen Kapazitäten noch zu nutzen. Und ja, auch einen Weg zurück zum alten Router hatte ich in Erwägung gezogen …
Mein Fazit: Broadcom kommt mir nicht mehr ins Haus!
Neueste Kommentare