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


Dies ist eine alte Version des Dokuments!


Ü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
Da es auf vmhost1 mit VyOS immer crashed, läuft da ein normales Debian

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.

vmhost1

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

bgp1

vpn7

vpn8

andere VMs

vmhost2

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

bgp2

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

vpn1

vpn6

vpn4

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

andere VMs

  • VM für OTRS

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