Layer 3 Firmware: Unterschied zwischen den Versionen

Aus Freifunk Franken
Wechseln zu:Navigation, Suche
Keine Bearbeitungszusammenfassung
Zeile 19: Zeile 19:
Auf Layer 3 können diese Hoods auch nicht verbunden werden, da jeglicher Traffic der in eine andere Hood muss, erstmal zum Standardgateway geschickt wird und das irgendwo im Rechenzentrum hinter einen DSL/Kabel/Tunnelanschluss steht. So eine Richtfunkstrecke wäre also nie sinnvoll zu verwenden.
Auf Layer 3 können diese Hoods auch nicht verbunden werden, da jeglicher Traffic der in eine andere Hood muss, erstmal zum Standardgateway geschickt wird und das irgendwo im Rechenzentrum hinter einen DSL/Kabel/Tunnelanschluss steht. So eine Richtfunkstrecke wäre also nie sinnvoll zu verwenden.


Wenn man ein wenig logisch weiter denk, kommt man dann zu den Schluss das Standardgateway muss näher an die Clients hin und genau dies passiert mit der dezentralen Hood
Ebenfalls kann in diesem Setup niemals richtig sinnvoll Traffic direkt abgekippt werden, was ja durchaus immer mal wieder ein Wunsch ist.
 
Wenn man ein wenig logisch weiter denk, kommt man dann zu den Schluss das Standardgateway muss näher an die Clients hin um dort schon die Routingentscheidung fällen zu können und genau dies passiert mit der dezentralen Hood


== Die dezentrale Hood ==
== Die dezentrale Hood ==

Version vom 5. November 2017, 16:08 Uhr

Immer öfter hört man aus der Gegend Fürth und Nürnberg die Begriffe "dezentrale Hood". Ich möchte hier mal versuchen zu erklären was damit genau gemeint ist und warum ich (und auch andere) darin die Freifunk Zukunft in Franken sehen.

Wie funktioniert das Netz aktuell

Fangen wir mit einen Beispielbild an (dies bildet NICHT den aktuellen Netzstand ab, sondern ist nur als Beispiel anzusehen)

Beispielbild

ganz einfach gesagt, ist jede Hood ein großer virtueller Switch den Batman erstellt. Jeder Knoten der am Internet hängt baut zu X (2-5) Gatewayserver 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 einen IPv4 Subnetz zugeordnet, z.b. Fürth 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 Standartgateway haben. Dies steht im Rechenzentrum und macht auch gleich DHCP Server. Alle Gateways sind über ein Layer 3 Routingprotokoll (ganz ähnlich wie das komplette 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 den 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 und auf als Layer 3 Routingprotokoll wird aktuell Babel verwendet. Daher auch die Begriffe in dem Bild.

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

Eine (Richt)funkstrecke zwischen den Strecken wäre auf Batman Ebene (Layer 2 Switch) nicht möglich, da sonst die Segmentierung kaputt geht und wir aus 2 kleine Switche einen großen machen (das passiert immer, wenn ich böse E-Mails schreibe das doch bitte der Standort richtig gesetzt werden soll).

Auf Layer 3 können diese Hoods auch nicht verbunden werden, da jeglicher Traffic der in eine andere Hood muss, erstmal zum Standardgateway geschickt wird und das irgendwo im Rechenzentrum hinter einen DSL/Kabel/Tunnelanschluss steht. So eine Richtfunkstrecke wäre also nie sinnvoll zu verwenden.

Ebenfalls kann in diesem Setup niemals richtig sinnvoll Traffic direkt abgekippt werden, was ja durchaus immer mal wieder ein Wunsch ist.

Wenn man ein wenig logisch weiter denk, kommt man dann zu den Schluss das Standardgateway muss näher an die Clients hin um dort schon die Routingentscheidung fällen zu können und 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

so was ist nun hier passiert? Wie man auf den Bild erkennen kann, sind in der Stadt sogenannte "dezentrale Gateways" entstanden. Auf diesen Gateways läuft grundsätzlich mal 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 Layer 3 Netz welches Subnetz sie denn genau hinten dran erreichen können. Genauso haben sie per Batman weitere Router hinten dran 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, StPaul ist ebenfalls sehr groß, aber wie z.b. den Hugo kann es auch 1-Router-Hoods geben)
  • Auf dem VPN Tunnel werden Pakete einmal weniger verpackt, da Layer 3 direkt geroutet werden kann und nicht ins Batman 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)

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 Batman. 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.