Architektur-Babel

Aus Freifunk Köln, Bonn und Umgebung
Version vom 21. April 2016, 10:07 Uhr von Yanosz (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „{{TOCright}} <span style="color: #F00">'''Hinweis'''</span>: Dieser Artikel beschreibt '''nicht das''' Freifunk-Netz aus konzeptioneller Sicht und erklärt vie…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

Hinweis: Dieser Artikel beschreibt nicht das Freifunk-Netz aus konzeptioneller Sicht und erklärt viele, tiefe Details. Um einfach mitzumachen musst Du nicht alles davon verstehen - wenn Du Interesse hast, lese einfach weiter :-).

Kurzzusammenfassung

  • ISP / VPN-Provider unabhängig.
  • Routing via Babel (Backbone + Adhoc)
  • Roaming über batman-adv

Einleitung

Stand 04/2016 verwendet das KBU-Netz batman-adv auf allen links (auch VPN). Server erfüllen die Aufgabe der Supernodes. Broadcasts belasten das Netz dort.

Dieser Artikel beschreibt eine davon abweichende, mögliche Konfiguration. Sie ist ISP (d.h. VPN-Provider) unabhängig und verzichtet auf eine Node-Hierachie (Node, Supernode).

Ziele und Anforderungen

Wesentlich Bestandteil sind:

Designziele

Das Netz soll die folgenden Eigenschaften bieten:

  1. Offenheit: Jede / Jeder soll mitmachen können.
  2. ISP-Unabhängigkeit: Es können verschiedene VPN-Provider verwendet werden. Das Netz ist nicht abhängig von einem ISP (bspw. Freifunk-Rheinland).
  3. Roaming: Zwischen Nodes, die direkten Funkontakt haben, soll Roaming möglich sein.
  4. Skalierbarkeit': Das Netz soll bis zu einer Größe von 65000 Nodes skalieren können.
  5. IPv4 und IPv6: Beides wird verwendet
  6. Dezentralität: Die Komponenten des Netzes werden nicht zentral verwaltet.
  7. Geringe Hardware-Anforderungen: Auch Geräte mit wenig Ressourcen können verwendet werden.
  8. Wiederverwendbarkeit: Andere Communities sollen analog Netze gestalten können.
  9. Niedrige Einstiegshürde: Wissen über weitere Linux-Distributionen, -Routing-Protkolle oder Konfigurationsmanagement soll nicht nötig sein.

Keine Designziele

Folgende Punkte werden nicht berücksichtigt. Technische gesehen sind sie aber grundsätzlich umsetzbar.

  1. Internet-Performance: Ein hoch performanter Zugriff auf das Internet soll nicht sichergestellt sein.
  2. Netzwerk-Management: Es muss nicht sichergestellt sein, dass eine einzelne Person möglichst viele Router effizient verwalten kann.
  3. Stabilität: Die Verfügbarkeit einzelner Komponenten wird nicht sichergestellt.