Reduzierung der fastd Tunnel auf 1 im Ruhrgebiet

Hallo zusammen,

parallel zu Möhne schlage ich für das schwer gebeutelte Ruhrgebiet eine zeitnahe Anpassung der fastd Tunnelanzahl auf 1 vor.

Die Probleme im Ruhrgebiet rechtfertigen meiner Meinung nach eine zeitnahe Umstellung, ohne snapshots und beta Versionen abzuwarten.

Fortsetzung der Diskussion von Fastd-Tunnel auf einen reduzieren:

1 Like

Frage dazu: Wie lange dauert es den bis ein Node merkt das sein Gateway nicht mehr Antwortet und bis die Verbindung zu einem anderen Supernode aufgebaut ist?

Werden die Tunnel aktuell Round-Robin oder Acive-Passive benutzt?

Es gibt ja zwei Möglichkeiten des Ausfalles. Der eine ist, der fastd Tunnel wird getrennt. Dann versucht der Knoten diesen wieder aufzubauen. Wenn es mit dem vorherigen Gateway nicht klappt nimmt er ein Anderes welches in der site.conf eingetragen ist.

Ist der Tunnel aber aufgebaut, nur es findet kein Datenaustausch durch den Tunnel statt, dann bleibt der Knoten offline. Mit zwei Tunneln je Knoten reduziert sich zu mindestens die Wahrscheinlichkeit des zweiten Falles.

Vielleicht andere Baustelle: Man macht Staging vor allem um „Fehler die es nicht gibt“ doch noch zu finden -statt sich öffentlich in den Kopf zu schiessen :wink:

Wir haben in MS ja gerade von 2->1 Tunnel umgestellt, da war das Staging in 5 Tagen durch.

Wie wahrscheinlich ist denn dieser Fall?

Ich betreibe uebrigens schon seit einiger Zeit 2 Router mit nur einem Tunnel und es hat bisher noch keine Probleme gegeben.

Als Vorstufe zum Stagen koennt ihr ja hier die Komandos zum manuellen Umstellen auf einen Tunnel posten. Dann kann jeder Betreiber selber entscheiden, ob einen oder zwei Tunnel.
Ich habe mit der ein-Tunnel-Anbindung jedenfalls keine Probleme

Keine Ahnung, aber als ITler finde ich Redundanz nie verkehrt. Und das euch eure Domänen in Sachen Grundrauschen um die Ohren fliegen war ja von Anfang an abzusehen, weil der FFRL ja nie die Communitys gefördert hat aktiv eigene Strukturen (Kollisions-Domänen) aufzubauen, sondern auf Zentralität gesetzt hat.

3 Likes

Als ITler kann ich dir sagen ich mag auch Redundanzen. Aber diese sind hier ja auch eher nicht vorhanden, da die Internet Verbindung der Nodes auch nicht Redundant ist.

Die Aussage von dir, zum FFRL stimmt ja nicht so ganz, da es aktuell ja schon einige Domains gibt und dieses ja gerade noch weiter Ausgebaut wird.

