Übersicht des neuen Meshes für Freifunk Bielefeld

Die Idee ist geklaut aus Gütersloh.

Grundsätzlich werden nur noch physikalische Maschinen verwendet. Pro physikalischer Maschine gibt es 2-3 Gateway-VMs, die weitgehend so wie bisher aufgesetzt werden. Über einen virtuellen Switch können diese direkt und ohne zusätzliche Tunnel meshen. An dem virtuellen Switch angeschlossen ist auch eine Routing-VM (derzeit ein VyOS). Diese baut Tunnel zum Freifunk Rheinland und zum ICVPN auf und spricht BGP. Die Gateway-VMs bekommen über den internen Switch per OSPF eine Defaultroute. Da das ganze jetzt noch nicht redundant ist, soll das ganze auf einer zweiten physikalischen Maschine nocheinmal aufgebaut werden. Zwischen den VMs gibt es dann ziemlich viele Tunnel, konkret:

• GRE zwischen beiden BGP-Routern
• GRE zwischen Gateway-VMs und entfertem BGP-Router als OSPF-Fallback
• lt2tpv3 zwischen Gateway-VMs

Die Gateway-VMs machen kein NAT mehr, das übernimmt die Routing-VM.

Die Routing-VM ist ein VyOS, allerdings werden damit nicht die Routingprotokolle konfiguriert. Das übernimmt wie bisher bird, weil Quagga kacke ist komische Dinge tut. Sollen die Konfigurationsdateien beim Upgrade übernommen werden, sollten diese in /config/ liegen. Bei bird ist das relativ einfach, in der /etc/bird/bird.conf einfach /config/bird/bird.conf includen und den Rest dort machen. Die Tinc-config muss einmal nach /config/ kopiert werden, sonst ist die futsch.
Für bird und tinc müssen zusätzliche Repos eingebunden werden. Tinc sollte nach der Anleitung von hexa- selbst gebaut werden, weil die 1.1-pre wesentlich stabiler ist

Weil IPs in einem Wiki dokumentieren unpraktisch ist, gibt es jetzt ein IP address management system. Zugang gibts auf Anfrage.
Link

Auf vpn7 läuft ein collectd mit CGP. Man müsste ™ auch mal ein Icinga o.ä. aufsetzen, um ein richtiges Monitoring zu machen.

05.06.16: vmhost1 läuft im Testbetrieb, ICVPN/DN42 IPv4 funktioniert noch nicht ganz