Administratives Tagebuch

Technik
61
62
63
  • {ns1,ns2}.as6766.net (DNS Resolver)
    • Connection Tracking Limit von 16k auf 256k erhöht, zuvor traten bei Clientspitzen Paketverluste auf.
64
65
  • stats.darmstadt.freifunk.net
    • minimales Intervall zum Nachladen von Metriken auf dem “Meshviewer Export” Dashboard auf 5 Minuten gesetzt. Dies wurde notwendig weil vereinzelt Nutzer den ganzen Tag über alle 5 Sekunden (~17280 Aufrufe/Tag bei je 10 Graphen mit insgesamt etwa 20 Metriken) mit Updates versorgt werden wollten und die Maschine somit dauerhaft unter Volllast lief.

machines-single
machines-single.png1000×500 51.9 KB

66
  • {zelena,grumpy,sleepy.sneezy,happy}.darmstadt.freifunk.net
    • Ganeti auf v2.16.0 migriert
  • gw*.darmstadt.freifunk.net
    • batman-adv auf v2018.3 aktualisiert
  • netbox.darmstadt.freifunk.net
    • auf ninech/netbox container migriert und Webhooks aktiviert
  • elsa.darmstadt.freifunk.net
    • Prometheus: Blackbox-Exporter für ICMP-Serien konfiguriert

Ansonsten hat die monatelange Arbeit alles für Multidomain fertig zu machen nun endlich Früchte getragen.

Die durchschnittliche Load aller Geräte ist signifikant gefallen.

router-summary
router-summary.png1000×500 173 KB

2 „Gefällt mir“
67
  • tickets.darmstadt.freifunk.net
    • Probleme mit SPF und DKIM behoben, wenn die nächsten Tage alles klappt aktualisieren wir unsere DMARC-Policy entsprechend
  • ns*.as6766.net
    • Prometheus: Blackbox-Exporter für Überwachung der Authoritative-Nameserver und Resolver eingerichtet
    • Prometheus: Unbound-Exporter eingerichtet, wir sammeln nun Resolver-Metriken
  • *.darmstadt.freifunk.net
    • borg: Backups werden nun statt LZMA mit Zstd komprimiert
  • ldap.darmstadt.freifunk.net
    • borg: Export der LDAP Datenbank mittels slapcat für Backup eingerichtet
68
69
70

Lange nichts mehr hier geschrieben. Das meiste funktioniert einfach und neben den regelmäßigen Systemupdates und Reboots bleibt glücklicherweise nicht viel zu tun. Natürlich bleibt immer hier und da etwas zu tun. In den letzten Wochen habe ich Vorbereitungen getroffen, die unser Konfigurationsmanagement mit Debian 10 (Buster) kompatibel macht, wann wir das Update vollziehen ist aber noch unklar. Hier die Highlights der letzten Monate:

71
  • gw*.darmstadt.freifunk.net
    • Die Gateways tauchen nun wieder auf der Karte auf
72

Alle Maschinen wurden auf Debian 9.10 (aktuelles Stretch Minor-Release) aktualisiert.

73

  • elsa.darmstadt.freifunk.net (Prometheus)

    • auf Debian Buster aktualisiert
    • hat aktuell noch Probleme mit der Bootloader-Installation auf das ESP welches auf einem RAID1 (MD, 0.9 Metadata) liegt.

  • ruby.darmstadt.freifunk.net (Grafana, Influxdb)

    • auf Debian Buster aktualisiert.

  • gw*.darmstadt.freifunk.net

    • auf batman-adv v2019.4 aktualisiert
    • auf Debian Buster aktualisiert
74

Viele weitere Maschinen sind nun auf Debian Buster aktualisiert worden.

Es folgen in Kürze noch das VM-Cluster. Außerdem

  • core1.man.da.as6766.net
    • auf Debian Buster aktualisiert
    • auf Bird 2.0.7 aktualisiert, wir filtern ab sofort
      • Bogon ASN/Prefixe,
      • zu lange Prefixe,
      • zu lange AS-Pfade,
      • RPKI-ungültige Prefixe
75

Etwas holprig fand heute das Update des VM- und Storageclusters statt. Beim Update von Ceph gab es Probleme, weshalb für mehrere Stunden aller Disk-I/O blockiert war. Damit sind nun aber schlußendlich alle Maschinen auf Debian Buster aktualisiert.

  • Alle VM-Hosts wurden auf Debian Buster aktualisiert
  • Ceph Cluster von Luminous (12.2.12) auf Nautilus (14.2.4) aktualisiert.

Gute Nacht.

1 „Gefällt mir“
76
77

Wir treffen uns seit Mitte Januar jeden Mittwoch um an der Infrastruktur zu arbeiten. Die Arbeit sollte sich daher innerhalb der nächsten Monate auf mehrere Schultern verlagern. Als eines der ersten einschlagenden Ergebnisse haben wir die automatische Aktualisierung unserer Server ausgeweitet. Außerdem haben wir nun einen automatischen Linter CI-Job für unsere Saltstack-Konfiguration.

1 „Gefällt mir“
78

Das letzte Update hier ist eine Weile her. Lustigerweise etwa eine Pandemie, und ähnlich unerfreulich war der heutige Ausfall unserer Internetanbindung.

