Layer 3 Firmware

Diese Seite gibt einen konzeptionellen Überblick über die Layer-3-Firmware und ihrer Vorteile gegenüber unserer alternativen Node-Firmware.

Infos wie ein Router mit der Layer-3-Firmware aufgesetzt wird, sind hier zu finden

Kurzfassung

Ein Layer-3-Router kann man sich wie ein Gateway „in der Stadt“ vorstellen, aber keine Angst, es ist bei weitem nicht so kompliziert wie es sich anfangs anhört. An dieses können, müssen aber nicht, Access Points und andere Netzwerktechnik angeschlossen werden, die keine Freifunk-Firmware brauchen. Es kann auch mit normaler Firmware weiter gemesht werden. Ebenfalls kann mit weiteren Layer-3-Router in der Stadt ein Peering eingegangen werden und sie somit direkt verbunden werden (z. B. über Richtfunk).

Die Vorteile zum alten Layer-2-System:

Die Verbindung wird schneller, da der L2-Traffic zurückgeht (durch die geringere Anzahl der Geräte innerhalb der Hood) und WireGuard oder GRE als Tunnelprotokoll verwendet werden kann, was deutlich schneller ist.
Man ist deutlich dezentraler und nicht von zentralen Komponenten wie z. B. den KeyXchange Abhängig. Man hat sein Netz selbst in der Hand.
Man kann Hoods in der Stadt über Richtfunk verbinden und somit Daten zwischen Hoods ohne jeglichen Internetuplink übertragen.
Theoretisch mit etwas Sonderkonfiguration kann sogar Traffic direkt am DSL-Anschluss ausgeleitet werden, wenn dies gewünscht ist (standardmäßig aber nicht aktiv und benötigt etwas größere Sonderkonfiguration).

Wie funktioniert das Netz aktuell?

Fangen wir mit einen Beispielbild an (dies bildet nicht den aktuellen Netzstand ab, sondern ist nur als Beispiel zu sehen).

Vereinfacht ist jede Hood ein großer virtueller Switch, den B.A.T.M.A.N. erstellt. Jeder Knoten, der am Internet hängt, baut zu X (2-5) Gatewayservern einen VPN-Tunnel auf und hängt sich über diesen Tunnel an den großen Switch. Meshrouter machen das gleiche, nur nutzen sie keinen VPN-Tunnel, sondern entweder das Ad-hoc-Netzwerk oder ein Netzwerkkabel.

Jeder „Switch“ ist nun einem IPv4-Subnetz zugeordnet, Fürth z. B. hat die 10.50.32.0/21. Damit ein Client mit z. B. der IP 10.50.33.22 das Subnetz (seinen Switch) überhaupt verlassen kann, muss er ein Standardgateway haben. Dies steht im Rechenzentrum (RZ) und stellt auch den DHCP-Server zur Verfügung. Alle Gateways sind über ein Layer-3-Routingprotokoll (ganz ähnlich, wie auch das Internet funktioniert) miteinander verbunden und tauschen ihre Subnetze aus. So sagt in der Grafik oben z. B. das Gateway Hassfurt: „Ich habe Internet und ich habe 10.50.6.XX (Subnetz von Hassfurt)“, das Gateway in Fürth sagt nur: „Ich habe 10.50.32./21.“ Somit kann das Gateway in Fürth den Internettraffic zu dem Gateway in Hassfurt schicken und alles, was aus Fürth zum Internet will, geht über das Gateway von Hassfurt.

Die Gateways sind meist über sogenannte GRE-Tunnel verbunden, als Layer-3-Routingprotokoll wird aktuell Babel verwendet. Daher auch die Begriffe im Bild.

Genauso kann ein Client in Hassfurt einen anderen Client in Fürth erreichen, da das Gateway nun weiß, worüber es die Clients in Fürth erreicht.

Eine (Richt)funkstrecke zwischen den Strecken wäre auf B.A.T.M.A.N.-Ebene (Layer-2-Switch) nicht möglich, da sonst die Segmentierung zerstört würde und wir aus zwei kleinen Switches einen großen machen würden – was früher sogar ein großes Problem war, was mittlerweile technisch gelöst wurde.

