…kommt gleich die Umleitung über die A2, da ist frei… 
1 „Gefällt mir“
An dieser Stelle die Bitte die stats seiten des Ruhrgebiets hier als weitere Reiter verfügbar zu machen:
http://map.freifunk-ruhrgebiet.de/alfred/alfred.html
@CHRlS: Da hab es eine Liste mit wieviel server man braucht + maximale Knoten anzahl und noch eine Seite mit der Auslastung der Ruhrgebietsserver.
Dann kann man selbst schauen, ob die Tunnel voll sind und dir nochmal extra die Dringlichkeit auf die Nase binden
Also haben wir 11server und bräuchten 20?
Wir bräuchten zumindest mindestens 16, ja.
Da ich aktuell versuche für den Übergang die Ressourcen für den Verein möglichst schlank zu halten laufen wir immer an der Lastgrenze.
Leider haben wir nach wie vor keinen Hoster für ein Blade Center finden können.
Back to topic: Nun kann es ein wenig wackelig werden, ich nehme jetzt ein paar experimentelle Dinge online, danach sollten dann sukzessive auch zwei weitere Server verfügbar werden…dann sind quasi 14 online…
1 „Gefällt mir“
Um schnell etwas Dampf aus dem Problem zu nehmen koennten diejenigen die einen Mesh mit mehr als einen VPN router betreiben auf eine VPN-Verbindung pro Uplink-Router herunter gehen. Die Redundanz ist ja ueber den 2. Uplink-Router gegeben.
Spart uebrigens auch Bandbreite im Uplink 
wenn das uns was bringt mache ich das gleich direkt mal … !
wie sollte das in der shell umzusetzen sein ?
uci set fastd.mesh_vpn_backbone.peer_limit=1
uci commit
reboot
1 „Gefällt mir“
Werde ich gleich mal später umsetzen
Ich werde es auf einen:
uci commit fastd.mesh_vpn_backbone.peer_limit
beschränken
Ich setze euch fortlaufend Kapazitäten nach, ihr müsst nicht unbedingt auf Tunnel verzichten.
Der Vorteil von 2 Tunneln ist, dass die Node nicht offline geht, wenn einer der beiden Tunnel neu aufbau und das bei zwei laufenden immer der beste Tunnel genutzt wird - also nicht unbedingt komplett unwichtig…
Wie lange braucht den der Mesh, um auf den Tunnel des 2. Uplink Routers zu schalten? Das sollte doch recht schnell gehen.
Wobei denn genau?
Wenn man peer limit 2 hat merkt man davon nix großartig. Wenn man peer limit 1 hat, dann muss erst ein Tunnel aufgebaut werden, das kann schon mal was dauern…
Die Frage ist ja wie lange ist der Timeout bis Fastd merkt das ein Tunnel nicht mehr funktioniert. Der Neuaufbau erfolgt dann nach diesem von @anon75826926 in der Gluon Mailingliste skizzierten Weise:
Klingt für mich so, das selbst das konfigurieren nur eines MESH Peers in der Firmware bei mehreren Möglichkeiten eine gewisse Redundanz mitbringt. Würde die Last auf den Supernodes doch um einiges verringern wenn jeder Knoten nur noch einen Tunnel aufmacht.
Wenn das peer Limit auf 1 steht, dann sollte nach dem ersten erfolgreich aufgebauten Tunnel kein weiterer Handshake gemacht werden, es sei denn der Tunnel kippt weg. So hatte ich es bislang immer verstanden.
Da immer nur ein Tunnel zeitgleich für den Nutztraffic in Nutzung ist habe ich keine echte Vorstellung davon, ob der zweite Tunnel überhaupt nennenswerte Last auf der Node und dem Gateway verursacht.
Vielleicht kann @anon75826926 dazu was sagen, der weiß das
Na immerhin die OGM wandern da ebenfalls durch, sprich die Grundlast, unabhängig welcher Supernode vom BATMAN gerade verwendet wird um Nutztraffic weiter zu leiten. Gerade in großem Mesh Netzen wie euren Domänen kann das z.B. für ein Anschluss der z.B. gerade mal DSL 2000 hat relevant sein.
Joa, der zweite Tunnel verdoppelt die Grundlast, was in Downstream-Richtung alle OGMs und Broadcasts sind, und in Upstream-Richtung nochmal alle OGMs. Die OGMs können den Upstream von ner lahme Leitung schon ganz gut auslasten… aber sind wenigstens eine relativ konstante Last, die keine unvorhersagbaren Lastspitzen erzeugt.
Vorteil bei zwei Verbindungen ist der schnellere Failover, wenn ein Gateway wegbricht, und Redundanz für den Fall, dass ein Gateway zwar da ist, was das VPN angeht, aber nicht korrekt funktioniert (z.B. wegen Überlastung hohen Paketverlust hat).
Aktuell ist das Timeout von fastd fest auf 90s eingestellt (ein hohes Timeout hat z.B. den Vorteil, dass bei einer 24h-Zwangtrennung die Verbindung wieder zum gleichen Gateway aufgebaut wird, sodass aus batman-adv-Sicht die Verbindung „nie weg war“ (bis auf kurzen Paketverlust zwischendurch). Ich könnte mir aber auch vorstellen, das Timeout in fastd v18 konfigurierbar zu machen, um vielleicht schon nach 10-20s einen Failover zu haben. (Ich habe vor einigen Monaten schon mal nen Patch für so ein Feature geschickt bekommen, den ich damals allerdings abgelehnt hatte…)
1 „Gefällt mir“
Wir haben das im Moment so, das wenn auf einem unserer GWs der Schweden Tunnel nicht mehr geht (Ping Timeout) das wir dem GW dann das BATMAN_adv GW Flag entziehen.
Man könnte zusätzlich nen Abwurf der Knoten durchführen, in dem man z.B. den FastD für 2 Minuten bei diesem Ereignis Off nimmt. Bis dahin sollten sich alle Knoten, wenn nur ein Tunnel aufgebaut werden darf, sich nen anderes GW suchen. Würde das gehen, oder hab ich nen Denkfehler?
@Chris: ich habe immer noch 2 Tunnel, aber je einen auf zwei verschiedenen Routern:
Die Frage war: Wenn der Tunnel des Routers Masurensee-01 wegbricht, wie lange dauert es, bis der gesamte Verkehr über Masurensee-03 laeuft.
1 „Gefällt mir“