Admintagebuch - Dokumentation der Admintätigkeiten

Moin,

@paulinsche und ich haben vorhin versucht das IPv6-Routing zu reparieren. Aus irgendeinem Grund schreibt Bird6 die Defaultroute für die Tabelle 42 nicht in den Kernel. In Bird wird sie mit einem Ausrufezeichen angezeigt und landet auch nicht im Kernel.

Wir wissen nicht genau warum, es gibt auch einen nichtssagenden Fehler im syslog, der höchst wahrscheinlich damit zusammen hängt. Das Problem besteht mindestens auf Fussels und Parad0x’ Gateway.

Wenn man die Defaultroute manuell in den Kernel einträgt, geht das IPv6 wieder. Dies haben wir derzeit als temporäre Lösung gemacht.

Grüße
Matthias

2 „Gefällt mir“

Gestern den lokalen ipv4 exit abgestellt. Dabei nicht überprüft, ob die default-route wieder via ospf angenommen wird. Heute morgen festgestellt, dass ipv4 keine default-route hatte. Ursache: auf ffmstd-des1 war die default-route vorhanden, diese wurde aber nicht ins ospf exportiert und somit nicht verbreitet. Vielleicht ein Bug, weil die mal weg war?

Dann habe ich das ospf neu gestartet.

Dec  3 08:09:27 ffmstd-des1 bird: Reloading protocol p-ospf-ffnet

Seither alles wieder gut. Für den Fall, dass die default-route nochmal weg fällt, habe ich folgendes im bird von ffwaf konfiguriert:

protocol static 'staticffnet' {
    table ffnet;
    import filter {
        if  net = 0.0.0.0/0  then { preference = 149; }
        accept;
    };
    export none;
    route 0.0.0.0/0 via 134.0.124.33;
};

Protocol static hat ein preferenz von 200, ospf von 150. Hier setze ich die für die default-route auf 149. Die Route wird nur aktiv, falls ich sie aus ospf nicht mehr lerne. Ich verdrehe mir nach wie vor immer wieder den Kopf wenn es um import/export geht, weil ich mir immer wieder die Richtung vor Augen führen muss.

Auf paradox habe ich einfach nicht raus bekommen können, warum die default-route die wir via BGP erhalten aus Sicht des Bird ungültig ist, die nächste Route aber nicht gewählt wird. Ich würde da jetzt ein aktuelles bird „backporten“.

Ich habe gerade den collectd auf kgbvax2 gefixt, zählen der fastd connections ist durch das ansible deployment kaputt gegangen (bei mehreren fastd instanzen funktioniert das alte Verfahren nicht). Da wurde das gepatchte Script leider einfach übergebügelt.
Die Korrektur steht in ansible-ffms als pull request.

Wobei die collectd.config halt auch noch anders aussehen müsste.

Und: Mir ist das mit den 4 Augen nicht so ganz klar, hätte es derer jetzt bedurft?

1 „Gefällt mir“

Reparieren darf man ohne.

1 „Gefällt mir“

\o/

Bericht von heute:

  • Remü-01 hab ich erstmal abgeschaltet. Der Host stürzt ständig ab, Arbeiten auf der Ansible-VM ist praktisch nicht mehr möglich (Michael und Void haben es wohl probiert und soll ziemlich ätzend gewesen sein). Daher habe ich die Remü-01-VM aus der Domäne-01 geschmissen. Dort sind jetzt noch Sense-02 und Greyworm-01.

  • Routingproblem gelöst: Ich hab mir einen Filter gebaut, der prüft ob eine IP aus unserem internen Netz kommt. Auf den Backbones werden dann per OSPF nur noch Routen zu diesem Netzen akzeptiert:

    filter freifunk {
    if net ~ 10.43.0.0/16 then accept;
    if net ~ 10.0.0.0/16 then accept;
    if net ~ 192.168.0.0/16 then accept;
    reject;
    };

Und im OSPF entsprechend:

import filter freifunk;

Mir Präferenzen zu arbeiten funktioniert irgendwie nicht richtig, da Bird wohl OSPF immer wichtiger nimmt als BGP. Warum das so ist weiß ich nicht. Analog für IPv6 genauso, dort eben auf 2a03:2260:115::/48. Wichtig ist, dass diese Filter nur auf den Backbones eingesetzt werden, die anderen Rechner wollen ja gerade explizit ihre Standardroute (default) per OSPF lernen.

Die Netztopologie sieht jetzt so aus:

Fanlin <---GRE / Layer 3---> Greyworm-01 <----GRETAP / Layer 2----> Sense-02 <----GRE / Layer 3----> Des1

Die Einträge der Routingtabelle sehen gut aus. Einen Knoten habe ich jetzt noch nicht dran gehangen.

Grüße
Matthias

Wir (@MPW, @descilla) haben heute für die DHCP Leases eine RAM-Disk konfiguriert (tmpfs). Folgendes wurde auf allen drei GW-Servern eingerichtet:

/etc/fstab

tmpfs   /var/lib/dhcp     tmpfs   defaults,size=100M        0       0

sowie

/etc/rc.local

[ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases
[ -e /var/lib/dhcp/dhcpd6.leases ] || touch /var/lib/dhcp/dhcpd6.leases
chown root:root /var/lib/dhcp /var/lib/dhcp/dhcpd.leases /var/lib/dhcp/dhcpd6.leases
if [ -e /var/lib/dhcp/dhcpd.leases~ ]; then
chown root:root /var/lib/dhcp/dhcpd.leases~
fi
if [ -e /var/lib/dhcp/dhcpd6.leases~ ]; then
chown root:root /var/lib/dhcp/dhcpd6.leases~
fi

Daruch ist die iowait der CPU auf allen GWs massiv abgefallen: https://freifunk-muensterland.de/grafana/dashboard/db/spielwiese-von-descilla

Die Anzahl der Clients ohne Leases bewegt sich nun zwischen 250 und 300 (Vormals 500+, https://freifunk-muensterland.de/grafana/dashboard/db/gateway-ubersicht ). Die größten Auswirkungen hatte die Änderungen auf das GW parad0x, hier war auch ein gesteigerter Durchsatz ins Rheinland nach den Änderungen zu erkennen. Ebenfalls bei parad0x wurde berücksichtigt, dass ihr ein dhclient für eth0 läuft, daher ist dort die Konfiguration ein wenig anders.

2 „Gefällt mir“

Auf sn-sense war eine falsche Version von batman-adv installiert (2014.3 anstatt 2013.4). Dadurch konnte diese VM nicht korrekt mit dem restlichen Netz kommunizieren. Korrekte Version von batman-adv installiert, jetzt sieht es wieder besser aus. PS: Nebenbei 90 Knoten hinzugewonnen.

4 „Gefällt mir“

In diesem Artikel habe ich übrigens angefangen die Tunnel-IPs zu dokumentieren: https://freifunk-muensterland.de/wiki/doku.php?id=intern:tunnelips

1 „Gefällt mir“

Domäne-02: Domäne-02 kann getestet werden

1 „Gefällt mir“

Habe tunnel zwischen fanlin <> ffwaf-srv3 in Betrieb genommen. Damit hängt Warendorf jetzt so drin:

des1 <> ffwaf-srv2 <> ffwaf-srv3 <> fanlin.

Bitte das neue Interface in Ansibel aufzunehmen. ACHTUNG: das Interface heißt “gre-zu-ffwafs3”, denn “gre-zu-ffwaf-srv3” war zu lang; eins der Skripte hat sich beschwert.

Habe auf fanlin etckeeper installiert.

Einen Fehler in gefunden (/etc/network/interfaces.d/*):

in den interfaces.d muss das “post-down ip link delete $IFACE” im inet6 Anteil erledigt werden. Steht das schon im inet4 Anteil, dass sind schlage einige down Anteile im inet6 fehl. Vergleiche 41_gre-zu-sense-03.cfg und 41_gre-zu-ffwaf-srv3.cfg. Bitte das im Ansibel zu korrigieren!

Den Tunnel des1 <> ffwaf-srv3 habe ich deaktiviert.

Das ganze Interface ist doch schon weg, wenn ip link del gemacht wird. Braucht man nochmal ip -6 link del? Oder löscht das Routingeinträge?

Im inet6-Abschnitt von 41_gre-zu-ffwaf-srv3.cfg steht jetzt

post-down ip link delete $IFACE

Wenn das im inet-Abschnitt steht (wo es vorher stand), wird es zu früh ausgeführt.
Das muss in den anderen Dateien auch noch angepasst werden.

1 „Gefällt mir“

Ich habe jetzt die Service-VM etwas weiter konfiguriert (ansible-ffms-Branch ffservice). Die Karte ist schon unter http://89.163.231.228/map/ erreichbar, enthält aber nur legacy und Warendorf, da die gretap-Tunnel noch fehlen. Außerdem fehlt batctl und wäre im Repository nur in Version 2014.3.0-2 verfügbar. Ich dachte, wir hätten mit Debian8 ein aktuelles batman (Kernel ist 3.16.7-ckt11-1+deb8u6)? Muss ich noch was zusätzlich installieren? Oder kann man ein altes batctl weiterverwenden?

2 „Gefällt mir“

Routing der zusätzlichen IPs vom Host greyworm gefixt.

Siehe https://freifunk-muensterland.de/wiki/doku.php?id=intern:infrastruktur:greyworm#besonderheiten_zu_beachten

1 „Gefällt mir“

@Fungur: Batctl musst du immer manuell installieren. Ich habe dazu die Ansible-Rolle im Entwicklungszweig kürzlich angepasst.

Können wir uns darauf einigen, dass hier nur Admin-Tätigkeiten geschrieben werden, und bei der ersten Frage zu einer Sache direkt ein neuer Thread auf gemacht wird? Bitte hier keine Antwort sondern einfach machen :wink: THX

3 „Gefällt mir“

greyworm: VMs waren down, keine Ahnung warum. Bevor ich ergründen konnte warum hat “Trigger-Finger” @mpw den host gebootet. :wink: Was ich aus den Augenwinkel gesehen habe ist das die VMs durchaus nach Boot hochlaufen, es muss sie also irgendein Ereignis runtergeholt.
Merke auf: Beim nächsten mal erst ins Log schauen bevor man reset drückt :smile:

Komischerweise hat der Reboot nicht geklappt, Host hing (reset).
Dabei die VMs von 4Gb auf 1Gb RAM reduziert - mehr als genug.

greyworm unter VMWare neu aufgesetzt. greyworm-1 bereitgestellt, keys drauf. Bon Voyage!

1 „Gefällt mir“

Habe ich wohl vergessen zu erwähnen: greyworm-2 und greyworm-3 sind auch ready mit Schlüsseln daruf. greyworm-4 mache ich gerade noch “auf Halde”, dann sind mir auch die IPs ausgegangen.

3 „Gefällt mir“