-
core1.man.da.as6766.net
- auf Kernel 4.9.2 aktualisiert
- *.darmstadt.freifunk.net
- auf Kernel 4.9.2 aktualisiert
-
libpam-systemd
installiert [#751636]
Wir stellten gerade Paketverlust von ~30% auf rumple.darmstadt.freifunk.net
, einem unserer geclusterten VM-Hosts fest. Dabei wurde in regelmäßigen Abständen die NIC zurückgesetzt. Dieses Problem betrifft gw05/gw06 und besteht mindestens seit Beginn des Wochenendes und eskalierte heute sehr auffällig. Wir haben daraufhin einen Neustart der Maschine eingeleitet
e1000e 0000:07:00.1 eth0: Reset adapter unexpectedly
Da es sich um ein VM-Cluster auf Basis von DRBD handelt musste der Partner-Node belle.darmstadt.freifunk.net
ebenfalls neugestartet werden. Das führte zu einem weiteren kurzzeitigen Ausfall von gw02/gw03.
Update 0:50 Uhr:
Die Netzwerkkarte auf rumple.darmstadt.freifunk.net
zeigt erneut den gleichen Defekt. Wir fahren gleich zur Colocation und tauschen die Karte aus.
Update 1:55 Uhr:
Die Netzwerkkarte wurde erfolgreich ausgetauscht, der Betrieb ist wieder hergestellt. Wir beobachten die Situation noch weiter.
Update 4:07 Uhr:
Der Server ist nicht mehr erreichbar, wir werden morgen versuchen die Ursachen und unsere Möglichkeiten zu ergründen. Bis dahin sind wir auf 400 eingehende VPN Verbindungen eingeschränkt, weshalb manche Knoten keine Verbindung zum Netz aufbauen können.
Update 17:40 Uhr:
Der Server läuft nun ohne die PCIe Netzwerkkarte und wir haben auf die internen Netzwerkinterfaces umgestellt. Wir beobachten nun die weitere Entwicklung.
-
www1.darmstadt.freifunk.net
- vhost/map.darmstadt.freifunk.net
- Durch den Absturz des Servers wurde ein Teil der Kartensoftware unvollständig ausgerollt, dies wurde nun manuell korrigiert.
- vhost/map.darmstadt.freifunk.net
- gw*.darmstadt.freifunk.net
- Peerlimit für VPN Verbindungen von 100 auf 130 angehoben, d.h. wir haben nun Platz für 520 VPN Verbindungen.
- *.darmstadt.freifunk.net
- Prometheus Node Exporter eingerichtet
-
www1.darmstadt.freifunk.net, forum.darmstadt.freifunk.net
- nginx Metriken bereitgestellt, werden derzeit noch nicht abgefragt
-
elsa.darmstadt.freifunk.net
- Prometheus und Prometheus Alertmanager eingerichtet
- Wir testen derzeit Rules und Alerting in
#ffda-mon
aufirc.hackint.org
- ns*.darmstadt.freifunk.net
- CAA Record für darmstadt.freifunk.net hinterlegt, die Zertifikatausstellung auf non-wildcard Zertifikate von Letsencrypt beschränken soll. Das bedeutet, dass wir für jede Zertifikatsausstellung die erprobten Validierungssschritte von Letsencrypt durchführen müssen.
- CAA Record für darmstadt.freifunk.net hinterlegt, die Zertifikatausstellung auf non-wildcard Zertifikate von Letsencrypt beschränken soll. Das bedeutet, dass wir für jede Zertifikatsausstellung die erprobten Validierungssschritte von Letsencrypt durchführen müssen.
@ CAA 0 issue “letsencrypt.org”
@ CAA 0 issuewild “;”
```
-
gw01.darmstadt.freifunk.net
- batman-adv auf v2017.0 aktualisiert.
-
www1.darmstadt.freifunk.net
- Logrotate access/error.log der nginx VHosts konfiguriert
-
Referrer-Policy
no-referrer-when-downgrade
für alle Webseiten konfiguriert
In den letzten 48 Stunden haben wir spätabends und nachts diverse batman-adv Versionen auf ein Problem beim Fragmentieren von Paketen getestet. Das batman-adv Modul in den Versionen 2017.0 und 2016.5 (und vermutlich seit 2014.0) scheint kein ausreichendes Padding für sehr kleine Fragmente herzustellen, dadurch können Pakete als ungültig verworfen werden. Wir haben dafür einen Bugreport angelegt und wurden dabei von neoraider vom Gluon-Projekt beim Debuggen unterstützt.
Wir warten nun darauf, dass die Entwickler die Analyse des Problems abschließen und sich für eine Lösung des Problems entscheiden.
Im Master-Branch von batman-adv befindet sich derzeit bereits zufällig ein Patch der das Fragmentierungsverhalten ändert, so dass alle Fragmente in ihrer Größe balanciert werden. Das Problem konnte hiermit nicht festgestellt werden.
Es könnte hierbei zudem einen Zusammenhang mit feststeckenden Autoupdatern geben. Wir bleiben dran!
- gw*.darmstadt.freifunk.net
- auf batman-adv 2017.0.1 aktualisiert, behebt den zuvor erwähnten Bug
- *.darmstadt.freifunk.net
- auf Kernel 4.9.13-1~bpo8+1 aktualisiert
-
www1.darmstadt.freifunk.net
-
firmware.darmstadt.freifunk.net, map.darmstadt.freifunk.net:
- Content-Security-Policy und X-Frame-Options ergänzt
-
firmware.darmstadt.freifunk.net, map.darmstadt.freifunk.net:
- gw*.darmstadt.freifunk.net, www1.darmstadt.freifunk.net
- batman-adv wird ab sofort per DKMS aktualisiert.
Wir haben in den letzten Tagen Probleme mit falschen ARP-Replies debuggt, weswegen Clients gelegentlich keine Gateways erreichen können. Dabei sind wir auf einen Knoten gestoßen, der laut Karte offline war, aber weiterhin unvollständig am Mesh teilgenommen hat. Daraufhin wurde der Betreiber benachrichtigt, der seinen Knoten neugestartet hat.
Diese Probleme konnten durch die Deaktivierung der Distributed ARP Table von batman-adv umschifft werden, ob sie nach Aktivierung wieder auftauchen kann zum aktuellen Zeitpunkt nicht sichergestellt werden. Wir werden hier in Zukunft weitere Versuche unternehmen das zu debuggen.
- gw*.darmstadt.freifunk.net
- batman-adv: DAT deaktiviert
-
map.darmstadt.freifunk.net
- Knoten werden nun erst nach 90 Tagen Offline-Zeit von der Karte geworfen
- etc.
- Prometheus (Monitoring):
- Alertingregeln persistiert
-
go-prom-irc
für Alerting ins IRC entwickelt (https://github.com/andir/go-prom-irc)
- Netbox (Dokumentation)
- Docker-Container aktualisiert (https://github.com/freifunk-darmstadt/docker-netbox)
- Installiert und angefangen Dokumentation abzubilden
- Prometheus (Monitoring):
Für kommenden Freitag (19. Mai) stehen Wartungsarbeiten in der Colocation bevor, wir werden vermutlich im Laufe des Wochenendes Teile der Infrastruktur auf neuen Servern installieren. Es wird zwischenzeitlich zu Unterbrechungen kommen, wenn wir mehr wissen geben wir das hier und über Twitter/Facebook bekannt.
- gw*.darmstadt.freifunk.net
- fastd-exporter (https://github.com/freifunk-darmstadt/fastd-exporter) entwickelt und deployed, wir sammeln nun in Prometheus Metriken des VPN-Daemons sowie zu den darüber abgewickelten Tunnelverbindungen der Nodes. An den Alerting-Regeln arbeiten wir noch.
Wir hatten am vergangenen Sonntag (2017-05-28) bis in den Montag Abend hinein einen Ausfall zweier VM-Hosts zu verzeichnen. Diese hosten u.a. vier Gateways, unsere zwei Nameserver und Management-Infrastruktur. Der Grund liegt in Stromschwankungen an diesem Abend, die im Zeitraum zwischen 21:20-22:10 erfolgten. Wir konnten das Problem in den redundanten Storage-Layer (DRBD) nachvollziehen, es verhinderte, dass wir die VMs booten konnten.
Bedauerlicherweise hat sich das Problem verflüchtigt, bevor wir es endgültig identifizieren konnten. Der Backbone war somit ab Montag (2017-05-29) 20:15 Uhr wieder vollständig verfügbar.
-
www2.darmstadt.freifunk.net
- neuen Webserver auf Basis von Debian 9.0 (Stretch) installiert
- neue Karte auf Basis von meshviewer & yanic deployed
- https://meshviewer.darmstadt.freifunk.net
- vermutlich 30-45 Tage Testbetrieb, dann Migration hin zu https://map.darmstadt.freifunk.net
Für Windows Clients liefern wir seit heute per Stateless DHCPv6 (RFC3736) IPv6-fähige DNS Resolver aus. Das sollte Windows-Clients durch weniger Roundtrips schneller eine funktionierende (IPv6-)Internetverbindung bescheren.
- gw*.darmstadt.freifunk.net
- Router Advertisments beinhalten nun das O-Flag (Other Configuration), dass Clients dazu veranlasst weitere Informationen per DHCPv6 anzufragen
- DHCPv6 Server, der zustandslos Informationsanfragen nach IPv6-fähigen DNS Resolvern beantwortet
-
tickets.darmstadt.freifunk.net
- Nach einem umfangreichen Datenverlust haben wir mit Zammad ein neues Ticketsystem installiert, dass bereits seit rund zwei Wochen in Betrieb ist.
-
prometheus.darmstadt.freifunk.net
- Benachrichtigungen werden nun über Pushover ausgeliefert.
-
prometheus.darmstadt.freifunk.net
- Wir beobachten nun die Raumtemperatur in der Colocation um über Klimaprobleme besser im Bilde zu sein.
-
icvpn2.darmstadt.freifunk.net
- neu eingerichtet, Automation auf Kompatibilität mit Debian 9 (Stretch) optimiert
- auf Tinc1.1 aktualisiert
- icvpn*.darmstadt.freifunk.net
- Route Origin Authorization für ICVPN-Routen im Importfiltern eingerichtet
- gw*.darmstadt.freifunk.net
-
mesh-announce betritt nun auch die korrekte Multicast-Gruppe auf dem Tunnelinterface, so dass nodeinfo Anfragen dort nun beantwortet werden.
-
mesh-announce betritt nun auch die korrekte Multicast-Gruppe auf dem Tunnelinterface, so dass nodeinfo Anfragen dort nun beantwortet werden.
- gw*.darmstadt.freifunk.net:
- batman-adv: aktualisiert auf v2017.2
Wenn im Backbone alles ruhig verläuft, dann haben wir insgesamt weniger zu tun. Wir haben daher primär eine Änderung betreffend der VPN MTU zu verkünden, die in der aktuellen Firmware (v1.0.3, v0.9.8) bereits genutzt wird um die Fragmentierung von vollen Paketen zu verringern und somit einen besseren Datenfluss zu erzeugen.
- gw*.darmstadt.freifunk.net:
- batman-adv: aktualisiert auf v2017.3
- fastd: neue Instanz mit 1312 Byte MTU auf Port 6101
- iptables: MSS clamping um jeweils 32 Byte angehoben
Monitoring ist ein essentieller Bestandteil einer zuverlässiger Infrastruktur. Wir setzen dafür auf Prometheus, was auf sogenannten Timeseries aufbaut.
-
prometheus.darmstadt.freifunk.net
- Prometheus auf das neue 2.0 Release aktualisiert
- Alertmanager auf 0.10 aktualisiert
- icvpn*.darmstadt.freifunk.net
- weiteren ICVPN Border-Router in Betrieb genommen und IBGP Sessions aufgebaut
- *.darmstadt.freifunk.net
- borgbackup nutzen wir für tägliche Backups aller wichtigen Komponenten der Infrastruktur die Zustände enthält
- www*.darmstadt.freifunk.net
- map: hopglass entfernt, Weiterleitung auf meshviewer eingerichtet
Durch vermehrte Berichte über Packet-Loss auf der VPN Verbindung haben wir nun die ausgehenden Socketbuffer vergrößert.
Gedroppte Packete auf VPN-Tunneln in ausgehender Richtung
- gw*.darmstadt.freifunk.net
net.core.wmem_max
,net.core.wmem_default
auf 80 MB erhöht
-
ruby.darmstadt.freifunk.net
- konfiguriert und ins Rack eingebaut
- InfluxDB deployed
-
www1.darmstadt.freifunk.net
- www.freifunk-hessen.de deployed, Änderungen von https://github.com/freifunk-hessen/www.freifunk-hessen.de werden automatisch deployed
-
www2.darmstadt.freifunk.net
- APT Repository eingerichtet (https://apt.ffda.io) und diverse Pakete in Vorbereitung auf das neue VM-Cluster gebaut
- Yanic überträgt nun Knotenmetriken an die InfluxDB-Instanz auf ruby
-
neues VM-Cluster eingerichtet
- 4x Dell PowerEdge R620
- Virtualisierung mit KVM durch Ganeti
- Ceph-Storage mit 8x512GB M.2 PCIe Storage
-
gw*.darmstadt.freifunk.net
- für den Multidomain-Betrieb rekonfiguriert
- gw02/gw03/gw05/gw06 auf neue Hardware umgezogen
- gw07/gw08 eingerichtet
- batman-adv
- aktualisiert auf v2018.1
- DHCP Snooping Testbetrieb, reduziert die von Gateways produzierten ARP-Anfragen
-
- Grafana installiert
- Dashboards konfiguriert
-
meshviewer.darmstadt.freifunk.net
- für Multidomain rekonfiguriert
- Graphen aus Grafana eingebunden
-
- hat einen Hardwaredefekt erlitten, wurde daher in neue Hardware umgezogen
-
meshviewer.darmstadt.freifunk.net
- Die Prettynames des Multidomain-Setups werden nun korrekt angezeigt