die ansible-ffms-VM (148.251.208.168 / 2a01:4f8:191:21e1::168) als neue Arbeitsumgebung in Betrieb genommen
Es ist etwas seltsam, dass nach einem frischen reboot bat0 eine IP-Adresse hat, obwohl es in br0 hängt. Das dürfte eigentlich nicht sein. Ein networking stop & start behebt das. Sonst will Alfred wohl auch nicht, @Fungur sucht nach dem Grund in seiner VM.
Der nächste und letzte Arbeitspunkt bevor die Knotenmigration beginnt, ist OSPF. Das muss aber natürlich gründlich getestet werden.
Ich hab heute einen großen Fortschritt beim Verständnis der Batman-Architektur gemacht, den ich euch nicht vorenthalten möchte.
Wir hatten oft Probleme bat0 mit ifup zu starten. Das liegt daran, dass man dieses Interface nicht klassisch hochfahren kann, sondern es kommt automatisch hoch, wenn man das Kernelmodul batman-adv geladen hat und dann ein anderes Interface mit batctl if add Batman übergibt. Dann wird bat0 gestartet.
Klassischer Weise geschieht dies vom fastd aus, indem nach dem Start von fastd das mesh-vpn per batctl übergeben wird.
Dies führt zu einer unschönen Verkettung, die gar nicht nötig ist. Man kann mit
ip link add bat0 type batadv
bei neueren Batmanversionen das bat0 direkt erzeugen und dann die Gretaps und ggfs. das mesh-vpn hinzufügen.
Die Brücke br0 braucht man nicht. Man kann direkt die Konfiguration auf static setzen und die 10.43.X.X und die IPv6 vergeben.
Dann löst man das Problem, dass bat0 manchmal nicht in br0 hängt und die Konfiguration wird deutlich einfacher. Auf den Hardware-Routern (also Knoten) ist es sehr praktisch mit Brücken zu arbeiten, da man hier ggfs. die verschiedenen Ethernets-Ports überbrücken möchte, ohne an der VLAN-Konfig des internen Switches rumzuspielen. Auf den Gateways nicht.
Daher testen wir das jetzt in der Domäne-01 mal und zünden die Brücke an :). Die interne IP-v4 und IP-v6 wird dann direkt auf’s bat0 gelegt.
Grüße
Matthias
/edit: Hab die Brücken angezündet und alles im Ansible-Zweig entwicklungszweig angepasst, funktioniert
da die Burse heute wieder offline war, haben wir jetzt die Pilotdomäne aufgeteilt. Des2 macht nur noch Burse und auf Des1 können wir mit dem Routing rumexperimentieren.
Dazu hab ich den den Tunnel zwischen Des1 und Des2 zugeschüttet und per bird6 hat des1 nun den ipv6-Bereich 2a03:2260:115:fe00::/56.
Bug im Ansible: IP-Forwarding wird nicht korrekt aktiviert, war zumindest auf Remue-01 nicht. Das müssen wir uns nochmal anschauen.
Wir haben OSPF auf remue-01 und greyworm-01 eingerichtet, aber es gibt irgendwie Paketverdoppelungen und -verluste, das läuft noch nicht rund. @paulinsche hat versucht das zu diagnostizieren, wir sind aber dem Fehler noch nicht auf die Schliche gekommen.
Auf virtHost-fanlin, gw-fanlin, sn-fanlin-1, sn,fanlin-2, gw-fusselkater, gw-commander1024 und gw-parad0x habe ich gerade das Kernel-Security-Update DSA3396 (betroffen sind wheezy und jessie) aufgespielt und die Maschinen rebootet.
Bitte alle anderen Maschinen ebenfalls updaten (apt-get update; apt-get upgrade; reboot).
Die Statistiken für die Knoten (Zweig node.* und nodes.*) werden jetzt nur noch jede Minute an den Graphite Server gesendet.
Die Belastung des WebServers ist dadurch deutlich gefallen da insbesondere die Verarbeitung der vielen Node-Daten eine hohe Last erzeugt hat.
Heute dabei waren Void, Simon, Paulo, Michael, Gunnar und ich.
Wir haben das Routing für IPv4 gefixt, wir können jetzt aus der ganzen Domäne-01 zum Backbone pingen
Wir haben festgelegt, dass die Tunnel zwischen den Domänen und dem Backbone die IPs 192.168.X.Y/30 bekommen, wobei X die Nummer der Domäne ist. Jede VM soll zudem ein Loopbackinterface aus 192.168.0.X bekommen. Jede VM bekommt eine Anbindung an alle drei Backbones, also 9 Tunnel pro Domäne
Nachdem IPv6-Routing läuft und beides in Ansible gegossen ist, werden wir uns an den Anschluss an das alte Backbone wagen.
Paulo hat von seinen Experimenten mit DHCP-Relays erzählt. Der von uns verwendete Isc-Dhcp-Server kann den Relay-Mechanismus nur über Layer2. Wir fragen bei den anderen Communities rum, ob es eine elegantere Lösung gibt, sonst müssen noch extra Gretap-Tunnel gegraben werden.
Sehr entspanntes und produktives Treffen, hat mir zumindest richtig Bock gemacht.
sn-descilla-1 hat sich auf den Bart gelegt. Neu durchgestartet, läuft wieder. Die beiden anderen VMs, die auf dem Server laufen (für Testdomäne) haben sich noch nie auf den Bart gelegt, immer nur sn-descilla-1. @kgbvax du hast mal von problemen deiner maschinen mit zwei Kernen erzählt, dass die auch immer abgekackt sind, oder habe ich das falsch in Erinnerung?
Beide betroffenen docker habe ich neu erstellt und grob getestet. Bitte melden falls etwas nicht funktioniert, dann kann ich das Backup wiederherstellen.
Ich werde heute Nacht mein Hostsytem neu starten, da Updates durchgeführt werden müssen. Davon betroffen sind die VMs: sn-descilla-1, ffmstd-des1, ffmstd-des2 sowie ffms-map.
Die Statistiken sind wieder funktional, zudem haben wir ein Script von @descilla eingebaut dass die aktiven DHCP Leases mit in die Statistiken einfügt.
Die entsprechenden Übersichten im Grafana haben wir angepasst und erweitert.
Interessant ist, dass die Anzahl der DHCP Leases konstant um 50 - 100 kleiner ist als die Anzahl der Clients.
Außerdem hat @Fungur heute an der Meta-Domain-Karte weiter gemacht. Das Ergebnis gibt es hier zu sehen: http://ffms-map.fungur.eu/map/ (derzeit ipv6 only).
Die Karte zeigt alle Knoten aus der Testdomäne, der Domäne-01, sowie der “legacy” Domäne an.
