On 04/07/16 20:27, Jan-Tarek Butt via Dev wrote:
Soll ich das nun machen?
Ich würde Erstmal die VLAN config für die Router bauen und testen wollen ob das alles performant läuft.
danach können wir ermitteln wie viele und Welche VLANs wir den Hoods zusweisen.
Ich bin das nun einmal durch gegangen.
VLANs sind leider keine optimale Lösung...
Die idee war im Grunde den batman-adv traffic beim mesh on LAN und/oder WAN eigentlich nur mit vlan tags zu versehen.
Viele Router haben aber einen VLAN-Switch. Unproblematisch wäre es wenn alle Router den gleichen hätten aber das ist ja natürlich nicht der Fall :D. Wie im Satz zuvor angedeutet gibt es auch einige wo sich anstatt nur ein Interface bei der CPU meldet auch welche wo sich zwei oder mehr melden. Z.B. WAN und LAN[0-3]. D.h. das z.B. WAN kein vlan manage"switch ist" aber lan[0-3] schon.
Ein weiteres Problem ist das viel consumer switch-Hardware nur VLANs 1 bis 31 oder sogar nur bis 15 tags können.
Man könnte das batman-adv VLAN feature nutzen indem man von bat0 (batman-adv Interface) ein bat0.X erzeugen auf bat0 und das dann in br-client steckt. Das ist dann auch völlig unabhängig von irgendwelcher Hardware und würde sogar das bssid handlich seitens des hoodselectors theoretisch überflüssig machen. Erhöht aber auch wieder die nötige MTU der WLAN-Interfaces um 4 und fastd interfaces. Gerade bei WLAN ist das immer einer teure Geschichte. Des weiteren führt das, dazu das wir gluon foken müssen und nen haufen packages ändern müssten. Eine variante wäre eine weitere abstraktions-Schicht zwischen den interfaces und den packages zu schaffen. Das geht aber wieder zu lasten des speicher Verbrauchs.
Eine weiter idee das zu lösen wäre evtl. QinQ nach IEEE 802.1ad das beteutet im Grunde soviel wie gestacktes VLAN. D.h. das die switches dann den äußeren vlan header interpretieren und entfernen. Vielleicht könnte man das tagen sogar in der Bridge konfigurieren (Linux-Bridges können seit einiger Zeit selbst VLAN-Header hinzufügen und entfernen). Da gibt es allerdings mehrere Probleme:
1. wir wissen nicht wie solche Billig-Switches darauf reagieren.
2. bei Interfaces die kein VLAN-Switch sind wie bei ein paar TP-link Geräten, führt es dazu das doppelt gestackte VLANs durch das lokale LAN geistern die wiederum auch von den Gegenseiten interpretiert werden müsste.
3. In andern VLAN netzen kann das spaßig werden.
Allgemein müsste sehr wenig am Setup geändert werden, aber es hängt alles davon ab, wie die VLAN-Switches von Routern damit umgehen und zwar jeder einzelner von jedem Router Type und auch Revisions übergreifend.
Das ist irgendwie alles nicht so das wahre.. Und wird Endeffekts mehr nerven kosten und Kopfschmerzten bereiten als gut tut.
Eine weiter mögliche Lösung werde ich in einen weiteren thread vorschlagen und erklären.
cheers Tarek