Moin,
Wie siehts denn aus mit der Dringlichkeit des Problems? Stört es jemanden wenn die Supernodes 6TB Traffic/Monat haben? Dass das alles anderes als Cool ist ist klar, aber gibt es dadurch tatsächliche Probleme im Hardwarebereich oder verursacht das dem Verein, Spendern oder Supernodebetreibern Kosten die nicht vertretbar sind?
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:
Moin,
Wie siehts denn aus mit der Dringlichkeit des Problems? Stört es
jemanden wenn
die Supernodes 6TB Traffic/Monat haben? Dass das alles anderes als
Cool ist ist
klar, aber gibt es dadurch tatsächliche Probleme im Hardwarebereich
oder
verursacht das dem Verein, Spendern oder Supernodebetreibern Kosten
die nicht
vertretbar sind?
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
-- Save the date: 13. Kieler Open Source und Linux Tage http://www.kieler-linuxtage.de - 18. und 19.09.2015
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Viele Grüße, Stefan
Am Montag, den 27.07.2015, 23:26 +0200 schrieb Stefan:
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.
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,
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.
Fände ich keine schöne Lösung ich würde das anders machen.
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.
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.
@ 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.
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
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.
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.
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.
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.
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.
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.
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,
ack. vollkommen richtige Äußerungen.
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.
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
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.
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:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
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.
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.
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.
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.
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.
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.
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,
ack. vollkommen richtige Äußerungen.
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.
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
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.
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBCAAGBQJVts+lAAoJEIu3uYB6vkH4JqcP/isrDIBI5DjG2udtOhuM+DEg jEh8AoodQqb+/3XSj/7Do9hb+eBd41/O9j2LE5LyAffP54+pa2wDBo0L0noI0cxv 4/fYI9q4flpmmX9TzknlUMYbz4WOyXK7+c8kMTBLpE8vGOd5HV2fMtCFZlxtbzFx QNEDRLk5oFXpeWJMQAdbdhVP/kCaoLa5nTrCZ8QYwk93/S2+NDV7RWdgGb4egXIp DHJPUxV5EofDkLFoNRZL7ExE+sR8r4r0W0+y2rahEMZbDyTI0t8WKUOcyQldId0h 1KGV818IlE8jdF2KFgyum96EJYGCV2Us1iKz/RbKcvfK7yi1wkBGheydcg6GUQQs cIWLDYUuWxO74f+C0c64t+HG2k9SOMvlz8dV5d/pgQTsKj+asosL2ZWTn4wZPnYJ 5WYcUpf6+xt8AHd6ZgMIo9zRQYicKTVOQfSeGxZ2qIDk/FyQB1q9x5EdzsiXqnHC pdREV77hLx9kZhVCodWW+zDvT2hYWYVy6PPcqxD9XSqMFkCLz2mjLH6JBwQhuuRi GVGOsbEVhDasWBI0Z3nuVi6gRKaJrarOBwKMTUgoVdAXkQnpE9IH3aYnA2AdXFlj /zG83lrt2RhXJMWkPoEXT7IHLOjGotDtyYtw206cVzu2pDT966K2oBLInNXNzyil ZwtfBrhNCw72UEOFERpD =4p5G -----END PGP SIGNATURE----- _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Viele Grüße, Stefan
Am Dienstag, den 28.07.2015, 01:42 +0200 schrieb Jan-Tarek Butt:
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.
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.
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.
Also ein VPN-Server, der zur Konfiguration dient, dann eine geokoordinatenbasierte VPN-Server-Auswahl?
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.
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?
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.
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:
Am Dienstag, den 28.07.2015, 01:42 +0200 schrieb Jan-Tarek Butt:
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.
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.
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.
Also ein VPN-Server, der zur Konfiguration dient, dann eine geokoordinatenbasierte VPN-Server-Auswahl?
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.
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?
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.
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
xmpp bjo@schafweide.org
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Viele Grüße, Stefan
Am 28.07.2015 um 02:41 schrieb Eike Baran:
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.
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.
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.
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.
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.
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.
Sehe ich ähnlich, nur würde ich deinen Orthodrom-Schwachfug da
das ist kein Schwachfoo. Orthodrom algerytmen sind cool :D
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.
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.
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.
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:
ok, da hast du recht.
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.
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:
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
Hi,
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.
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.
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
Am 28.07.2015 um 02:41 schrieb Eike Baran:
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:
+1
bedenkt es ist ja nicht nur die traffik die uns um die ohren fliegt, die srv müssen schufften für [ ] (nichts).
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,
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.
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