Schön wäre es, ist aber nicht der Fall.
Der Node bleibt bei dem defekten Gateway, solange das via Batman noch sichtbar ist. (und das kenne ich leider als Standard-Fall. Also "fastd-connect stabil, batman stabil bei einem gateway, aber dieses Gateway hat keine brauchbare Außenanbindung -oder faktisch gar keine. Ergo: der Plasterouter bleibt in Nibelungentreue bei dem hirntoten Gateway sitzen statt auf den zweiten schon aufgebauten Tunnel zu schalten und dort das Gateway zu nutzen.)

2 Likes

Ich kenne mich mit der beim FFRL verwendeten Raketen Technologie auf den Supernodes noch nicht so ganz aus. Aber unsere Gateways haben nen Script laufen was immer mal wieder durch den Schweden Tunnel nen Ping schickt. Und wenn der nicht zurück kommt, dann wird einfach ein batctl gw off gemacht. Dann wird der Schweden OpenVPN Tunnel neu gestartet und das Spielchen wiederholt sich. Ist der Schweden Tunnel wieder verfügbar, wird wieder batctl gw server gesetzt. Zusammen mit ner DHCP Lease Time von 5 Minuten, wäre ein Client also nur diese maximalen 5 Minuten ohne Anbindung. Das wäre das Szenario was du andeutest. Und ich war mir eigentlich sicher das es so was auf jedem Gateway gibt. Ok, wieder was gelernt.

Es kann aber auch mal dazu kommen das eben ein FastD Tunnel aufgebaut ist und zwischen Knoten und Gateway, warum auch immer, keine Daten durch gehen. Wenn da keine Daten durchgehen, dann auch keine BATMAN OGM und somit würde ein zweiter Tunnel zu einem anderen Gateway sehr wohl Sinn machen.

Hallo Zusammen!

Die Umstellung war schon länger geplant, nach Rücksprache mit anderen Communities werden wir sehr kurzfristig ein Update ausrollen.

Gruß,
Philip

1 Like

Als hinkender Vergleich: Du hast damit ein Redundantes Stromkabel vom PC-Netzteil zu den Festplatten. (Aber weder redundante Netzteile, noch eine USV, noch ein Raid…)
Sprich: Die Redundanz hilft nicht wirklich viel weiter, weil die realten Probleme andere sind.
Die werden zwar durch „nur ein Kabel“ auch nichtgelöst, aber zumindest spart man sich dann überflüssiges Zeug.

Verstehe zwar nicht was du mir sagen willst, aber gut. Wir haben 3 Gateways bei zwei verschiedenen Providern, wir haben 3 DHCP Bereiche, wir haben 3 VPN Tunnel von 2 verschiedenen Anbietern und wir haben 2 FastD Tunnel je Knoten. Ich bin ja auch nur Mitglied einer 135 Knoten Community. Was wage ich mich denn den Größenwahnsinn und die technischen Konzeptlosigkeit einer 1300 Knoten Domäne des FFRL in Frage zu stellen.

Siehste! Unsere Domaine ist viel größer als Eure!

Ich glaube alle haben verstanden, dass dir das Konzept des FFRL nicht gefällt.

Wie ich ja jetzt in einem anderen Thema gelernt habe, hängt die Trägheit von BATMAN von der DHCP Lease Time ab.

Bleibt ja trotzdem die Frage, ob die Reaktionszeit von fastd nicht unter eine sinnvollen Lease Time liegt. Unabhängig davon in welcher Domäne man sich befindet.

PS: Auch in kleinen Domänen sind verringertes Grundrauschen und weniger Serverlast interessant. Aber da euer Netz ja ein perfekt geplantes Konzept hat, was auch niemals mehr verändert wird und beliebig skalierbar ist, kann ich verstehen, dass du da nicht konstruktiv drüber diskutieren möchtest.

2 Likes

Tolle Antwort Andreas. Du wolltest mir doch unterstellen wir hätten keine Redundanz. Dem ist aber nicht so. Ihr habt keine Redundanz, zu mindestens was ich bislang von eurem Netz weiß, und ihr wollt diese Redundanz noch weiter verringern in dem ihr nur einen FastD Tunnel laufen lassen wollt. Ihr seit von Anfang an nicht in der Lage gewesen euer Wachstum sinnvoll zu steuern. Wegen euch kommt Freifunk in Verruf weil eben nichts funktioniert oder nur langsam. Ich hab mich schlapp gelacht als ich nen Knoten mit eurer Firmware hier hingestellt habe. Von wegen Schweden Tunnel performt nicht. Euer Kram mit eigenem AS aber auch nicht so wirklich. Und erst jetzt wo das Kind in den Brunnen gefallen ist, weil ihr es nicht gebacken bekommen habt die einzelnen Communitys vorher (15 Knoten Regel) auf eigene Beine zu stellen und in eigene Collisions Domains auszulagern mit eigener Infrastruktur.

1 Like

Das Update ist jetzt unterwegs auf die Knoten:

3 Likes

Auch wenn auf Ruhrgebiet getaggt, ich blicke ja gerne über den Tellerrand; meist kann man ja was lernen :wink:

Das Szenario, was @freifunker beschrieb, daß nämlich ein VPN-Tunnel zwar da war (einen fehlenden startet unser kostengünstiger Praktikant, Mr. Cron, nämlich 24/7), aber nicht so ganz doll viel transportierte, hatten wir hier jüngst auch mal. Und mit zunehmendem Verständnis der Abläufe stellen sich mehr und mehr Fragen. Bislang habe ich, altgediente Serverschabe und SPOF-aware, zwei parallele fastd-Tunnel für sinnvoll gehalten. Seit meinen Offloading-Versuchen¹ halte ich batman_adv eher für einen untauglichen Versuch, denn einen gelungenen Anlauf, und die ganze Kombo mit batman_adv und Eingriffen in den Traffic für zu hinterfragen.

Nachdem das Thema mit den (nicht erreichbaren) v4-Gateways kommuniziert wurde: spricht denn irgendwas für zwei fastd-Tunnel, außer daß es in der Theorie toll klingt, faktisch aber nix bringt?

 
 


¹ Offloader hat gwA und gwB als fastd-Peers, batman_adv hat gwB selektiert. Per Mesh-on-?AN angeschlossener Knoten selektiert tapfer gwC als Default-GW, was zu unsinnigem Traffic Knoten > gwA/gwB > gwC führt. Complete and utter failure in meinen Augen.

1 Like

Der einzige Vorteil eines zweiten Tunnels ist, dass wenn ein Gateway neu startet und der Tunnel zusammen bricht, aber die DSL-Leitung noch da ist, schneller auf ein anderes Gateway umgeschaltet wird.

Mit nur einem Tunnel dauert das etwa 90 Sekunden. Das das ein eher seltener Fall ist, denn meistens zieht eher jemand das Kabel oder die Zwangstrennung haut alles weg, haben wir im Münsterland uns auch dazu entschieden nur einen Tunnel aufzubauen.

Hängende Tunnel werden ohnehin nicht zuverlässig erkannt, von daher ist der Vorteil eines zweiten faktisch nicht gegeben.

FYI: In Lübeck werden wir mit der nächsten Firmware auch das Peerlimit auf 1 setzen. Die Annahme, dass VPN Endpunkte häufiger ausfallen und ein schnellerer failover als das Aufbauen einer neuen Verbindung nötig ist, trifft bei uns nicht mehr zu. Communities, die direkt mit dieser Netzstruktur angefangen haben, kennen das Problem wahrscheinlich so garnicht und dort dürfte ein Limit von 1 dann auch sinnvoll sein.

Wie hat sich denn die Belastung der Supernodes durch das umstellen auf einen Tunnel verändert?

Ich bin weiterhin der Meinung dass die Last mit dem Traffic und damit der Userzahl korreliert und nicht mit der Zahl der Tunnel und kann das auch durch Zahlen belegen:

Exemplartisch an Supernode02, das trifft aber auch für die anderen Supernodes zu:
http://137.226.33.62:8003/nodes.freifunk-aachen.de/comparison-week.html

Worüber ich mit diesen Zahlen natürlich keine Aussage treffen kann, ist ob mit nur einem Tunnel die Grundlast insgesamt fallen würde. Vergleichbare Graphen dazu würden mich sehr interessieren.

1 Like