@FanLin: Ich nehme an, du hattest den reboot zeitgesteuert gesetzt? War bisschen witzig, als die Kiste auf einmal meinte, dass sie jetzt neu startet ;).
Nach @FanLin s Neustart liefen die DHCP-Server irgendwie nicht mehr und DNS war auch noch kaputt. Ich hatte jetzt keine Zeit mehr das zu untersuchen und hab die DHCP-Server neu gestartet und zur Sicherheit 8.8.8.8 und die üblichen dazu eingetragen.
/edit: Kurze Analyse hat ergeben, dass es vermutlich nur am DHCP lag.
Zu erledigen: Google-DNS-Server wieder rausschmeißen und DHCP automatisch starten lassen
Leider liefen die DHCP-Server halt nicht. Warum weiß ich auch nicht genau. Eventuell klappt da etwas mit der Ramdisk nicht oder es ist etwas ganz anderes.
Falls du Fussel nochmal neu startest, bedenke bitte, dass die default-ip-v6-Route per Hand gesetzt werden muss.
Service-VM angepasst: Neuer Meshviewer mit Statistik-Graph und Offline-Knoten im Hintergrund. In der Gesamtkarte kann man dabei auch die Domäne der einzelnen Knoten sehen.
Karte in der Hauptseite auf Gesamt-Daten umgestellt.
ffwaf-srv2 ist heute morgen gestorben. Da ich am monitoren war, habe ich es nach 10min gemerkt. Via VNC-Konsole resettet.
ffwaf-srv3 ist heute abend gestorben. Reset via VCN-Konsole nicht möglich. Nach Eingriff von Hoster alles wieder in Ordnung.
Da dann alle Knoten auf ffwaf-srv2 waren habe ich die Gelegenheit genutzt und die beiden batmans via tap verbunden. Konfiguration ist jetzt fast identisch zu anderen Maschinen.
Leider häufen sich die Abstürze. @MPW hat sich bereit erklärt die Resets über Console auch durchzuführen. Ich werde im dafür die Passwörter vom Hoster aushändigen.
Backbone Rollen für Backbone-Server durchgetestet und angepasst.
Die Vergabe der IP Adressen für die Tunnel zwischen Backbone und Domänen muss jetzt nicht mehr statisch vorgegeben werden, sondern erfolgt nach folgendem Prinzip: 192.168.[Domänen-ID*10+BB-Server-ID].[SN-Server-ID*4]/30 (+1 für bb server, +2 für gw)
Die Rollen auf Backbone-Server c1024 ausgerollte. Jedoch noch nicht auf der anderen Seite eingebunden. Beim Tunnel zum ffrl gab es auch noch Probleme. Mit einem weiteren Augenpaar noch mal anschauen…
DHCP Server war auf remue-01 und greyworm-01 down: Jan 10 04:38:40 remue-01 dhcpd[16627]: receive_packet failed on bat0: Network is down
und Jan 10 04:39:14 greyworm-01 dhcpd[28775]: receive_packet failed on bat0: Network is down
DHCP Server neu gestartet, jetzt werden wieder Leases verteilt. Jemand eine Ahnung, was da passiert sein könnte (fanlin-03 war nicht betroffen)?
Gegen 11:00 Uhr habe ich dhcpd/radv so umgestellt, dass die DNS-Server der Clients wieder auf google-Server zeigen. Hintergrund ist, dass der lokale DNS am 4.Januar angestellt worden ist und die Crashes am 4ten angefangen haben. Erster Absturz war jedoch am 3ten Januar vor der Installation vom bind9 (DNS-Server). Es ist ein Versuch die Server wieder zu stabilisieren.
ffwaf-srv2: 12:15 - 15:55
ffwaf-srv3: 14:50 - 15:50 (dadurch Totalausfall in Warendorf)
Alles Pakete die bei up/down von Interfaces Aktionen ausführen, die möglicherweise das Hinzufügen/Entfernen der (l2tp-)Interfaces beeinflussen. Weiter geht es mit dem Abwarten. Außerdem:
sysctl kernel.panic=3
Das soll dazu führen, dass die Server bei einem Crash nach drei Sekunden wieder starten. Der Eintrag wurde über /etc/sysctl.d/10-panic.conf auch permanent eingetragen.
Ich habe heute morgen den master nach entwicklungszweig gemerged und danach zusammen mit den anderen Admins noch folgende Änderungen in Ansible gemacht:
Neues Namensschema für Tunnel: tun=Tunnel zu RL, gre=Tunnel BB-GW, tap=Gretap
yml-Dateien enthalten Tags für jede Rolle, so dass man Rollen einzeln ausführen oder skippen kann
bind-Master für die neuen Domänen ist jetzt die Service-VM
neue Tunnel, u.a. zum neuen Backbone c1024
Network-Restart-Handler restarten jetzt zusätzlich auch dhcpd
diverse kleine Fixes
Die Änderungen wurden auf allen neuen Domänen- und Backbone-Servern ausgerollt. Danach wurde der entwicklungszweig nach master gemergt.
Mit dem passenden Repo wurden bird und bird6 jetzt auch auf Parad0x und Fusselkater auf Version 1.5.0 aktualisiert. Die Konfiguration brauchte ein paar Anpassungen:
Alles auf Tabelle ffnet umgestellt
Funktionen funktionieren scheinbar nicht richtig, wenn sie mit einem Semikolon beendet werden, daher entfernt
Außerdem wurde an Parad0x der Fra-Tunnel abgeschaltet, da er bis auf weiteres ohnehin nicht zur Verfügung steht.
Beide haben jetzt wieder eine direkte Standardroute für IPv6 und sich gegenseitig als Reserve.
Damit funktioniert IPv6 jetzt wieder richtig in der alten Domäne ohne manuell gesetzt Routen.
Ich habe mit erlaubt den Tunnel zwischen Fanlin/ffwaf-srv3 zu ändern. Dort ist jetzt eine MTU von 1280. Das ein Strohhalm an den ich mich klammere: Auf ffwaf-srv3 war vor dem Start der Crashes eine 1280 definiert.
Diese Konfiguration war (analog) schon für ipv4 definiert und findet man so auch auf des1. Sie sogt dafür, dass Geräte, die Ihre MTU (trotz Hinweis von dhcpd/radvd) nicht auf 1280 setzen, zumindest bei tcp Verbindungen trotzdem ordentlich arbeiten können.
Ich habe diese Änderung wieder zurückgedreht. Begründung:
1 - Die DHCP-Server laufen im failover-mode. Im Syslog habe ich beobachtet, wie clients keine IP-Adresse bekamen:
Jan 13 15:52:39 ffwaf-srv2 dhcpd: DHCPDISCOVER from d0:ae:ec:x via dom1-mesh: load balance to peer ffwaf-dom1
Jan 13 15:52:42 ffwaf-srv2 dhcpd: DHCPDISCOVER from d0:ae:ec:x via dom1-mesh: load balance to peer ffwaf-dom1
Jan 13 15:52:42 ffwaf-srv2 dhcpd: DHCPDISCOVER from 64:b3:10:x via dom1-mesh: load balance to peer ffwaf-dom1
Jan 13 15:52:43 ffwaf-srv2 dhcpd: DHCPDISCOVER from 44:d9:e7:x via dom1-mesh: load balance to peer ffwaf-dom1
Jan 13 15:52:45 ffwaf-srv2 dhcpd: DHCPDISCOVER from d0:ae:ec:x via dom1-mesh: load balance to peer ffwaf-dom1
Jan 13 15:52:46 ffwaf-srv2 dhcpd: DHCPDISCOVER from 44:d9:e7:x via dom1-mesh: load balance to peer ffwaf-dom1
Laut Log von ffwaf-srv3 kam gleichzeitig dort nichts an. Ich gehe davon aus, dass Batman die Pakete schlicht nicht weiter/duchgeleitet hat, in der Annahme, dass ffwaf-srv2 die ja beantworten würden.
2 - Mit der Rücknahme der Änderung, bin ich wieder näher an der bis zum 3. Januar stabilen Konfigurtion (die aktuellen Crashes in Warendorf …)
ip -6 rule add fwmark 1 table ffnet
ip6tables -t mangle -A PREROUTING -i tun-+ -j MARK --set-mark 1
sysctl net.ipv6.fwmark_reflect=1
Hintergrund:
Ein traceroute führt ohne das zu folgendem:
traceroute to 2a03:2260:115:fe03:900c:9d04:a92:41b (2a03:2260:115:fe03:900c:9d04:a92:41b), 30 hops max, 80 byte packets
1 gtso1-srv1-eth1-vlan3.net.vitroconnect.de (2a00:e180:cafe:3::1) 1.749 ms 1.732 ms 1.711 ms
2 dsdf1-cr2-gige-0-1-0-16-v101.net.vitroconnect.de (2a00:e180:ffff:5::1) 5.470 ms 5.477 ms 5.489 ms
3 freifunk.dus.ecix.net (2001:7f8:8:0:3:13e5:0:1) 4.770 ms 4.778 ms 4.906 ms
4 2a03:2260:0:e2::2 (2a03:2260:0:e2::2) 16.479 ms 16.487 ms 16.524 ms
5 **ffmstd-des1.ffms.w-root.de (2a01:4f8:162:10d2:5:23:dead:c0de) 20.966 ms 20.948 ms 21.034 ms**
6 2a03:2260:115:fe02::6 (2a03:2260:115:fe02::6) 41.046 ms 39.451 ms 39.454 ms
7 2a03:2260:115:fe03:900c:9d04:a92:41b (2a03:2260:115:fe03:900c:9d04:a92:41b) 80.279 ms 80.942 ms 86.562 ms
In Hop 5 antwortet des1 mit seiner eth0 Adresse, statt seiner freifunk-Adresse. net.ipv6.fwmark_reflect=1 führt dazu, das icmp-pakete mit der fwmark belegt werden, die das Paket hatte, das den icmp ausgelöst hast. Werden über ffrl eingehenede Pakete markiert (via ip6tables) sorgt die rule dafür, dass das Paket über den richtigen weg wieder zurück geht:
traceroute to 2a03:2260:115:fe03:900c:9d04:a92:41b (2a03:2260:115:fe03:900c:9d04:a92:41b), 30 hops max, 80 byte packets
1 gtso1-srv1-eth1-vlan3.net.vitroconnect.de (2a00:e180:cafe:3::1) 1.660 ms 1.644 ms 1.624 ms
2 dsdf1-cr2-gig0-1-0-0-101.net.vitroconnect.de (2a00:e180:ffff:5::1) 5.659 ms 5.666 ms 5.665 ms
3 freifunk.dus.ecix.net (2001:7f8:8:0:3:13e5:0:1) 4.735 ms 4.743 ms 4.825 ms
4 2a03:2260:0:e2::2 (2a03:2260:0:e2::2) 16.456 ms 16.464 ms 16.501 ms
5 **2a03:2260:0:cc::2 (2a03:2260:0:cc::2) 34.472 ms 34.480 ms 34.561 ms**
6 2a03:2260:115:fe02::6 (2a03:2260:115:fe02::6) 41.001 ms 39.511 ms 39.515 ms
7 2a03:2260:115:fe03:900c:9d04:a92:41b (2a03:2260:115:fe03:900c:9d04:a92:41b) 81.114 ms 84.142 ms 82.577 ms
Beachte Hop5: Antwort kommt von interface tun-ffrl-ber1. Ich habe das testweise auf des1 installiert. Falls ich was damit kaputt gemacht habe, grillt mich. Würde das so ansibelisieren.
Habe gerade, auf den FanLin-Maschinen, das is-dhcp*-Sicherheitsupdate DSA-3442 eingespielt.
Bitte spielt das Update auch auf die anderen Kisten auf.
Ist es eigentlich richtig, daß auf sn-fanlin-1 und -2 kein dhcp mehr läuft?
