GW-Struktur

Mi Sep 23 09:37:37 CEST 2015

Guten Morgen

da das ganze hier in ein ziemliches Kuddelmuddel untergeht und ich nicht 
mehr so recht peil welcher Server nun wohin am besten ist und welcher 
raus soll, hab ich mal ein pad aufgemacht dort kann jeder ordentlich 
mitarbeiten :)

https://pad.freifunk.net/p/Gatewayaufteilung-Franken

mfg

Chris

Am 23.09.2015 um 08:30 schrieb Christian Dresel:
> Guten Morgen
>
> ich hab mal versucht ein wenig zusammen zu stellen was zukünftig Sinn
> machen könnte, dabei bedacht was bald noch an Gateways (zumindest wovon
> mir Infos vorliegen) kommt sowie den Wunsch von Tim ro1 möglichst
> rauszulassen (Was in der aktuellen Konfiguration noch relativ schwer
> ist). Dies ist die absolute Minimalkonfiguration und dabei hab ich schon
> bemerkt das nicht alles so klappt da zu wenig Gateways da sind. Ich hab
> jetzt minimale Erfahrung was so ein Server in etwa packt und zumindest
> bei meinen sollte man schauen nicht mehr als 255 Clients drauf zu
> werfen, dann ist der Speed auch absolut i.O. (noch im guten einstelligen
> MBit Bereich [wenn nicht gerade jeder dicke DL laufen hat, was aber 
> jetzt in der Nürnberger Hood absolut nicht der Fall war, der 
> allermeiste Traffic war irgendein Overhead über den openvpn Mullvad 
> Tunnel ging nur sehr wenig raus im Verhätlnis was übers fastd reinkam] 
> was ja schon das Ziel sein sollte). Daher macht es eher
> weniger Sinn den Server in mehrere verschiedene Hoods zu stecken.
>
>
> So hier mal meine "Idee", gern darf herumgewurschtelt werden wenn 
> jemand andere, bessere Ideen hat (oder ich seinen eigenen Server 
> falsch eingeordnet habe):
>
>
> Default
> nue1.freifunk-franken.de
> ro1.freifunk-franken.de
>
>
> Fürth
> ChrisDServer
> Klee (V2.0)?
> delphiN will doch auch mal irgendwann einen aufstellen soviel ich 
> mitbekommen habe, da er meines wissens aus Fürth kommt, geh ich 
> einfach mal davon aus das es ein Kleeblattserver werden soll?
>
>
> Nürnberg
> Mayosemmel sein neuer (?) nach meiner Info will er nach NBG.
> !!wer kann hier noch einen 2. stellen?!!
>
>
> Hassberge
> fff-has
> fff-has2
> fff-has3
>
>
> HassbergeSued
> fff-has1
> fff-has2
> fff-has3
> (Hassberge hab ich wenig Einblick, ich hab einfach mal die Server 
> genommen die da sind)
>
>
> Erlangen
> nue1.freifunk-franken.de
> ro1.freifunk-franken.de
>
>
>
> Würzburg
> fff-wue1
> !!auch hier fehlt ein 2.!!
>
>
> BGL
> watzmann
> staufen
>
>
>
> Ansbach hat ihr eigenes Zeug oder?
>
>
>
> Problem Nürnberg&Würzburg:
> ro1 will ich ja eher drausen lassen -> Tims Wunsch. nue1 wenn man
> rein nimmt, langweilen sich die anderen Server dein "Er gibt allen 
> Clients IPs
> hat aber nach Berlin ne dünne Leitung" kommt dann wieder zum tragen.
> Hier wären wohl ein paar neue Gateways wünschenswert oder haben die
> Hassberge Server noch Ressourcen über und könnten da mit übernehmen?
>
>
> Für Erlangen und default haben wir so gar keine Server, vielleicht macht
> nue1 da durchaus Sinn, ob und was in Erlangen zukünftig geplant ist,
> ist mir nicht bekannt.
>
>
> mfg
>
>
> Christian
>
>
>
> Am 22.09.2015 um 00:11 schrieb Michael Fritscher:
>> Hi,
>>
>> wir sollten uns glaube ich so langsam mal Gedanken um die GW-Struktur 
>> machen.
>>
>> Wir haben einige Server, die in allen Hoods mit drinhängen, sowie Hoods,
>> wo 5 GWs herumwerkeln. Unter denen gibt es mittlerweile einen ziemlichen
>> Verhau an GRE-Links.
>>
>> Das ist zwar alles schön und gut, produziert aber ziemlichen Overhead 
>> und
>> auch unnötigen Traffic. Außerdem macht es die Konfigurationsdateien und
>> die Fehlersuche nicht gerade übersichtlicher.
>>
>> Deswegen mein Vorschlag:
>>    * Jeder Gateway sollte in max. 3 Hoods drin sein.
> Erfahrungsgemäß, zumindest bei meinen, zuviel. Bei größeren Gateways 
> vielleicht i.O. Rest hab ich oben bereits geschrieben.
> Ich mein 255 Clients pro Gateway, wir haben rund 10 Gateways von einem 
> 2500 Clientspeak sind wir noch weit entfernt und dann sind das auch 
> reine Peakwerte. Wenn man es schafft die Clients halbwegs sinnvoll auf 
> die Gateways zu verteilen sollte man mit 255 Clients pro Gateway noch 
> etwas hinkommen (und wenn wir das haben, stehen vielleicht schon 
> wieder neue Gateways rum?!). Und bei 255 Clients auf 3 Hoods zu 
> verteilen macht in meinen Augen wenig Sinn.
>>    * Jede Hood sollte 3 GWs haben - was ein guter Kompromiss zwischen
>> Ausfallsicherheit und Overhead sein sollte. Davon sollte(n) einer,
>> besser 2 einen direkten (=nicht über olsrd) Uplink ins Internet haben.
>>    * Jeder Gateway sollte 2-3 GREs zu GWs haben, die wenig bis keine
>> gemeinsame Hoods haben (Hood-intern sind die GWs ja eh per fastd
>> verflochten)
> hab ich zu wenig Erfahrung um das zu planen, wer will darf gerne oben 
> mal anfangen eine sinnvolle Struktur zu schaffen.
>>    * Wenn wir mehr Server haben sollten wir die Hoods verkleinern.
> davon sind wir glaub ich noch etwas entfernt wenn ich mir das oben so 
> angucke ;)
>>
>> Weitere eher administrative Vorschläge:
>>    * Jeder Gateway sollte min. 2 Admins haben - zum einen wegen der
>> Erreichbarkeit, außerdem können so Neulinge besser eingearbeitet und
>> betreut werden. Ganz ehrlich ist m.E. ein GW mit zu viel Verantwortung
>> verbunden als dass ein (Linux & Netzwerk-) Neuling ein GW alleine
>> betreiben sollte.
>>    * Wenn bemerkt wird, dass ein GW beispielsweise einen fehlerhaften
>> Uplink hat, diesen aber weiterhin announct, sollte er temporär per
>> KeyExchange gekickt werden, um Schaden vom Netzwerk zu vermeiden.
>>    * Traffic-Statistik für alle Interfaces sowie olsrd-Daten sollten
>> Pflicht werden (ob jetzt vnstat oder mrtg ist egal) - darüber können
>> schnell Probleme festgestellt werden.
>>    * Man könnte sich überlegen, ob man einen Service baut, der anhand 
>> der
>> gewünschten Hoods, GREs etc. automatisiert GW-Konfigurationstemplates
>> erstellt - dann wären die einheitlich und es gäbe weniger Raum für
>> Fehler.
>>    * Alternativ könnte man sich überlegen, ob eine Ausgabe von 
>> ifconfig -a,
>> ip route/rule show, ip route/rule show table sowie
>> /etc/network/interfaces zwingend "irgendwo" hinterlegt und aktuell
>> gehalten werden muss (Dinge wie öffentliche IPs maskieren sind erstmal
>> Details;)  )
>>    * Eine weitere Alternative wäre ein über ein Script 
>> bereitgestellte API,
>> die jedes GW haben muss und worüber die aktuelle Konfiguration
>> eingesammelt werden kann. Wäre eventuell was fürn keyxchange.
>>
>> Das sind einfach so meine Ideen zu diesem Themenkomplex, wo nichts in
>> Stein gemeiselt ist;-)  Aber ich denke, dass wir so langsam eine Größe
>> erreicht haben, wo man sich darüber zumindest mal Gedanken machen 
>> sollte.
>>
>> Viele Grüße,
>> Michael
>