Auf Layer 3 können diese Hoods nicht verbunden werden, da jeglicher Traffic, der in eine andere Hood muss, erstmal zum Standardgateway geschickt wird, das irgendwo im RZ hinter einen DSL-, Kabel- oder Tunnelanschluss steht. So eine Richtfunkstrecke wäre also nie sinnvoll zu verwenden. Auch kann in diesem Setup niemals sinnvoll Traffic direkt am DSL Anschluss ausgeleitet werden, was immer mal wieder gewünscht wird – es „kann gemacht werden“, ist aber keinesfalls(!) Pflicht; man kann auch bei Layer-3-Routern weiterhin per VPN den Traffic ausleiten, was auch Standard ist.

Wenn man ein wenig logisch weiter denkt, kommt man zu dem Schluss, dass das Standardgateway näher an die Clients muss, um schon dort die Layer-3-Routingentscheidung fällen zu können. Genau dies passiert mit der Layer-3-Firmware.

Die Layer-3-Firmware

(Dieses Bild bildet nicht den aktuellen Netzstand ab, sondern ist nur als Beispiel anzusehen.)

Was ist hier nun passiert? Wie man auf den Bild erkennen kann, sind in der Stadt sogenannte Layer-3-Router entstanden. Auf diesen Gateways läuft grundsätzlich fast das Gleiche, wie auf den Gateways im RZ. Sie kommunizieren auf verschiedenste Wege (Richtfunk, VPN – wie GRE, OpenVPN, fastd, WireGuard –, Glasfaser, etc. Dies sind z. B. die blauen Linien im Monitoring) miteinander und announcen (geben bekannt) im Layer-3-Netz, welches Subnetz sie wiederum erreichen können. Genauso haben sie weitere Accesspoints hinter sich hängen, welche nun zu dieser Hood gehören. Sie machen auch DHCP und somit wird die Routingentscheidung nicht erst im RZ gefällt, sondern bereits in der Stadt. Somit ergeben sich die Möglichkeiten:

Man kann Hoods per Richtfunk auf Layer 3 verbinden.
Hoods bleiben sehr klein, da meist nur wenige Router hinten dran hängen. (Die aktuell größte Hood dürfte Hardhöhe sein, welche nur per Richtfunk angebunden ist und keinen eigenen Internetzugang hat, St. Paul ist ebenfalls sehr groß, aber auch, wie z. B. Hugo, gibt es Hoods mit nur einem Router.)
Auf dem VPN Tunnel werden Pakete einmal weniger verpackt, da Layer 3 direkt geroutet werden kann und nicht ins B.A.T.M.A.N. eingepackt werden muss.
Theoretisch kann auch Internetraffic problemlos direkt vor Ort abgeworfen werden. (Fall der Störerhaftung? Dies ist aktuell nur mit massiver Sonderkonfiguration möglich und kein Standartfall.)

In Fürth sieht das aktuelle Setup z. B. so aus. (Bild ist schon wieder veraltet, kann aber als reales Beispiel gut angesehen werden.):

Hier ist vom Prinzip alles enthalten, was ich oben erklärt habe:

fff-reddog stellt als Layer-3-Router-Zugang zum Internet über F3 Netze e. V. bereit. Daran angeschlossen ist als weiterer Layer-3-Router, vm2-fff-gw-cd1, welches ebenfalls ein Server im RZ ist und kein Internet anbietet. Er kann den Traffic also nur über fff-reddog ins Internet schicken.

Natürlich gibt es im echten Netz noch weitere Server im RZ, die Internetzugang anbieten, sodass der Ausfall von fff-reddog nicht der Ausfall des Internets im Freifunknetz wäre, sondern sich das Routingprotokoll Babel wird sich einfach automatisch einen anderen Server aussuchen der Internetzugang anbietet. Wenn man dann weiter denkt, geht das ganze soweit, dass sogar das Gateway Reddog noch am Netz bleibt, wenn fff-reddog ausfällt, es kann zwar den GRE-Tunnel zu fff-reddog nicht mehr nutzen, es kann aber über Richtfunk über St. Paul, über Hardhöhe, über Unterfürberg und anschließend über vm2-fff-gw-cd1 ins Internet gehen.

