neu

Ignore-this: 48c443d16decb0f4a86efafe409c9487

Technik/Netzinfrastruktur/Dortmunder Supernodes - erste Überlegungen.page

@@ -1 +1,228 @@
-neu
+---
+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.