Ein zusätzliches Problem sind alle unnötigen Broadcasts die durch das Netz gehen! Zum Beispiel Avahi (zeroconf, Bonjour), windowsshares, applefoo .... Teilweise strahlen die Desktops so viel Broadcasttraffic aus das man beim passiven sniffen schon genug über ein Netz lernen kann. Da helfen dann nur Broadcastdomänen aka Routing so wie wir das mit den Hoods vorhaben um den traffic sinnvoll zu reduzieren in dem jegliche Broadcasts auf eine geringere Teilnehmer Zahl beschränkt werden. An Batman rum zu schrauben löst das Problem definitiv langfristig nicht. Gruß Pascal Am 08.03.2016 um 08:34 schrieb lrnzo via Nordwest:

zur Erklärung: neulich auf dem Workshop wurde gesagt, dass viele der offline Router nicht wirklich offline sind, sondern dass das eben nur die mit dem geringsten uplink sind, wo die nutzbare Bandbreite eben schon für den originatorfoo draufgeht und für alfred nichts mehr da ist.

Am 08.03.2016 um 08:10 schrieb lrnzo via Nordwest:

...

und vorallem: was davon ist zeitlich konstant? wenn ich mir auf https://stats.ffnw.de/ mal die wochenstatistik ansehe, schwankt ja die #clients zwischen 2000 und 600. Diese Schwankung sehe ich aber überhaupt nicht in der #online/offline-nodes. hierfür muss es imho eine Ursache geben, die rund um die Uhr konstant ist, wie zB das Originatorgrundrauschen, dessen Intensität sich durch eine einzige Zahl verändern läßt. Mit den Clients und ihrer Aktivität hat das imho nichts zu tun.

LG lrnzo

Am 08.03.2016 um 07:56 schrieb lrnzo:

...

und was davon ist broadcast?

Am 08.03.2016 um 07:33 schrieb Hilko Böcker || Freifunk Osnabrück:

...

Die ganzen anderen Kommunikationen zwischen den Router den Clients und den Servern auf Layer 2 requests und alles mögliche.

...

Am 08.03.2016 um 07:27 schrieb lrnzo <lrnzo@osnabrueck.freifunk.net>:

tarek und bjo meinten jedenfalls, dass das der Hauptteil des Problems ist. Auch dass layer2 Netzes generell nicht besonders gut skalieren, was ich aber nicht verstanden haben, da es doch imho eher ein Problem der Topologie als des layers ist. Aber die beiden stecken natürlich viel tiefer drin als ich. Ich hatte das neulich auf dem Workshop mal gefragt. Welche anderen Verstopfungen siehst du denn?

...

Am 08.03.2016 um 07:21 schrieb Hilko Böcker || Freifunk Osnabrück: Vielleicht denke ich da falsch aber es sind ja nicht nur die Batman Nachrichten die das netzt verstopfen.

> Am 08.03.2016 um 07:05 schrieb lrnzo via Nordwest > <nordwest@lists.ffnw.de>: > > alle router mit batman-adv.bat0.orig_interval=60000 sind noch da. > Weiß jemand, nach welcher "Zeit des Schweigens" ein Router vom > alfred (?) als offline angesehen wird? waren das 5 minuten? > > LG lrnzo > >> Am 07.03.2016 um 22:36 schrieb lrnzo via Nordwest: >> ich habe jetzt jedenfalls mal versuchsweise >> >> uci set batman-adv.bat0.orig_interval=60000 >> >> also 1 Minute bei meinen diversen Routern in der Martinistraße >> in Os >> eingestellt. wenn die morgen früh noch teil des Netzes sind wissen >> wir >> mehr. >> >> LG Lorenz >> >>> Am 07.03.2016 um 20:12 schrieb lrnzo via Nordwest: >>> Hallo, >>> >>> ich frage ich gerade, ob es neben dem netsplit nicht auch etwas >>> bringen >>> würde, wenn man für jeden Router die Zeitspanne zwischen zwei >>> originatorpaketen vergrößert. es gibt ja den Wert >>> >>> batman-adv.bat0.orig_interval >>> >>> der liegt imho defaultmäßig bei 5000 ms. d.h. jeder router im ffnw >>> verschickt alle 5s ein originator packet an alle anderen, d.h. >>> mein >>> kleiner wehrloser router hier bekommt alle 5000/1500 ms=3,333ms >>> so ein >>> packet zugestellt. Hat damit schon jemand experimentiert und >>> weiß, auf >>> welchen Wert man das Intervall flächendeckend erhöhen müsste, um >>> ein >>> wenig Druck aus dem Kessel zu nehmen? könnte er Wert vielleicht >>> schon im >>> nächsten geplanten firmware image auf testweise 10000 ms gesetzt >>> werden, >>> damit man auch was sieht? reicht nicht vielleicht auch ein >>> originator >>> pro Minute, pro Stunde, oder gar pro Tag? >>> >>> bin sehr gespannt auf eure meinung hierzu. >>> LG lrnzo

