GW-Struktur=?iso-8859-1?Q?=2C_war:_Re:_AW:_Gateways_N=FCrnberg=2C_was_ist_da_los?=?

[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.
  * 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)
  * Wenn wir mehr Server haben sollten wir die Hoods verkleinern.

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