Meshwolken trennen mit VLANs

Hallo.

Ich habe einen Futro S450 als Offloader, welcher leider nur einen einzigen Ethernet-Port besitzt und keinen PCI-Streckplatz für weitere NICs.
Ich möchte gerne mit ihm mehrere getrennte Meshwolken füttern. Dazu erzeuge ich mehrere Mesh-Interfaces auf verschiedenen VLANs.
(Als Vorlage für die VLANs habe ich Commandline administration · freifunk-gluon/gluon Wiki · GitHub benutzt)

Zu meinem Vorgehen:
Als erstes erzeuge ich mit uci zwei Devices mit VLAN 1027 und 1042:

uci set network.mesh_vland1027=device
uci set network.mesh_vland1027.type=8021q
uci set network.mesh_vland1027.vid=1027
uci set network.mesh_vland1027.ifname=eth0
uci set network.mesh_vland1027.name=vlan1027-mesh

uci set network.mesh_vland1042=device
uci set network.mesh_vland1042.type=8021q
uci set network.mesh_vland1042.vid=1042
uci set network.mesh_vland1042.ifname=eth0
uci set network.mesh_vland1042.name=vlan1042-mesh

Und anschliessend die Interfaces

uci set network.mesh_vlan1027=interface
uci set network.mesh_vlan1027.ifname=vlan1027-mesh
uci set network.mesh_vlan1027.mesh=bat0
uci set network.mesh_vlan1027.proto=batadv
uci set network.mesh_vlan1027.auto=1

uci set network.mesh_vlan1042=interface
uci set network.mesh_vlan1042.ifname=vlan1042-mesh
uci set network.mesh_vlan1042.mesh=bat0
uci set network.mesh_vlan1042.proto=batadv
uci set network.mesh_vlan1042.auto=1

Nach einem commit und reboot habe ich nun auf eth0 zwei Mesh-Interfaces auf VLAN 1027 und 1042. So weit, so gut.

Nun zum Problem:
Wenn ich mit nur einer Wolke meshe (1027 oder 1042 ist egal), wird im Meshviewer die Verbindung mit TQ 98-100% angezeigt. Hänge ich die zweite Wolke dazu, dümpelt die zweite mit ca. 15% herum. Die Verbindung zur ersten Meshwolke bleibt bei 98%.

Wo liegt mein Denkfehler, was übersehe ich?

Gruß Christian

P.S. das gleiche Verhalten lässt sich auf einem WR841N und einer Nanostation reproduzieren. Auf Geräten mit einem richtigen VLAN-fähigen Switch (z.B. WDR3600) funktioniert das Prinzip, auch wenn die Konfiguration der VLANs anders ist.

vlan1042? Ich dachte die kleinen TP-Links würden nur einstellige(?) Werte für VLans unterstützen.

Bist Du sicher, dass da überhaupt über vlan gemeshed wird?

Ich habe nach diesem Prinzip die WAN-Interfaces der ganzen (MoL-)Meshknoten auf VLAN 1000 geschubst. Das hat auf allen Geräten (auch 841ern) einwandfrei funktioniert.
Es hängen auch „richtige“ VLAN-fähige Switches dazwischen, die Nummern scheinen also zu stimmen. Mesh-on-WLAN ist auf den meisten Geräten aus, die meshen wirklich per Kabel.

Ach, wenn die 841er das Vlan nicht selbst „machen“, sondern das Tagging von den Switchen davor übernommen wird, dann passt das natürlich.

Meinst du wirklich zwei getrennte Netze? So zwei Broadcast-Domains?
So wie du es gemacht hast könnte ich wetten dass die Netze dadurch gebridged werden.
Ich hoffe du meinst zwei nicht per Funk, aber durch VPN verbundene Meshwolken.

Nicht sicher, aber da ich nicht zum „type=8021q“ gefunden habe und es erfolgreich anders am laufen hab, versuch doch mal folgendes:

Lass das mit den devices weg und dann trag das VLAN direkt in das Interface ein.

uci set network.mesh_vlan1027=interface
uci set network.mesh_vlan1027.ifname=eth0.1027
uci set network.mesh_vlan1027.mesh=bat0
uci set network.mesh_vlan1027.proto=batadv
uci set network.mesh_vlan1027.auto=1

Vielleicht war ich auch nur zu blöd die devices anzulegen, aber mein „Mobile AMD Sempron™ Processor 2100+“ wollte so einfach keine getaggten Pakete machen.

1 Like

Danke, das war die Lösung! :+1:

Anscheinend braucht man wirklich keine 8021q-Devices mehr extra anzulegen. Einfaches Verwenden von eth0.x genügt. Ich hätte nicht gedacht, dass es so einfach ist :grinning:
Der Futro kann nun bequem über VLANs den Upload und mehrere getrennte Meshwolken bedienen. Es funktioniert übrigens auch mit hohen VLAN-Nummern.

