--- 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] [2] insb. Kapitel 4 und 5.3 von [3] insb. Folien 3 und 22 von [4] [5] ------------ **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.