Architektur: Unterschied zwischen den Versionen

Aus Freifunk Köln, Bonn und Umgebung
Zur Navigation springen Zur Suche springen
Zeile 5: Zeile 5:


== Einleitung ==
== Einleitung ==
Dieser Artikel beschreibt die Architektur des in Köln, Bonn und Umgebung verwendeten Freifunk-Netzes. Dabei wird insbesondere auf die Zusammenhänge zwischen Server-Konfiguration und Firmware-Eigeschaften eingegangen. Dieser Wiki-Seite beschreibt die Konfigration der verschiedenen Server jedoch nur aus Architektur-Sicht. Sie ist somit nicht Bestandteil der Server-Dokumentation.
Dieser Artikel beschreibt die Architektur des in Köln, Bonn und Umgebung verwendeten Freifunk-Netzes. Dabei wird insbesondere auf die Zusammenhänge zwischen Server-Konfiguration und Firmware-Eigeschaften eingegangen. Diese Wiki-Seite beschreibt die Konfigration jedoch nur aus Architektur-Sicht - sie ist nicht nicht Bestandteil der Server-Dokumentation.


Im Rahmen der Einleitung wird die verwendete Stratgie (''komplettes Briding'') dargelegt. Die folgenden Absätze (OSI-2: Briding, OSI-3: Routing) gehen detailliert auf die verschiedenen Schichten des Netzes ein. Der letzte Absatz gibt einen Ausblick auf mögliche Änderung, die in Zukunft einziehen können.
Im Rahmen der Einleitung wird die verwendete Stratgie (''komplettes Briding'') dargelegt. Die folgenden Absätze (OSI-2: Briding, OSI-3: Routing) gehen detailliert auf die verschiedenen Schichten des Netzes ein. Der letzte Absatz gibt einen Ausblick auf mögliche Änderung, die in Zukunft einziehen können.

Version vom 21. März 2013, 16:17 Uhr

Abb. 1

Hinweis: Jans Seite zur Architektur im FF-Netz - WIP. Bitte NICHT ändern.

Freifunk-KBU verolgt die Komplettes Bridging-Strategie: Fastd-Server verbinden als Super-Nodes WLAN-Mesh-Partionen. IP-Adressen werden per DHCP und radvd vergeben. Ein routed Backbone-VPN (tinc) verbindet die Supernodes und ermöglicht Routing zum Exit.

Einleitung

Dieser Artikel beschreibt die Architektur des in Köln, Bonn und Umgebung verwendeten Freifunk-Netzes. Dabei wird insbesondere auf die Zusammenhänge zwischen Server-Konfiguration und Firmware-Eigeschaften eingegangen. Diese Wiki-Seite beschreibt die Konfigration jedoch nur aus Architektur-Sicht - sie ist nicht nicht Bestandteil der Server-Dokumentation.

Im Rahmen der Einleitung wird die verwendete Stratgie (komplettes Briding) dargelegt. Die folgenden Absätze (OSI-2: Briding, OSI-3: Routing) gehen detailliert auf die verschiedenen Schichten des Netzes ein. Der letzte Absatz gibt einen Ausblick auf mögliche Änderung, die in Zukunft einziehen können.

Strategie

Das Netz wird als Hierachisches P2P-Netz betrieben. Die verwendete Komplettes Bridging Stratgie sieht vor, dass das komplette Netz ein einziges zusammehängendes OSI-2 Segment bildet. Dieses Segment verbindet alle Klienten, Nodes und Server, soweit sie Bestandteil des Freifunk-Meshes sind. Dadurch sind je 2 Klienten in verschiedenen Teilen des Netzes immer über eine zu Grunde liegende Infrastruktur via "Ethernet" (nach IEEE 802-Substandards) miteinander verbunden. Für die Infrastruktur selbst wird batman-adv (http://www.open-mesh.org/) verwendet. Somit:
Daten zwischen Netzteilnehmer werden als Frames switched, das Netz bildet eine große Broadcast-/Link-Local-Multicast-Domäne.

Implementierung: Nodes

Abb. 2

Auf den Nodes existieren verschiedene Netze, die teilweise mit einander verbunden sind (Abb. 2). Jeder Node spannt dabei zwei Wireless-Lan-Netze auf und bat ggf. eine VPN-Verbindung auf. Hinweis: Aus technischen Gründen (u.a. vlan-Fähigkeit einzelner Geräte), weichen Interface-Namen auf einzelnen Nodes teilweise ab.

  • wlan0 wird als "Master"-Netz betrieben mit SSID kbu.freifunk.net betrieben. Für Klienten erscheint es als normaler Accesspoint.
  • wlan1 arbeitet als "Ad-Hoc"-Netz mit ESSID und BSSID: 02:d1:11:37:fc:39 betrieben. Es ermöglicht die direkte Kommunikation zwischen verschiedenen Nodes.
  • tap0 ist das VPN-Interface. Verfügt ein Node über einen drahtgebundenen Zugang zum Internet, so baut er eine VPN-Verbindung auf.

wlan1 und tap0 sind hierbei dem bat0 Interface hinzugefügt. Somit werden in beiden Netzen (ad-hoc, VPN) batman-adv-Frames anstelle gewöhnlicher Ethernet-Frames übermittelt. Alle Stationen in diesen Netzen müssen daher die gleiche batman-adv Protokollversion zur Kommunikation verwenden. Ethernet-Frames nach IEEE 802 können nicht verwendet werden.

Implementierung: Super-Nodes

Super-Nodes (auch: fastd-Server) sind Nodes, die VPN-Verbindungen von Nodes entgegen nehmen. Ein Super-Node ist im Internet erreichbar, d.h. Nodes können VPN-Verbindungen dorthin initiieren auch wenn sie sich z.B. hinter einem NAT befinden. Super-Nodes verfügen über eine gute Internet-Anbindung (mindestens 100MBit/s up/down). Jeder Node hält typischerweise VPN-Verbindungen zu zwei verschiedenen Super-Nodes. Adressen und VPN-Schlüssel der Super-Nodes sind fest in der Node-Firmware verdrahtet.

OSI-2: Switching

OSI-3: Routing