@adorfer Doch, die 841er machen die VLANs selber, ich habe nur mit einem VLAN-fähigen Gerät (hier Archer C5 mit OpenWRT) getestet, ob die auch richtig getagged werden und sich einzeln ein- und ausschalten lassen.
Übrigens funktionieren die hohen VLAN-Nummern auch problemlos auf meinen 841ern (soeben getestet mit gluon-v2015.1.2).

Ich weiss nicht, wo das Gerücht mit den 841ern herstammt, möglicherweise ist die Anzahl der VLANs gemeint und nicht die Nummer? Zumindest hat das Vorgehen mit dem 8021q-Device bereits unter gluon v2015.1 hier mit hohen Nummern für WAN und ein einzelnes Meshinterface funktioniert.

Hi @DL3DCF @paulinsche

ich wollte das selber auch machen aber leider hat es nicht geklappt.
Habt Ihr zusätzlich zu den Teilen oben noch etwas angepasst zb /etc/config/network
oder so?
Bei mir sieht es so aus das ich einen Switch habe wo 3 Mesh Wolken ankommen in 3 VLANs (1021,1022,1023) auf einem Port aber nur das von weiter oben (natürlich mit den richtigen VLANs) klappt nicht.
Habe das mit einem 841V9 und nem x86 ausprobiert.

Hier das Mesh
http://map.ffruhr.freifunk-ruhrgebiet.de/#!v:m;n:30b5c2ee0d38

Danke

Siehst Du denn in nem tcpdump dass die getaggten Pakete am Offloader ankommen?

Interfaces wurden angelegt und sind aktiv?

8021q Modul wurde geladen?

1 Like

Ja die Pakete kommen an und die Interfaces sind auch aktiv. Muss ich das Modul separat laden? Hat das in einem anderen Post gelesen das es seit 2015.1 default aktiv ist?

Puh, keine Ahnung, aber sieh doch mal nach ob es geladen wurde:

lsmod | grep 8021q

Hallo.

Wie sieht deine /etc/config/network den aus?
Der entsprechende Ausschnitt aus meiner:

[…]

config interface 'mesh_lan'
	option macaddr '02:1a:9a:6b:12:eb'
	option mesh 'bat0'
	option proto 'batadv'
	option auto '1'
	option ifname 'eth0.999'

config interface 'mesh_philipp'
	option ifname 'eth0.1001'
	option macaddr '02:1a:9a:6b:12:ec'
	option mesh 'bat0'
	option proto 'batadv'
	option auto '1'

config interface 'mesh_sundwig'
	option ifname 'eth0.1027'
	option macaddr '02:1a:9a:6b:12:ed'
	option mesh 'bat0'
	option proto 'batadv'
	option auto '1'

[…]

Mehr war bei mir nicht nötig. Das funktioniert so auf meinem Futro und ganz ähnlich auch auf einem 841er.
https://map-hemer.freifunk-mk.de/#!v:m;n:0019996b12eb
Demnächst werden noch 2 weitere Links hinzukommen.

Gruß Christian

Auf einem 841er muss man Tagging auf dem Switch aktivieren und dem Switch jeweils mitteilen in welcher port auf welchem vlan lauscht. Vergleiche https://freifunk-muensterland.de/wiki/doku.php?id=technik:loadsharing

Ich hätte erwähnen sollen, dass ich auf den 841ern nur MoW benutze. Am WAN-Port (eth1) genügt es, ifname an das entsprechende VLAN anzupassen (ifname ‚eth1.x‘).

Auch wenn ich hier eine Leiche ausgrabe…
Solch ein Verhalten mit 15% TQ hat man, wenn man den verschiedenen VLAN Interfaces keine separaten MAC Adressen gibt. Batman kommt dann damit nicht zurecht.

Ich gebe auf einem System grundsätzilch jedem Interface im Batman (egal ob jetzt vlan oder auf unterschiedlicher HW) eine eigene MAC.
Es ist schlicht sicherer, für den Fall dass doch mal „hintenherum“ ein Kurzschluss passiert.

1 Like

Etwas ähnliches haben wir auf Supernodes beobachtet, eigentlich sollte Batman sich darüber beschweren als es einfach hinzunehmen. Ich denke das Batman die Interfaces dann per Round-Robin verwendet und die Pakete immer abwechselnd über ein anderes versendet.

Das kann dann in soweit auf Gateways störend sein, wenn von einem Gateway alle Interfaces einzeln auftauchen in der „gwl“.
Umgekehrt kann man das natürlich auch kreativ nutzen, um Gateways „attraktivier“ zu machen, in Szenarien wo das über „künstlich zu viel Bandbreite Announcen“ nicht funktioniert oder ratsam ist.