wiki/Technik/Netzinfrastruktur/Dortmunder Supernodes - erste Ueberlegungen.page

---
format: markdown
categories: Netz-Infrastruktur, Backbone, Supernodes, Hintergrundinfos
title: Erste Überlegungen - Dortmunder Supernode(s)
...

**Markus schrieb:**

Gestern (09.02.2015) gab's einen Aufruf von Chris (Admin der Supernodes von FF-Ruhr),
nach Communities, die Supernodes unterbringen und auch
selbst betreiben können, um die Infrastruktur besser zu verteilen. 
Diese sollen perspektivisch auch Traffic über Richtfunk austauschen.

Details: https://forum.freifunk.net/t/lokale-ressourcen-gesucht/2488

[...]

Ich verstehe noch nicht komplett was Chris da meint mit "WDS Backbone
für Batman-Wolken", aber das lässt sich ja klären. 

Für klassische Supernodes die VPNs terminieren reicht die Anbindung des WiLa vermutlich nicht aus, deshalb sollten wir auch nach Spendern gucken, wo man ohne Ärger Server/VMs unterstellen kann die konstant richtig Traffic erzeugen. 

----------


**Johannes antwortete:**

Ich versuche im Folgenden mal, den Rest Deiner (Markus) mail nach
meinem Verständnis von Chris Vorschlag zu beantworten.

> https://forum.freifunk.net/t/lokale-ressourcen-gesucht/2488

"Eine weitere Aufgabenstellung in der lokalen Community wäre es, mit
 den lokalen Freifunkern die WDS Vernetzung der einzelnen lokalen Batman
 Wolken zu planen, so dass der Traffic mittelfristig durch die Luft
 unmittelbar die lokalen Supernodes erreicht, statt wie bislang quer
 durch's Internet über getunnelte Verbindungen laufen zu müssen."

> Ich verstehe noch nicht komplett was Chris da meint mit "WDS Backbone
> für Batman-Wolken", aber das lässt sich ja klären.

Ich formuliere mein Verständnis dieses Ausdrucks mal so: Chris meint
einen Funkbackbone zwischen lokalen meshes, durch den die nodes der
verschiedenen beteiligten meshes untereinander und mit den lokalen(!)
Supernodes eine (layer 2) Verbindung bekommen können. (Wg. layer 2
braucht man in der Luft WDS [1], damit die MAC Adressen von Sender und
Empfänger erhalten bleiben.)

Oder im Klartext: Richtfunkverbindungen zwischen den verschiedenen
Funkwolken (meshes) der community.

Dieses Gerüst aus Richtfunkverbindungen soll batman frames
transportieren können, ist also am einfachsten ein auf layer 2
"neutrales" Richtfunknetz. (Man muss sich dabei nichtmal auf ein Gerüst
(Baumstruktur) beschränken, die Richtfunkknoten und -strecken können
einen beliebigen Graphen bilden (Vorteil: Redundanz) - ein mesh eben:-)
(Sowas geht ggf. auch ohne batman, s zB [2]. Mangels Muße zur Recherche
kann ich grad nix dazu sagen, wie "neutral" batman als layer 2 "switch"
wirklich ist. In der gerade zitierten Bacherlorarbeit werden ad-hoc
Netze (mesh) als mögliche Nutzer einer "neutralen" layer 2 (Richtfunk-)
Infrastruktur angesprochen. Wie das umgekehrt aussähe, wäre meine Frage
an batman Versteher:-)

> Für klassische Supernodes die VPNs terminieren reicht die Anbindung
> des WiLa vermutlich nicht aus,

Auf die Dauer sicher nicht, aber zum ersten Aufbauen und Betreiben
eines eigenen Supernodes der community würde es erstmal reichen. Und
diese Aufbauarbeit wäre nachhaltig sinnvoll, da der L.A. sogar jetzt
schon ein "eigenes" mesh hat;-) Ganz zu schweigen von dem, was schon
"damals" in der Brauschweiger Str. an Freifunk so ging [3], sowie der in
Antennenwurfweite befindlichen Münsterstr. Außerdem hat es (das wurde
gestern auch mal erwähnt) schon reale, zusammenhängende
Richtfunkstrecken in der Nordstadt gegeben, unter Einbeziehung des L.A.
Da gab's also schonmal den handgreiflichen Ansatz zu einem
Funkbackbone, den Chris (m.E.) mit "WDS Vernetzung der einzelnen
lokalen Batman Wolken" meint. Natürlich ist die Anbindung des L.A. über
den WiLa auf Dauer nicht geeignet, mehr als das nähere geographische
FF-Umfeld des L.A. ins Internet zu channeln. Es ist dabei nicht meine
Absicht, für eine Aufstockung des dortigen links zu plädieren (außer
vielleicht das Quartiersmanagement hat ein paar hundert € im Monat aus
der Portokasse dafür übrig;). Es geht mir 1. um die Lernmöglichkeiten
durch die dortige Situation, und 2. um die Nachhaltigkeit, die so ein
Engagement hätte. 

