Ich habe die Ansible Rolle auf “ffmstd”-des1/des2 ausgerollt. Somit hat nun das gesamte Adminteam auch Zugriff auf “Das Labor” aka domaene-test.
Danach habe ich die entsprechenden host_vars sowie group_vars ins Ansible übertragen. Da es recht unkritisch ist, habe ich es direkt in den Master gepumpt.
Heute waren Simon, Void, Michael, Andreas, Sebastian und ich beim Admintreffen dabei.
- Wir haben eine Ansible-Rolle für bind9 gebaut und die Domäne-01 hat jetzt auch ein eigenes DNS-System
- DHCP-Rolle im Ansible-Master repariert und
- neue DHCP-Bereiche auf die alte Domäne ausgerollt
Jeder der drei derzeit aktiven DHCP-Server verteilt jetzt ein /19 (8190 Adressen), weil wir im Graphana gesehen haben, dass die Leases tatsächlich teilweise am Maximum waren.
Wir hoffen, dass DHCP jetzt deutlich stabiler läuft, bitte melden, wenn es weiterhin keine IP gibt!
Grüße
Matthias
2 „Gefällt mir“
Wie groß war des Range denn vorher? Bzw. welche Server waren am Maximum?
Was mich wundert ist, dass seit der änderung etwa drei mal so viele Clients kein Lease bekommen. Wie es aussieht scheinen die Clients bei einem Range-Wechsel doch etwas länger zu brauchen.
Hier 11:04, keine IP an iOS
Ich habe jetzt den Kernel des Hostsystems von Remü auf Version 4.2 mit dem offiziellen Debian Backports aktualisiert. Wenn das Ding weiterhin abstürzt, müsste man doch mal die VMs stoppen.
root@ffhost01:~# uname -a
Linux ffhost01 4.2.3-2-pve #1 SMP Sun Nov 15 16:08:19 CET 2015 x86_64 GNU/Linux
root@ffhost01:~# uptime
19:13:23 up 0 min, 1 user, load average: 0.46, 0.11, 0.04
Also er wurde am 29.11. um 19:13 Uhr das letzte mal neu gestartet.
Das „Labor“ Warendorf ist jetzt „redundant“ an ffmstd-des1 (via gre) angebunden.
- Batman ist wie in http://www.open-mesh.org/projects/batman-adv/wiki/Bridge-loop-avoidance beschrieben aufgesetzt: ein bridge interface beinhaltet bat0 und ein gretap-interface zum Partner. Richtig funktioniert das nur, wenn die bridge mit „promisc on“ konfiguriert ist.
- DHCP läuft über failover jeweils auf der Bridge. Es kommt zu einem Loadbalancing in der Vergabe. Im IP-Pool heißt es: option routers dom1-mesh-gw.freifunk-muensterland.net; Der Name löst via /etc/hosts jeweils auf die IP-Adresse des jeweiligen Servers auf. Somit wird immer der Router als Gateway vergeben, der auch den Lease rausgerückt hat.
- Beide Server sind unter dem gleichen Namen im DNS eingetragen: ffwaf-dom1.freifunk-muensterland.net
Habe gerade auf parad0x den fastd restartet, um die Knotenverteilung wieder ins Lot zu bringen.
Logging auf parad0x abgeschaltet (wie im Wiki beschrieben).
Loadaverage ist derzeit im akzeptablen Bereich.
1 „Gefällt mir“
Auf host01.yadn.de (remue) auf sda und sdb SMART-Long-Test gestartet, sowie memtester auf den RAM losgelassen.
Morgen mal schauen, ob da was bei raus kommt…
Update: Kernelpanic!
Moin,
@paulinsche und ich haben vorhin versucht das IPv6-Routing zu reparieren. Aus irgendeinem Grund schreibt Bird6 die Defaultroute für die Tabelle 42 nicht in den Kernel. In Bird wird sie mit einem Ausrufezeichen angezeigt und landet auch nicht im Kernel.
Wir wissen nicht genau warum, es gibt auch einen nichtssagenden Fehler im syslog, der höchst wahrscheinlich damit zusammen hängt. Das Problem besteht mindestens auf Fussels und Parad0x’ Gateway.
Wenn man die Defaultroute manuell in den Kernel einträgt, geht das IPv6 wieder. Dies haben wir derzeit als temporäre Lösung gemacht.
Grüße
Matthias
2 „Gefällt mir“
Gestern den lokalen ipv4 exit abgestellt. Dabei nicht überprüft, ob die default-route wieder via ospf angenommen wird. Heute morgen festgestellt, dass ipv4 keine default-route hatte. Ursache: auf ffmstd-des1 war die default-route vorhanden, diese wurde aber nicht ins ospf exportiert und somit nicht verbreitet. Vielleicht ein Bug, weil die mal weg war?
Dann habe ich das ospf neu gestartet.
Dec 3 08:09:27 ffmstd-des1 bird: Reloading protocol p-ospf-ffnet
Seither alles wieder gut. Für den Fall, dass die default-route nochmal weg fällt, habe ich folgendes im bird von ffwaf konfiguriert:
protocol static 'staticffnet' {
table ffnet;
import filter {
if net = 0.0.0.0/0 then { preference = 149; }
accept;
};
export none;
route 0.0.0.0/0 via 134.0.124.33;
};
Protocol static hat ein preferenz von 200, ospf von 150. Hier setze ich die für die default-route auf 149. Die Route wird nur aktiv, falls ich sie aus ospf nicht mehr lerne. Ich verdrehe mir nach wie vor immer wieder den Kopf wenn es um import/export geht, weil ich mir immer wieder die Richtung vor Augen führen muss.
Auf paradox habe ich einfach nicht raus bekommen können, warum die default-route die wir via BGP erhalten aus Sicht des Bird ungültig ist, die nächste Route aber nicht gewählt wird. Ich würde da jetzt ein aktuelles bird „backporten“.
Ich habe gerade den collectd auf kgbvax2 gefixt, zählen der fastd connections ist durch das ansible deployment kaputt gegangen (bei mehreren fastd instanzen funktioniert das alte Verfahren nicht). Da wurde das gepatchte Script leider einfach übergebügelt.
Die Korrektur steht in ansible-ffms als pull request.
Wobei die collectd.config halt auch noch anders aussehen müsste.
Und: Mir ist das mit den 4 Augen nicht so ganz klar, hätte es derer jetzt bedurft?
1 „Gefällt mir“
Reparieren darf man ohne.
1 „Gefällt mir“
\o/
Bericht von heute:
-
Remü-01 hab ich erstmal abgeschaltet. Der Host stürzt ständig ab, Arbeiten auf der Ansible-VM ist praktisch nicht mehr möglich (Michael und Void haben es wohl probiert und soll ziemlich ätzend gewesen sein). Daher habe ich die Remü-01-VM aus der Domäne-01 geschmissen. Dort sind jetzt noch Sense-02 und Greyworm-01.
-
Routingproblem gelöst: Ich hab mir einen Filter gebaut, der prüft ob eine IP aus unserem internen Netz kommt. Auf den Backbones werden dann per OSPF nur noch Routen zu diesem Netzen akzeptiert:
filter freifunk {
if net ~ 10.43.0.0/16 then accept;
if net ~ 10.0.0.0/16 then accept;
if net ~ 192.168.0.0/16 then accept;
reject;
};
Und im OSPF entsprechend:
import filter freifunk;
Mir Präferenzen zu arbeiten funktioniert irgendwie nicht richtig, da Bird wohl OSPF immer wichtiger nimmt als BGP. Warum das so ist weiß ich nicht. Analog für IPv6 genauso, dort eben auf 2a03:2260:115::/48. Wichtig ist, dass diese Filter nur auf den Backbones eingesetzt werden, die anderen Rechner wollen ja gerade explizit ihre Standardroute (default) per OSPF lernen.
Die Netztopologie sieht jetzt so aus:
Fanlin <---GRE / Layer 3---> Greyworm-01 <----GRETAP / Layer 2----> Sense-02 <----GRE / Layer 3----> Des1
Die Einträge der Routingtabelle sehen gut aus. Einen Knoten habe ich jetzt noch nicht dran gehangen.
Grüße
Matthias
Wir (@MPW, @descilla) haben heute für die DHCP Leases eine RAM-Disk konfiguriert (tmpfs). Folgendes wurde auf allen drei GW-Servern eingerichtet:
/etc/fstab
tmpfs /var/lib/dhcp tmpfs defaults,size=100M 0 0
sowie
/etc/rc.local
[ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases
[ -e /var/lib/dhcp/dhcpd6.leases ] || touch /var/lib/dhcp/dhcpd6.leases
chown root:root /var/lib/dhcp /var/lib/dhcp/dhcpd.leases /var/lib/dhcp/dhcpd6.leases
if [ -e /var/lib/dhcp/dhcpd.leases~ ]; then
chown root:root /var/lib/dhcp/dhcpd.leases~
fi
if [ -e /var/lib/dhcp/dhcpd6.leases~ ]; then
chown root:root /var/lib/dhcp/dhcpd6.leases~
fi
Daruch ist die iowait der CPU auf allen GWs massiv abgefallen: https://freifunk-muensterland.de/grafana/dashboard/db/spielwiese-von-descilla
Die Anzahl der Clients ohne Leases bewegt sich nun zwischen 250 und 300 (Vormals 500+, https://freifunk-muensterland.de/grafana/dashboard/db/gateway-ubersicht ). Die größten Auswirkungen hatte die Änderungen auf das GW parad0x, hier war auch ein gesteigerter Durchsatz ins Rheinland nach den Änderungen zu erkennen. Ebenfalls bei parad0x wurde berücksichtigt, dass ihr ein dhclient für eth0 läuft, daher ist dort die Konfiguration ein wenig anders.
2 „Gefällt mir“
Auf sn-sense war eine falsche Version von batman-adv installiert (2014.3 anstatt 2013.4). Dadurch konnte diese VM nicht korrekt mit dem restlichen Netz kommunizieren. Korrekte Version von batman-adv installiert, jetzt sieht es wieder besser aus. PS: Nebenbei 90 Knoten hinzugewonnen.
4 „Gefällt mir“
In diesem Artikel habe ich übrigens angefangen die Tunnel-IPs zu dokumentieren: https://freifunk-muensterland.de/wiki/doku.php?id=intern:tunnelips
1 „Gefällt mir“
Domäne-02: Domäne-02 kann getestet werden
1 „Gefällt mir“
Habe tunnel zwischen fanlin <> ffwaf-srv3 in Betrieb genommen. Damit hängt Warendorf jetzt so drin:
des1 <> ffwaf-srv2 <> ffwaf-srv3 <> fanlin.
Bitte das neue Interface in Ansibel aufzunehmen. ACHTUNG: das Interface heißt “gre-zu-ffwafs3”, denn “gre-zu-ffwaf-srv3” war zu lang; eins der Skripte hat sich beschwert.
Habe auf fanlin etckeeper installiert.
Einen Fehler in gefunden (/etc/network/interfaces.d/*):
in den interfaces.d muss das “post-down ip link delete $IFACE” im inet6 Anteil erledigt werden. Steht das schon im inet4 Anteil, dass sind schlage einige down Anteile im inet6 fehl. Vergleiche 41_gre-zu-sense-03.cfg und 41_gre-zu-ffwaf-srv3.cfg. Bitte das im Ansibel zu korrigieren!
Den Tunnel des1 <> ffwaf-srv3 habe ich deaktiviert.