Reduzierung der fastd Tunnel auf 1 im Ruhrgebiet

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 „Gefällt mir“

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 „Gefällt mir“

Das Update ist jetzt unterwegs auf die Knoten:

3 „Gefällt mir“

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 „Gefällt mir“

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 „Gefällt mir“

@CHRlS wie ist denn der Erfolg der Reduzierung auf einen Tunnel?

Ich nehme auch gerne Statistiken von der Knoten Seite.

Mein letzter Stand war, dass das Grundrauschen davon nicht beeinträchtigt wird, da auch bei zwei aktiven Tunneln, Batman ja nur einen sieht und daher nicht mehr Pakete versendet werden als bei einem.

Daher nützt das nur den Supernodes (bzw. Gateways, wenn das technisch zusammenfällt).

Ja das habe ich auch bemerkt, größere Domains bekommen wir damit nicht. Nur weniger CPU Auslastung. Aber dadurch können wir auf den Supernodes zwei unterschiedliche Layer2 Netze fahren und somit einfacher aufsplitten.

Ich denke das ohne Layer3 VPN sich nichts ändern wird. Daher sind auch Domainsplits nicht lange von nutzen wenn man z.b. viele Clients bedient.

Danke, das bestätigt mein Verständnis wie das Mesh VPN funktioniert.

Was bedeutet denn weniger CPU Last? Ihr solltet doch jetzt zwar nur noch halb so viele Tunnel haben, aber dafür nur noch Tunnel die auch tatsächlich belastet werden.
Daraus ergibt sich, dass die maximale Zahl an Tunneln verringert werden muss. Möglicherweise Richtung 60%. Damit können natürlich trotzdem noch genauso viele Clients wie zuvor bedient werden.

@nomaster, du hast doch auch cpu Graphen der Supernodes, kannst du vielleicht die der letzten Wochen veröffentlichen?

Siehe hier:

Ich bin davon ausgegangen, dass das mit dem Wegfall des ULA Präfix zusammenhängt.

Nee damit hat es nichts zu tun, das wurde bei uns sowieso nicht mehr aktiv genutzt. Autoupdater und NTP liefen schon seit 4-5 Monaten via Public V6

Allein die Tatsache, dass alle Clients noch ULA Adressen untereinander ausgetauscht haben sollte einiges am Rauschen gewesen sein, ich würde wirklich gerne wissen wie sich die Belastung in Ruhrgebiet, Lübeck und Möhne verändert hat.

Die Clients tauschen keine Adressen untereinander aus und die Announcements von den Radvd Instanzen auf den Nodes werden auf diesen schon gefiltert und nur an Clients an den Lan Ports oder via Wifi weiter gegeben. Demnach hat dies keine Probleme verursacht, dies hab ich auch mit tcpdump bestätigen können.
Probleme gibt es dann wenn z.b. mehrere Gateways announced werden anstatt anycast routing mit nur einer Adresse zu verwenden. Das selbe gilt für zu viele Präfixe von den Supernodes.

HIer noch mal die Multicast Regeln:

rule 'FORWARD -p IPv6 --ip6-protocol ipv6-icmp --ip6-icmp-type router-solicitation -j OUT_ONLY'
rule 'OUTPUT -p IPv6 --ip6-protocol ipv6-icmp --ip6-icmp-type router-solicitation -j OUT_ONLY'

rule 'FORWARD -p IPv6 --ip6-protocol ipv6-icmp --ip6-icmp-type router-advertisement -j IN_ONLY'
rule 'INPUT -p IPv6 --ip6-protocol ipv6-icmp --ip6-icmp-type router-advertisement -j IN_ONLY'

Wie man sieht dürfen nur router solications gesendet werden und nur router advertisements empfangen werden.
Die Router Solication Pakete sind unabhängig davon ob man Ipv6 Adressen auf einem Interface hat, diese werden via Multicast abgefragt. Daher haben diese nicht die Auslastung verursacht.

Danke für die Erklärung.

1 „Gefällt mir“