Das klingt jetzt nach „Wir putzen das Bad nicht mehr, da es doch spätestens übermorgen wieder dreckig ist.“
Und wenn die Ansage lautet „Kein Meshvpn für Nodes mit nicht mindestens 1MBit/s Upstream dauerstrich“, dann ist das eine klare Aussage Deinerseits.
ich würde dann schauen, welche Mesh-VPN-Nodes diese Voraussetzung nicht erfüllen und dann einen Domainsplit „horizontal“ einleiten, wo Leute mit weniger Uplink (z.B. nur DSL8000) willkommen sind.
Schließlich ist leider nicht überall DSL16000 oder VDSL verfügbar.
Eher „Das Bad wird mit jedem Tag exponentiell dreckiger auch wenn man sauber macht“ um bei der Analogie zu bleiben
Der Aufwand das zu splitten wird immer größer, es werden immer mehr Server benötigt um das ganze auch redundant zu halten. Wir haben momentan 10 Server für Rheinufer, wenn wir jetzt 50 / 50 splitten geht es noch. Allerdings werden wir immer mehr Admins brauchen, denn ich werde nicht zwei Kollisionsdomänen betreuen können da ich auch nur in einem der Netze Debugging Kapazitäten hätte.
Einfach gesagt: Um kleine DSL-Anschlüsse nutzen zu können haben wir doppelten Administrations- und Konfigurations-Aufwand.
Ich bin kein Freund von schnellen Lösungen. Vor allem wenn diese uns immer weiter in Richtung Pre-2014 FFRL Zustände drängen. (Tonnenweise Communities, nichts lief, Admins waren für die kleinen Communities nicht vorhanden oder hatten schlichtweg keinerlei Know-How)
Alternativ würde ich dir für kleine DSL-Anschlüsse einfach dazu raten nur eine VPN Verbindung aufzubauen anstatt 2. Das halbiert das Grundrauschen
Wäre jetzt auch nur eine Übergangslösung wie der Split selber, allerdings mit wesentlich weniger Aufwand und daher eher bevorzugt als die ganzen Domain zu splitten.
Sinnvoller wäre es das Konzept wie LibreMesh zu implementieren:
Im Ruhrgebiet splitten wir deshalb nicht die Domäne in kleine zentrale Stücke, sondern splitten Communities aus, die sich dann selber um die Server kümmern.
Die ausgesplittete Community (Sub-)Domäne hängt dann per GRE hinter der (Haupt-)Domäne.
Baut Wissen auf und entlastet die Admins der (Haupt-)Domäne.
Das skaliert und lässt sich bei Bedarf innerhalb der Subdomäne weiter verästeln.
Genau das möchte ich verhindern denn es schafft ein kaum überschaubares Chaos. Daher werden wir vorerst keine Pläne für einen Split verfolgen und das vorhandene System optimieren.
Der Split war wie ich oben schon schrieb damals schon eine provisorische Lösung da wir eben nicht mehr in Richtung des Pre-2014 FFRL Konzeptes gehen wollen.
Wenn eine Community sich aus anderen Gründen abspalten möchte habe ich da natürlich generell nichts gegen. Dies beinhaltet aber wie @CHRlS schon schrieb das diese Domain dann auch dedizierte Admins bekommt.
Ich hoffe, dass wenn der Bedarf nach Admins klar formuliert wird, sich dafür auch Personen finden werden.
Und gerade in einigen „Ecken“ des Netzes sehe ich durchaus auch Potential. (Oder umgekehrt formuliert: Eine gut arbeiten Zentraninstanz sorgt auch dafür, dass sich kaum jemand „vorwagt“. Wenn der Laden doch gut geführt wird. Und gerade bei den Admin-Affinen Leuten ist ja in der Regel auch schnelles Internet daheim, daher dann auch kein Leidensdruck für einen Domainsplit).
Oder ganz klar anders formuliert: Ich habe wegen der Grundlast der Rheinufer-Domain „Körbe“ für VPN-Uplink bekommen.„Router an Strom: o.k… Aber kein MeshVPN“ Das war nach wenigen Tagen wieder aus, weil trotz Bandbreitenbremse die Leute es nicht ertragen haben, dass in ihrer Zwangsrouter-Statistik plötzlich ein 80%-Traffic-Verbraucher nachems Freifunk auszumachen war.
Da hilft danna uch alle „Du hast doch eine Flatrate“-Argumentation nicht. Da ist dann plötzlich der Freifunk daran schuld, jedes Mal wenn das Internet gefühlt „langsam“ ist.
Jetzt kann man natürlich sagen „Wer nicht will, der will eben nicht“ und „wer nicht will, der hat schon“. so eine Antwort könnte jedoch auch als Arroganz ausgelegt werden.
In Aachen haben wir angedacht einen etwas anderen Weg zu gehen.
Da wir mit vier (wegen fehlender gre Tunnel eigentlich mit einem) Supernodes 1.000+ Clients und 450+ Nodes versorgen und die Supernodes weiterhin nur müde Lächeln.
Nach meiner Einschätzung treiben die Clients den Hintergrund Traffic ähnlich wie die Nodes.
Wir denken nun darüber nach analog zu Wupper mehrere Kollisionsdomänen auf den Supernodes zu betreiben, nur eben mit layer 3 Segmentierung. Das verspricht effektiv die Ressourcen der DSL Leitungen zu schonen ohne übermäßig mehr Arbeit in die Infrastruktur zu stecken.
Habt ihr denn Graphen zu eurem Hintergrund Traffic, hier wäre mal zum Vergleich ein Knoten der nur bei Veranstaltungen belastet wird, aber grundsätzlich nicht zwei weitere per Mesh versorgt. Ich finde das ist zumutbar:
Zu erkennen ist die Abhängigkeit von der Benutzer Zahl in der Domäne, denn die Nodes schwanken nicht so stark nach Uhrzeit.
Ich verstehe die Problematik die du darlegst, ich widerspreche dir auch nicht das die Grundlast zu hoch ist. Aber aus technischer Sicht ist es eben Humbuk das System so aufzuzwirbeln aufgrund von subjektiven Meinungen der potenziellen Aufsteller.
Generell geht hier immer der technische Aufwand und die technischen Möglichkeiten sowie deren Aufwand vor wenn es gilt so etwas zu entscheiden.
Wir brauchen Konzepte die das Grundrauschen auf das absolute Minimum reduzieren ohne temporäre Umwege über Splits usw.
Wenn eine Lösung Zeitnah benötigt wird sollten wir diese für diese speziellen Fälle individuell erarbeiten. (z.b. nur ein VPN-Tunnel aktivieren)
Ja das habe ich auch bemerkt, bei uns sind es teilweise auch Nodes die ohne Filter betrieben werden die den Traffic in die höhe treiben.
Es wird wohl über kurz oder lang nicht mehr möglich sein ein reines Layer2 Mesh zu betreiben, was auch der Grund ist weshalb ich generell gegen eine vorläufige Lösung bin und lieber ein Konzept erarbeite was z.b. wie bei Libremesh den Exit/Supernode Traffic via Layer3 abhandelt.
In IPv6 kann ich mir das durchaus vorstellen, aber bei IPv4 ist das Routing dermaßen statisch, dass roamende Clients zwischen lokalen Wolken eine echte Herausforderung werden.
Daher Suche ich im Moment erstmal nach einer Möglichkeit die bestehende Struktur leichter skalierbar zu machen.
Bei V4 könnte man evtl mit Anycast Routing arbeiten (z.b. eine dedizierte Mac-Adresse die nur im Scope Node<-> Client gültig ist und die IP des Supernodes hat). Aber das wäre eher Stoff für einen Workshop oder eine Mumble-Session.
IPv4-Roaming war billig zu haben.
Aber wer braucht das wirklich? Das könnte man meiner Meinung nach von heute auf morgen rauswerfen.
Und selbst wenn man es mit einer flachen RFC1918er nicht bekommt, weil die DHCP-Server ihre pools lokal bewirtschaften: So what, dann wird halt auch nochmal lokal geNATed.
Wer Dienste anbieten will für die Wolke, der kann jederzeit IPv6 machen.
Mal ganz ehrlich… unsere Clients wechseln doch sowieso träger die Uplinks als die singende Kirchengemeinde im Ostergottesdienst die Orgel auszubremsen versucht… Wir haben eben keine Wifi-Controller, die aktives Steering betreiben.
Wir haben keine Lösung.
Die Lösung heisst derzeit: „Berliner Modell“: „Wenn’s Dir hier nicht passt, dann geh’ doch woanders hin“
Du sprachst von „1MBit/s Upstream für Freifunk“.
Ich kenne viele Leute, die haben nur 700kBit/s Gesamt-Upstream.
Und selbst Anschlüsse mit nur 1MBit/s Gesamt-Upstream sollen noch recht verbreitet sein.
Mag sein, dass Du in einer wohlhabenden Ecke mit optimaler Breitband-Versorgung wohnst.
Meine Anfragen zu Freifunk erreichen mich aber aus Gebieten, wo man sich freut, dass es überhaupt Internet gibt und man das auch gern teilen möchte.
In der Domäne Ruhrgebiet geht es uns auch eher um Ausbau der Admin-Belegschaft und den Aufbau genau der chaotisch benannten Layer3 Baumstruktur, um dadurch automatisch möglichst kleine Mesh-Zellen zu bekommen.
Aber die wichtigste Komponente dabei - zumindest für mich - sind die lokalen Admins, die mich dadurch automatisch um ganze Städte entlasten, denn das resultierende reine Layer3 IP-Routing ist (nahezu) wartungsfrei.
Ich teile eigentlich alle Ansichten bis hierhin. Vor allem sind die Vorschläge für mich erst einmal gar nicht konträr. Wir können neue Leute einarbeiten, Segmente unter autonome Verwaltung stellen und technische Dinge tun – alles gleichzeitig.
Wenn wir die einzelnen Wolken nicht mehr per VPN meshen, dann wird sich der BATMAN-Traffic deutlich verringern. Für die User würde kein merklicher Nachteil entstehen, vermute ich. Wenn zwei Wolken nicht meshen ist es unwahrscheinlich, dass Clients dort roamen wollen.
Der Traffic zwischen den Standorten einer Domäne sollte selbstverständlich geroutet werden und weiterhin ungehindert fließen.
Jo klar Administratoren sind wichtig, aber es gibt auch einen Break-Even Point wo es zu viel wird.
Wichtig ist ein Configuration Management und Resourcen fürs Debugging. Administratoren sollten im besten Fall nur für Debugging auf auf die Shell der Supernodes verbinden müssen.
Aber wie gesagt, ich möchte lieber ein Konzept erarbeiten was möglichst komplett ohne Split auskommt (Es sei denn die V4 Adressen in dem Subnet gehen aus ;))
Egal welches Konzept sich heraus kristalisiert. Der Knoten Setup muss einfach bleiben. Sprich keine IP Adressen über Wikis oder so verteilen um am Netz teilzunehmen.
