Architektur-Babel: Unterschied zwischen den Versionen

Aus Freifunk Köln, Bonn und Umgebung
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 42: Zeile 42:
== Umsetzung ==
== Umsetzung ==
Modifizierte: [[Netzwerk-Konfiguration#Routing_über_das_VPN,_bridging_zwischen_batman-adv_und_Infrastruktur | Routing über das VPN, bridging zwischen batman-adv und Infrastruktur]]-Strategie
Modifizierte: [[Netzwerk-Konfiguration#Routing_über_das_VPN,_bridging_zwischen_batman-adv_und_Infrastruktur | Routing über das VPN, bridging zwischen batman-adv und Infrastruktur]]-Strategie
# Nodes verbinden zu einem ISP (z.B. FFRL e.V, hide.me) und erhalten Routbare IPs, sofern sie an das Internet angebunden sind.
# Jedem Node wird ein eindeutiges private IPv4 und ULA IPv6 Netz zugewiesen.
# Jeder Node betreibt einen DHCP und einen radvd auf dem Infrastruktur-Netz.
# Im ad-hoc-Netz werden babel und batman-adv verwendet.
## batman-adv ''nur'' für Roaming. Broadcast wird komplett gefiltert. Jeder Node ist batman-adv Gateway
## babel zur IP-Kommunikation zwischen den Nodes genutzt.
# Verfügt der Node über öffentliche IPv6-Prefixes, dann schaltet er DHCPv6-Prefix Delegation auf dem ad-hoc Interface (''nicht'' batman-adv) ein. Benachbarte Nodes können darüber Prefixes erhalten.

Version vom 21. April 2016, 11:18 Uhr

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. Die Netze existieren unabhängig.
  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.

Umsetzung

Modifizierte: Routing über das VPN, bridging zwischen batman-adv und Infrastruktur-Strategie

  1. Nodes verbinden zu einem ISP (z.B. FFRL e.V, hide.me) und erhalten Routbare IPs, sofern sie an das Internet angebunden sind.
  2. Jedem Node wird ein eindeutiges private IPv4 und ULA IPv6 Netz zugewiesen.
  3. Jeder Node betreibt einen DHCP und einen radvd auf dem Infrastruktur-Netz.
  4. Im ad-hoc-Netz werden babel und batman-adv verwendet.
    1. batman-adv nur für Roaming. Broadcast wird komplett gefiltert. Jeder Node ist batman-adv Gateway
    2. babel zur IP-Kommunikation zwischen den Nodes genutzt.
  5. Verfügt der Node über öffentliche IPv6-Prefixes, dann schaltet er DHCPv6-Prefix Delegation auf dem ad-hoc Interface (nicht batman-adv) ein. Benachbarte Nodes können darüber Prefixes erhalten.