» Freifunk München » technische Grundsatzentscheidungen » Meinungsbild #79 i138: Segmentierung des Freifunk-München Netzes in zwei Broadcast-Domains

i138: Segmentierung des Freifunk-München Netzes in zwei Broadcast-Domains



17 Ja, Erststimme

Angenommen

17Ja100%Ja
0Enthaltung0%Enthaltung
0Nein0%Nein

Segmentierung des Freifunk-München Netzes in zwei Broadcast-Domains

Aufgrund einiger unklarer Bugs und des massiven Wachstums des Freifunk-München Netzes schlagen wir vor das Netz in zwei Batman-Segmente aufzuteilen:

1) Segment München
2) Segment Umland

Umland weil wir ausserhalb von München zwar auch Freifunk fördern wollen, dort aber lokale Communities die einzige nachhaltige Variante sind. Wir sind uns allerdings der Einstiegshürde und des Henne/Ei Problems bewusst, und bieten damit eine Übergangslösung an.

Gründe

  • Verringerung des allgemeinen Broadcast- und Management-Traffics
  • Stabilisierung des Betriebs bei zukünftigen Bugs
  • Verbesserung der allgemeinen Netz-Performance
  • Planungssicherheit für die nächsten Monate
  • technische Basis für einen stabileren Betrieb, der uns ein Zeitfenster zur grundlegenden Lösung der aktuellen Probleme verschafft.

Trennungskriterien

Alle Knoten die innerhalb des Großraums München liegen, oder keine Koordinaten via Alfred veröffentlichen, kommen in das München-Segment.

Alle Knoten die laut Koordinaten ausserhalb des Großraums München liegen, landen im Umland-Segment.

Technische Umsetzung

gw03 und gw04 werden weiterhin das Hauptnetz von Freifunk München versorgen. Für neue Segmente werden je nach Bedarf 1-2 dedizierte Gateways aufgesetzt.

Pro Segment werden unterschiedliche IPv4 und IPv6 Präfixe benutzt, die aber untereinander geroutet werden.

Jedes Segment erhält seine eigene Mesh SSID & BSSID, aber benutzen weiterhin die Client SSID muenchen.freifunk.net. Ein Meshen unterhalb der Segmente wird damit zumindest über die Funk-Schnittstelle verhindert, kann aber durch Mesh-on-LAN/WAN weiterhin unbeabsichtigt passieren.

Pro Segment wird eine eigene Firmware angeboten, die alle notwendigen Einstellungen beinhaltet.

Alle Informationen und Statistiken von allen Segmenten werden gesammelt auf unserer Karte und in den Daten des ffmap-backends (nodes.json, graph.json, nodeslist.json) verfügbar sein. Die Zugehörigkeit zum jeweiligen Segment ist durch den Site Code und den unterschiedlichen Netzen erkennbar.

Da Knotenbetreiber vermutlich nicht aktiv Knoten durch manuelle Firmware-Upgrades in andere Segmente verschieben, wird durch den Autoupdate-Mechanismus Knoten denen eindeutig einem Segment zugeordnet werden können (z.B. durch Geokoordinaten) die entsprechende Firmware ohne den Besitzer direkt zu informieren gepusht.

Ausblick

Uns ist klar, dass ein Layer-2 Netz mit Batman nicht für unsere Anforderungen und die Vision eines Stadtweiten WLAN-Meshes mit Richtfunk-Backbone skalieren wird. Wir schlagen dieses Vorgehen trotzdem vor, weil es aktuell keine technisch funktionale Alternative gibt Wir arbeiten trotzdem an dieser Alternative weiter, aber dafür benötigen wir zuerst einen entsprechend stabilen Betrieb des Produktivnetzes.

Verbesserungsvorschläge (2)

geschrieben und bewertet von Unterstützern dieser Initiative

Min. zwei Gateways je Segment

kollektive Bewertung: 
| umgesetzt: 

Es sollten grundsätzlich nicht unter 2 GWs je Segment geplant und gefahren werden. Die Dienstgüte der "Nachbar" Segmente sollte der des München-Stadt Segments in nichts nachstehen. Auch die Stabilitätsschwankungen der Vergangenheit haben gezeigt, dass ein zweites GW zur Abfederung von Störungen und Lastspitzen notwendig war.

DetailsMehr lesenWeniger anzeigen

Benamung d. "aeusseren" Segments

kollektive Bewertung: 
| umgesetzt: 

Fuer eine bessere Kompatibilitaet im normalen Sprachgebrauch schlage ich vor, das nicht-Muenchen-Stadt Segment nicht Bootstrap, sondern "Muenchen Umland", "Umland" o.ae. zu nennen. Fast niemand ohne technischen Hintergrund (und oft nichtmal die) weiss, was unter Bootstrap zu verstehen ist.

DetailsMehr lesenWeniger anzeigen