On 03/08/2016 04:19 PM, Malte Modler via Nordwest wrote:

[...] Erfahrungen machen [...] einfach machen, lernen, spielen.

-- Gruß pic Xmpp: picard@ffnw.de & picard@fr32k.de @ME https://wiki.nordwest.freifunk.net/picard

Hi, Der default wert von des Protokoll Intervalls beträgt 1000ms Es dient dazu das batman-adv geänderte routen erkennen kann. Der maximale Intervall beträgt 60000ms. Aktuell beträgt der wert 5000ms. Es wäre tatsächlich zu überlegen diesen wert höher zu setzen. Das wird theoretisch den Management traffic reduzieren. Das ist durch aus in einem netzwerk interessant welches relativ statisch ist, also wo es entsprechend wenig mobile Router gibt. Auf der anderen Seite führt es dazu das es entsprechend länger dauert bis die Routen bei Änderung des realen Netz Zustandes, registrieren das die zuvor bestandene/genutzte Route evtl. nicht mehr existiert. Wenn wir den wert z.b. von 5s auf 10s setzen sollten, sollte sich der traffic entsprechend reduzieren. vg Tarek

Hi,

das hört sich plausiebel an.

Könnten wir das nicht bei der 0.8 mit einbauen, damit man hier schon weniger Management Traffic hat.

Wir haben das mal Lokal hier getestet und keinerlei "Verschlechterungen" dadurch festgestellt.

Ich habe die 0.8 gestern bereits fertig gemacht und einen entsprechenden change log gerade über die devliste geschickt. Ich persönlich würde bezüglich der Orgi_intervall Einstellung noch ein bisschen recherchieren wollen und dann lieber eine 0.8.1 releasen. vg Tarek

On 03/09/16 17:33, lrnzo via Nordwest wrote:

auf folgenden 10 Routern in der Martinistr in OS ist seit montag Abend 60000 eingestellt.

fd74:fdaa:9dc4:0:a2f3:c1ff:fe99:28b8 fd74:fdaa:9dc4:0:16cc:20ff:fec0:329a fd74:fdaa:9dc4:0:c24a:ff:fe40:7298 fd74:fdaa:9dc4:0:c24a:ff:fe6c:fba6 fd74:fdaa:9dc4:0:c6e9:84ff:feb0:d2c4 fd74:fdaa:9dc4:0:12fe:edff:fec2:60a2 fd74:fdaa:9dc4:0:12fe:edff:feaf:4426 fd74:fdaa:9dc4:0:12fe:edff:fef4:72a fd74:fdaa:9dc4:0:12fe:edff:fef3:cd62 fd74:fdaa:9dc4:0:6666:b3ff:fe2f:1444

bzw siehe hier: https://mesh.ffnw.de/#!v:m;n:6466b32f1444

Ich bin das gerade noch mal durch gegangen und habe bezüglich des Intervalls mit Tim von Freifunk Franken gesprochen. Eine erhöhung des originator Intervalls dürfte das roaming der Clients sehr mühselig machen. Da es bei einem Wechsel des Routers dann bis zu dem besagten Intervall dauert bis eine neue Route existiert. Daher wäre eine weitere Erhöhung denke ich aus meiner Sicht nicht ratsam da, dann z.b. in Wittmund ein Roaming vermutlich nicht mehr wirklich gut funktionieren dürfte. Aktuell liegen wir auch schon beim 5 fachen des default wertes.

