Der der schön kleinen Segmente ist bei 841ern mit nennenswert Nutzern gut zu erkennen:
Zahl der Clients:
Load:
Nur der Traffic geht hoch:
und bei der fastd Belastung auf dem Supernode der primär herhalten muss kann man es auch schon gut erkennen:
Die Zahle der Knoten in den Segmenten steigt langsam an:
Hier eine kurze Anleitung mit den nötigen Schritten um per ssh auf aktuelle experimental zu wechseln:
uci set autoupdater.settings.branch=experimental
uci set autoupdater.settings.enabled=1
uci commit autoupdater
echo 1 > /lib/gluon/release
uci set wireless.client_radio0.disabled=1
wifi
autoupdater
Das Client wlan wird fürs autoupdate abgeschaltet da es dann zu 100% zuverlässig funktioniert hat. Mit >20 Clients habe ich sonst teils mehrere Anläufe benötigt.
Außerdem definiere ich das aktuell die Firmware Version 1 läuft (mit dem echo >1) nur so wir wenn aktuell eine stable Firmware läuft die experimental als neuere Version akzeptiert.
Hi,
ich finde die Idee der dynamischen Segemntierung richtig klasse und würde gerne mit testen. Im Zugriff habe ich meinen lokalen Freifunkrouter (ffach-Gressenich-Bergerhof27-uplink) , der per Mesh on LAN ffach-Gressenich-Bergerhof27 bedient und dieser wiederrum über das WLAN mit ffach-Gressenich-Feuerwache vermeshed ist.
Reicht es aus den Uplink (der einzige mit Internetzugang) auf experimental zu ziehen, damit das meshen mit den anderen beiden noch funktioniert?
Oder muss ich die Kette von hinten bedienen. Also erst die Feuerwache hochflashen und zuletzt den Uplink?
Es ist genau anders herum. Die fastd Verbindungen haben wir in der Firmware schon recht lange eingeplant.
Ich war nur bisher die Hoffnung den IPv6 Prefix den die Knoten Verteilen nicht ändern zu müssen. Inzwischen sind wir der Meinung dies nicht vermeiden zu können und haben daher einen neuen Prefix für die Knoten festgelegt.
Es müssen also alle Knoten die Clients bedienen über die neue Version verfügen, reine offloader können auf Beta und Stable bleiben.
Die Beta Version baue ich jetzt, ich strebe eine Verteilung in der Nacht von Sonntag auf Montag an.
Ok, dann sollte ich erst die Feuerwache und dann den Bergerhof27 auf experimental updaten und den Vorgang im github dokumentieren?
Aktualisieren sich diese experimental Knoten später von alleine auf die Beta?
Oder sollte ich noch was abwarten und direkt mit der Beta anfangen?
Nein, die Benennung der experimental ist leider diesmal so, dass man den Autoupdate auf experimalt sellen muss damit die Firmware sich nicht direkt zum aktuellen Beta/Stable ändert. Das mache ich in Zukunft wieder sinnvoller.
Die Beta ist seit eben im Bau, das dauert nicht lange. Ich würde an deiner Stelle kurz warten.
Ich habe die Beta8 nun auf einem Ubiquiti Bullet M und einer TP-Link TL-WR1043N/ND v2 installiert. Beide sind online und meshen mit ihren Kollegen auf Stable.
Sobald die Kollegen auf Stable sich das update gezogen haben kannst du auch in ein neues Segment.
@HOJAC hat inzwischen schöne Shapefiles für die bezugsbereiten Segmente 02-07 angefertigt:
Knifflig wird die Unterteilung des Stadtgebiets:
Gibt es Bedenken wegen dieser Aufteilung?
Ich bin schon sehr gespannt auf die automatische Verteilung, nun erstmal gebanntes warten aufs Autoupdate. Dienstag sollten es die meisten Knoten erhalten haben.
Irgendwelche Bedenken bezüglich der Grenzen wird es immer geben. Die Unterteilung von Aachen Innenstadt und Aachen Stadt Randbezirke ist sicher wegen der vielen Nodes sinnvoll.
Beim Umland würde ich es gut finden, wenn sich die Städteregion Aachen, der Kreis Düren und der Kreis Heinsberg klar trennen würden. Vielleicht wollen die Dürener/Heinsberger auf lange Sicht eigene Supernodes betreiben und dann wäre es gut, wenn das Gebiet entsprechend abgesteckt wäre? Auf jedenfall muss man sich so die Frage gefallen lassen, warum die Landkreise vermischt sind.
Dementsprechend würde ich das Segment 6 im Kreis Düren belassen und Würselen, Eschweiler, Alsdorf, Herzogenrath und Baesweiler entweder in ein neues Segment stecken oder zu dem Aachener und Stolberger Segment hinzufügen. Der Kreis Düren bestände dann aus zwei Segmenten und die Heinsberger hätten eines.
Anbei zwei Karten aus der Wikipedia mit den entsprechenden Landkreisen:
Ich bin schon gespannt wie gut das künftig laufen wird. Vermutlich wäre die Aachener Segmentierungstechnik auch was für andere Communities.
Ja, die Segmentierungs nach „Verwaltungsbereichen“ wäre auch eine Überlegung. Im Moment haben wir uns eher an geographischen Meshbarrieren orientier (Autobahnen und grüne Landstriche).
Wobei der riesen Vorteil an dem angestrebten System ist ja auch, dass eine spätere Umgestaltung „einfach automatisiert“ durch verschieben der Segmentgrenzen durchgeführt werden kann und die Nutzer es im Idealfall nicht mal bemerken.
Würde auch erstmal vorschlagen wir orientieren uns erst daran wie es technisch am besten läuft um die Kinderkrankheiten besser abfangen zu können (dazu braucht man z.B. kleine Segmente, damit Kurzschlüsse nicht ganz so schlimm sind).
Wenn Düren dann konkret eigene Supernodes allein für Kreis Düren betreiben möchte ist es natürlich noch möglich von Hand einen geographischen Bereich rauszuschnitzen.
Die Segmente sind in der Tat alles andere als statisch.
Im Stadtgebiet Aachen ist definitiv mit Knoten zu rechen die über die Grenzen hinweg meshen, diese werden dann in eines der beiden Segmente verschoben.
Technisch ist es ohne weiteres zu realisieren einzelnen Segmenten zusätzliche Supernodes hinzuzufügen die lokal finanziert werden.
Wir haben sogar schon zusätzliche Supernodes in der Firmware die nicht existieren. Schlicht als Reserve.
Momentan sind 50% unserer IPv4 Adressen in unserem default Segment gebunden. Die anderen habe ich jetzt komplett auf die Segmente 02-07 verteilt. Sobald ein Großteil der Knoten verschoben ist soll das default Segment auch nur noch ein /20 Netz haben. Wir haben also bald wieder Raum für weitere Segmente. 1,8,9,10 sind schon in der Firmware. Doku im Wiki:
https://wiki.freifunk.net/Freifunk_Aachen/IP-Adressen
Ok, dann halten wir fest, dass die Aufteilung rein technisch ist und mit wenig Aufwand geändert werden kann. Dann kann es gerne (meiner Meinung nach) so bleiben und die Orientierung an natürlichen Grenzen (Wald, Autobahn) ergibt natürlich auch Sinn. Wenn ihr einen Blogeintrag für den Rest der Welt schreibt, sollte mit 2-3 Sätzen vielleicht erwähnt werden, warum die Grenzen so sind und das sie bei Bedarf verschoben werden können.
Also meinen Segen habt ihr 
Die meisten Knoten mit kompatibler Firmware die auf der Karte in einem der Segmente auftauchen oder mit einem dieser meshen sind nun in den Segmenten.
Anzahl der Knoten nach Segmenten:
default.value 165
segment-02.value 191
segment-03.value 164
segment-04.value 163
segment-05.value 143
segment-06.value 184
segment-07.value 151
Die Last verteilt sich nun auf diverse fastd Prozesse:
Die gesamt load pro Kern (von je 4) ist dabei auf den Supernodes mit schwächerer CPU etwas gestiegen. Diese bedienen nun aber auch viel mehr Knoten als zuvor. Dafür ist auch der Traffic Richtung Exit Nodes nenneswert höher, ohne einen entsprechenden Anstieg des gesamt Traffics. Unser prozentualer Overhead ist also geringer geworden.
Falls sich jemand fragt, wieso das Default-Segment noch so voll ist:
Einerseits sind dort im Moment noch alle Knoten die keine Geo-Koordinaten haben und auch keine Mesh-Partner haben durch die man auf eine Position schließen kann. Das ist ca. die Hälfte.
Die andere Hälfte sind inkompatible Firmwares, meist weil die Leute den Autoupdater abgeschaltet haben, oder auch weil Eigenbau im Einsatz ist. Diese Leute sollten dringend eine neue Firmware flashen, weil sie sonst bald keinen Zugang mehr zu unserem VPN haben werden!
Anleitung zur Reaktivierung des Autoupdaters: Howto: Autoupdater aktivieren - Technik Freifunk Aachen
(Dieser drastische Schritt wird notwendig weil wir die IP-Netzstruktur komplett umgemodelt haben, und wir nicht das alte ac01 Legacy-Netz auf ewig drin haben wollen. Außerdem würde ein solch alter Knoten der mit einer neuen Wolke mesht die gesamte Wolke notgedrungen ins Default-Segment ziehen.)
Ebenfalls betroffen sind die TP-Link WR841 v10, da wir für diese nur eine master-Branch-Firmware als Übergangslösung zum Download angeboten haben, aber auf Autoupdate verzichtet haben. Das sollte mit dem nahenden Release von Gluon 2016.1 aber spätestens behoben sein, dann kriegen die ebenfalls ihr Autoupdate.
Die 2016.1 ist ja seit Kurzem verfügbar. Wann rechnet man damit die Segmentierung abgeschlossen zu haben?
Wenn sich jemand erbarmt den Algorithmus zum automatisierten Knotenschubsen zu entwickeln.
Ansonsten läuft die Segmentierung ja schon (sind auch schon alle Knoten aufgeteilt), nur werden Kurzschlüsse von Hand behoben.
Hat aber nichts mit der 2016.1 zu tun, die wird unabhängig vom Segmentierungsfortschritt ausgerollt.
Die 2016.1 als experimental liegt hier:
https://images.aachen.freifunk.net/experimental/
Als Beta folgt sie in den kommenden Tagen, wenn wir unseren neuen Build Server verwenden können. Stable wenn sich die Beta bewährt hat.