Das obige bezieht sich aber auf lokale meshes, die "hinter" einem
lokalen Supernode hängen. ("Hinter dem Supernode" ist vom
FF-RL-Backbone aus gesehen, und damit auch vom Internet aus.)
Du (Markus) hattest aber erstmal VPN-Supernodes, die übers Internet
hereinkommende VPN-Verbindungen von FF-DO-*-nodes annehmen, im Sinn,
denn es war ja unklar, was Chris mit WDS-blafoo gemeint hatte. 

Zum Verständnis der VPN-Supernodes im FF-RL habe ich ein Bildchen [4]
gefunden, aber weiß keins zur Veranschaulichung der von Chris
vorgestellen Variante (lokale Supernodes). Wenn jemand sowas sieht oder
Muße hat, selbst den Pinsel zu schwingen, dann her damit:-)

> deshalb sollten wir auch nach Spendern gucken, wo man ohne Ärger
> Server/VMs unterstellen kann die konstant richtig Traffic erzeugen. 

Jau, das ist völlig unabhängig von den Überlegungen zu lokalen
Supernodes sinnvoll! Beide Varianten stehen sich praktisch aber mglw.
dadurch im Weg, dass die verfügbaren Kräfte des FF-DO-* erstmal nur für
eine Kiste reichen. Muss man gucken, welch lustige Schar der tatkräftig
Interessierten sich bald versammelt ... :-) Aber im Falle einer
Alternative zwischen VPN-Supernode und lokalem Supernode würde ich aus
logischen und strategischen Gründen die lokale Variante vorziehen. (Es
kann ganz andere Gründe geben, die für die Alternative VPN-Supernode
sprechen könnten, zB domänenstrategische oder die Präferenzen der
konkret am Projekt Supernode Beteiligten.)

Jedenfalls spricht m.E. Folgendes für die lokale Variante:

1. Die lokale Variante enthält die VPN Variante (logischer Grund)

Denn ein paar VPN Verbindungen von FF-DO-* Knoten können durchaus auch
im L.A. terminiert werden. Es reicht ja, wenn die admins in spe ihre
eigenen Knoten oder meshes über den lokalen Supernode an den Rest des
FF anbinden, aber eben über ihren Internetanschluss per VPN (und
(noch:-) nicht per WLAN-backbone). Wenn man so einen "kleinen"
VPN-Supernode auf einem lokalen Supernode mitlaufen lässt, lernt man
auch die Konzepte und Handgriffe für einen VPN-Supernode, und kann in
der Domäne mithelfen oder einen VPN-Supernode "vorne im Internet" (im
data center mit großer Bandbreite) für die Dorfmunder community
betreiben. Das ist dann für die admins ein Unterschied in der Quantität
des durchgeschobenen traffics, aber nicht bei den Konzepten und
Handgriffen, die man vom "kleinen" Dorfmunder VPN-Supernode schon kennt.
(BTW, "vorne im Internet" könnte (zumindest theoretisch) auch Dokom
heißen, denn dort würde (insb. ein lokaler:-) Supernode Sinn machen,
weil hinter der via Dokom-Infrastruktur die Flüchlingsunterkünfte
hängen.)

2. Broadcastdomänengröße und WLAN-Backbone (strategischer Grund)

Ich verstehe Chris so, dass die Domäne Ruhr keine einheitliche
Broadcastdomäne mehr sein soll ("Nach dem Umbau wird die jeweilige
Community mittels GRE Tunneln (IP Layer!) an die Domäne angebunden, so
dass die aktuelle Grundlast der Domäne nicht mehr in die Community
gelangt." => keine layer 2 Verbindung mehr zwischen der community und
und dem Rest der Domäne.) Dass irgendwann einmal Ende Gelände mit der
Größe der Broadcastdomain sein wird, das ist ja kein Geheimnis (wurde
auch gestern wieder erwähnt, woll?). Den Aufruf von Chris deutete ich
daher mal so, dass an der Lösung konkret gearbeitet werden soll. Das
geht zwar (m.E.!) auch ohne lokale Supernodes, aber weil die lokalen
communities ohnehin eine sinnvolle Einheit bei der Aufspaltung der
großen Broadcastdomäne sind, kann man das gleich mit der Lokalisierung
von traffic mittels WLAN-backbone verbinden. Wenn ich das alles richtig
verstanden habe (mit Hilfe von [4],[5]), dann erscheint mir das
Konzept lokaler Supernode als sinnvoller Schritt in die Zukunft, da er
direkten Nutzen bringt und die Lokalisierung des traffics und der
Verantwortung voranbringt. Und WLAN-Backbone ist doch durch die
(bestimmt nicht nur für mich) spannenden Infos über das Antennenwesen
beim Technik-Treffen fast greifbar geworden:-)


