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

Sowohl vmhost1 als auch vmhost2 hatten zunächst unerklärliche Kernelpanics in Abständen von Minuten, Stunden oder auch Wochen. Nach Installation von aktuelleren Kernels aus Debian-Backports liefen die Systeme zwar stabil, allerdings waren GRE-Tunnel ziemlich langsam (~400 kbit/s anstatt 250 Mbit/s). Abhilfe schaffte dann der Tipp eines Rheinländers, das Hardware-Offloading der Netzwerkkarte abzuschalten:
ethtool -K eth0 tx off rx off sg off tso off gso off gro off

Kiste bei myloc, 16GB RAM, Quadcore, 2x 2TB HDD

• VyOS
• zwei Cores
• 2GB RAM
• bird
• GRE zu FFRL
• ICVPN

• Debian Jessie
• zwei Cores
• 4GB RAM

• Debian Jessie
• zwei Cores
• 4GB RAM

• VM für OTRS

Kiste bei Hetzner, 16GB RAM, Quadcore, 2x 1,5TB HDD

• VyOS
• zwei Cores
• 2GB RAM
• bird
• GRE zu FFRL
• ICVPN
• diverse DN42-Peerings über OpenVPN

• Debian Jessie
• zwei Cores
• 4GB RAM

• Debian Jessie
• zwei Cores
• 4GB RAM

• zwei Cores
• 4GB RAM
• Debian Jessie
• hängt im alten Mesh für IPv6-Uplink

• 05.06.16: vmhost1 läuft im Testbetrieb, ICVPN/DN42 IPv4 funktioniert noch nicht ganz
• 04.08.16: vmhost1 läuft soweit stabil, ICVPN/DN42 funktioniert. vmhost2 wird eingerichtet
• 14.09.16: Die Kernel-crashes scheinen jetzt endgültig behoben zu sein, neuer Kernel und abschalten von Offloading der NIC hat geholfen