Hallo zusammen,
da ja in nächster Zeit wohl eine neue stable-Version ansteht, stellt sich mir die Frage, ob es nicht sinnvoll wäre die Fastd-Tunnel-Zahl per default auf eins zu setzen. Das würde uns beim Grundrauschen etwas Aufschub bringen und ich wüsste keinen Fall, indem der zweite Tunnel einen wesentlichen Vorteil bringen würde. Meines Wissens läuft auch schon eine Domäne mit einem Tunnel, allerdings weiß ich grade nicht mehr welche das ist.
Was ist eure Meinung dazu?
Viele Grüße
Finde ich einen guten Einwurf - wer möchte, kann die Zahl per SSH ja immer noch nachkorrigieren.
Bietet eigentlich nur Ausfallsicherheit, soweit ich das verstanden habe. Wenn also ein SuperNode ausfällt, bleibst Du online. Mit nem Peerlimit von 1, bricht dann alles zusammen, bis er nen neuen Peer gefunden hat. Das kann dann aber nen Moment dauern.
Ich wäre aufgrund des Grundrauschens auch sehr dafür das Peer-Limit auf 1 runter zu setzen, da ich das bei knappen Leitungen sowieso immer einstelle. Bedeutet nämlich bei jedem Update immer Nacharbeit, weil das Setting nicht updatefest ist.
Tante Edith sagt: Wenn das updatesicher werden könnte, wäre das fast geiler, da man dann individuell auf die Gegebenheiten vor Ort reagieren könnte.
In der Theorie funktioniert das zwar so, allerdings ist BATMAN in der Praxis glaube ich so träge, dass es keinen großen Zeitvorteil bringt einen zweiten Tunnel zu haben.
Wie hoch ist denn die Leasetime? Und erhalten eure Clients bei allen Supernodes denselben Gateway?
In Karlsruhe wird nur noch ein Tunnel aufgebaut, negative Auswirkungen der Umstellung sind mir nicht bekannt.
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
Das habe ich bei mir schon seit einiger Zeit laufen und konnte keine negativen Auswirkungen feststellen.
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“
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.
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.
Wäre es dann nicht sinnvoll direkt 2015.1 als stable zu bauen?
