GW-Struktur

Alex Gutfried alexgutfried at gmail.com
Mi Sep 23 09:20:11 CEST 2015


Nbg laufen momentan has und has2 und Wü läuft wue1 uuuund ich glaube ein
weiterer has.

Am 23. September 2015 um 09:12 schrieb mayosemmel <mayosemmel at googlemail.com
>:

> Halte ich für eine Gute Aufteilung ( wenn alle mitmachen) . Allerdings
> sollten wir vermeiden nur ein GW pro Hood zu haben (insbesondere Nbg und
> Wzbg).
> Klaus M. Pracht aus Arnstein wollte doch auch noch Infos was er für ein GW
> tun müsste...
>
> Grüße Jan
> ------------------------------
> Von: Christian Dresel <fff at chrisi01.de>
> Gesendet: ‎23.‎09.‎2015 08:30
> An: franken-dev at freifunk.net
> Betreff: Re: GW-Struktur
>
> 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
>
> --
> franken-dev mailing list
> franken-dev at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
>
> --
> franken-dev mailing list
> franken-dev at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
>
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20150923/a71956c9/attachment-0002.html>


Mehr Informationen über die Mailingliste franken-dev