VLAN-Config auf Turris Omnia

Ich habe vor einiger Zeit einen älteren Plastikrouter, auf dem OpenWRT läuft, gegen einen ungleich stärkeren Turris Omnia ausgetauscht, da mein älterer Router nicht mehr für Internetgeschwindigkeiten über 150MBits geeignet war, wegen eines zu schwachen Prozessors.

Ich hatte bei der Einrichtung allerdings einige Probleme mit der Einrichtung von VLANs. Bei TP-Link Routern ist der Switch mit im Hauptchip, man richtet VLANs ein, und alles ist gut. Beim Omnia ist der Switch-Chip aber ein dedizierter Chip, der mit dem Hauptchip über zwei Leitungen verbunden ist (siehe hier). Von daher muss man da ein bisschen mehr Gehirnschmalz rein stecken, damit alles klappt – sonst sperrt man sich aus.

VLANs

Hier sei einmal auf das tolle Snapshot-Tool schnapps verwiesen, was auf dem Omnia installiert ist. Hierbei sollte man vor der VLAN-Config mit schnapps create einen Snapshot erstellen, auf den man einfach rollbacken kann. Hierfür hält man den Resetbutton gedrückt, bis die zweite LED aufleuchtet, und lässt ihn los, bevor die dritte LED aufleuchtet (siehe hier).

Die folgende Config richtet mindestens zwei verschiedene VLANs ein. Hierbei ist br-home das Standard-VLAN, was im Auslieferungszustand br-lan heißt.

Das VLAN wird eingerichtet in /etc/config/network.

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option vid '1'
        option ports '1 5t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option vid '2'
        option ports '2 5t'

Mit dieser Config werden zwei VLANs eingerichtet. Das Device, switch0 ist der interne Switch des Omnias, der aber halt ein dedizierter Chip ist. Die vid ist tatsächlich die VLAN-ID, mit der die Pakete getagged werden, falls sie über einen getaggten Port laufen, und die Option vlan ist nur fürs interne Handling von OpenWRT. Interessant wird die Option ports. Hier sind Port 5 und 6 die “Backplate-Ports”, die vom Switch-Chip zum Hauptchip gehen, so wie auf o.g. Grafik zu sehen ist. Diese Ports sind natürlich tagged, weil da mehr als ein VLAN zum Hauptchip geleitet werden. Hier könnte man auch Port 6 tagged nutzen, da beide Ports in die gleiche Richtung weisen – es ist aber nicht unbedingt notwendig. Man sollte aber natürlich pro VLAN nur einen der beiden Ports nutzen, sonst hat man einen Loop – und dann geht alles kaputt.

Im Werkszustand sind schon einige VLANs konfiguriert, die u.a. dafür sorgen, dass Ports 0-3, die auf der Rückseite in einer Baugruppe sind, über Port 5 in die Backplate gehen, und Port 4, der mit dem Ethernet-WAN-Port in einer Baugruppe ist, über Port 6 in die Backplate geht. Diese Config kann man getrost entfernen, man kann problemlos auch Port 4 über Port 5 tagged in die Backplate leiten.

Nachdem man nun die VLANs konfiguriert hat, geht es an die Konfiguration der entsprechenden Interfaces. Hier verhält sich der Omnia etwas seltsam, oder ich mache es nicht so, wie vorgesehen, aber es funktioniert.

Die VLAN-Config legt mehrere Interfaces nach dem Schema eth0.1 an, wobei 1 hier die VLAN-ID ist. Die sind alle mit Port 5 verbunden, der physisch mit der Schnittstelle eth2 verbunden ist. Daher muss jedes Interface eigentlich eine Bridge sein, die über eth0.x und eth2 bridged.

Eine Beispielconfig sieht beispielsweise so aus:

config interface 'admin'
        option force_link '1'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ifname 'eth0.1 eth2'

Dieses Interface legt nun offensichtlich eine Bridge über eth0.1 und eth2 an, und konfiguriert ein paar Parameter für Layer 3. Eigentlich sollte man nun alle anderen Interfaces genau so konfigurieren – aber hier entsteht die Diskrepanz zwischen meiner Logik und der tatsächlichen Funktionalität. Ein zweites Interface wird nämlich so angelegt:

config interface 'home'
        option proto 'static'
        option ifname 'eth0.10'
        option 'bridge'
        option netmask '255.255.255.0'
        option ipaddr '192.168.10.1'

Wie man sieht, wird hier für das ifname nur noch das Interface des Switches angegeben, nicht des Hauptchips, obwohl der Typ immer noch auf bridge steht. Ich vermute, dies hat was damit zu tun, dass über das erste konfigurierte Interface schon eine Bridge existiert, und das was mit den bereits vorhandenen Tags auf dem Port zu tun hat. Wie auch immer, versucht man eth2 in mehr als einem Interface aufzunehmen, dann funktioniert das nicht, und das Interface lässt sich nach einem Start nicht erreichen.

Dies herauszufinden hat mich viel Zeit und Frust gekostet, aber man legt nun alle weiteren Interfaces genau so an – als eine Bridge über nur ein physikalisches Interface. Ich schätze, wenn man irgendwo auch noch über Port 6 des Switches mehr als ein VLAN tagged laufen lässt, muss man es hier genau so machen – eine Interfacekonfiguration als Bridge über zwei physikalische Interfaces, alle weiteren als Bridge über nur ein Interface.

Auf jeden Fall läuft es so. Falls ihr, die ihr das hier hoffentlich irgendwann mal lest, eine Idee habt, wieso das nun so ist, würde ich mich um einen kurzen erläuternden Kommentar freuen.

Kommentare anzeigen