Admintagebuch - Dokumentation der Admintätigkeiten

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.

Gerade das hab ich extra gefiltert, weil sonst teilweise die per OSPF gelernte, fremde Route über BGP bevorzugt wurde.

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

3 „Gefällt mir“

Habe grad, auf allen FanLin-Maschinen, das SSH-Sicherheitsupdate DSA-3446 eingespielt.
Bitte aktuallisiert die anderen Kisten.

Außerdem ist ein Wordpress Sicherheitsupdate für Debian raus: DSA-3444

@void, @Parad0x, @MPW, @Fungur, @kgbvax, @descilla, @FanLin, @paulinsche

2 „Gefällt mir“

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.

Simon guckt sich das im Ansible nochmal an.

1 „Gefällt mir“

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.

1 „Gefällt mir“

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.

  • In der Ansible-Rolle für die Rheinlandanbindung fehlten ip rules, im master korrigiert und auf Des1 ausgerollt
  • In backbone.yml bird deaktiviert, da die AS-Nummer für Des1 falsch gesetzt werden würde
  • Einführung für @scroom in die Routenführung des FFML

Ich würde einfach in den host_vars von des1 die abweichende AS Nummer setzen.

Paketverluste auf fanlin:

[860266.975112] nf_conntrack: table full, dropping packet
[860266.975370] nf_conntrack: table full, dropping packet
[860266.975374] nf_conntrack: table full, dropping packet
[860266.975655] nf_conntrack: table full, dropping packet

Habe das kurz gefixt:

echo 65536 > /proc/sys/net/nf_conntrack_max 

Verweise hier kurz auf NAT Tables Sizing … Habe auch auf des1 den Wert hochgedeht. Bitte das zu ansibelisieren…

@descilla hat das Problem mit den Paketverlusten gerade behoben.

Die common-Ansible-Rolle kopiert jetzt automatisch die status.pl nach /root/, weil man die doch häufiger mal braucht.

  • Domäne-01: Remü-08 wieder entfernt, da die zusätzliche Kiste ohne spezielles Routing nur Quertraffic verursacht hat.
  • Überflüssige Tunnel abgerissen, sodass jedes Gateway nur noch einen Anschluss ans Backbone hat
  • IPv4-Bereiche der DHCP-Server wieder auf die Einstellungen von Ansible-Master zurückgedreht

Remü-08 abgeschaltet.

Hoffe, es läuft dort jetzt wieder besser.

Und falls jemand den Überblick verloren hat:

Ansible Master ist jetzt auf Commander, Fanlin und Des1 ausgerollt.

1 „Gefällt mir“

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).

Jetzt sollte es wieder laufen.

Grüße
Matthias

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!

2 „Gefällt mir“

Service-VM: Letsencrypt-Zertifikat für https://service.freifunk-muensterland.de/ und https://karte.freifunk-muensterland.org/ installiert, inkl. Ansible und Cron-Job für Zertifikatserneuerung.

2 „Gefällt mir“

Hallo,

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;
};

Grüße
Matthias

1 „Gefällt mir“

Neu auftretende Fehler mit apt kann man wie folgt beheben: