Mea culpa. Der geplante automatisierte Neustart lief nicht, da sich mein Laptop aufgehängt hatte. Also hab ich den VirtHost an besagtem Tag manuell rebootet und im Grafana danach nix auffälliges gesehen. Posting hier hab ich verduselt; sorry.
Habe grad auf allen FanLin-Büchsen, Commander1024 und Des1 u.a. das Bind9-Sicherheitsupdate DSA-3511 eingespielt. Habe grad wenig Zeit, wäre super wenn jemand™ die anderem Maschinen versorgt. @Parad0x, @descilla, @Fungur, @MPW, @FanLin, @kgbvax, @void, @paulinsche
EDITH:
sn-greyworm-1 bis -4 und sn-remue-01 bis -08 hab ich grad auch schon verarztet. Der Rest muß noch …
Nachdem mein rudimentäres Monitoring häufiger Ausfälle gemeldet hat, habe ich den ffwaf-srv4 mal gebootet in der Hoffnung, dass sich nur was verschluckt hat…
Spezifischeres Routing auf Domäne 08 ausgerollt, in der Hoffnung, dass der Durchsatz durch korrektes Routing besser wird.
@Fungur, @descilla und ich haben heute angefangen den Umbauplan für Ansible Richtung [Multidomänen-L2TP][1] umzusetzen. Wie weit wir gekommen sind, könnt ihr dem Git entnehmen:
Außerdem wurde die Installation der status.pl noch von der common-Rolle in die fastd-Rolle verschoben.
Zum Testen des Multidomänen-L2TP-Batman-Ansible haben wir die VMs Greyworm-06 und Fanlin-02, sowie die IPs der Domänen 09 und 10 genommen.
Alle Gateway-Server, die mit des1 verbunden sind hatten im syslog kontinuierlich Meldungen dieser Art stehen:
Mar 15 06:25:05 remue-01 kernel: [4165459.119802] net_ratelimit: 64 callbacks suppressed
Mar 15 06:25:05 remue-01 kernel: [4165459.119825] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:05 remue-01 kernel: [4165459.119941] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:05 remue-01 kernel: [4165459.119944] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:05 remue-01 kernel: [4165459.229973] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:05 remue-01 kernel: [4165459.230014] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:05 remue-01 kernel: [4165459.250150] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:05 remue-01 kernel: [4165459.250165] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:05 remue-01 kernel: [4165459.281930] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:05 remue-01 kernel: [4165459.415657] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:05 remue-01 kernel: [4165459.424296] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:12 remue-01 kernel: [4165466.100622] net_ratelimit: 24 callbacks suppressed
Mar 15 06:25:12 remue-01 kernel: [4165466.100627] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:12 remue-01 kernel: [4165466.342335] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:12 remue-01 kernel: [4165466.348441] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:13 remue-01 kernel: [4165467.009646] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:14 remue-01 kernel: [4165468.276497] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:16 remue-01 kernel: [4165470.878291] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:16 remue-01 kernel: [4165470.878832] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:16 remue-01 kernel: [4165470.878946] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:16 remue-01 kernel: [4165470.878953] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:16 remue-01 kernel: [4165470.888180] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:20 remue-01 kernel: [4165474.465305] net_ratelimit: 2 callbacks suppressed
Mar 15 06:25:20 remue-01 kernel: [4165474.465322] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.415861] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.785980] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.791873] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.797889] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.803754] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.840556] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.841506] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.896428] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x2
Mar 15 06:25:21 remue-01 kernel: [4165475.898563] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:35 remue-01 kernel: [4165489.288017] net_ratelimit: 9 callbacks suppressed
Mar 15 06:25:35 remue-01 kernel: [4165489.288032] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:45 remue-01 kernel: [4165499.297453] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Mar 15 06:25:52 remue-01 kernel: [4165506.396447] ip_tunnel: non-ECT from 5.9.86.144 with TOS=0x1
Nachdem ich die komplette konfiguration auf des1 geprüft habe, weder Einträge im syslog auf des1 noch Hinweise zu dem Problem im Internet gefunden habe (außer) und der Ursprung der Meldung im Linux Kernel zu finden war, habe ich ein Kernel-Downgrade von 4.3 auf 4.2 durchgeführt. Und tadaa: Fehler(-meldung) weg. (Fehler war, dass wohl ToS Flags an Pakete gesetzt wurden, das ECT Flag aber nicht gesetzt war. Außer die Quittierung im syslog hatte dieser Fehler wohl keine (großartige) Auswirkung.)
Das Problem hatte aber nicht zur Ursache, dass auf des1 vergleichsweise wenig Traffic durchgeht, da bin ich aber auch dran.
Das Remue-Blech scheint wohl gestern Morgen neu gestartet worden zu sein. Zumindest waren die fastd Connections recht ungleich verteilt. Ich habe dies ausgeglichen.
URL verweist nun nicht mehr auf [...]/stable/[...], sondern auf [...]/versions/{version}/[...]. Da das Umstellen auf Stable nicht direkt mit dem FW-Downloader-Assistenten zusammenhängt ist so sichergestellt, dass die Links weiterhin funktionieren.
Workaround für Firefox im Umgang mit Hover auf Multipolygone eingebaut
Code muss weiterhin noch mal in schön geschrieben werden (ich hoffe, dass ich bald dazu komme)
Für Domäne 08 auf desvm-01 vorkonfiguriert (noch nicht an andere Maschinen verdrahtet), falls die Performance-Probleme auf dray-01 bestehen bleiben kann dieser als Ersatz verwendet werden.
Domäne 11 auf den VMs desvm-02 und greyworm-07 konfiguriert und ans FFMS-Backbone angebunden. site-ffms für Domäne 11 konfiguriert. Die Firmware wird die Tage von @Alucardo gebaut.
(Teil-)Ursache für komische Last-Verteilung und komische Routen im Backbone / BB<->GW gefunden:
Die most specific routen, die über OSPF announced wurden passten nicht mit dem überein, was als DHCP Range auf den GWs eingestellt war. Daher gab es Überschneidungen, die dann quer geroutet wurden:
Es war jedoch kein Programmatischer Fehler oder Konfigurationsfehler. Es scheint, dass die Ranges angepasst wurden, anschließend jedoch lediglich die bird Rolle ausgeführt wurde, nicht jedoch die dhcp rolle.
Ich habe das nun nachgeholt:
TASK [dhcp : create dhcp config] ***********************************************
changed: [greyworm-01]
--- before: /etc/dhcp/dhcpd.conf
+++ after: dynamically generated
@@ -1,16 +1,16 @@
# This file is managed by ansible, don't make changes here - they will be overwritten.
default-lease-time 240;
max-lease-time 1200;
authoritative;
-log-facility local6;
+log-facility local7;
subnet 10.43.8.0 netmask 255.255.248.0 {
- range 10.43.13.67 10.43.15.254;
+ range 10.43.12.1 10.43.13.255;
option routers 10.43.8.4;
option domain-name-servers 10.43.8.4;
option interface-mtu 1280;
}
changed: [remue-01]
--- before: /etc/dhcp/dhcpd.conf
+++ after: dynamically generated
@@ -1,16 +1,16 @@
# This file is managed by ansible, don't make changes here - they will be overwritten.
default-lease-time 240;
max-lease-time 1200;
authoritative;
-log-facility local6;
+log-facility local7;
subnet 10.43.8.0 netmask 255.255.248.0 {
- range 10.43.8.26 10.43.10.160;
+ range 10.43.8.26 10.43.9.255;
option routers 10.43.8.2;
option domain-name-servers 10.43.8.2;
option interface-mtu 1280;
}
changed: [fanlin-03]
--- before: /etc/dhcp/dhcpd.conf
+++ after: dynamically generated
@@ -1,16 +1,16 @@
# This file is managed by ansible, don't make changes here - they will be overwritten.
default-lease-time 240;
max-lease-time 1200;
authoritative;
-log-facility local6;
+log-facility local7;
subnet 10.43.8.0 netmask 255.255.248.0 {
- range 10.43.10.161 10.43.13.66;
+ range 10.43.10.1 10.43.11.255;
option routers 10.43.8.3;
option domain-name-servers 10.43.8.3;
option interface-mtu 1280;
}
Grund für bird logging spam im syslog auf des1 gefunden.
Mar 17 06:26:27 des1 bird: Netlink: File exists
Mar 17 06:27:27 des1 bird: Netlink: File exists
Mar 17 06:28:26 des1 bird: Netlink: File exists
Mar 17 06:29:27 des1 bird: Netlink: File exists
Mar 17 06:30:27 des1 bird: Netlink: File exists
Mar 17 06:31:27 des1 bird: Netlink: File exists
Mar 17 06:32:27 des1 bird: Netlink: File exists
Mar 17 06:33:26 des1 bird: Netlink: File exists
Mar 17 06:34:27 des1 bird: Netlink: File exists
Mar 17 06:35:27 des1 bird: Netlink: File exists
Mar 17 06:36:27 des1 bird: Netlink: File exists
Mar 17 06:37:27 des1 bird: Netlink: File exists
Mar 17 06:38:27 des1 bird: Netlink: File exists
Mar 17 06:39:27 des1 bird: Netlink: File exists
Mar 17 06:40:27 des1 bird: Netlink: File exists
Mar 17 06:41:27 des1 bird: Netlink: File exists
Mar 17 06:42:27 des1 bird: Netlink: File exists
Mar 17 06:43:27 des1 bird: Netlink: File exists
Mar 17 06:44:27 des1 bird: Netlink: File exists
Mar 17 06:45:27 des1 bird: Netlink: File exists
Mar 17 06:46:26 des1 bird: Netlink: File exists
Grund war eine Alien-Route auf einem nicht mehr genutzten Tunnel: Mar 18 01:20:29 des1 bird: p-kernel-ff: 10.0.1.4/30: [alien] ignored
Ich habe daher das (auf der anderen Seite nicht mehr konfigurierte) Interface iface gre-ffwaf-srv2 abgerissen. Jetzt ist Ruhe.
PS: Auf die Schliche gekommen bin ich dem Ganzen, indem ich im kernel protokol in der bird config debug all eingetragen habe. Anschließend erhält man sehr hilfreiche Status-Meldungen im syslog.
snmp wurde vom Server-Spender dort konfiguriert und läuft daher nicht auf allen Servern. Es scheint wohl einen Bug bzgl. mancher ipv6 Konfigurationen im snmp zu geben. Ich habe die defaults entsprechend diesem bugreport angepasst: https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1246347
Habe gerade festgestellt, dass es außerdem ziemlich wichtig ist, dass man bei gre-tunneln das „ttl 255“ nicht vergisst. Tut man das, dass vererbt sich das ttl des transportieren Pakets, und ein traceroute sieht dann nicht gut aus, oder ein mtr klappt gar nicht:
$ traceroute 10.43.120.33
traceroute to 10.43.120.33 (10.43.120.33), 30 hops max, 60 byte packets
1 10.43.120.33 (10.43.120.33) 39.905 ms 39.979 ms 39.969 ms
Die neun Hop ober kommen zustande, weil …
# traceroute 89.187.208.59
traceroute to 89.187.208.59 (89.187.208.59), 30 hops max, 60 byte packets
1 ffhost01.yadn.de (144.76.30.226) 0.059 ms 0.046 ms 0.040 ms
2 static.113.186.243.136.clients.your-server.de (136.243.186.113) 0.906 ms 1.283 ms 1.372 ms
3 hos-tr6-juniper2.rz19.hetzner.de (213.239.251.161) 0.350 ms hos-tr4.juniper2.rz19.hetzner.de (213.239.231.33) 0.336 ms hos-tr3.juniper2.rz19.hetzner.de (213.239.231.1) 0.330 ms
4 core21.hetzner.de (213.239.245.97) 0.307 ms 0.311 ms core22.hetzner.de (213.239.245.137) 0.295 ms
5 core4.hetzner.de (213.239.245.14) 4.834 ms core1.hetzner.de (213.239.245.218) 4.834 ms core4.hetzner.de (213.239.245.18) 4.839 ms
6 juniper4.ffm.hetzner.de (213.239.245.1) 4.916 ms 5.015 ms 4.987 ms
7 vitroconnect.fra.ecix.net (62.69.146.52) 6.403 ms 5.868 ms 5.947 ms
8 dsdf1-cr1-tgige-0-0-0-0.net.vitroconnect.de (89.187.208.138) 8.581 ms 8.662 ms 8.553 ms
9 ffwaf-srv4.freifunk-muensterland.net (89.187.208.59) 8.110 ms 7.980 ms 7.932 ms
Ich habe jetzt die Service-VM komplett an die neue domaenen-Variable in group_vars/all angepasst, nachdem ich dort die nötigen Einträge für alle Domänen erstellt habe. Teilweise werden aber auch noch die alten Variablen genutzt, so dass die Service-VM sowohl mit “alten” Domänen als auch mit den neuen Multidomänen arbeiten kann.
Virthost FanLin hat sich heute um 04:00 wohl irgendwie verabschiedet. Pingtechnisch ist er irgendwie noch ansprechbar, mehr aber auch nicht. Über das Servermanagementinterface habe ich versucht ihn zu restarten; erfolglos. Der Support ist verständigt und weitere Infos folgen.