Da wir im Gluon den Split Horizon Patch des Batman benutzen, ist der Batman Upstream Traffic auf den DSL Leitungen kurzfristig kein Problem, Hamburg hat laut Leo ca. 60 kbit/s:
Anhand der Alfred Daten haben:
Ruhrgebiet 435 Router im Netz
Rheinufer 330 Router im Netz
Also sogar noch deutlich weniger Router als die Hamburger.
Ich habe nun insgesamt vier Supernodes am Laufen. Alle vier nehmen Verbindungen von Nodes an, jedoch die beiden schwächeren Systeme, die auch routen, nur bis zu jeweils 100. Die stärkeren Systeme nehmen beliebig viele Nodes (Fastd Peers) entgegen, sind aber bisher nicht fürs Routing zuständig, sondern leiten die Verbindungen nur über die zweite Fastd-Instanz weiter. Diese ist mit AES-128 gesichert, was auf den Xeon-Prozessoren bessere Leistung bietet, als der auf den Node-Verbindungen laufende Cipher SALSA-2012.
Momentan haben die Supernodes alle etwa 50-60% Auslastung. Es ist also angezeigt, möglichst bald weitere Systeme an den Start zu bringen. Dann werde ich auch Routing auf allen Supernodes konfigurieren. Das erfordert jedoch auch Arbeit am Rheinland Backbone, die nicht ohne Unterstützung beginnen möchte. Beim Congress werden wir dazu vielleicht Gelegenheit haben.
Der Split wird nicht aus politischen Gründen notwendig (wie es vermutlich @maltis gemeint hat), sondern aus technischen. Du bemerkst bereits richtig, dass es etwas mit dem Broadcast-Traffic zu tun hat. Da gibt es Optimierungsmöglichkeiten, wie @CHRlS weiter unten angemerkt hat. Dennoch stoßen wir irgendwann an eine Skalierungsgrenze und müssen dann splitten.
Wenn wir das tun, müssen wir vorher genug fähige Admins im Team haben. Beide entstehenden Domänen sollen autonom sein und ihre Probleme eigenständig lösen können. Das ist eins der schwierigen Probleme bei diesem Vorgang. Zu der technischen Durchführung gibt es mehrere Ideen; lasst uns diese nicht an dieser Stelle diskutieren, denn das führt uns von dem akuten Problem weg.
Rheinufer muss zum jetzigen Zeitpunkt mindestens 6 Supernodes haben, besser 8, da selbst bei 6 das festgelegte 100 Router / 2 Supernodes Verhältnis schon wieder leicht überschritten ist.
Ja, ich weiß. Wir haben 6 CPU am Laufen, da zwei der Supernodes Dual-Xeon-Systeme sind. Wenn mehr notwendig erscheint, müssen wir die Formel mit dem Vorstand neu bestimmen.
Und: 400 Nodes sind verdammt viel. Vor ein paar Monaten waren es noch die Hälfte. Ich bin beeindruckt und mein Tatendrang ist größer denn je.
Hier kann man schöne sehen, wie der Traffic (Grün/Violett) sich auf vier Systeme verteilt hat und die CPU-Last (Gelb) ebenso. Die Lücke bei Rheinufer1 ist ein Absturz des Systems (Kernel Panic), der heute Mittag geschehen ist. Die Ursache ist mir unklar.
BATMAN
Haben wir in letzter Zeit regelmäßiger:
Welche bat-Version nutzt Ihr auf euren Servern? Die gepatchte aus Gluon oder 2013.4.0 pur?
Ich weiß nicht, ob es was damit zu tun hat, aber dies wurde vor 8 Tagen eingepflegt:
kann ja nicht schaden das Modul upzudaten und neu zu kompilieren
…noch die selbstkompilierte 2013.4 pur, aber wir steigen jetzt mal testweise um auf die Paketinstallation „batman-adv-dkms“
Ich weiß nicht, ob das Paket weiterentwickelt wurde oder es einfach nur 2013.4.0 enthält und mit DKMS ein Kernelupdate vereinfachen soll. Auf die Schnelle habe ich gerade nichts darüber gefunden.
Ich würde es mit der von @phip verlinkten Version versuchen, die hat auch noch zusätzliche Patches und ist so gesehen „kompatibler“ mit der Version auf den Nodes. 
Das war übrigens der Grund, warum ich akut nochmal einen Satz Experimental-Builds für Gluon gemacht habe. In der Hoffnung damit die „verschwundenen Nodes“ im alfred oder beim ipv6-batman-routing reduzieren zu können. Bin mir aber unschlüssig, ob das hilft, denn der Effekt tritt immer noch auf, wenn auch gefühlt seltener.
Wo wäre die gesicherte Information zu „müssen Split durchführen“ Grenze?
Ich frage für eine Lieferung von ganz vielen Routern…
Gefühlt liegt die Grenze des Machbaren bei 500 Routern pro Domain.
Weil irgendwann der elende Broadcast-Traffic (egal ob mit oder ohne Split-Horizon-Patch) so arg wird, dass Standort mit „DSL-Lite“ schlicht gar nicht mehr genug Upstream haben und schon mit dem Broadcast-Mist ihren Upload „saturieren“.
P.S.: Communities statis zu bilden „Nach Ortschaften“ mag nahe liegen.
Meine Vermutung ist jedoch, dass dabei stets sehr unterschieldich große Gebilde bei herauskommen, da das Wachstum nicht überall gleich bleiben wird. Ausserdem wird man immer wieder von neuem Teilen müssen.
Schöner wäre es, diese Segmentierung des Netzes irgendwie automatisiert hinzubekommen.
Idee „in die Tüte gesprochen“:
Man könnte man anhand der AP-Stationen herum (auch den „Nicht-Freifunk-ESSIDs“, alles was ein iw scan so ausgibt) anhand freier Datenbanken schon gut geographich lokalisieren. (Falls bei der Einrichtung keine Koordinaten hinterlegt wurden)
Und dann könnte man die Nodes nach einem ersten Handshake mit einem „Dispatcher“ gemäß Geokoordinaten und gehörter Nachbarn in eine regionale Wolke geben (also ihnen die Liste der für sie zuständigen Supernodes übergeben.)
Wie man das öffentliche Routing der IPv6-Adressen dann hinbekommt, das müsste man noch prüfen, evtl. nochmal umswitchen nach diesem Dispatch) #
Auf jeden Fall hätte man Wolken, die in ihren Grenzen je nach Netzentwicklung durchaus dynamisch wandern könnten. Langsam zwar, aber eben so, dass sie Lastsituation in den einzelnen Teildomains ähnlich bleiben.
Wie gesagt bei 620 Nodes hat Hamburg derzeit 60 kb/s upload „waste“, das skaliert also noch deutlich größer…da ist bislang noch niemand im Zwang gewesen splitten zu müssen!
Ich habe gerade einen 1 Monat lang dauernden Kampf mit bat15 hinter mir, der überhaupt keinen Spaß gemacht hat. Da konnte ich so viel verstellen und optimieren wie ich wollte; dies brachte keine Verbesserung. Im Batman-Code wurde etwas nicht bedacht, schlicht vergessen oder ein Flüchtigkeitsfehler hat sich eingeschlichen. Es bringt also nichts das fehlerhafte Modul zu nutzen, da auf einem Gateway durch das Datenaufkommen der Fehler statistisch öfter passieren kann, als auf einem Knoten. Ein Knoten startet sich zudem einfach neu, ein Server landet bis zum Reset im Nirvana.
bat14 wird nicht mehr aktiv weiterentwickelt. Um so mehr lobe ich die Tatsache, das bemerkte Fehler durch Patches behoben werden, entweder als entdecker Fehler oder als Erkentniss aus aktiver bat15 Entwicklung. Mich hat es einfach nur vom Hocker gehauen, dass mir weder die allerneueste bat15 Version noch die viel neuere, mit dem neuestem Kernel gelieferte Version helfen konnte den auftretenden Fehler zu beseitigen. Und da der Fehler noch nicht entdeckt wurde …
Ich kann zwar kein C, aber ich glaube, dass der von mir verlinkte Patch Euren Fehler beschreibt. Die Entwickler stellen keine Fehler bereinigte Version von bat14 mehr zum Download bereit, also muss man sie sich aus dem Git ziehen. Das geht zum Glück auch ohne Git:
https://github.com/freifunk-gluon/batman-adv-legacy/archive/master.tar.gz
Versucht es, es kann nur besser werden.
Ist bei uns nicht ganz so massiv wie es bei Dir war - im Schnitt haben wir einen Server pro Woche der ne Panik hat. Da es bei uns nun so eingestellt wurde das nach einer Minute Wartezeit bei einer Kernel Panik automatisch restartet wird, kommen die Gateways vermutlich sogar von alleine wieder hoch.
Wie passt „gefühlt max 500 pro Domain“ und „wir haben 650“ mit der Erfolgsmeldung: „1.000 Router drehen“ (https://freifunk-rheinland.net/) zusammen?
Ich verstehe das nicht.
Viele Grüße, Fx
Das Ruhrgebiet hat in Hochzeiten schon 480 Router, fortlaufend mindestens 430 im Netz.
Entsprechend hatten wir schon sehr früh Probleme im Umgang mit größeren Domänen und hatten uns ebenfalls entsprechend früh mit den Hamburgern ausgetauscht.
Wieviele wir ohne größere Probleme tatsächlich ins Netz bekommen weiß noch niemand. Aus dem Bauch raus tippe ich derzeit vorsichtig auf annähernd 1.000 Stück - aber bitte nicht verwechseln, dies ist kein profunder Wert, sondern lediglich eine Schätzung auf Basis der größten mir bekannten Kollisionsdomäne Hamburg und deren Zahlenmaterial.