Administration/Handbücher/Hoodsystem

Aus Freifunk Nordwest Wiki
< Administration‎ | Handbücher
Version vom 17. August 2017, 13:19 Uhr von Floh1111 (Diskussion | Beiträge) (Floh1111 verschob die Seite Administration/Server/Dokumentation/Hoodsystem nach Administration/Handbücher/Hoodsystem, ohne dabei eine Weiterleitung anzulegen)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

Hoods

Viele Hoods und ein Autonomes System

Um die Hoods umsetzen zu können haben wir das Freifunk Nordwest Netzwerk als [System (ASN)] mit der Nummer 65513 definiert. Diese Nummer ist dem für private Zwecke reservierten Nummernbereich entnommen, siehe

Innerhalb des ASN kommen verschiedene Konzepte und Routingprotokolle zum Einsatz, die im Folgenden Beschrieben werden.

Eine Hood bezeichnen wir als geographische Region mit der bestimmte Netzwerkeigenschaften verbunden werden. Ziel des Hoodsystems ist ein Freifunknetzwerk, das ein Mesh-Protokoll auf Layer-2 einsetzt, mithilfe eines kontrollierten Prozesses zu zerteilen um so den zur Verwaltung des Layer-2 Netzes notwendigen Overhead-Traffic (Mesh-Overhead, ARP-Requests, Broadcasts) auf ein kontrollierbares maß zu reduzieren. IdR. besteht eine Hood aus:

  • Name
  • Technische Ansprechpartner (min. 2)
  • Hoodtyp (defaulthood oder realhood)
  • Geographische Region (nur wenn Hood eine realhood ist; definiert als Rechteck mithilfe zweier Geopositionen)
  • Layer-3 Subnetz
  • 1 Supernode mit N-Fastd-Instanzen (Fastd kann kein Multithreading, daher mehrere Instanzen zur optimalen Auslastung der CPU)
  • 0-100 Nodes
  • 0-N Clients

Jede Hood wird in dem ASN als eine [[1]] defininiert. Das heißt die Teilnehmer einer einzelnen Hood können sich auf Layer-2 direkt erreichen. Die Hoods untereinander sind jedoch physikalisch voneinander getrennt (Layer 2-Trennung). Teilnehmer in anderen Hoods können nur auf Layer-3 erreicht werden.

Zur Herstellung der Broadcast-Domäne, also den direkten Zusammenschluss der Teilnehmer einer Hood (Supernode, Nodes, Clients) auf Layer-2, nutzen wir das für WLAN optimierte Mesh-Protokoll B.A.T.M.A.N. advanced, welches wie ein virtueller Switch funktioniert. Dank der Broadcast-Domäne ist auch Roaming innerhalb einer Hood möglich (Client kann Nodes bei flächendeckendem Netz ohne Verbindungsabbruch wechseln).

In jeder Hood existiert eine Supernode, die idR. durch einen Server in einem Rechenzentrum repräsentiert wird. Eine Supernode übernimmt vier Funktionen:

  1. Verbindung der Mesh-Wolken innerhalb einer Hood (Einzelne Nodes oder Gruppen von Nodes innerhalb einer Hood, die sich nicht per WLAN sehen können aber an das Internet angeschlossen sind)
  2. Verbindung zwischen den Hoods auf Layer-3 (Supernode-Backbone mittels IPGP)
  3. Verteilen von IP-Adressen an die Clients per DHCP
  4. Zur Verfügung stellen einer Default-Route ins Internet (dies ist im Freifunk-Kontext teilweise optional)

Die Hoods untereinander sind über die Supernodes auf Layer-3 verbunden. Die Gesamtheit dieser Verbindungen bezeichnen wir als Supernode-Backbone. Zum Herstellen der einzelnen Verbindungen unter den Supernodes werden [[2]] genutzt. Damit jede Supernode die Subnetze jeder anderen Supernode kennt, nutzen wir im Supernode-Backbone das [Gateway Protokolls] (IGP) OSPF auf den GRE-Tunneln. So kann jeder Teilnehmer einer Hood alle Teilnehmer der übrigen Hoods auf Layer-3 erreichen.

