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.
Aye aye Sir. 
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.
Ich habe den Beitrag in ein vorhandenes Thema verschoben: Ffwaf-srv2/3 - neuerdings mit regelmäßigen crashes
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…
Remue-05 und 06 konfiguriert, noch keine Backboneanbindung
Fanlin-03 konfiguriert, ist beim GRE-Tunnel ziehen abgestürzt.
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)?
Wieder Server-Ausfälle in Warendorf:
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.
Danach folgende Änderungen durchgeführt:
Diese Pakete deinstalliert:
-bind9 1:9.9.5.dfsg-9+deb8u4
-bind9utils 1:9.9.5.dfsg-9+deb8u4
-resolvconf 1.76.1
-vnstat 1.12-2
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:
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:
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.
Noch eine Änderung (auf fanlin):
ip6tables -t mangle -A POSTROUTING -o tun-+ -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss ! --mss 0:1220 -j TCPMSS --set-mss 1220
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 …)
Auf des1 fehlten folgende Regeln:
ip -6 rule add iif tun-ffrl-ber1 table ffnet
ip -6 rule add iif tun-ffrl-fra1 table ffnet
Habe sie manuell eingetragen.
Ich schlage vor folgendes umzusetzen:
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?
Fehlende ip rule Regeln für v4 und v6 für br0 und tun-ffrl-{ber,dus} auf Fussel in die interfaces-Datei eingetragen.
Auf greyworm-01 funktionierte das Routing ins Backbone nicht korrekt. Das Gateway ist an fanlin und des1 angebunden. Auf des1 erscheinen folgende Fehlermeldungen im syslog:
Jan 14 17:56:39 des1 kernel: [68858.951743] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:39 des1 kernel: [68858.981647] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:39 des1 kernel: [68858.981655] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:39 des1 kernel: [68858.981663] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:39 des1 kernel: [68858.982002] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:43 des1 kernel: [68862.927845] net_ratelimit: 60 callbacks suppressed
Jan 14 17:56:43 des1 kernel: [68862.927869] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:48 des1 kernel: [68867.390399] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:48 des1 bird: Netlink: File exists
Jan 14 17:56:48 des1 kernel: [68867.915316] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:48 des1 kernel: [68867.915548] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:48 des1 kernel: [68867.926220] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:48 des1 kernel: [68867.947544] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:48 des1 kernel: [68867.970042] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:48 des1 kernel: [68868.185767] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:48 des1 kernel: [68868.185801] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:48 des1 kernel: [68868.185826] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:53 des1 kernel: [68872.433622] net_ratelimit: 66 callbacks suppressed
Jan 14 17:56:53 des1 kernel: [68872.433629] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:53 des1 kernel: [68872.449299] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:53 des1 kernel: [68872.463469] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:53 des1 kernel: [68872.497663] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x29
Jan 14 17:56:53 des1 kernel: [68872.500202] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x29
Jan 14 17:56:53 des1 kernel: [68872.576135] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x29
Jan 14 17:56:53 des1 kernel: [68872.635288] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:53 des1 kernel: [68873.030610] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:53 des1 kernel: [68873.225020] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:54 des1 kernel: [68873.388555] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:58 des1 kernel: [68877.489814] net_ratelimit: 26 callbacks suppressed
Jan 14 17:56:58 des1 kernel: [68877.489838] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:58 des1 kernel: [68877.501589] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Jan 14 17:56:58 des1 kernel: [68877.519068] ip_tunnel: non-ECT from 89.163.247.45 with TOS=0x2a
Mit ip l del gre-des1 bzw. ip l del gre-greyworm-01 Tunnel temporär eingerissen. Jetzt geht der Traffic wieder über fanlin und es scheint zu funktionieren.
sysctl net.ipv4.tcp_ecn meldet auf beiden (und anderen) Systemen net.ipv4.tcp_ecn = 2. Ggf. können wir dem Problem heute in der Admin-Runde nachkommen (werde es heute vermutlich nicht zur Admin-Runde schaffen).
Außerdem ist uns aufgefallen, dass die zusätzlichen Anbindungen ans Backbone (die für Ausfallsicherheit sorgen sollten). Viel “Quertraffic” auf den Gateways verursachen. Wir müssen hier schauen, ob wir hier spezifischere Routen announcen wollen, doch keine Redundante Anbindung wollen oder noch eine andere Idee haben.
Ich habe den ipv4-bgp auf des1 deaktiviert. Dann müssen nicht alle anderen die Tunnel zu des1 runter fahren. ipv6-tunnel zum ffrl läuft.
Anstellen geht im birdc:
enable „ffrl_ber1“
Vielleicht routet ffrl die 185.66.193.52 gerade nicht, denn
Tracing the route to 185.66.193.52
1 89.187.208.146 2 msec 0 msec 0 msec
2 194.146.118.149 !N !N *
Fanlin ist in Ordnung:
Tracing the route to 185.66.193.49
1 89.187.208.146 1 msec 0 msec 0 msec
2 194.146.118.149 0 msec 0 msec 0 msec
3 * *
des1 hat jetzt keine default-route mehr für ipv4, könnte sie theoretisch aber lernen (von anderen ospf-sprechern).
IPv6 in Domäne 3 gefixt. Das /64 netz worde zurück zu fanlin geworfen, da es nicht von bat0 erkannt wurde.