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.
Graphite ist jetzt auf Version 0.9.15 aktualisiert, die Datenbanken habe ich durchkonvertiert.
Die Statistiken scheinen jetzt frei von Lücken zu sein.
Aktuell ist alles in “node” und “nodes” auf 1-Minutem Auflösung
Der Rest ist noch auf 10-Sekunden Auflösung, hie werde ich erst einmal noch etwas die Serverlast beobachten
Mit Hilfe von Lars läuft das IPv4 auf Des1 jetzt wieder. Das lo mit der Nat-IP hatte statt /32 nur /30 und wurde daher von dem filter hostroute im bird verspeist.
Wieder des1: diesmal fehlte die ipv4 rule für eingehende Pakete auf tun-ffrl-*
root@des1 ~ # ip rule
0: from all lookup local
32752: from 185.66.193.52 lookup ffnet
32753: from all iif gre-remue-01 lookup ffnet
32754: from all iif gre-ffwaf-srv2 lookup ffnet
32755: from all iif gre-parad0x-01 lookup ffnet
32756: from all iif gre-greyworm-02 lookup ffnet
32757: from all iif gre-greyworm-01 [detached] lookup ffnet
32758: from all iif gre-remue-06 lookup ffnet
32759: from all iif gre-remue-05 lookup ffnet
32760: from all iif gre-remue-04 lookup ffnet
32761: from all iif gre-remue-03 lookup ffnet
32762: from all iif gre-remue-02 lookup ffnet
32764: from all iif bruecke-alt-neu lookup ffnet
32765: from all iif lo lookup ffnet suppress_prefixlength 0
32766: from all lookup main
32767: from all lookup default
So sah es aus. Fix ging so:
root@des1 ~ # ip rule add iif tun-ffrl-ber1 table ffnet
Habe das in /etc/network/interfaces.d/ eingetragen, aber das wir durch den nächsten Anibel-Lauf wieder überschrieben. Bitte das dort zu fixen.
ServiceVM: create_map_data.sh von Git-Repository tools nach ansible-ffms umgezogen und dabei angepasst: altes Warendorf raus, Beschreibungen der Domänen hinzugefügt.
Münsterland-Domäne repariert. Auf Parad0x war die bird.conf für v4 falsch und daher gab es keine V4-Standardroute und es ging nur V6 durch. Fussel war dadurch stark ausgelastet (> 60 Mbit/s).
Stabilität geht vor Geschwindigkeit. Ich weiß mir aktuell nicht anders zu helfen, als in Domäne-14 lt2p wieder abzustellen und fastd anzumachen (upload der images erfolgt gerade). Bitte auch an @Alucardo, das latest-Image zu installieren, sobald es verfügbar ist (baue gerade, und werde an einer Stelle noch testen können).
Habe zuvor die Kette experimental -> beta -> stable gebaut, einige von Hand migriert und auch ein paar autoupdates geschehen lassen. Wünscht mit viel Glück und drängt die übrigen Aktiven in Warendorf dazu mich dazu zu zwingen die Verantwortung für das Netz in Warendorf abzugeben!
ich hab heute Nacht spezifischeres Routen für IPv4 implementiert, sodass die Backbone-Server, falls sie mehrere Tunnel zu einer Domäne haben, anhand der DHCP-Bereiche der Gateways schon eine Vorentscheidung treffen, wohin die Pakete gehen sollen.
Die Problematik ist folgende: Querverkehr durch das Batmannetz lähmt die Verbindung extrem.
Wenn es also die folgende Konstellation gibt:
Backboneserver
|-> Gateway A
| | (Gretap)
|-> Gateway B
Dann haben wir immer Querverkehr. Entweder schickt der Backboneserver alles zu Gateway A und alles, was zu B gemusst hätte, wird durch den Gretap-Tunnel zurück geschoben. Oder umgekehrt.
Daher können wir derzeit pro Domäne nur #Gateways <= #Backbones bauen, damit jeder eine direkte und eindeutige Verbindung hat. Das ist natürlich nicht im Sinne des Erfinders.
Also wird per ipcalc der DHCP-Bereich im Ansible aufgeteilt und dann in Bird als statische Routen angelegt. Diese werden dann über OSPF ans Backbone geschickt.
Das ist jetzt im Ansible-Zweig spezifischeres_Routen mal umgesetzt (mit Simons Hilfe) und auf der Domäne-01 ausgerollt. Für IPv6 wird das ganze noch etwas komplizierter denke ich.
Hier ein Beispiel von Remü-01:
protocol static dhcp_Bereich {
table ffnet;
route 10.43.8.2/32 via "bat0";
route 10.43.8.26/31 via "bat0";
route 10.43.8.28/30 via "bat0";
route 10.43.8.32/27 via "bat0";
route 10.43.8.64/26 via "bat0";
route 10.43.8.128/25 via "bat0";
route 10.43.9.0/24 via "bat0";
route 10.43.10.0/25 via "bat0";
route 10.43.10.128/27 via "bat0";
route 10.43.10.160/32 via "bat0";
}
OSPF-Filter:
export filter {
if source=RTS_STATIC_DEVICE then accept;
else reject;
};