[1] <http://de.wikipedia.org/wiki/Wireless_Distribution_System>

[2] insb. Kapitel 4 und 5.3 von <http://www.wissenschaftsladen-dortmund.de/2013/04/01/bachelorarbeit-internet-anbindung-per-richtfunk/>

[3] insb. Folien 3 und 22 von <http://hitforum.de/dudl-pre.pdf>

[4] <https://forum.freifunk.net/uploads/default/170/326136dea60dc3de.png>

[5] <https://wiki.freifunk-rheinland.net/Freifunk_Rheinland_Net_2.0>


------------


**Markus antwortete:**

Bei FF-Ruhr rennen wir da offene Türen ein, denn Chris hat alle Hände
voll zu tun mit den bestehenden Supernodes. Sofern eine Community fähig
ist, Supernodes zu betreiben möchte er gern den Betrieb abgeben. Damit
ist einerseits die Infrastruktur verteilter und die Layer2-Domäne wird
verkleinert, weil Dortmund dann eine eigene Broadcast-Domain ist, was
der Performance von all unseren Nodes zugute kommt.

> > Ich verstehe noch nicht komplett was Chris da meint mit "WDS Backbone
> > für Batman-Wolken", aber das lässt sich ja klären.
> 
> Ich formuliere mein Verständnis dieses Ausdrucks mal so: Chris meint
> einen Funkbackbone zwischen lokalen meshes, durch den die nodes der
> verschiedenen beteiligten meshes untereinander und mit den lokalen(!)
> Supernodes eine (layer 2) Verbindung bekommen können. (Wg. layer 2
> braucht man in der Luft WDS [1], damit die MAC Adressen von Sender und
> Empfänger erhalten bleiben.)
> 
> Oder im Klartext: Richtfunkverbindungen zwischen den verschiedenen
> Funkwolken (meshes) der community.

Genau. Chris hat das im Mumble nochmal vertieft. Vorteil ist, dass die per WDS angebundenen Knoten
untereinander und auch zum Internet viel mehr Performance haben weil sie alle kein VPN mit Verschlüsselung brauchen.

> > deshalb sollten wir auch nach Spendern gucken, wo man ohne Ärger
> > Server/VMs unterstellen kann die konstant richtig Traffic erzeugen. 
> 
> Jau, das ist völlig unabhängig von den Überlegungen zu lokalen
> Supernodes sinnvoll! Beide Varianten stehen sich praktisch aber mglw.
> dadurch im Weg, dass die verfügbaren Kräfte des FF-DO-* erstmal nur für
> eine Kiste reichen. Muss man gucken, welch lustige Schar der tatkräftig
> Interessierten sich bald versammelt ... :-) 

Ich denke das geht beides. Es wird gerade versucht, für die Supernodes,
die von den Communities betrieben werden eine möglichst ähnliches Setup
zu ermöglichen, indem Debian als einheitliche Distribution favorisiert
wird und die Software (batman, fastd etc.) in ein für alle zugängliches
Repository gepackt wird, so dass das Setup eines Supernode relativ
einfach gehen sollte. Es ist natürlich weiterhin möglich andere Systeme
zu nutzen und mit Dingen nach belieben zu experimentieren. 

Ich finde das recht spannend, gerade weil Paketierung und
Automatisierung eins meiner Lieblingsthemen sind und es da noch viel
zutun gibt. Also tendenziell sollte der Betrieb von einem oder mehreren
Supernodes irgendwann nicht viel mehr Arbeit machen und man kann sich
auf die Weiterentwicklung konzentrieren.

Ich kann mir gut vorstellen, dass wir ein/mehrere Supernodes im Rechenzentrum
betreiben, um die "normalen" über VPN angebundenen Nodes zu entlasten,
gleichzeitig aber auch einen Supernode in den WiLa stellen, der erstmal
nur die Lokalen Nodes im LA und alles, was man über's Dach vom LA
erreichen kann direkt vom WiLa ins FFRL-Backbone ableitet.

Um dieses WDS-Thema dann vom Experimentierstadium (wofür ich Dortmund
und den LA für den perfekten Standort halte) in wirklich große
Dimensionen (Stadt zu Stadt, RZ zu LA etc.) zu bekommen will der FFRL
auf jeden Fall versuchen Mittel z.B. vom LfM und anderen zu bekommen,
weil sowas anders nicht zu stemmen ist.