Hallo zusammen, im Blog auf der ffac Webseite hat es im November eine kleine Hochwassermeldung gegeben. Ist das noch akut? Ist der Zustand immernoch schlechter als gewünscht? Sollte man aktuell immernoch davon absehen, mehr Geräte aufzustellen? Oder könnte man dort mal ein positives Update posten?
danke und ciao,
lImbus
Hi, das positve Update war am Rande in unserem Spendenaufruf drin 
Genau genommen wurde das akute Performance-Problem bereits drei Tage nach der offiziellen Meldung gefixt. Ein Server war total am Anschlag, und ein Wechsel von Opteron-Prozessor und OpenVSwitch auf einen aktuellen Intel-Prozessor mit VMWare Hypervisor hat das Problem behoben, sodass es wieder annehmbar performt. Danach wurde nicht mehr am Produktivsystem rumprobiert, um die Ursache genau einzugrenzen.
Wir können aber weiterhin nicht unbegrenzt wachsen, bis das neue Segmentierungssystem läuft, welches die Regio Aachen dynamisch in per Layer 2 verbundene (aktueller Planungsstand, wenn das nicht reicht, kann man immer noch Layer 3 Routing einführen) kleine BATMAN-Domänen splitten wird. So muss man nicht mehr bei Domänensplits die Firmware wechseln, außerdem können beliebige Regio Aachen nodes miteinander meshen (ggf. werden dann die gefundenen Nachbarn automatisch in das selbe Segment verschoben).
ETA gibts leider keine, die Suche nach zusätzlichen Helfern war aber auf dem CT gestern Thema.
Außerdem kleiner Status: Da Alfred auf manchen Internetanschlüssen nicht mehr durchkommt, vermuten wir, dass der Wasserstand auf der Karte nicht stimmt. Dort sind 1000 Knoten online, aber wir haben über 1200 BATMAN originators. Also sind 200 Knoten für die Karte unsichtbar, nehmen aber nach wie vor am Freifunknetz teil.
Gibt es irgendwo eine Doku oder Erklärung zu dem Verfahren? Würde mich sehr interessieren.
zu den 1000 zu 1200 …
da hilft Alfred compilieren das nicht nach 10 Minten schon vergisst … das hat bei uns fürs erste geholfen, also TIMEOUT in der alfred.h (??) glaub von 600 auf 1800 gesetzt.
Ist halt alles noch in Planung. Ich kann aber mal versuchen ins Detail zu gehen, wie der aktuelle Stand ist.
Die Segmentierung erfolgt durch einen Hack mit fastd-Whitelists/Blacklists, die dynamisch generiert werden.
In der site.conf sind bei uns aktuell für jeden Node 100 fastd-Endpunkte eingetragen, aufgeteilt in 10 Gruppen. Der Knoten wird also versuchen, zu jedem dieser Endpunkte eine Verbindung aufzubauen.
Das „Segment 0“ lässt jeden rein, sperrt aber nach Blacklist aus, alle anderen lassen nur per Whitelist rein.
Ein uns noch unbekannter Knoten wird also jetzt verschiedene Segmente ausprobieren und irgendwann in Segment 0 akzeptiert werden, das einzige was ihn bis jetzt aufnehmen würde.
Dann wird nach einer noch zu bestimmenden Logik der Knoten einem anderen Segment zugeordnet. Also in Segment 0 in die Blacklist kommen und in genau einem anderen Segment in die Whitelist. Größtenteils wird das nach Geo-Koordinaten gehen.
Da wir für alle Segmente eine Firmware nutzen ist das Meshing immer möglich. Also ist eine automatische „Kurzschluss“-Erkennung nötig, die erkennt wenn zwei Segmente miteinander verkoppelt werden. Das würde ja dazu führen, dass BATMAN-Originators ausgetauscht würden, und Traffic zwischen Segmenten über eine dünne Uplinkleitung statt über die Supernodes fließen würde. Probleme mit DHCP gäbe es auch.
Und als ob das noch nicht genug wäre, darf diese Zuteilung auch nicht zu streng sein. Man stelle sich den Fall vor, wo jemand für verschiedene Segmente Knoten fertig macht, inkl. Geodaten, die aber alle testweise bei sich im Keller funken lässt. Da würde natürlich die Kurzschlusserkennung anschlagen und alle in das selbe Segment stecken. Wenn aber alle vor Ort im Einsatz sind sollten die natürlich zeitnah wieder in die „natürlichen“ Geo-basierten Segmente finden.
Die fehlende Entwicklungsarbeit ist also noch:
Auf Supernodeseite sieht es dann so aus, dass jedes Segment ein bat00-bat10 Device ist, welches das BATMAN-Mesh terminiert. Originators würden da ja nicht rauslecken, was nach Tests bereits den Broadcasttraffic von 300 kBit/s auf 100 kBit/s reduzieren würde, womit die Nodes wieder klar kommen sollten.
Die werden testweise erstmal zusammengebridget, und dann schauen wir ob das schon reicht.
Wenn nicht bekommt jedes Segment halt ein eigenes z.B. /20 für DHCP bzw. /64 für IPv6 und dann wird per Layer 3 geroutet, was kein zusätzlicher Aufwand ist.
Danke für die ausführliche Erklärung. Das klingt alles noch reichlich kompliziert.
Versprecht ihr euch davon so viel mehr als von einer statischen Aufteilung?
Großer Vorteil: Es gibt nur eine Firmware für die gesamte Regio Aachen und es ist garantiert dass ein Knoten mesht, egal welche Nachbarn er findet.
Wenn wir z.B. statisch stadtweise Aufsplitten, dann kommen wir da in Bad Aachen nicht weiter, da wir da schon wieder über 500 Knoten in einer Domäne haben würden. Direkt wieder grenzwertig.
Wenn wir anfangen die Stadt zu zerteilen, dann wird das wieder komplizierter. Man kann jetzt nach PLZ gehen, aber da zerhacken wir garantiert jetzt schon einige Innerstadt-Nachbarmeshes auf den PLZ-Grenzen. Und bei einem komplexeren System ist die Gefahr noch größer, dass ein unbedarfter Nutzer sich vertut, und Inseln entstehen, die nicht meshen. Alles irgendwie doof. Da ist der dynamische Ansatz schon praktisch, weil eben einfach immer gemesht wird, und nur Uplinks die Supernodes tauschen.
Außerdem: Die statische Aufteilung ist für uns zu viel Aufwand und skaliert nach unseren jetzigen Erfahrungen nicht ausreichend.
Obwohl wir sagen, dass sich alle mit Knotenaufstellen zurückhalten sollen, haben wir immer noch ein Wachstum von ca. 100 Knoten pro Monat. (Nach Originators, Alfred streikt ja schon)
In manchen Orten der Regio Aachen sind Marketingvereine und IT-Unternehmen in den Startlöchern, den Mitgliedern und Kunden den Freifunk besonders zu empfehlen.
Wenn das los geht, kann das nochmal explodieren.
Wir sind zwar nicht-kommerziell, und es gibt keine Garantie etc. aber trotzdem hängen wir am Ruf, dass Freifunk zumindestens „normalerweise“ irgendwie benutzbar ist. Da hilft es nicht, wenn wir splitten, dann läuft es ein paar Wochen gut, dann sind wir wieder zu stark gewachsen, und dann muss ein neuer Split von den Kernadmins von Hand eingeleitet werden. Da wir es ordentlich machen wollen und Ehrenamtler sind, muss man da mit ein paar Wochen Vorbereitung rechnen.
Am Ende wären die Admins halt nur noch am Domänen splitten und kommen gar nicht zur Netzverwaltung. Und gefühlt wäre das Netz irgendwie zur Hälfte der Zeit kaputt. Dann geht das Netz einfach allen nur noch auf die Nerven und bringt nur den Techniknerds was, die sich auch drüber freuen können, dass es einfach Freifunk gibt.
Nicht zuletzt erhoffen wir uns eine effiziente Verteilung auf die einzelnen Instanzen. Splits werden nicht mehr rein geographisch nach Verwaltungsgrenzen geplant, sondern man kann einfach immer das jeweils aktuell problematisch größte Segment in zwei Hälften zerlegen. Wie kompliziert die Grenzen sind, ist am Ende eben egal (s.o.)
Probleme macht es natürlich, wenn wir von den max. ~20-Knoten-Funkmeshes wegkommen und die ersten Teppiche entstehen, wo ein zusammenhängendes Mesh für ein Segment zu groß ist. Dann wird man überlegen müssen, was man dann macht. Am besten einfach nur noch interne Services nutzen, dann haben wir ja langsam die Infrastruktur dafür etabliert 
Das klingt hochinteressant. Ist das irgendwie dokumentiert? Ich sehe uns nämlich in 6 Monaten im FFnord Netz vor ähnlichen Problemen stehen. Da wäre dieser Weg ne super Lösung!
Musst du mal @MrMM fragen. Wir haben uns afaik das Konzept nicht alleine ausgedacht, sondern das kommt iirc sowieso aus Stuttgart.
Aber ja, Doku sollten wir vielleicht mal forcieren, vielleicht findet sich dann ja jemand, der uns das Alfred- und fastd-Socket-json-Geparse und die Aufteilungslogik für die Segmente schreibt.
Bei dem Wissen und Können, was dafür notwendig ist, frage ich mich, ob ihr die Zeit und Arbeit nicht besser in Babel steckt. Das sollte ja dann besser skalieren und das Problem langfristig lösen…
Werde es auf jeden Fall gespannt verfolgen, ob es klappt ;).
Obwohl wir sagen, dass sich alle mit Knotenaufstellen zurückhalten sollen, …
das ist mal ne Antwort auf meine Frage.
@yayachiken: Was denn nun? Du sagst, alles wäre wieder gut, aber neue Knoten aufbauen nicht ?
@lImbus Ich sehe da keinen Widerspruch. Im Moment ist das Netz brauchbar wenn nicht zu viele neue Knoten dazu kommen bis die Segmentierung abgeschlossen ist. Daher wird denen, die noch warten können, empfohlen sich mit ihren Installationen noch etwas zu gedulden.
Richtig.
Außerdem gilt das auch vor allem für große Projekte. Wenn jetzt einer hingeht und denkt „Oh super, hier kann ich eine ganze Fußgängerzone verfunken!“ und stellt in einer Woche 200 Knoten auf, dann wäre das ungünstig.
Aber wenn jemand zu Hause nur einen Knoten für vielleicht 10 Clients aufstellt, dann macht das den Kohl ja auch nicht mehr fett 
Und lieber als dass du dann beim Warten die Lust am freifunken verlierst ist es uns doch sowieso
Ich habe heute die Segmentierung etwas umgestellt und setzte dabei nun doch auf eine komplette Layer3 Trennung. Die STP loop Erkennung ist offensichtlich nicht in der Lage mit mehreren Batman Interfaces umzugehen wenn sie zeitgleich an unterschiedlichen Supernodes hinzugefügt wurden.
Momentan fallen dadurch alle Knoten die in den neuen Segmenten sind aus der Karte.
Wer trotzdem mit testen möchte und isolierte Knoten hat kann gerne einen pull request schicken:
Bitte den Dateinamen mit der NodeID beginnen.
Vielleicht noch als kleine Ergänzung wie man an den Fastd-Key kommt.
Auf der Konsole (SSH)
# /etc/init.d/fastd show_key mesh_vpn
oder den Router in den ConfigMode bringen, kurz die Konfigurationsseite aufrufen (wie bei der Ersteinrichtung) und Speichern&Neustarten klicken. Jetzt wird der Key auf der Hinweisseite angezeigt.
Jetzt nicht mehr 
.
