Teilnehmer

Thema des Abends

Gateway Domänen Roulette 3.0

Wir nutzen Ansible um die Auslastung der VPN-Verbindungen zwischen Freifunk-Knoten und Gateways neu zu verteilen.

Siehe auch https://forum.freifunk-muensterland.de/t/gateway-roulette-3-0/3553?u=parad0x

Offtopic

  • Falschen Kernel auf TJ01 bemerkt ← Ursache für Routingprobleme

Typische Parameter für ansible-playbook

ParameterSteht fürBewirkt folgendes
-iInventoryNutze die nachfolgende Datei als Ziel-Liste
-llimitNur das folgende Host aus der Ziel-Liste nutzen
--check
Zunächst nur auflisten welche Änderungen vorgenommen werden würden
--diffdifferenzZeigt im Detail an was geändert wird
--start-at-task='xxxx'

(Frage) -skip-task (Frage)
Überspringt einzelne Schritte aus dem Playbook

Ablaufschritte

  • Roulette Script ausführen (Haken)
  • Arbeit des Scripts Prüfen. (Haken) (Dom16 von Handle und Fanlin wegmigriert)
  • Commiten ✓
  • DNS Master ausrollen ✓
  • Karte ausrollen ✓
  • Gateways ausrollen ✓
  • Icinga ausrollen ✓
  • Voll-umfassenden Reboot. ✓
  • Netz auf Funktion Prüfen ✓

Gatewayroulette

  • Zunächst: Kernelupdate auf TJ01.
  • Die VM wurde frisch eingerichtet, somit ist Kernel 3.16 drauf. Kernel 3.16 hat einen Bug, dass die Suppress_prefixlength 0 Funktion nicht richtig funktioniert. Daher muss ein Kernel ≥ 4.0 drauf. Es darf aber auch kein Kernel neuer als 4.9 bpo3 drauf sein, 4.9 bpo4 geht schon nicht mehr. Das ist noch ein temporäres Problem mit dem Tunneldigger.