Damit wäre das Freifunk Netzwerk abgeschlossen. IdR. möchten wir unser Autonomes System aber auch zu anderen Autonomen Systemen wie z.B. dem von Freifunk Rheinland verbinden. Entweder weil wir dort den für das Internet bestimmten Traffic unserer Clients abladen möchten oder weil Verbindungen zu anderen Autonomen Systemen toll sind. Eine Verbindung zu anderen ASN kann von jeder Supernode mittels eines GRE-Tunnels und des [Gateway Protokolls] (EGP) [[3]] aufgebaut werden.

TODO: Grafik

Neue Hood einrichten

  • Einstiegsfragen klären
    • Wie soll die neue Hood heißen? (Beachte Technik/Dokumentation/Hoods#Aufbau_des_Hoodfiles)
    • Wer sind die technischen Ansprechpartner?
    • Wo soll die neue Hood entstehen?
    • Wer mietet den Server (Was wird benötigt, welche Möglichkeiten gibt es (selbst Mieten oder Verein mietet und lokale Personen spenden) und was kostet das langfristig überhaupt?)
    • Wo wird der Traffic abgeladen? (Welche Möglichkeiten gibt es da und was kostet das überhaupt?)
  • Die nachfolgenden Punkte sollten die neuen technischen Ansprechpartner der Hoods mit Hilfe erfahrener Admins vornehmen (der Prozess sollte verstanden werden und im Zweifelsfall sollten die technischen Ansprechpartner die Einrichtung selbst vornehmen können)
  • Auf der Admin-Mailingliste anmelden
  • Auf der Admin-Mailingliste um Aufnahme in die [[4]] im Gitlab bitten
  • Server mieten
    • Login testen
  • Server Basiskonfiguration vornehmen
  • DNS Konfiguration vornehmen
  • Merge-Request im [[5]] stellen um den eigenen Public-Key in die [[6]] einzutragen und so Zugang zur Serverinfrastruktur zu erhalten
  • Server-Basiskonfiguration vornehmen
  • Puppet Agent einrichten
  • Nach erfolgreichem Abschluss aller obigen Punkte können sich andere Admins auf dem Server einloggen und bei Problemen helfen
  • Eine neue [Node-Definition] erstellen und ins Puppet-Data Repo pushen
  • Puppet Agent erneut ausführen und Checken ob die neue Konfiguration aus der Node-Definition erfolgreich angewendet wurde
  • Mithilfe des Hodgenerators ein neues [[7]] vorbereiten und die Änderungen als Merge-Request im [[8]] einstellen.
  • Auf das nächste Firmware-Release warten...


Hood-Administratoren

Jede Hood wird von mindestens 2 lokalen Ansprechpartnern betreut. Informationen siehe:

Hoodfile

Das Hoodfile ist in ein eigenes OpenWRT Paket (hoods) gekapselt und definiert die Hoods.

Aufbau des Hoodfiles

  • name: Jede Hood erhält einen einzigartigen alphanumerischen Namen mit nicht mehr als 9 Zeichen (sonst gibt es Probleme mit Interfacenamen)
  • bssid: Jede Hood erhält eine einzigartige BSSID
  • defaulthood: standardmäßig "false"
  • Es gib nur eine default hood, dieser werden keine Koordinaten zugewiesen.
  • servers: eine normale Hood und die Defaulthood hat mindestens eine Supernode. Allerdings ist zu empfehlen das die Defaulthood mehrere Supernodes beinhalten sollte.
  • eine normale hood muss mindestens eine rechteckige fläche zugewiesen sein.
  • normale hoods dürfen sich nicht überschneiden. Ausgeschlossen ist die default hood

Hoodgenerator

Der Hoodgenerator (Hoodgen) wird von den Entwicklern genutzt um das Hoodfile anzuzeigen und zu bearbeiten.

Vom Hoodnamen zur Supernode

Die Supernode einer Hood ist jeweils über den Hoodnamen erreichbar: <hoodname><2 Ziffern>.sn.ffnw.de

Router manuell auf Hood konfigurieren

Aktuell ist dies nur indirekt durch die manuelle Angabe von Koordinaten im Config-Mode möglich. Ein Interface zum erzwingen einer Hood ist geplant, siehe https://git.nordwest.freifunk.net/ffnw-firmware/packages/issues/30

Pads

Siehe https://pad.ffnw.de/p/hoods