Benutzer-Werkzeuge


    Warning: Undefined array key "REMOTE_USER" in /usr/local/www/wiki.freifunk-bielefeld.de/lib/tpl/starter/main.php on line 62
  • Admin

  • Warning: Undefined array key "REMOTE_USER" in /usr/local/www/wiki.freifunk-bielefeld.de/lib/tpl/starter/tpl_functions.php on line 50

    Warning: Undefined array key "REMOTE_USER" in /usr/local/www/wiki.freifunk-bielefeld.de/lib/tpl/starter/tpl_functions.php on line 77
  • Registrieren

Webseiten-Werkzeuge


Übersicht des neuen Meshes für Freifunk Bielefeld

Die Idee ist geklaut aus Gütersloh.

Grundidee

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.

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.

IPAM

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

Monitoring

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

Crashende Hypervisoren

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

vmhost1

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

bgp1

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

vpn7

  • Debian Jessie
  • zwei Cores
  • 4GB RAM

vpn8

  • Debian Jessie
  • zwei Cores
  • 4GB RAM

andere VMs

  • VM für OTRS

vmhost2

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

bgp2

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

vpn1

  • Debian Jessie
  • zwei Cores
  • 4GB RAM

vpn6

  • Debian Jessie
  • zwei Cores
  • 4GB RAM

vpn4

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

noc

  • VM basierend auf Openstack und Debian
  • Webseite, Wiki, IPAM (NIPAP), noc-Webseite
  • IPv6 über 6in4-Tunnel zu bgp1

aktueller Stand

  • 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