Genauso ist auch eine Kommunikation zwischen den Hoods problemlos über Richtfunk möglich. Z. B. entscheidet sich Gateway Unterfürberg regelmäßig dafür das Gateway Neunhof über die Hardhöhe zu erreichen. Somit kann ich hier in Unterfürberg komplett ohne Internet mit Neunhof reden. Ein Traceroute sieht hier so aus:

christiand@christian-pc:~$ traceroute 10.50.140.1
traceroute to 10.50.140.1 (10.50.140.1), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.229 ms  0.276 ms  0.327 ms
 2  fff-gw-cdhome.fff.community (10.50.138.1)  0.918 ms  0.965 ms  0.963 ms
 3  fff-gw-hh.gw.fff.community (10.50.130.1)  6.898 ms  6.905 ms  6.902 ms
 4  neunhofgw.fff.community (10.50.140.1)  25.396 ms  25.402 ms *

(Den ersten Hop wegdenken, das ist mein priv. Netz welches ins Freifunknetz NATtet, die hohen Pingzeiten sind auf den großen Distanzen sowie recht schlechter Anbindung von Neunhof durchaus normal, da ist kein DSL o. ä. dazwischen!)

Danach gibt es drei Gateways (Neunhof, Unterfürberg, Reddog) in der Stadt welche über VPN-Tunnel zu den Servern im RZ verbunden sind, darauf wird nur Layer 3 (Babel) gesprochen, kein B.A.T.M.A.N. Es wird hier also nur geroutet. Jedes Gateway ist eine eigene Hood.

Weiter gibt es Hoods die nur per Richtfunk angeschlossen sind (Hardhöhe und St. Paul) und keine direkte Verbindung zu den Internetgateways haben. Um das ganze etwas sinnvoll aufzuteilen werden die Verbindungen oft in eigene VLANs gesperrt. Hier muss man einfach mit seinen Gegenüber kommunizieren, welche VLAN-ID denn gerade noch frei ist.

Um sich das besser vorstellen zu können, sieht so ein Traceroute von der Hardhöhe aus:

root@fff-gw-hh:~# traceroute 10.83.252.11
traceroute to 10.83.252.11 (10.83.252.11), 30 hops max, 38 byte packets
 1  fffgwcdhome.gw.fff.community (10.83.252.15)  4.107 ms  6.053 ms  3.777 ms
 2  fff-gw-cd1.gw.fff.community (10.83.252.11)  49.502 ms  50.849 ms  50.973 ms
root@fff-gw-hh:~#

Man sieht gut, dass das Gateway auf der Hardhöhe erst zu fffgwcdhome routet (das ist Unterfürberg) und von dort das Internetgateway fff-gw-cd1 (das ist vm2-fff-gw-cd1) erreichen kann. Anhand der Pingzeiten kann man erkennen, das der erste Hop eine Richtfunkstrecke ist, der zweite Hop muss dann durch mein DSL.

Monitoring

Im Monitoring sieht das Ganze dann so aus (Layer „Local Routers“):

Wie man sieht, sind alle Gateways mit blauen Linien (Layer 3) verbunden.

Redundanz

Ach und warum eigentlich dezentral?

Redundanz durch L3-Peerings bedeutet Ausfallsicherheit. Wenn ich genug Layer-3-Peerings habe (egal ob Richtfunk, Glasfaser, VPN etc.) bin ich irgendwann nicht mehr von einer Person abhängig, sondern es müssten schon ganz viele mich aus ihrem Netz werfen, damit ich bei Freifunk nicht mehr mitspielen darf. Es gibt keine zentrale Instanz mehr die mich abschalten kann – dezentral!