ansible-playbook -i hosts gateways.yml -l tj01 -t backports-kernel --diff --check
  • Automatisch wurde dadurch Kernel 4.9 bpo5 installiert. Der ist wie gesagt zu neu, wir installieren nun per Hand bpo2. In bpo4 wurde der Bug repariert, den der Tunneldigger braucht. Mit der Firmware 3.2.0 wären auch neuere Kernel möglich.
  • Manuelles Entfernen des Kernels bpo5.
  • In der gateways.yml haben wir die backports-Rolle auskommentiert, damit nicht aus Versehen auf den Gateways ein neuer Kernel installiert wird.
  • Gateway-Rouletteskript sn-alloc.R ausgeführt. Dieses lädt sich automatisch die Statistiken aus dem Graphite und verteilt die Domänen auf die Gateways
  • Es sollte manuell überprüft werden, dass die großen Domänen nicht doch auf den schwachen Gateways landen. Z. B. sollte Domäne 16 auf direkt angebundenen Gateways liegen.
  • Erklären der Einträge in den host_vars-Dateien
    • server_id/vm_id identisch, Gateways werden durchnummeriert, wird für die Rollen benötigt, die die Tunnel zwischen den Gateways aufbauen
    • server_besitzer: Nur Statistik, kommt in die Tagesnachricht
    • hoster: wird benutzt um beim Routing Kosten zu setzen, damit Pakete bevorzugt nicht zwischen Hostern hin- und hergereicht werden
    • Das BGP Pref (bgp_local_pref) 200 ist der Standardwert und muss nicht explizit angegeben werden. Wenn ein Eintrag 201 gesetzt bekommt, dann hat der andere (ohne Eintrag) Vorrang.
    • ffnw/ffrl_nat_ip: Nat-IP für das V4-Natting auf dem Gateway, die IP kommt auf die Loopback-Schnittstelle (ip a s lo) und wird uns von den Upstreamprovidern zugeteilt
    • ffnw/ffrl_tun: Tunnel-IPs für die Tunnel zum FFRL und FFNW
    • domaenenliste: Einträge aller Domänen, die auf dieses Gateway sollen. Pro Domäne wird die Nummer, der DHCP-Bereich, die server_id innerhalb der Domäne (bei uns immer 2 oder 3, gibt die IPV4 der bat-Interfaces vor 10.x.0.2 oder .3, und das Partnergateway. Die IP .1 gehört zum Knoten
    • dhcp-Typ: Legt fest, ob der ISC- oder KEA-DHCP-Server verwendet wird

    • Frage: wie groß ist ein /18. Antwort: kann man leicht mit ipcalc ausrechnen

      test
      mpw@Server0:~$ ipcalc 10.1.0.0/18
Address:   10.1.0.0             00001010.00000001.00 000000.00000000
Netmask:   255.255.192.0 = 18   11111111.11111111.11 000000.00000000
Wildcard:  0.0.63.255           00000000.00000000.00 111111.11111111
=>
Network:   10.1.0.0/18          00001010.00000001.00 000000.00000000
HostMin:   10.1.0.1             00001010.00000001.00 000000.00000001
HostMax:   10.1.63.254          00001010.00000001.00 111111.11111110
Broadcast: 10.1.63.255          00001010.00000001.00 111111.11111111
Hosts/Net: 16382                 Class A, Private Internet
    • Tunneldigger: instance_pre_domain: Wenn wahr, wird für jede Domäne eine eigene Instanz des Tunneldiggers gestartet. Falls unwahr, wird nur ein Tunneldigger für alle Domänen gestartet
    • Es gibt aber noch das Problem, dass wenn man eine neu startet, alle Tunnel getötet werden
  • Nun wird committet (Upload der Änderungen ins Github):
git status
#git add .		#Würde alle Dateien zum Upload ins Git markieren. Wollen wir nicht, weil noch andere Dateien im Ordner sind.
git add hosts_vars/*
git add hosts
git add sn-alloc.R
git commit -m 'Gateway Domaenen Roulette 3.0'
  • Nun wird der DNS-Master ausgerollt, damit die Einträge domaeneXX-{a,b}.servers.ffmsl.de auf die neuen Gateways zeigen. In den Knoten sind vier Gateways hinterlegt domaeneXX-a.servers.freifunk-muensterland.de, domaeneXX-b.servers.freifunk-muensterland.de und noch jeweils mit .net am Ende. Auf dem DNS-Master werden die A-Einträge nun geändert und somit die DNS-Einträge, die von den Knoten über die DNS-Server der DSL-Anbieter abgefragt werden.
  • DNS-Master ausrollen:
  • ansible-playbook -i hosts dienste.yml -l dnsmaster -t services_bind --diff
  • Karte ausrollen: Aufpassen, dass der HopGlass-Server nicht aktualisiert wird, weil die Formate nicht mehr kompatibel wären
  • Dies ist erforderlich, damit der Kartenserver weiterhin für jede Domäne an den passenden Gateways hängt. Er ist mit GRETAP-Tunneln an die Gateways angebunden
  • ansible-playbook -i hosts mapserver.yml -l karte -t mapserver_interfaces --diff
  • Die Reihenfolge wäre eigentlich egal. Es ergibt Sinn mit dem DNS-Master zu beginnen, damit die Caches auf den DNS-Servern schon aktualisiert werden
  • Ob zuerst die Karte oder die Gateways oder beides parallel ausgerollt wird, ist eigentlich egal
  • Gateways ausrollen:

  • Netzwerk-Neustarts auskommentieren, weil sich dabei Gateways häufiger mal aufhängen. Besser nach dem Ausrollen alle Gateways neu starten

  • Dazu folgende Dateien editieren:

    • vim roles/backbone_gre_ffms/tasks/main.yml

    • vim roles/backbone_gre_upstream/tasks/main.yml

    • vim roles/gateways_gre_upstream/tasks/main.yml

    • vim roles/gateways_gretap/tasks/main.yml

    • Jeweils notify und restart networking auskommentieren

  • Nun ausrollen:

    ansible-playbook -i hosts gateways.yml --diff --check
  • Suchen in den zuvor ausgeführten Shellbefehlen: Strg + R drücken, dann Buchstabenkombination tippen, nach der gesucht werden soll. Wenn man den vorherigen Eintrag möchte, nochmal Strg + R drücken.
  • Nun Icinga ausrollen:
  • ansible-playbook -i hosts monitoring.yml -l icinga
  • Auf Fanlin und TJ01 ist das Bauen von Batman abgebrochen, weil die Kernel-Header fehlen.
  • Dort wird vorerst Batman 2016.4 laufen gelassen
  • Icinga zeigte viele Fehler an, es wurde bemerkt, dass das Ausrollen auf Corny2 irgendwie abgebrochen war und dort noch die alte Konfiguration lief. →Corny2 nochmal ausgerollt






  • Keine Stichwörter