19:06
Heute gegen 19:06 Uhr stellte ich unerwartet den Ausfall unseres Peering-Routers fest. Über eine Out-of-band Anbindung ans Management-Netz konnte ich feststellen, dass es sich um Probleme mit der Netzwerkkarte (Mellanox ConnectX-3 Pro) handelte. Das Anpingen der Maschine funktionierte eine Weile, dann wieder nicht. Wenn wir keine stabilen Netzwerklinks haben, dann können wir keine BGP-Sessions aushandeln. Dadurch entsteht dann ein völliger Konnektivitätsverlust mit dem Internet.

Wir versuchten dann zunächst das Debugging aus der Ferne, was durch ein kaputtes Keyboard-Layout des HTML5 KVM unnötig erschwert wurde. Es war schlicht nicht möglich das Pipe-Symbol (|) einzugeben, so dass die effektive Konsolennutzung sehr erschwert wurde. Nach einem Neustart war klar: Die Netzwerk Interfaces fehlen nun vollständing im Hostsystem. Die Netzwerkkarte zeigt aber noch ihr Option ROM, ist also definitiv noch lebendig.

20:30
Wir bewegten uns dann in Richtung Colocation, da wir in der Regel vor Ort mehr ausrichten können. Hier konnten wir durch das Kernel log (dmesg) greppen und die Fehlermeldung des Netzwerktreibers erkennen.

mlx4_core 0000:03:00.0: Missing UAR, aborting

Kurz in den Quellcode des Kernels geschaut wird klar, dass hier kein oder nicht genug Speicher für die die Kommunikation mit der Karte allokiert wurde.

        if (!(pci_resource_flags(pdev, 2) & IORESOURCE_MEM)) {
                dev_err(&pdev->dev, "Missing UAR, aborting\n");
                err = -ENODEV;
                goto err_disable_pdev;
        }

Der Quelllcode stammt aus drivers/net/ethernet/mellanox/mlx4/main.c:3796 in Linux v5.10.92. Er wurde zudem seit 2014 nicht mehr angefasst, der Fehler liegt also vermutlich an anderer Stelle.

21:12
Nach einer kurzen Recherche konnten wir einen Fix für dieses Problem ausfindig machen. Wenn wir den nun aktuellen Kernel (5.10.70) mit pci=realloc=off booten, dann klappt alles wie gewohnt. Das wurde im Bootloader so persistiert und nach einem Reboot sind wir reproduzierbar wieder online. Ob das Problem durch ein Kernelupgrade erst aufgetreten ist haben wir nicht gestetet, vorher lief jedenfalls Kernel 5.10.46.

Zum Verständnis: Die Speicherallokation scheint bereits durch das BIOS zu erfolgen und wird gewöhnlicherweise durch den Kernel vergrößert falls nötig. Hier scheint ein Fehler vorzuliegen, weshalb wir die Reallokation durch den Kernel deaktivieren müssen.

                realloc=        Enable/disable reallocating PCI bridge resources
                                if allocations done by BIOS are too small to
                                accommodate resources required by all child
                                devices.
                                off: Turn realloc off
                                on: Turn realloc on

(via The kernel’s command-line parameters — The Linux Kernel documentation)

Jetzt wo wir vor Ort sind ergibt sich natürlich die Gelegenheit das längst überfällige Debian Bullseye Upgrade durchzuführen. Heißt: Es kommt heute noch zu ein zwei weiteren, kürzeren Ausfällen, bei denen wir schauen ob das Problem mit dem neuen Kernel (5.10.92) weiterhin auftritt, oder ob wir weiterhin diesen Workaround benötigen.

21:57
Das Upgrade ist fertig und wir haben einen Reboot ohne die Kernel-Option gewagt. Leider weiterhin kaputt. Wir bauen sie also wieder ein und rebooten erneut.

22:00
Wieder online. Habe nun kurz über das initiale Fehlerbild nachgedacht und halte es für unwahrscheinlich, dass ein Kernelupgrade das ausgelöst haben könnte. Für den Fall der Fälle haben wir noch eine Ersatzkarte vor Ort liegen, die wir tauschen können. Da das aber jetzt erstmal wieder so läuft und wir andere Personen mit dem gleichen Problem im Internet wiederfinden konnten, bei denen das ebenfalls half, gehen wir davon aus, dass kein Defekt der verbauten Karte vorliegt.

22:47
Aus den Logs und Graphen lässt sich nun sehr gut ablesen, dass der Ausfall bereits ab etwa 18:51 statt fand. Ein Problem ist demnach natürlich auch, dass wir kein Monitoring außerhalb unseres eigenen Netzes haben, und auch die Benachrichtigung auf das Internet angewiesen ist.

3 „Gefällt mir“
79

In den letzten zwei Wochen haben wir den Backbone für das im Kernel enthaltene Tunnelprotokoll L2TP umgebaut. Der Tunnel wird weiterhin über fastd aufgebaut, so dass die vorhandenen Schlüsselpaare weiterverwendet können. Dadurch, dass der Verkehr weniger Kontextwechsel zwischen Kernel- und Userspace erzeugt sollte auf allen Geräten ein höherer Durchsatz bei geringer Belastung möglich sein. Unterstützung für L2TP ist derzeit Teil der testing Firmware (ab 2.5~20220322) und kann ab sofort getestet werden. In der stabilen Firmware wird der Support mit Version 2.6.0 frühestens in der Mitte des Jahres erscheinen, da wir hierfür noch auf das Release von Gluon v2022.1 warten.

2 „Gefällt mir“
80

Das Hypervisor-Cluster wurde heute auf Debian Bullseye und Ganeti 3.0 aktualisiert. Es gab hierbei keinerlei Ausfälle.

2 „Gefällt mir“