Fastd-Tunnel auf einen reduzieren

Das können dir vielleicht @nullu, @Lars oder @einstein sagen :slight_smile:

In Karlsruhe wird nur noch ein Tunnel aufgebaut, negative Auswirkungen der Umstellung sind mir nicht bekannt.

1 Like

Kann ja jeder für sich testen…

uci set fastd.mesh_vpn_backbone.peer_limit=1
uci commit fastd.mesh_vpn_backbone.peer_limit
reboot

1 Like

Das habe ich bei mir schon seit einiger Zeit laufen und konnte keine negativen Auswirkungen feststellen.

1 Like

Sollte man in den nächsten Schnappschuß bringen - damit sollte es etwas mehr feedback geben
und mann könnte zur Not zurückrudern

Die Leasetime vom des DHCP Server ist eine Stunde.

Meiner Meinung nach sollte dennoch 2 fastd der default bleiben. Man kann den 3 Zeiler von @biggesee ja einfach in ein Script packen und dieses nach einem Firmware update auf die von einem gewarteten Router los jagen.

Es aber im nächsten Snapshot mal austesten fände ich auch gut. Leider sind keine 4% der Router mit der Snapshot Firmware unterwegs und von daher fände ich es doch sehr mutig sofort so einen Schnitt zu machen und das bereits in der nächsten stable zu ändern.

Klar es bringt einige Vorteile:
Weniger Last auf Servern
Weniger Upload „verschwendet“

1 Like

Wir haben aber per default keine ferngewarteten Router. Daher ist das nicht so einfach. (Stichwort Backdoor)

Fakt ist, dass es Gegenden im Einzugsgebiet der Möhne gibt, wo zwei Peers zu viel Grundrauschen für die krüppelige DSL erzeugen.

Man bräuchte mal ne typische Liste von Vorteilen zu Nachteilen von zwei Peers. Feldtest im Snapshot und dann könnte man entscheiden.

Announcen die Supernodes denn unterschiedliche Gateways per DHCP und die Gateways sind identisch mit den Supernodes? Falls ja, bringt dir die Redundanz nichts, da der Client erstmal sein DHCP-Lease erneuern muss um den anderen Gateway zu nutzen. In einer Stunde hat fastd auch längst eine Verbindung zum nächsten Supernode aufgebaut.

Ich gehe davon aus ja aber ich kann es dir nicht beantworten.

@lars kannst du mal was dazu sagen?

Korrigiert mich bitte, aber es geht noch auch um die Frage, was schneller ist oder?

Wenn fastd schneller merkt, dass der Tunnel weg ist und einen neuen aufbaut, ist der zweite Tunnel überflüssig.
Wenn BATMAN es schafft schneller die Route umzustellen, dann hat ein zweiter Tunnel vielleicht einen geringen Zeitvorteil gegenüber nur einem Tunnel.

Oder denke ich da als Nichtfachmann zu einfach?

Das wär ja dann möglicherweise mit einem Versuchsaufbau in der Sandkastendomäne zu klären.

Auch wenn Batman die Route umschwenkt, haben die Clients nichts davon, wenn sie weiterhin die nicht mehr erreichbare defaultroute verwenden.

Beispiel:

Gateway A hat 10.255.0.1
Gateway B hat 10.255.128.1

Fastd ist zu beiden verbunden, Batman hat B selektiert, die Clients haben per DHCP 10.255.128.1 als Defaultroute.
B ist nicht mehr erreichbar, Batman schwenkt zu A, die Clients haben aber weiterhin 10.255.128.1 als Gateway und erneuern die Lease maximal nach einer Stunde. In der Zeit haben die Clients trotz Batman-Redundanz kein Netz.

2 Likes

klingt logisch.
Aber ist denn zwingend gesagt, dass wenn Router A eine fastd Verbindung zu Server A habe auch Server A der DHCP für alle Clients dahinter ist. Weiter wählt auch jeder weitere Router seinen BATMAN Gateway selber und unabhängig vom fastd des Router A aus und ich bin mir sicher, dass dieser auch immer mal wieder wechselt.

Wenn einer weiss nach welcher Zeit oder welchem Unterschied in der Linkqualität gewechselt wird, wäre ich für diese Info sehr dankbar.

Also ein Router ohne mesh dahinter 1 fastd; mesh dahinter eher 2 Tunnel.

BATMAN filtert soweit ich weis nur die initialen DHCP requests. Sprich wenn ein Client noch keine IP hat. Bei der Erneuerung wird zuerst der bekannte DHCP Server per unicast angefragt und nur wenn der nicht mehr antwortet, wird wieder per Broadcast vom Client allgemein alle DHCP Server angefragt. Und hier greift dann wieder BATMAN ein und leitet die Anfrage zu seinem besten Gateway.

@bjo hat Recht, die zwei Tunnel sind wirklich in unserem Setup nicht so wirklich sinnvoll. Ich werde mal eine neue Firmware bauen mit einem Tunnel.

1 Like

Wäre es dann nicht sinnvoll direkt 2015.1 als stable zu bauen?

Ich möchte keine ungeprüften Änderung in den stable Zweig ausrollen. Stell dir mal vor ein Fehler passiert und unsere 975 Knoten müssen von Hand repariert werden :wink:

Wie wäre es wenn wir die neue Änderung jetzt noch 1-2 Wochen prüfen und danach machen wir sie zur Stable?

Du hast da mehr Ahnung von, war nur ein Vorschlag :smiley:

Dann updatet sich mein Knoten eben eine Version zurück (Snapshot drauf, aber Autoupdater auf stable).

Da zu jedem Knoten ja ein Mensch gehört der ihn betreibt ist das ja ziemlich einfach. Das technische KnowHow soll ja schließlich vermittelt werden, bevor ein Knoten Online geht. :wink:

1 Like
  1. Das ist trotzdem nichts was man machen möchte.

  2. Es kommt drauf an wie kaputt etwas ist.

@Lars hat einen neuen Snapshot bereitgestellt