disclaimer: ich habe nicht viel theoretisches Hintergrundwissen zu meshnetzwerken noch ein Gedanke, der mir gerade kam und den ich gerne loswerden würde: schon dadurch, DASS wir so viele Router im Netz haben ist es überflüssig, dass jeder davon häufig einen Originator raushaut. Denn wenn ich mir mal auf einem x-beliegiben Router die Ausgabe von "batctl o" angucke, habe ich dort nicht nur knapp über 1000 Zeilen (also die Anzahl der Originatoren, die auf direktem Weg bei diesem Router eingetrudelt sind) sondern in jeder Zeile stehen ja auch noch durchschnittlich etwas über 4 weitere MAC-Adressen: nexthop und potential nexthops. Allerdings haben mir die allermeisten dieser (potential) nexthops eh schon selbst einen Originator geschickt. Vielleicht sehe ich das ein wenig zu einfach, aber ich glaube, dass durch die hohe Originatorfrequenz und die hohe Routerzahl das Mesh mehrfach redundant ist. In kleineren Netzen mag es notwendig sein, eine hohe Orignatorfrequenz zu haben. Aber ich könnte mir vorstelle, dass man sie ab einer bestimmten Netzgröße auch reduzieren kann, ohne Responsivität einzubüßen. ihr könnt das ja gerne selber mal testen. einfach "batctl o | wc -l" dann habt ihr die #originators und mit "batctl o | grep -o -E \([0-9a-f][0-9a-f]:\){5}" bekommt ihr alle (auch mehrfach auftauchenden MACs). das dann nur noch durch wc -l pipen und schon habt ihr deren Anzahl. wahrscheinlich müsste man da aber auch noch mal nach dem outgoingIF unterscheiden, habe ich aber gerade keine Zeit zu. anyone? Viel Spaß lrnzo Am 09.03.2016 um 10:58 schrieb Stefan via Nordwest:

Hey,

das hört sich plausiebel an.

Könnten wir das nicht bei der 0.8 mit einbauen, damit man hier schon weniger Management Traffic hat.

Wir haben das mal Lokal hier getestet und keinerlei "Verschlechterungen" dadurch festgestellt.

Stefan

Am 09.03.2016 um 10:56 schrieb Jan-Tarek Butt via Nordwest:

...

Hi,

Der default wert von des Protokoll Intervalls beträgt 1000ms Es dient dazu das batman-adv geänderte routen erkennen kann. Der maximale Intervall beträgt 60000ms. Aktuell beträgt der wert 5000ms. Es wäre tatsächlich zu überlegen diesen wert höher zu setzen. Das wird theoretisch den Management traffic reduzieren. Das ist durch aus in einem netzwerk interessant welches relativ statisch ist, also wo es entsprechend wenig mobile Router gibt. Auf der anderen Seite führt es dazu das es entsprechend länger dauert bis die Routen bei Änderung des realen Netz Zustandes, registrieren das die zuvor bestandene/genutzte Route evtl. nicht mehr existiert. Wenn wir den wert z.b. von 5s auf 10s setzen sollten, sollte sich der traffic entsprechend reduzieren.

vg Tarek

_______________________________________________ Nordwest mailing list Nordwest@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/nordwest

_______________________________________________ Nordwest mailing list Nordwest@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/nordwest

Ich wollte mit meiner Aussage niemanden vom spielen abhalten! Lediglich darauf hinweisen das es noch anderen Broadcasttraffic gibt der das Netz verstopft. Viel Spaß beim ausprobieren. G Pascal Am 08.03.2016 um 16:19 schrieb Malte Modler via Nordwest:

Hi,

Es soll ja auch nicht unbedingt eine Dauerlösung sein, sondern als Übergang bis die Hoods fertig sind. Dennoch kann man, wenn wir damit gute Erfahrungen machen, es ja auch mit Hoods so weiter laufen lassen.

LG Malte