Layer 3 Firmware

Aus Freifunk Franken
Wechseln zu:Navigation, Suche

Hood
Hood grafisch
Dezentrale Hood
Hood V1 (alt)
[[..|Hood V2]]
- V2 Testkarte
- V2 Hood file

Hood nach Gemeinden
Hood als Polygon

Immer öfter hört man den Begriff "dezentrale Hood". Ich möchte hier versuchen zu erklären, was damit genau gemeint ist und warum ich (und auch andere) darin die Freifunk-Zukunft in Franken sehen.

Infos wie ihr eine dezentrale Hood aufsetzt und eine passende aktuell noch privat gebaute Firmware (es wird daran gearbeitet dies Upstream zu bekommen) findet ihr hier.

Kurzfassung

Eine dezentrale Hood besitzt ein eigenes Gateway "in der Stadt". 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.

Der Vorteil zum alten 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.
  • Wenn man es richtig macht ist man komplett dezentral
  • Man kann Hoods in der Stadt über Richtfunk verbinden und somit Daten zwischen Hoods ohne jeglichen Internetuplink übertragen

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)

Beispielbild

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 AdHoc 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 und stellt auch den DHCP-Server zur Verfügung. Alle Gateways sind über ein Layer3-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.XXXX (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 Layer3-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 2 kleine Switches einen großen machen würden (das passiert immer, wenn ich böse E-Mails schreibe, dass doch bitte der Standort richtig gesetzt werden soll).

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 Rechenzentrum hinter einen DSL/Kabel/Tunnelanschluss steht. So eine Richtfunkstrecke wäre also nie sinnvoll zu verwenden. Auch kann in diesem Setup niemals sinnvoll Traffic direkt am DSL Anschluss abgekippt werden, was immer wieder gewünscht wird.

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

Die dezentrale Hood

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

Beispielbild

Was ist hier nun passiert? Wie man auf den Bild erkennen kann, sind in der Stadt sogenannte "dezentrale Gateways" entstanden. Auf diesen Gateways läuft grundsätzlich fast das Gleiche, wie auf den Gateways im Rechenzentrum. Sie kommunizieren auf verschiedenste Wege (Richtfunk, VPN [GRE,OpenVPN,fastd,wireguard,...], Glasfaser, etc. dies sind z.b. die blauen Linien im Monitoring) miteinander und announcen (-> geben bekannt) im Layer3- Netz, welches Subnetz sie wiederum erreichen können. Genauso haben sie per B.A.T.M.A.N. weitere Router hinter sich hängen, welche nun zu dieser Hood gehören. Sie machen auch DHCP und somit wird die Routingentscheidung nicht erst im Rechenzentrum 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 Layer3 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?)

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


Netzplan Layer 3 Fürth

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.

Aber keine Sorge es gibt hier Backupscripte die in dem Bild fehlen, also für Ausfälle ist hier ausgesorgt, das ganze ist soweit dezentral, das selbst wenn fff-reddog ganz ausfällt vm2-fff-gw-cd1 automatisch auf Mullvad umschaltet und somit dezentralen Zugang zum Internet weiterhin aufrecht erhält. Wenn man dann weiter denkt, geht das ganze soweit, das sogar Gateway Reddog noch am Netz bleibt, es kann zwar den GRE Tunnel zu fff-reddog nicht mehr nutzen, es kann aber über Richtfunk über StPaul, ü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 3 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 StPaul) 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 2. 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!