-----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