diff --git a/content/technik-und-konzepte/freifunk-franken-netz/backbone.svg b/content/technik-und-konzepte/freifunk-franken-netz/backbone.svg new file mode 100644 index 0000000..3c3bed3 --- /dev/null +++ b/content/technik-und-konzepte/freifunk-franken-netz/backbone.svg @@ -0,0 +1,586 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ellipsis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ellipsis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/technik-und-konzepte/freifunk-franken-netz/hoods_fehler.svg b/content/technik-und-konzepte/freifunk-franken-netz/hoods_fehler.svg new file mode 100644 index 0000000..c359a31 --- /dev/null +++ b/content/technik-und-konzepte/freifunk-franken-netz/hoods_fehler.svg @@ -0,0 +1,839 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ellipsis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 2 + 1 + + + + + diff --git a/content/technik-und-konzepte/freifunk-franken-netz/index.md b/content/technik-und-konzepte/freifunk-franken-netz/index.md new file mode 100644 index 0000000..96d971f --- /dev/null +++ b/content/technik-und-konzepte/freifunk-franken-netz/index.md @@ -0,0 +1,209 @@ +--- +title: "Freifunk Franken Netz" +date: 2022-11-18T00:10:23+01:00 +--- + +Überblick über das Freifunk Franken Netz und seine Technik + + + +![Übersicht des Freifunk Franken Netz](netz.svg "Übersicht des Freifunk Franken Netz") + +## Zentrale Hoods "V2" +### Szenario 1: "klassisch" + +Das mit der **1** gekennzeichnete Szenario sollte den meisten Freifunkern am vertrautesten sein. +Freifunkknoten mit unserer **Node Firmware** meshen mit wenig Konfiguration automatisch über WLAN mit einem [B.A.T.M.A.N. Advanced][batman]-Tunnel (durchgezogene Linien in grün). + +Um auch einen Weg ins Internet zu finden, müssen sich Geräte über einen weiteren Layer 2 Tunnel (bei uns [fastd], oder optional [VXLAN], gestrichelte Linien in grün) zu einem **Gateway** aufbauen. + +Alle Knoten im diesem Verbund befinden sich im selben Layer 2 Netz. Wir nennen diesen Verbund eine **Hood**. +In einer Hood ist es, als ob jeder Knoten am selben, virtuellen Switch hängt. +Es ist damit wie eine große LAN-Party, wo jeder jeden direkt über MAC Adressierung erreichen kann. + +![Vergleich reales Netz zur Netztopologie](node_real_topologisch.svg "Vergleich reales Netz zur Netztopologie") + +Viele Teilnehmer im selben Netzsegment sorgen leider für ein zunehmendes Grundrauschen. +Ab einigen hundert Teilnehmern ist das Netz zu groß sinnvoll Nutzverkehr weiterleiten zu können. +Deshalb sind Hoods [geographisch begrenzt][hoods], um die Teilnehmerzahl in einem beherrschbaren Umfang zu halten. + +Das **Gateway** ist grob gesagt die *Fritz!Box* für eine Hood. +Gateways stehen bei uns gut angebunden in Rechenzentren, denn durch sie wird sämtlicher Traffic geleitet, der zu anderen Geräten im restlichen Freifunknetz, oder über unsere Borderrouter ins Internet soll. +Sie sind damit der **zentrale** Router in Hood, die darüber hinaus auch einen DHCP Server, Konfiguration für die Knoten, Monitoring und vorallem die Verbindung zu unserem **Layer 3** Backbonenetz herstellen. + +### Szenario 2: "realistisch" + +Szenario **2** zeigt allerdings wie es häufig tatsächlich aussieht. +Die überwiegende Mehrheit an Freifunkknoten haben keine Nachbarn, mit denen sie automatisch meshen können. + +Freifunkknoten stehen leider häufig nicht in Nähe oder mit Sichtkontakt zu anderen Knoten. +Zusätzlich verfügen die meisten Geräte nicht über die passende Antennentechnik um nennenswerte Strecken performant, oder wenigstens stabil, zu überbrücken. + +Über die Zeit ist das Freifunknetz daher etwas zu einen Hotspotnetz verkommen, um bequem die Störerhaftung zu umgehen. +Das ist nicht notwendigerweise schlimm oder schlecht, aber man hat sich dennoch etwas vom Wunschszenario entfernt. + +Vorallem darf keine Verbindung zwischen benachbarten Knoten aus unterschiedlichen Hoods existieren (rote Linie zwischen **1** und **2**). +Es würden zwei sonst getrennte Netze gemischt und Knoten fehlkonfiguriert, da eine Verbindung zu mehrere Gatways mit unterschiedlicher Konfiguration besteht. +Die Firmware unterbindet daher solche Verbindungen. + +![Fehlerhafte Verbindung zwischen zwei Freifunkknoten aus unterschiedlichen Hoods](hoods_fehler.svg "Fehlerhafte Verbindung zwischen zwei Freifunkknoten aus unterschiedlichen Hoods") + +Gelegentlich laufen aber die Hoodgrenzen recht ungünstig beispielsweise mitten durch einen Ort. Selbst gewollte Verbindungen sind so nicht möglich. + +Erst recht problematisch ist das klassische Konstrukt für ambitioniertere Aufbauten, die per Richtfunk mehrere Kilometer überbrücken möchten. +Diese Funkstrecken sind mittlerweile in der Größenordnung einiger Hoods und kreuzen damit sogar mehrere solche Gebiete. + +Will man mit Geräten aus anderen Hoods kommunizieren, geht der Verkehr + +1. durch das eigene Gateway +2. durch das Layer 3 Netz zum anderen Gateway +3. zum Zielgerät + +## Layer 3 Netz +### Motivation + +Unser klassischer Aufbau kann also nicht beliebig groß werden und muss daher in kleinere Netzsegmente zerlegt werden. +Ohne weiteres hätte man so zunächst nur viele eigenständige Inseln gebaut, aber keine Verbindungen dazwischen. +Außerdem soll der Traffic irgendwo ins Internet geleitet werden können und von dort auch wieder den Weg zurück finden. Rechtlich ergeben sich da leider immer noch Probleme, die nicht jeder Gatewaybetreiber auf sich nehmen mag. + +Es braucht also eine vernünftige Lösung Gateways untereinander zu verbinden und gleichzeitig auch einen weg ins Internet bereit zu stellen. + +### Routing +Zu diesem Zweck gibt es [Routingprotokolle][Routingprotocol]. Router und unsere Gateways verbinden sich dazu auch wieder mit Tunneln, Kabeln, oder Richtfunk. Sie teilen sich dabei aber kein einzelnes Netzsegment. +Im Gegensatz zu einem Heimnetz, wo jedes Gerät gesagt bekomme welche IP es hat, definiert sich ein Router selbst welche IP er hat und welche Netze er direkt erreicht. +Bei einem Gateway ist das beispielsweise das Prefix für die verwaltete Hood. +Diese Informationen tauscht er dann mit seinen direkten Nachbarroutern aus, welcher diese Informationen ebenfalls an alle seine Nachbarn weitergibt. + +![Backbonenetz](backbone.svg "Backbonenetz") + +Auf diese Art lernen die Router in diesem Verbund welche Netze es gibt und über welchen Nachbar diese am günstigsten zu erreichen sind. Diese Routen werden dann automatisch in die Routingtabellen vom Router geschrieben und müssen deshalb nicht per Hand konfiguriert werden. Das ganze geschieht dynamisch und wird ständig überwacht. Bei Verbindungsabbrüchen oder neuen Routern im Netz werden die Routingtabellen automatisch bei Bedarf angepasst. + +Es ließt sich natürlich sehr ähnlich zu dem was [B.A.T.M.A.N Advanced][batman] leistet. Der Unterschied liegt aber darin, dass [B.A.T.M.A.N Advanced][batman] MAC Adressen verwaltet und darüber hinaus Pakete zusätzlich in einen extra Tunnel dafür verpackt, während beim Routing Pakete anhand ihrer IP Adressen nur von einem Interface zu nächsten geleitet werden. + +Beim Routing fällt also bei der Paketverarbeitung deutlich weniger Arbeit an. + +#### Babel + +Im Freifunk Franken Netz verwenden wir das [Babel Routing Protocol][babel] ([RFC 8966], [Wikipedia][babel-wiki]). + +Babel ist ein Distance-Vector Routingprotokoll. Das bedeutet, ohne zu viel in Details zu gehen, dass es jeder Strecke zwischen zwei Routern Kosten zuordnet. Langsame Verbindungen kosten mehr als schnelle Verbindungen. Die Kosten sind nur eine Zahl, die man konfigurieren kann. Ein Router lernt über seine Nachbarn wie viel der Weg zu einem bestimmten Netz über diesen Nachbar in Summe kostet und entscheidet sich dann für den Weg mit den kleinsten Kosten. Dieser Weg wird dann als Route in der Routingtabelle eingetragen. + +Stand Ende 2022 umfasst diese Routingtabelle ca. 1750 Routen für IPv6 und 1100 Routen für IPv4. Dies beinhaltet allerdings auch die Routen zum restlichen [icvpn]. + +#### Borderrouter + +Eine besondere Aufgabe haben unsere Borderrouter. Sie stellen den Übergabepunkt zum restlichen Internet. Auf der einen Seite sind sie mit dem Babelnetz verbunden, auf der anderen Seite mit "dem Internet". Mittlerweile passiert das ordentlich mit Peeringpartnern an Internetexchanges über das [Border Gateway Protocol (BGP)][BGP] - *das* Routingprotokoll im Internet. + +Stand Ende 2022 umfasst die Routingtabelle ca 159000 Routen für IPv6 und 900000 Routen für IPv4. + +### Szenario 3: Layer 3 + +![Layer 3 Router](l3.svg "Layer 3 Router") + +Dargestellt in **3** ist ein Router mit der Layer 3 Firmware. Dieser baut zwei Tunnel (z.B. [Wireguard] oder [GRE], gestrichelte Linie in blau) zu anderen Routern im Layer 3 Netz auf. Der Router hat ebenfalls noch eine weitere direkte Verbindung (z.B. Kabel oder Richtfunk, durchgezogene Linie in blau). + +Auf diesen Verbindungen wird Babel gesprochen. Der Router informiert seine Nachbarn über seine eigene IP Adresse und das Prefix von dem Clientnetz (orange), welches der Router bereitstellt. + +Der Router nimmt also ohne Umwege direkt am Layer 3 Netz teil. Er hat die volle Kontrolle darüber, mit welchen anderen Routern er peeren möchte und ist dabei nicht geografisch an ein Gateway gebunden. + +In diesem Beispiel ist das verwaltete Netz sehr klein dargestellt. Das kann Sinn machen, wenn eine direkte Teilnahme am Layer 3 Netz gewünscht ist, oder die Hauptaufgabe des Routes darin besteht für ein angrenzendes Richtfunknetz die Internetverbindung sicher zu stellen. + +### Szenario 4: Großaufbau + +![Layer 3: Großaufbau](l3_large.svg "Layer 3: Großaufbau") + +Bei größeren Aufbauten wie in **4**, die bis zu **mehrere hundert Clients** bedienen sollen, kann das Layer 3 Konzept seine ganze Stärke zeigen. In der Regel werden solche Projekte eher von wenigen Leuten gezielt geplant und aufgebaut. +Vor Ort kann das Netz daher mit klassischen Mitteln durch Kabel, Switches und gewöhnliche Accesspoints aufgebaut werden. +Die Anbindung an das Freifunknetz geschieht am besten über Kabel oder Richtfunk (durchgezogene Linie in blau). + +Dieser Aufbau ist besonders geeignet bei +- Festen +- Stadthallen +- Marktplätze +- Geflüchteten Unterkünfte + +Solch ein Szenario ist teilweise nur schwer mit der Node Firmware zu realisieren. Einfach eine Anzahl an Knoten verteilen und hoffen, dass das Mesh schon alles richten wird, ist ab einer gewissen Größe einfach nicht praktikabel. +Selbst wenn man den Aufbau ähnlich ansetzt und nur einen Knoten verwendet, kann es zu Engpässen kommen, da das Meshprotokoll und ggf. die Tunneltechnologie den Geräten mehr abverlangt. +Auch die Hood als ganzes könnte durch den höheren Resourcenverbrauch beeinträchtigt werden. Eventuell muss sogar der Gatewaybetreiber eingreifen und z.B. weitere IP Adressen verfügbar machen. + +### Szenario 5: ohne Tunnel + +![Layer 3: Ohne Tunnel](l3_ohne_tunnel.svg "Layer 3: Ohne Tunnel") + +**5** ist das absolute Luxuszenario. Direkt Kabel und Richtfunk (durchgezogene Linien in blau) zum Borderrouter. Kein Tunnel, nur IP Pakete von einer Buchse in die andere. +Dank 60GHz Hardware bedeutet das mittlerweile bezahlbare Gigabit Geschwindigkeiten. +Mehr ist dazu auch nicht zu sagen :) + +--- +# TODO +## Einleitung + +- weniger Details, dafür mehr Überblick + - eher als Sprungbrett zu einzelnen Themen gedacht +- Entscheidungshilfe Node vs L3 +- weniger als Nachschlagewerk gedacht, dafür hoffentlich roter Faden erkennbar +- ertragbare Länge + +## Welche Firmware? + + - Einfache Auswahlkriterien + - Noch einmal **kurz** Vor- und Nachteile auflisten + +| | Node | Layer3 | +|---|:-:|:-:| +| Konfiguration | + | - | +| Automatisches Wifi Mesh + Roaming | + | - | +| Performance | - | + | +| Flexibilität Peering | - | + | +| Flexibilität Hardware | - | + | +| Aufwand Firmwareentwicklung | - | + | +| Aufwand Gateways | - | + | +| ... | ... | ... | + +## Glossar +- Fußnoten[^Layer3]? + - tauchen nicht in der TOC auf + - Position nicht steuerbar + - sollte allerdings überall gehen +- Links zu Headern? [Beispiel](#Beispiel) zu [Fußnoten](#Fußnoten) + - Abhängig vom Markdownprocessor + - Hedgedoc erzeugt eventuell andere IDs als gitea oder hugo + +### Beispiel + +### Fußnoten + +[^Layer3]: **Layer3** +usw + +## Bemerkungen / FAQs +- Layer 3 Technik ist unabhängig von Freifunk Franken + +[batman]: https://www.open-mesh.org/projects/batman-adv/wiki "B.A.T.M.A.N Advanced" +[fastd]: https://github.com/NeoRaider/fastd "fastd" +[VXLAN]: https://datatracker.ietf.org/doc/html/rfc7348 +[hoods]: https://monitoring.freifunk-franken.de/map?mapcenter=49.82400,10.78600,9&source=1&layers=1,1,1,0,1,0,0 "Freifunk Franken Monitoring" +[Routingprotocol]: https://en.wikipedia.org/wiki/Routing_protocol +[RFC 8966]: https://datatracker.ietf.org/doc/html/rfc8966 +[babel]: https://www.irif.fr/~jch/software/babel/ +[babel-wiki]: https://en.wikipedia.org/wiki/Babel_(protocol) +[icvpn]: https://wiki.freifunk.net/IC-VPN +[BGP]: https://en.wikipedia.org/wiki/Border_Gateway_Protocol +[Wireguard]: https://www.wireguard.com/ +[GRE]: https://en.wikipedia.org/wiki/Generic_Routing_Encapsulation + + + + + + + + + + + + + + + + diff --git a/content/technik-und-konzepte/freifunk-franken-netz/l3.svg b/content/technik-und-konzepte/freifunk-franken-netz/l3.svg new file mode 100644 index 0000000..4e46249 --- /dev/null +++ b/content/technik-und-konzepte/freifunk-franken-netz/l3.svg @@ -0,0 +1,389 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ellipsis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 3 + + diff --git a/content/technik-und-konzepte/freifunk-franken-netz/l3_large.svg b/content/technik-und-konzepte/freifunk-franken-netz/l3_large.svg new file mode 100644 index 0000000..da3b5a7 --- /dev/null +++ b/content/technik-und-konzepte/freifunk-franken-netz/l3_large.svg @@ -0,0 +1,677 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ellipsis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 4 + + diff --git a/content/technik-und-konzepte/freifunk-franken-netz/l3_ohne_tunnel.svg b/content/technik-und-konzepte/freifunk-franken-netz/l3_ohne_tunnel.svg new file mode 100644 index 0000000..0f5a336 --- /dev/null +++ b/content/technik-und-konzepte/freifunk-franken-netz/l3_ohne_tunnel.svg @@ -0,0 +1,400 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ellipsis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 5 + + diff --git a/content/technik-und-konzepte/freifunk-franken-netz/netz.svg b/content/technik-und-konzepte/freifunk-franken-netz/netz.svg new file mode 100644 index 0000000..377afbd --- /dev/null +++ b/content/technik-und-konzepte/freifunk-franken-netz/netz.svg @@ -0,0 +1,1861 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ellipsis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Borderrouter + Router + Gateway + Layer3 Firmware + Node Firmware + Switch + Access Point + Direktes Peering + Peering über L3 Tunnel + Batman auf direkter Verbindung + Batman in L2 Tunnel + Direkte Verbindung + Clients + + Dezentrale Hood + 5 + 4 + 3 + 2 + 1 + + Hood + + + + + + diff --git a/content/technik-und-konzepte/freifunk-franken-netz/node_real_topologisch.svg b/content/technik-und-konzepte/freifunk-franken-netz/node_real_topologisch.svg new file mode 100644 index 0000000..4ed6855 --- /dev/null +++ b/content/technik-und-konzepte/freifunk-franken-netz/node_real_topologisch.svg @@ -0,0 +1,1094 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ellipsis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ellipsis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ellipsis + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + real + topologisch + + +