Domainsplit im Rheinufer

Die Ausgliederung der Aachener Region hat zwar Entlasung gebracht, aber der Bonus ist schon fast wieder aufgefressen durch das tägliche Wachstum.

Dass ein Netz mit mehr als 400 Nodes zu Instablität neigt und mit 800 klar „auf Messers Schneide“ balanciert werden muss (bei unendlichem Background Traffic plus faktischem Ausschluss für alle Leute mit nur „DSL-light“ ('Dorf-DSL"):
Halte ich für inzwischen als bedauerlich, aber nicht zu ändernden Fakt. (Gegenteilige Wortmeldungen mit Lösungsvorschlägen gern gesehen)

Welches wären denn die nächsten Domainsplit-Pläne für das Rheinufer?
Gibt es welche?
Wenn nein, was würdet ihr vorschlagen?

Wenn es keine lokalen Communities geben sollte, könnte man ggf. das Netz auch geographisch Teilen auf mehrere getrennte Server(-instanzen) nach "Rheinufer Nord/Süd/Ost/West, Linksrheinisch, Westrheinisch… whatever…

Hi :smile:

Vorerst ist kein Split vorgesehen, da wir noch genügend Kapazität haben.
Davon ab soll es „demnächst“ auch ein neues VPN Konzept für Gluon geben, daher würde ich das eher abwarten bevor wir Domains splitten.

Gruß
Cyrus

1 Like

„demnächst“ wird auch Batman-Adv aktualisiert. Oder ganz ausgetauscht gegen etwas Besseres.

Das hört sich für mich jedoch leider nach einem Schüttelscheck (also einem „ungedeckten Wechsel“) an.

Wenn das nicht beizeiten kommt, dann stehen wir vor einem Problem. Zumindest sollten wir uns Gedanken machen, was wir dann tun.

Oder anders: Ich teile den Optimismus hinsichtlich „noch genügend Resourcen“ nicht.
Es geht mir dabei NICHT um die Server, sondern darum, dass der Background-Traffic steigt und faktisch Leute mit einem „Limit-DSL“ selbst bei geringem lokalen Verbrauch nicht bei uns mitmachen können. Einfach weil da „30GB+“ an Grundlast pro Monat für einen MeshVPN-Node stehen, ohne dass auch nur ein Client überhaupt mal auf einer Google-Startseite war…

(Wenn wir sagen „Freifunk nur noch für VDSL-User, nicht mehr für DSL2000/DSL-Hybrid-Geschädigte“, dann ist es natürlich auch o.k.
Dann könnten wir aber schauen, ob wir für diese Leute evtl. eine eigene „Overlay“ Domain aufmachen. (die dann natürlich nicht mehr mit den anderen Meshen können.)

3 Likes

Das wird sich leider auch mit Splits nicht lösen lassen und ist nur eine temporäre Maßnahme bis auch die später abgekapselte Domain überläuft.
Limit-DSL ist ganz klar nicht für Freifunk vorgesehen, es sollte mindestens 1Mbit Upstream und 5-10Mbit Downstream für die Node zur Verfügung stehen.
Splitting ist und war immer eine Notlösung bis eine bessere Lösung da ist. Besser als ein Split wäre noch einfach die Verbindung zu den anderen Nodes zu trennen so das nur noch die Supernodes über VPN erreicht werden.

Gibt es dazu einen Github-Eintrag oder so?

Alles klar, dann sollten wir die Domäne Möhne wohl langfristig runterfahren :slight_smile:

2 Likes

Damit hast du dann aber kein dezentrales MESH Netzwerk mehr, sondern nur ein beliebiges Hotspot Netzwerk. Der Sinn und Zweck ist ja der das ich in dem Netz zum einen über Funk das Netzwerk erweitern kann, zum anderen ich auch theoretisch ohne Zentrale Komponenten einen anderen Client im Netz erreichen kann.

Wenn dann bitte nur eine Hybrid Lösung.

1 Like

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.

2 Likes

Eher „Das Bad wird mit jedem Tag exponentiell dreckiger auch wenn man sauber macht“ um bei der Analogie zu bleiben :wink:
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 :wink:

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.

3 Likes

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.

3 Likes

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.

Hab auch selten funktionierendes Roaming :wink: Wenn dann halt nur da wo die AP-Dichte auch gegeben ist und das ist (leider) fast nirgends der Fall.

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.