Fastd-Tunnel, BATMAN_adv und Routing

Fortsetzung der Diskussion von Reduzierung der fastd Tunnel auf 1 im Ruhrgebiet:

Moin Kai!

Wie du schon geschrieben hast ist nur ein Tunnel halt ein SPOF. Und in der IT gilt nun mal N+1 ist immer besser als nur N. Und solange das Netz das noch aushält, ist doch alles prima in meinen Augen.

BATMAN_adv ist nun mal ein MESH Routing Protokoll welches nur eine einzige Metrik auswertet. Nämlich die Anzahl der eintreffenden Originator Messages von jedem Knoten und Gateway. Mir ist schleierhaft was das Zünglein an der Waage ist was bei einer TQ von 255 bei mehreren Gateways dann den Ausschlag gibt für welches Gateway sich Batman letztendlich entscheidet.

   de:ad:c0:1a:32:08 (225) de:ad:c0:1a:32:03 [  mesh-vpn]:  41 - 2048KBit/512KBit
=> de:ad:c0:1a:32:03 (255) de:ad:c0:1a:32:03 [  mesh-vpn]: 207 - 48MBit/48MBit
   de:ad:c0:1a:32:02 (255) de:ad:c0:1a:32:02 [  mesh-vpn]: 207 - 48MBit/48MBit
root@MA-WDR4300:~# 

Ich selber finde es auch suboptimal das sich das ganze nicht gleichmäßig verteilt. Mir fällt aber nichts ein was man besser machen könnte, oder welches Mesh Protokoll für unsere Infrastruktur nun besser wäre. Leider fehlen mir selbst die Möglichkeiten mich an der Entwicklung zu beteiligen, so gerne ich andere Protokolle zu mindestens mal testweise ausprobieren möchte. Es gibt ja nen ganzen Haufen von Protokollen.

Der Hybride Ansatz, die Funkwolke mit BATMAN und das Backend mit was anderem klingt zwar Sexy. Doch ich denke dann da auch schon wieder weiter. Was passiert wenn sich die einzelnen BATMAN Wolken dann doch wieder in einer Stadt berühren und zu einer großen wachsen? Oder muss ich verschiedene Firmwares pflegen welche unterschiedliche MESH IDs haben? Oder kann man das als Selektor im Config Mode einbauen? Und bekommt man das den Menschen vermittelt das sie sich für den richtigen entscheiden der in ihrem Gebiet verwendet wird? Vielleicht was automatisches, je nach eingetragener Koordinate, wenn sie denn eingetragen wird?

Interessant, dass bei euch so ungleichmäßig ausgewählt wird.

Nachdem wir nun die groups Funktion der site.conf verwenden sind die fastd Tunnel zwischen den beiden Rechenzentren in Aachen sehr schön aufgeteilt (Supernode 1&2 und 3&4 sind jeweils ein Standort)

Das bedeutet jeder Knoten kann sich immer zwischen einem Gateway aus 1&2 und einem aus 3&4 entscheiden.

Das führt zu diesem Ergebnis:

Der Supernodes 1 ist also weniger interessant als 3 oder 4. Supernode 2 hingegen wird als besser als 3 oder 4 bewertet.

Ich weiß, dass Node 1 eine besonders kurze Route ins Internet hat. Ich hätte daher eigentlich erwartet dass er der bevorzugte Knotenpunkt ist, da er damit auch weniger hops zu den meisten DSL Anbietern hat.

An der Uptime der Supernodes kann es nicht liegen, nur Supernode 4 hat vor zwei Tagen neu gestartet:
https://munin.ffac.aachalon.net/nodes.freifunk-aachen.de/comparison-day.html#system

Inwiefern beeinflusst denn die Internetanbindung des Gateways die Wahl der Knoten? Dazu liegt den Knoten doch keine Information vor, da das nicht über Batman geht.

Oder wie funktioniert das? Ich dachte da wird einfach gewürfelt und das ist durchaus eine ganz normale Wahrscheinlichkeitsverteilung.

Zu welchen Supernodes überhaupt ein VPN Tunnel aufgebaut wird ist reines würfeln.

Welcher Tunnel dann auch aktiv genutzt wird, hängt primär vom Packt loss ab. Der sollte durch die fastd Tunnel in aller Regel 0% sein. Aber eben auch von der Latenz, eine kurze Route vom DSL Anschluss zum Supernode sollte also bevorzugt werden.

OGMs that follow a path where the quality of wireless links is poor or saturated will suffer from packetloss or delay on their way through the mesh. Therefore OGMs that travel on good routes will propagate faster and more reliable.

ist zwar schon älter, aber die Info gehört hierher:

fastd macht zu beginn eine dns abfrage und connection zu allen fastd servern die auf enabled stehen, der schnellste bekommt den zuschlag, das geht weiter bis das limit (oder die limits der gruppen) erreicht ist. Verliert fastd eine connection ist der prozess eher random …
aber eben nicht initial, da bekommt der schnellstantwortende Server den Zuschlag - quasi.
Und fastd Verbindugnen sind extrem stabil, die überleben DSL reconnects locker, oder mini timeouts, die interessieren sich auch nicht für link quality, packet loss oder gar ob am anderen Ende überhaupt weiter Internet gibt.
Wenn die Server kein Limit haben nehmen die munter immer weiter Router an …