VLANs auf einer 4040

Moin,

weiß jemand, wie man das WAN auf einer 4040 als zusätzliches VLAN (z. B. 10) auf einem der gelben Ports ausgibt?

Anwendungsfall hier ist, dass an der 4040 proprietäre APs hängen, die untaggt mit Freifunk-Clientnetz und taggt mit dem WAN-Netz versorgt werden sollen.

Auf den 1043ern kann man einfach in der /etc/config/network beim VLAN-Block 2 den LAN-Port hinzufügen.

Und auch die 4040 zeigt an, dass intern so gearbeitet wird:

# swconfig dev switch0 show
[...]
VLAN 1:
	vid: 1
	ports: 0 1 2 3 4 
VLAN 2:
	vid: 2
	ports: 0t 5 

Aber das VLAN 2 taucht in der /etc/config/network nirgendwo auf. Ich hatte jetzt überlegt ob man ein weiteres Interface in br-wan hängt, aber ideal ist das nicht, weil dann alles durch die CPU muss statt auf Hardwareebene geswitcht zu werden.

Viele Grüße
Matthias

Ich würde dir abraten id 2 zu benutzen, da irgedwas manchmal „hard-wired“ ist. Ensprechend kannst du auch mit der swconfig die ports abändern. Wichtig ist nur das alles tagged zum cpu port ist (nehme ich mal an).

Deswegen mach doch so? Dann ist dhcp einfach untagged auf allen ports.

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

                              
config switch_vlan
	option device 'switch0'
	option vlan '42'
	option ports '0t 1t 2t 3t 4t'
                              
config switch_vlan
	option device 'switch0'
	option vlan '40'
	option ports '0t 1 2 3 4'

config interface 'mgmt'
	option ifname 'eth0.42'
	option proto 'static'
	option ipaddr 'xxx'
	option ip6addr 'xxx'

config interface 'dhcp'
	option ifname 'eth0.40'
	option proto 'static'
	option ipaddr 'xxx'
        option type 'bridge'
	option ip6addr 'xxx'

FYI: Bald gibt es DSA support auf trunk in Openwrt. Dann stimmt oben geschriebens nicht mehr ganz.

Moin @Polynomialdivision,

danke für die Antwort. Wenn ich sie richtig verstehe, beziehst du dich hier aber nur auf die gelben Ports. Ich suche eine Lösung für den blauen Port, bzw. möchte den blauen Port auf die gelben durchbridgen.

Grüße
Matthias

Ich hab’s gelöst, es ist tatsächlich so trivial. Einfach unter dem VLAN 1 einen Block für wie oben richtig geraten VLAN2 anlegen. Obwohl es standardmäßig nicht drin ist, geht es genau wie bei einem 1043er.

Jedoch konnte ich die IP der 4040 auf dem WAN-Port nicht von einem Gerät am gelben Port aus erreichen. Von Upstream aus ging es und die durchgebridgten Clients konnten auch Upstream alles erreichen. Für meinen Anwendungsfall genügt das erstmal. Der Switch in der 4040 scheint nicht zu checken, welche MAC die CPU im Gerät selbst hat.

# Bestand
config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '1 2 3 4 0'

# neu eingefügt
config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '0t 1t 2t 3t 4t 5'

Nach einem Neustart wird die Konfig übernommen:

# swconfig dev switch0 show
[...]
VLAN 1:
	vid: 1
	ports: 0 1 2 3 4 
VLAN 2:
	vid: 2
	ports: 0t 1t 2t 3t 4t 5 

Hatte mich vorher nicht getraut, weil das Gerät ca. 30 min entfernt steht. Hab es jetzt mit einem lokalen Gerät testen können.

Ich würde dir trotzdem dazu raten, beide ports zu taggen zur CPU hin und nicht dieses vlan2 bzw 1 zu benutzen. Port 5 ist das WAN. :wink: Aber wenn es läuft, dann lass es so. :slight_smile:

1 „Gefällt mir“

Wenn du zufällig Zeit hast und mehrere 4040er, dann versuch mal bitte die freezes nachzuprdouzieren, wenn du bock hast :slight_smile:

Moin,

hab mir das Ticket mal durchgelesen. Ich würde erstmal beobachten, ob das jetzt auftritt.

Wir haben viele 4040 mit VLAN-Konfig im Einsatz. Häufig einfach Mesch und Clientnetz parallel auf einem Port um über einen Switch Außenrouter mit Mesch- und Innenrouter mit Clientnetz zu versorgen. Da hat es noch keinen einzigen Absturz gegeben, soweit mir bekannt ist.

Und jetzt eben die Konfig mit dem WAN-Netz. Bisher auch keine Probleme.

Werde das auf jeden Fall mal beobachten.

4040 hab ich noch einige hier. Hast du einen konkreten Test, den ich nachstellen soll? Dort wirkt es einfach so, als ob die Geräte sich halt weghängen, was ich bei mehreren Geräten, teilweise schon Monate im Einsatz, bisher nicht hatte. Allerdings mit Gluon, nicht mit OpenWrt.

Grüße
Matthias

Ne, aber mittlerweile hat @blocktrron glaube ich auch einmal den Crash Reproduziert. Und es ist wirklich so merkwürdig. Ich glaube mit unterschiedlich viel Traffic trittt auch der freeze unterschiedlich oft auf. Ich wollte mal nen iperf3 testbed aufbauen.

1 „Gefällt mir“
1 „Gefällt mir“

Hier nur der Hinweis für alle, die den Thread ab 2022 lesen:
Gluon 2022.1 unterstützt VLANs jetzt updatefest.

Wer mag kann sich ja mal die Doku ansehen, die wir dafür gerade vorbereiten, ob es noch Verständnisprobleme gibt:

@MPW wenn ich das richtig im Kopf habe, wird es nicht möglich sein Client und Mesh auf dem selben Interface gleichzeitig zu betreiben, weil das zu Schleifen führen kann, die Gluon nicht abfängt.

1 „Gefällt mir“

Den Satz verstehe ich nicht. Es geht gerade um VLANs, also das Trennen von virtuellen und physikalischen Interfaces. Schleifen machen in Mesh nichts um im Clientnetz darf das sowieso nicht sein. Und ehrlich gesagt verstehe ich deinen Satz auch nach mehrfachem Lesen nicht.

Aber siehe hier:

(Zeile 111 im Diff)

1 „Gefällt mir“

Mein Fehler. Die Info, dass du zwei getrennte VLANs auf dem Interface für die beiden Rollen nutzt hatte ich überlesen. Das geht natürlich weiterhing aber jetzt persistent konfigurierbar und von gluon unterstützt :slight_smile:

Ich hatte rausgelesen, dass du auf dem selben VLAN-Interface Mesh und Client gleichzeitig abgeworfen hättest und das keine Probleme verursacht hätte.

1 „Gefällt mir“

Ne, das wäre wirklich schräg :wink:

1 „Gefällt mir“