Das Netz lief nicht rund; this should have been fixed.

Auch in dieser Woche hatten wir mit Problemen zu kämpfen, aber, die gute Nachricht, wir haben den Auslöser wohl gefunden und erst einmal beseitigt.

Screenshot
Dash­board, ers­ter An­lauf.
Die gute Nachricht zuerst: wir haben mittlerweile ein relativ gutes Monitoring unserer Hypervisoren, virtuellen Maschinen und der Dienste.

Die schlechte Nachricht: wir haben noch längst nicht jeden Fehlerfall durch’s Monitoring abgefangen :(

So ist uns bis zum Donnerstag abend leider ›durch die Lappen gegangen‹, daß der DHCP-Server keine Rückroute zu den Gateways hatte, sodaß die DHCP-Anfragen zwar ankamen und beantwortet wurden — diese Antworten aber nie bei den Endgeräten ankamen.

Screenshot
Moni­tor­ing, Alarme.
Dieses Problem ist sein Donnerstag gegen 20 Uhr behoben.

Bei Tests in der Stadt, als auch bei Rückmeldungen per Mail, zeigte sich aber ein weiteres Problem: gw02 konnte nicht via bgp1, gw04 nicht via bgp2, Datenverkehr ins Internet routen. Die Daten versackten aufgrund eines weiteren Routingfehlers auf dem VPN-Server (vpn01.4830.org), dieses Problem wurde gegen 22:30 erkannt und behoben.

Screenshot
Moni­tor­ing, Warn­ungen.
Auch hierfür existiert seit dem späten Abend nun ein Test.

Leider sind wir an dieser Stelle beim »learning while doing« angekommen: über verbessertes Monitoring oder auch nur durch Servertests lernen wir, welche Probleme auftreten können, schreiben entsprechende Skripte für das Monitoring — und warten dann ab …

Kurzum: wir können nur verhindern, was wir als Problem schon kennen. Insofern werden sich die Mittel und Wege über die Zeit schon deshalb ändern.

ditaa-Grafik
VM-Verteilung, 2016-02-26.
Zur Visualisierung wurde testweise eine neue VM aktiviert …

… leider korreliert die Darstellung, welche den Status in simplen Kacheln wiedergibt, so nicht mit der Wirklichkeit.

Wie dem auch sei: für das Routingthema existiert seit heute abend ein Test, der Probleme beim Routing unserer Netze via NAT gegen die Außenwelt aufspüren sollte.

Nur: in der aktuellen Form macht es leider keinen Sinn, die URL des »Dashboards« zu nutzen. Die gezeigten Daten (s. Screenshot) verallgemeinern zu sehr. Ein direkter, passwortloser Zugang wurde nun nachgefragt, die Umsetzung wird sich noch hinziehen …

Nachwehen

Ein Gedanke zu „Nachwehen

  • 26. Februar 2016 um 09:34
    Permalink

    Leider erhalte ich Heute morgen trotzdem keine DHCP-IP im Freifunknetz. Auch ein Neustart des APs hilft nicht.

Kommentare sind geschlossen.