Architektur-Babel: Unterschied zwischen den Versionen

Aus Freifunk Köln, Bonn und Umgebung
Zur Navigation springen Zur Suche springen
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.
* 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.
* Jedem Node wird ein eindeutiges private IPv4 und ULA IPv6 Netz zugewiesen.
# Jeder Node betreibt einen DHCP und einen radvd auf dem Infrastruktur-Netz.
* Jeder Node betreibt einen DHCP und einen radvd auf dem Infrastruktur-Netz.
# Im ad-hoc-Netz werden babel und batman-adv verwendet.
* 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
** batman-adv ''nur'' für Roaming. Broadcast wird komplett gefiltert. Jeder Node ist batman-adv Gateway
## babel zur IP-Kommunikation zwischen den Nodes genutzt.  
** 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.
* 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:19 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

  • 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.