Moin,
Auch wenn ich mich jetzt etwas in die "Spinner"-Ecke stelle: Selbst wenn von den genannten 6 TB "nur" 50% durch schlecht-konzipiertes Netz o.ae. kommt, ist das imho etwas wo absolut dringender Handlungsbedarf ist. Das ist oekologisch und oekonomisch absolute Verschwendung.
Traffic ist erstmal etwas was man nicht sieht, aber es ist schon so, das Router/Server die unter Volllast laufen wesentlich mehr Strom ziehen, wesentlich mehr Abwaerme produzieren etc. pp. Also (imho) etwas was oekologisch durchaus relevanz hat.
Auch oekonomisch ist es absurd, das jede Menge Traffic erzeugt wird - davon der eigentlich relevante Traffic nur ein Minibruchteil ist. Der Traffic den srv10 (oder srv11?) einer von den beiden verursacht, sorgt dafuer, das wir an dem Standort jetzt Hardware aufruesten muessen. Es zieht also an anderen Stellen auch Kosten (ohne direkt dem Verein zulasten zu fallen) nach sich. Wenn dies aufgrund von realen Anforderungen ist, find ich das super. Wenn dies eine Folge von schlechter Konzeption und Aussitzen ist, ist das eher nicht so schick :)
felix
Hi,
ich habe mir zu der Ganzen Problematik auch noch einmal Gedanken gemacht. Der aktuelle Netzaufbau zieht ja nur noch Probleme mit sich.
Ein ganz grober Vorschlag nur: Wir nehmen 3 Server (04 - eh kaputt, 08 und 09) richten diese oberhalb von 10.18.128.0 ein und lassen anhand der geokoordinaten FW Updates ausrollen. Ist ein Router im Bereich Osnabrück, dann installiert er das Update und ist in der neuen Umgebung.
Ich denke, dies können wir relativ kurzfristig realisieren, denn Monate haben wir leider nicht mehr. Vom Netz und server sollte es nicht das Problem sein, eher vom Autoupdater.
@ tata: Können wir dafür was im autoupdater ändern?
Auch wenn eine 2. FW mehr Arbeit mit sich bringt, für ein stabiles Netz sollten wir das hinnehmen.
So und nun bin ich für Kopfschläge bereit :-)
Am 27. Juli 2015 14:34:03 MESZ, schrieb Felix Kronlage kronlage@bytemine.net:
Viele Grüße, Stefan
Am Montag, den 27.07.2015, 23:26 +0200 schrieb Stefan:
Ok, das wäre ja so ähnlich wie mein Vorschlag. Ich denke auch, dass wir zumindest einige "Sofortmaßnahmen" ergreifen sollten. Für das Testsetup mit 05 und 08 bräuchten wir ein paar Router, die wir da mal dranhängen können, um mit ihnen u.a. auch böse Konfigurationen zu testen.
@ tata: Können wir dafür was im autoupdater ändern?
Wir können zudem auch mal schauen, wie die Rheinländer das in Aachen gelöst haben - aber das Forum ist mal wieder down.
Auch wenn eine 2. FW mehr Arbeit mit sich bringt, für ein stabiles Netz sollten wir das hinnehmen.
2 site.conf zu pflegen und zu bauen sollte ja nun kein großer Aufwand sein.
bjo
Hi,
Fände ich keine schöne Lösung ich würde das anders machen.
Also als schnelle sofort Maßnahme würde ich vorschlagen das wir eine layer 2 Trennung auf Gateway ebene vollziehen das sollten den Management traffic signifikant verringern das dieser überproportional steigt.
Eine zweite Firmware bzw. siteconf fände ich auch keine schöne Lösung. Mein vorschlag wäre folgender. Wir setzen einen Punkte in Form von geokoordinaten und lassen die Router mit Hilfe von orthodrom algerytmen ihre nächst zugehörige hood berechnen. Das ist eine schnell und sauber um setzbare Möglichkeit.
Mein zweiter Vorschlag: Wir verzichten auf Gateway ebene bis hin zum vpn Router auf Layer 2 und richten ein layer 3 Routing zwischen allen Routern ein. Somit würden wir. das batman auf die reine WLAN ebene begrenzen.
Allgemein bevorzuge ich den ersteren Vorschlag. Ich stimme fkr da im übrigen voll und ganz zu. Der overhead ist in zwischen unzumutbar deswegen jetzt eine schnelle Lösung mit großer Wirkung, allerdings bin ich da zurzeit auf Clemens Seite wir haben einige große Baustellen offen und die kosten uns viel zeit und nerven. Ich würde es sehr bevorzugen, wie Clemens das im Pad auch schon dargestellt hat, wenn wir uns genau überlegen wir wir das Netz Designen wollen damit es möglichst Skala bleiben soll. Auch müssen wir berücksichtigen was wir mit Netz erreichen wollen für mich ist es ein großes Forschungsnetz, wo man neue protocole und Möglichkeiten aufprobiert. Dazu gehört auch mal in eine Sackgasse zu fahren wie wir die jetzt haben. Wo wir fest stellen das unser Layer 2 Ansatz nicht funktioniert.
cheers Tarek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Grundsätzlich geht das vermutlich in die richtige Richtung, denke ich, ABER: ich bin mir nicht so ganz sicher, ob das eine "Sofortmaßnahme" sein kann, denn der Ansatz unterscheidet sich doch stark von dem, was wir momentan fahren und auf x Maschinen eingerichtet haben. Und eine Trennung auf dem Gateway würde ja auch bedeuten, dass dieses Gateway zeitgleich in mehreren Batman-Meshes hängen müsste und zwischen diesen routet, oder? Wir müssten da wohl erstmal Know-How checken.
Eine unproblematische Sofortmaßnahme wäre tatsächlich die - von mir auch nicht dauerhaft präferierte - Lösung über eine zweite Siteconf. Da in so (voll-)vermaschten Netzen Overhead vermutlich mehr als linear steigt, sollte eine halbierung erstmal merklich Luft bringen.
Sehe ich ähnlich, nur würde ich deinen Orthodrom-Schwachfug da streichen und einfach Geokoordinaten verwenden. In einer Config werden einfach die Koordinaten der Zentren der Hoods gespeichert und dann mit Pythagoras gecheckt, welche hood am nächsten ist; zumal es uns ja nicht um Meter-genaue Entfernungen, sondern nur um den relativ nähsten Hood-Mittelpunkt geht.
Der grundsätzliche Ansatz, das Mesh (wie genau auch immer) von unserer sowieso statischen Server-Infra fernzuhalten, macht denke ich Sinn. Auch hier kann ich wieder nur sagen: Muss man schauen, wie man das so konfiguriert bekommt.
ack. vollkommen richtige Äußerungen.
allerdings bin
Ehm, mag sein, dass wir verschiedene Baustellen haben, aber ein Freifunk ohne funktionierenden Freifunk wäre so ungeil, dass ich diesem Thema hier mal Priorität 0 zuweisen würde D:
Auch müssen wir berücksichtigen was wir mit Netz erreichen
War ja irgendwo absehbar, aber wir können jetzt zumindest festhalten: bis etwa 800 nodes kann man das noch so gerade irgendwie keuchend am laufen halten D:
Gruß, Eike
Die Ideen gehen im Grundsatz ja in die gleiche Richtung nur ich denke wir haben keine lange Planungsphase.
Wir sollten uns lieber auf zwei Firmwares einstellen und wenn dadurch nur das Grundrauschen um 50% sinkt haben wir doch schon ein großes Ziel erreicht. Sei es mit der 2. FW so wie es ist: Das bauen stellt sich ja nicht als Kunst raus, dass würden wir von hier ja übernehmen.
Könnten wir dem Autoupdater denn nach den Koordinaten das Update welches er nehmen soll beibringen?
Es kann momentan nicht der Stand sein, dass man immer wieder bjo bitten muss was an den Kisten zu machen oder einfach mal eben nachts um 3 auf 4 GWS alles neuzustarten.
Es mag zwar nicht die sinnvollste Variante sein, aber es hilft uns nur!
Am 28. Juli 2015 02:41:10 MESZ, schrieb Eike Baran eike.baran@uni-oldenburg.de:
Viele Grüße, Stefan
Am 28.07.2015 um 02:41 schrieb Eike Baran:
Wir fahren das große layer 2 Netzwerk nur wegen Netmon. Wir hatte vorher auch schon darüber nach gedacht die Gateways z.b. mit BgP oder ospf nur auf layer 3 untereinander Routen zu lassen. Das würde bedeuten das wir bei 4 Gateways 4 für sich getreten batman Netze haben also 800 Router / 4 ~200 Router große batman Netze bei mehr Gateways werden es dann natürlich kleinere Netze. Somit würde der overhead drastisch sinken.
das dauert bis wir zwei firmwares in getrennte Netze ausgerollt haben. Zudem kann man den effect auch ganz simplem über eine Firmware lösen, in dem man einfach 2 fastd groups erstellt und über ein selectirungs script die router schich selbst der passenden group zuweisen. Das ist meiner Meinung nach ein sauberer weg als die Firmwares über den autoupdater zu trennen.
das ist kein Schwachfoo. Orthodrom algerytmen sind cool :D
das könnte man relativ schnell in ein package schmieden. Die koordinaten der router die kein position gesetzt haben kann man über lwtrace -t raus bekommen.
ok, da hast du recht.
Jap, eigentlich schon. wir wollten das Netz in der Vergangenheit schon öfter mal trennen aber da gab es immer die netmon Problematik
Wir müssen uns im Grunde entscheiden auf welcher Seite wir eine Trennung machen. Auf der Server Seite durch routing oder auf der firmware Seite durch selectirung.
Ich glaube schneller und einfacher wäre die Server seitige Trennung. Bjo hat da meines wissens nach auch schon auf 05 und 08 entsprechend ein setup eingerichtet.
vg Tarek
Am Dienstag, den 28.07.2015, 01:42 +0200 schrieb Jan-Tarek Butt:
Naja, die Supernodes zu bridgen dürfte auch schon eine Reduktion zur Folge haben, denke ich. Dann haben wir auf den fftransit-Interfaces nicht mehr den Batman-Traffic aller anderen Supernodes, und Netmon sollte zumindest theoretisch weiter laufen.
Also ein VPN-Server, der zur Konfiguration dient, dann eine geokoordinatenbasierte VPN-Server-Auswahl?
Ja, wenn https://github.com/tcatm/pyddhcpd Serienreife hat, dann bräuchte man auf den Gateways nur noch ripd. Oder willst du zurück zu OLSR?
Der momentane Zustand ist IMHO untragbar, und bei aller Liebe zum Forschen, bis zum optimalen Setup für 5000 Router und 10000 Clients ist es noch ein weiter Weg und wir können nicht warten, bis wir das gefunden haben.
bjo
Vorschlag: Ein Package in die FW mit 2 VPN Gruppen. Das wäre die denkbar einfachste Variante. Hat tata auch bereits als Idee gehabt.
04, 08, 09 für unseren Bereich dafür nutzen. Wir können alles entsprechend umbauen, da die Server keinerlei Dienste im Moment fahren.
Am 28. Juli 2015 09:41:15 MESZ, schrieb Bjoern Franke bjo@nord-west.org:
Viele Grüße, Stefan
Hi,
Ja das würde dem was ich meinte am nächsten kommen und sollte schnell umgesetzt sein.
@Bjo: ich hab es leider noch nicht geschafft ein paar Router entsprechen fertig zu machen da ich jetzt auch wieder zur Arbeit muss. Ich würde heute Abend mal entsprechend ein paar Router ins Test Setup hängen.
vg Tarek
Das hört sich super an! Wenn wir es dadurch gescheit ersteinmal trennen können! Wenn wir was machen können, ausser die GW´s umzustellen,sag Bescheid!
Am 28.07.2015 um 10:01 schrieb Jan-Tarek Butt:
Ja das würde dem was ich meinte am nächsten kommen und sollte schnell umgesetzt sein.
Hoi,
ich hab heute eh keine Zeit, aber es wäre cool, wenn wir die Tage das testen können. 08 hat schon ein fastd-setup (/etc/fastd/ffnw_sandbox), Port 12345, Key muss noch neu generiert werden. 05 bräuchte das auch noch. fftransit rennt in einem eigenen Netz (Port 555), das nur zwischen 05 und 08 existiert.
vg
-
Bjoern Franke -
Eike Baran -
Felix Kronlage -
Jan-Tarek Butt -
picard -
Stefan