GW-Struktur

[Tim Niemeyer]

Hi

Am 23. September 2015 09:22:43 MESZ, schrieb Michael Fritscher <michael at fritscher.net>:
>Hi,
>
>die Verteilung klingt erstmal gut :-) Wenn irgendwo noch was benötigt
>wird
>- wue1 kann sicher noch eine 2. Hood mitmachen. Könnten dann z.B. Nue
>und
>Wue verkreuzt machen. Falls sinnvoll kann ich den vServer auch klonen.
>(Liefe dann auf den gleichen dezidierten Server, aber ich würde dann
>z.B.
>einen anderen Mullvad-Uplink oder einen Richtung Berlin nehmen)
>
>Was mir auffällt: ro1 ist der einzige Server mit ICVPN-Anbindung.
>Wollen
>wir da für etwas Redundanz sorgen?

Klar, wenn du da Lust zu hast gern. Bei Fragen helfen ich oder casandro gern weiter.

Tim

>Viele Grüße,
>Michael
>
>> 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
>>