Hallöle,
mir kam gerade ein Gedanke, der uns evtl. relativ einfach beim Problem des Kabelmeshes in der Hoodauswahl hilft.
Ich habe es noch nicht zu Ende gedacht!!
Stichwort VLAN.
Wie wäre es, wenn wir jeder Hood eine VLAN ID zuweisen, die im Kabelmesh verwendet wird?
Es wäre auf jeden Fall sichergestellt, dass Router in unterschiedlichen Hoods diese nicht per Kabelmesh verbinden.
Was wir nicht unmittelbar dadurch erreichen, ist, dass ein Kabelmesh sich in der Hoodauswahl als Einheit verhält.
Auf VLAN 0 könnte man Meta-Daten austauschen, entweder um a) das einheitliche Verhalten des Kabelmeshes sicherzustellen b) ein Layer 3 Routing durch das Kabelmesh zu fahren, z. B. indem die betreffenden Nodes am OSPF Verkehr teilnehmen, o. Ä.
Die VLAN-Trennung könnte uns schon jetzt Sicherheit vor Verbinden zweier Hoods bringen, ohne das Kabelmesh gänzlich abzuschalten.
Ansonsten, wie gesagt, nur ein kurzer Gedankenblitz, den ich sehr reizvoll finde :)
hi,
mir gefällt der Ansatz sehr, und ich glaube er könnte auch bei folgendem Problem helfen: siehe Anhnag
Gruß Malte
Ahoi,
Klingt imho sehr sinnig!
felix
On 07 Apr 2016, at 00:15, Simon Kurka via Dev <dev@lists.ffnw.de mailto:dev@lists.ffnw.de > wrote:
Hallöle,
mir kam gerade ein Gedanke, der uns evtl. relativ einfach beim Problem des Kabelmeshes in der Hoodauswahl hilft.
Ich habe es noch nicht zu Ende gedacht!!
Stichwort VLAN.
Wie wäre es, wenn wir jeder Hood eine VLAN ID zuweisen, die im Kabelmesh verwendet wird?
Es wäre auf jeden Fall sichergestellt, dass Router in unterschiedlichen Hoods diese nicht per Kabelmesh verbinden.
Was wir nicht unmittelbar dadurch erreichen, ist, dass ein Kabelmesh sich in der Hoodauswahl als Einheit verhält.
Auf VLAN 0 könnte man Meta-Daten austauschen, entweder um a) das einheitliche Verhalten des Kabelmeshes sicherzustellen b) ein Layer 3 Routing durch das Kabelmesh zu fahren, z. B. indem die betreffenden Nodes am OSPF Verkehr teilnehmen, o. Ä.
Die VLAN-Trennung könnte uns schon jetzt Sicherheit vor Verbinden zweier Hoods bringen, ohne das Kabelmesh gänzlich abzuschalten.
Ansonsten, wie gesagt, nur ein kurzer Gedankenblitz, den ich sehr reizvoll finde :)
mir kam gerade ein Gedanke, der uns evtl. relativ einfach beim Problem des Kabelmeshes in der Hoodauswahl hilft.
Ich habe es noch nicht zu Ende gedacht!!
Stichwort VLAN.
Wie wäre es, wenn wir jeder Hood eine VLAN ID zuweisen, die im Kabelmesh verwendet wird?
Es wäre auf jeden Fall sichergestellt, dass Router in unterschiedlichen Hoods diese nicht per Kabelmesh verbinden.
Was wir nicht unmittelbar dadurch erreichen, ist, dass ein Kabelmesh sich in der Hoodauswahl als Einheit verhält.
Auf VLAN 0 könnte man Meta-Daten austauschen, entweder um a) das einheitliche Verhalten des Kabelmeshes sicherzustellen b) ein Layer 3 Routing durch das Kabelmesh zu fahren, z. B. indem die betreffenden Nodes am OSPF Verkehr teilnehmen, o. Ä.
Die VLAN-Trennung könnte uns schon jetzt Sicherheit vor Verbinden zweier Hoods bringen, ohne das Kabelmesh gänzlich abzuschalten.
Ansonsten, wie gesagt, nur ein kurzer Gedankenblitz, den ich sehr reizvoll finde :)
Das ist aufjedenfall ein sehr guter Ansatz. :)
vg Tarek
Hey,
die Idee hört sich klasse an. @tarek: Kannst du sowas implementieren?
Am 07.04.2016 um 08:18 schrieb Jan-Tarek Butt via Dev:
mir kam gerade ein Gedanke, der uns evtl. relativ einfach beim Problem des Kabelmeshes in der Hoodauswahl hilft.
Ich habe es noch nicht zu Ende gedacht!!
Stichwort VLAN.
Wie wäre es, wenn wir jeder Hood eine VLAN ID zuweisen, die im Kabelmesh verwendet wird?
Es wäre auf jeden Fall sichergestellt, dass Router in unterschiedlichen Hoods diese nicht per Kabelmesh verbinden.
Was wir nicht unmittelbar dadurch erreichen, ist, dass ein Kabelmesh sich in der Hoodauswahl als Einheit verhält.
Auf VLAN 0 könnte man Meta-Daten austauschen, entweder um a) das einheitliche Verhalten des Kabelmeshes sicherzustellen b) ein Layer 3 Routing durch das Kabelmesh zu fahren, z. B. indem die betreffenden Nodes am OSPF Verkehr teilnehmen, o. Ä.
Die VLAN-Trennung könnte uns schon jetzt Sicherheit vor Verbinden zweier Hoods bringen, ohne das Kabelmesh gänzlich abzuschalten.
Ansonsten, wie gesagt, nur ein kurzer Gedankenblitz, den ich sehr reizvoll finde :)
Das ist aufjedenfall ein sehr guter Ansatz. :)
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
On 04/07/16 08:25, Stefan wrote:
Hey,
die Idee hört sich klasse an. @tarek: Kannst du sowas implementieren?
Dazu müssen wir den hood generator um ein feld VLAN ID erweitern.
Ich komme erst am Wochenende dazu. Aber prinzipiell sollte das kein Problem sein.
Es könnte sein das sich das auf die Ressourcen der Router auswirkt aber dass müssen wir testen.
vg Tarek
Moin
Das könnte ich implementieren im Hood Generator
Gruß
Johannes
Von meinem iPhone gesendet
Am 07.04.2016 um 08:30 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
On 04/07/16 08:25, Stefan wrote: Hey,
die Idee hört sich klasse an. @tarek: Kannst du sowas implementieren?
Dazu müssen wir den hood generator um ein feld VLAN ID erweitern.
Ich komme erst am Wochenende dazu. Aber prinzipiell sollte das kein Problem sein.
Es könnte sein das sich das auf die Ressourcen der Router auswirkt aber dass müssen wir testen.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Soll ich das nun machen?
Johannes
Am 07.04.2016 um 09:59 schrieb Johannes Rudolph | Freifunk Nordwest via Dev dev@lists.ffnw.de:
Moin
Das könnte ich implementieren im Hood Generator
Gruß
Johannes
Von meinem iPhone gesendet
Am 07.04.2016 um 08:30 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
On 04/07/16 08:25, Stefan wrote: Hey,
die Idee hört sich klasse an. @tarek: Kannst du sowas implementieren?
Dazu müssen wir den hood generator um ein feld VLAN ID erweitern.
Ich komme erst am Wochenende dazu. Aber prinzipiell sollte das kein Problem sein.
Es könnte sein das sich das auf die Ressourcen der Router auswirkt aber dass müssen wir testen.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
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
Hi,
mir kam gerade ein Gedanke, der uns evtl. relativ einfach beim Problem des Kabelmeshes in der Hoodauswahl hilft.
Ich habe es noch nicht zu Ende gedacht!!
Stichwort VLAN.
Wie wäre es, wenn wir jeder Hood eine VLAN ID zuweisen, die im Kabelmesh verwendet wird?
Es wäre auf jeden Fall sichergestellt, dass Router in unterschiedlichen Hoods diese nicht per Kabelmesh verbinden.
Was wir nicht unmittelbar dadurch erreichen, ist, dass ein Kabelmesh sich in der Hoodauswahl als Einheit verhält.
Das ist dann evtl. auch nicht mehr notwendig. Denn die Router könnten dann ja auch direkt ein Layer3 Routing aushandeln.
vg Tarek
-
Felix Kronlage -
Jan-Tarek Butt -
Johannes Rudolph -
Johannes Rudolph | Freifunk Nordwest
-
Malte Modler -
Simon Kurka -
Stefan