Guckst Du hier: Nebeneinander von geographisch überlappenden Communities - #52 von CHRlS
Und guckst Du hier: Performance-Probleme - #8 von nomaster … wird klar, daß der Split innerhalb Eurer Domänen keine Frage des „ob“, sondern nur noch des „wann“ ist. Performance-Probleme - #19 von adorfer ist auch sehr aufschlußreich.
Unbegreiflich, ja unverantwortlich, daß sehenden Auges an der Totgeburt der globalen SSID festgehalten wird.
Okay, vielleicht hilft ja eine Wiederholung, Wiederholung:
Den Punkt kann man zwar ignorieren, wenn er die eigene Argumentation kippt, das macht es dann aber nicht richtiger 
1 „Gefällt mir“
Wenn Du lesen würdest, was man Dir erwidert, wäre es einfacher. Aber ich kann es gerne wiederholen, vielleicht klappt’s ja diesmal:
Um Deine These zu retten, erkläre doch bitte, wie Du in der unmittelbaren Nachbarschaft zweiter unterschiedlicher Kollisionsdomänen (andere IP-Ranges, andere Exits), die die gleiche SSID nutzen, einen „link down“ beim Endgerät, welches ja nur den AP im gleichen BSS wechselt, erzeugst?
Ich verstehe offensichtlich die Frage nicht.
Du meinst wenn man sich zuhause auf den Wohnzimmerschrank 2 Geräte aus 2 unterschiedlichen Kollisionsdomänen hinstellt, so dass man beide unmittelbar in Empfangsreichweite hat?
Moin,
da ich hier häufiger zitiert wurde, möchte ich auch den Satz wiederholen, der nicht zitiert wird:
Eine Entscheidung sich zwei Geräte aus zwei unterschiedlichen Kollisionsdomänen ins Wohnzimmer zu stellen, ist genau so sinnvoll, wie bewusst ein Gerät von Domäne A in eine Umgebung zu stellen, in der schon Geräte von Domäne B stehen.
Ich sehe übrigens ein, dass man hier zu keiner Einigung kommen wird. Ich bastele die Software für Warendorf weiter mit Freifunk und nehme soweit Rücksicht auf andere, wie man es von mir erwarten kann.
1 „Gefällt mir“
Ich meine, daß ein Nebeneinander unterschiedlicher Setups mit der gleichen SSID ein Bug und kein Feature sind.
Correct me if I’m wrong: Derzeit packt Ihr meinem Verständnis nach alles, was in einer ‚Domäne‘ ist, in eine Broadcastdomain/ein Mesh. Und Ihr nutzt auch für unterschiedliche Domänen die gleiche SSID. Diese Domänen befinden sich in dicht besiedelten Gebieten und grenzen z. T. unmittelbar aneinander (lt. der Karte, die Du mal erstelt hast). Ferner ist es ein eher offenes Geheimnis, daß one mesh fits all irgendwann (Hamburg oder Paderborn dürften mit die ersten sein, die das Limit ausloten) nicht mehr funktioniert. Die derzeit – imho – wahrscheinlichste Lösung zur Verringerung des Größe des Meshs/der Wolke/der Broadcastdomain ist der Split.
Daraus ergibt sich für mich:
Punkt 1: Verschiedene Domänen dürfen sich nicht auf Funkreichweite annähern, da sonst die Prämisse „carrier loss => neuer DHCP Request“ nicht mehr greift: der Client wird faktisch bis zum halben DHCP-Timeout disconnected. obwohl er eine Verbindung anzeigt.
Punkt 2: Knoten unterschiedlcher Domänen dürfen nicht in Funkreichweite aufgestellt werden. Das ist in etwa Dein Wohnzimmerschrank-Beispiel, nur daß das in der Realität imho durchaus vorkommen kann — Realwirtschaft orientiert sich nicht zwingend an Domänen- oder Ortsgrenzen, weshalb z. B. Gütersloh als auch Paderborn über lokale Ketten Knoten in anderen „Hoheitsbereichen“ haben. Mit unterschiedlchen SSIDs (jeweils der Fall) kein Problem, auch bei einem späteren Ausbau der „Heimatcommunity“ nicht. (Fremdkörper bleibt Fremdkörper, aber er schadet nicht.)
Punkt 3: Skalierung. Ich kenne die Hintergründe zu Eurer grade aktuell im Kontext Wupper/Troisdorf „diskutierten“ design decision nicht. Daß Ihr in Probleme reinlauft, ist aber – imho – dokumentiert. Während Punkt 1 ja noch irgendwie steuerbar ist (theoretisch), wie wollt Ihr einen Split so vornehmen, daß eine Funklücke zwischen den neuen Broadcastdomains bleibt? (Und wie das FW-Update steuern? Frage aus echtem Interesse, denn wir stehen für die Nachbarstadt vor dieser Frage – wir möchten nicht in die „Gluon-Falle“ tappen und daher nun zumindest per Stadt, später, wenn es wirklich einschlägt, notfalls per Stadtteil, zumindest unterschiedliche fastd-Instanzen nutzen, ggf. auf unterschiedlichen KVMs.)
Aus u. a. diesen Gründen halte ich eine SSID für keine wirklich tolle Idee. Ja, klar ist es doof, wenn man in jedem Kaff eine neue SSID einmalig aktivieren muß; andererseits bekomme ich für einen Klick free WiFi, mir ist das diesen kleinen, einmaligen Umstand durchaus wert. Und natürlich kann man das konstruiert nennen; bei der „Einflußkarte“ allerdings scheint mir die Konstruktion nur noch ein wenig an der Realität vorbei zu sein, und was die Wachstumsthematik angeht, ist die Realität imho schon weiter. Und was Punkt 2 angeht: das ist real, wie freifunk-karte.de zeigt.
Das waren die ursprünglichen Hintergründe und Überlegungen für das Domänen Design: Freifunk Rheinland e.V.
Vor meiner Zeit beim Freifunk Rheinland e.V., entsprechend wenig kann ich aus erster Hand dazu sagen.
Aus meinem Verständnis aus allen Infos und Gesprächen ist die Kurzzusammenfassung:
Insgesamt soll die Community vor Ort durchaus verantwortlich für die Community und das Geschehen vor Ort sein, aber die Einstiegshürden sollten entfallen, Ressourcen besser genutzt werden durch Konsolidierung von Ressourcen (menschlicher und materieller) und Langzeitstabilität geschaffen werden, auch wenn vor Ort mal Leute weg brechen.
zu 1 u. 2)
So nah ist bei uns nichts aneinander, im Endeffekt ist das aber durch den Lease Timeout steuerbar…
Wir haben 1.200 Router quer durch NRW, Albufer in Karlsruhe, bald sogar Möhne in Hessen verteilt. Wenn Du Dir vorstellst wie groß das Gebiet ist, dass die Map so schön abgedeckt anzeigt, dann kannst Du Dir vorstellen wie groß die Lücken zwischen den Communities und Routern sind.
Zwar sind häufig in den Grenzgebieten Router ausgerechnet nah aneinander, aber da sprechen wir immer noch über Kilometer.
Zu 3) die Probleme im Rheinufer in den letzten Wochen hatten viele Gründe. Von Tests für das Rheinland Backbone bis hin zu Skalierungsproblemen, in der Form, dass die dafür festgelegten Grenzwerte Anzahl Nodes zu Anzahl Supernodes komplett vollständig überschritten waren. Im Falle Rheinufer kannst Du nicht 300 Router mit VPN Mesh für 400 Router in der Wolke über 2 vServer drücken, dann ist halt irgendwann schluss mit lustig…aber das wurde/wird schon nachgezogen…
Aufgrund der jüngsten Ereignisse sehen wir (Domäne Ruhrgebiet) uns mit unseren 500 Routern nun jedoch weniger bis gar nicht mehr an das festgelegte Design gebunden.
Entsprechend beratschlagen wir derzeit im Hintergrund einen Umbau.
Ich möchte zum jetzigen Zeitpunkt noch nicht zu sehr in die Details einsteigen, aber anhand der bereits offenen Punkte und des letzten Brainstormings könnte es in diese Richtung laufen:
- Änderung im Gluon zur Auswahl der Community im LuCi Frontend, dies legt die Ports der entsprechenden fastd Instanz fest
- automatisierter Scriptgesteuerter Split aller Communities in eigene Kollisionsdomänen, über ein Script auf dem Router, welches ersten Punkt automatisiert bestimmt und festlegt
- mittels Script auf den DNS Servern besseres Loadbalancing der Supernodes (VPN Gateways), anhand CPU Last und Tunnelmenge
Die Domäne würde dann noch wie bislang eine organisatorische Einheit abbilden und die Technik stellen, aber keine eigene Kollisionsdomäne mehr haben, sondern nur noch die Kollisionsdomänen der einzelnen Communities betreiben.
Aber wie gesagt, alles weder beschlossen noch im Detail ausgearbeitet, dies steht bislang nur als eine mögliche Idee im Raum.
Auf die zentrale SSID würde dies jedoch keinen Einfluss haben, sondern lediglich unsere Skalierungsgrenze ein wenig verschieben.
3 „Gefällt mir“
Etwas OT, aber das wollte ich schon länger fragen: "dass die dafür festgelegten Grenzwerte Anzahl Nodes zu Anzahl Supernodes komplett vollständig überschritten waren" -- woher habt Ihr diese Zahlen, gibt's die Formel öffentlich? Weil: mit unseren popeligen 150 Knoten mit im Peak heute 420 Clients fühlt es sich zeitweise zäh an, und z. T. ist auch die RTT statt bei ca. 60 bei >200 ms, sodaß ich mich frage, ob wir auch schon >2 GWs *brauchen*.
Guten Rutsch!
Ne generelle Formel gibt es dafür leider nicht, da es immer auf das Nutzerverhalten in der jeweiligen Community ankommt.
Wenn nur das Whatsapp von 300 Leuten beim Bäcker bedient wird, ist das eben ne andere Hausnummer, als wenn 300 Leute mit ihrem Notebook surfen und nochmal ne andere Nummer als wenn 300 Leute darüber zocken und erst recht wenn 300 Leute downloaden im schlimmsten Fall Torrents.
Die Mischung des Userverhaltens bestimmt dann unterm Strich wie ausgelastet die Tunnel und Server sind.
Bei uns im Ruhrgebiet hat sich als gut stimmender Faktor unterm Strich ergeben, wenn wir nicht mehr als 100 Node Tunnel pro Server annehmen. Durch unser derzeitiges Verhältnis von Routern mit VPN Uplink zu Routern im Mesh only von ca. 1,4:1 ergeben maximal 100 Tunnel dann einen Wert von (100*1,4)/2 (weil jeder Router 2 Tunnel aufbaut) also maximal 70 Routern pro Gateway.
Wir haben übrigens derzeit einen durchschnittlichen Maximalwert von 1,5 Clients pro Router, ihr vermutlich 3 Clients pro Router. Wenn man das einfach mal ins Verhältnis setzt würde das bei uns 105 Clients pro Gateway als zulässigem Maximum entsprechen…420/105=4 Gateways bräuchten wir bei uns, damit es die Leistung nicht runter zieht.
Das kann für euch so stimmen, kann aber auch vollkommen unterschiedlich sein, wenn die Clients weniger „konsumieren“…
2 „Gefällt mir“
Vielleicht wäre ein an tr-069 angelegte Konfiguration auch was: die Knoten landen erstmal in einer default Umgebung und werden dann aufgrund von bestimmten Parametern umkonfiguriert. Nur so als Idee.
Paulo.
Ich hoffe schlicht, dass eine echte TR.69-engine wegen der Größe der dafür notwendigen XML-Libraries schlicht nicht mehr in die 4MB-Flashes der zu gefühlt >95% verbreitten Plasterouter passt.
1 „Gefällt mir“
Halt was ähnliches, dass wie uci aussieht … Mit Opt-In natürlich 
So hochspannend ich das Thema auch finde (siehe auch Gluon-Liste), mit „Nebeneinander von geographisch überlappenden Communities“ hat die selektive (Re-)Konfiguration von Knoten mehr so nix mehr zu tun, oder?
Die Eingangsfrage ist beantwortet, daß …
… vielleicht nicht so klug ist, wie es sich auf den ersten Blick anhört, wurde auch erörtert …
… und bedeutet, auf die Eingangsfrage betrachtet, „solange ›Freifunk NRW‹ nicht auch die SSID ›Freifunk‹ sendet, funkt man ‚nur‘ aneinander vorbei — bei identischer SSID würde man Nutzer aktiv stören können durch parallelen Ausbau. Bei identischer Mesh-Konfiguration wären eher nicht-positive Effekte zu erwarten, wenn man sich auf Funkebene träfe“.
Offen wäre im Kontext vielleicht noch ob/wie man sich da koordiniert, aber da es schon reicht, nicht „Freifunk“ als SSID zu nutzen, ist die Frage eher was für Stammtische.
Inwiefern es generell sinnvoll ist, daß man Aktivitäten zersplittert, muß jeder vor Ort selbst entscheiden. Ich habe „unseren“ Ostenfelder Freifunker auf mögliche Kontaktaufnahme aus Münsterland vorbereitet, ob es da Gespräche gab, weiß ich nicht; seine Knoten sind jedenfalls z. Zt. noch „bei uns“. Dafür habe ich nichts mehr vom Interessenten aus SHS gehört, dafür einen Tweet der Bielefelder gesehen, daß dort ein an BI angehängtes Netz entstünde.
Relevant ist meines Erachtens, daß sich in einem Ort, einer Stadt ein schlagkräftiger fester Kern von Freifunkern bildet. Welcher anderen Organisation sie sich anschließen oder ob sie gänzlich ihr eigenes Ding drehen, ist imho nebensächlich, nur die Technik sollte dem nicht generell entgegen stehen (sprich: bitte community-lokale SSID verwenden; daß Kanal & Mesh-BSSID übereinstimmen, wäre arger Zufall und ggf. ebenfalls nix gut). (Und mittelfristig denke ich, allen Dezentralisierungsideen um Trotz, doch, daß sich Gruppen bilden, die mehrere Freifunknetze/Regionen technisch betreuen, einfach, weil Arbeitsteilung irgendwann Sinn macht und lokal Freiräume schafft. Siehe heute schon Nordwest, Franken oder NRW/Rheinland; Bielefeld scheint auch auf dem Weg zu sein.)
lest mal zur Ergänzung hier:
https://forum.freifunk.net/t/zwangsmitgliedschaft-im-verein-nrw/1069/74