Reduzierung der fastd Tunnel auf 1 im Ruhrgebiet

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

@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 Like

Gerne!

Ich denke mal das wir um ein warten auf das Layer3 VPN nicht herum kommen. Klar können wir noch weiter Domain Splits machen, aber ich sehe uns bei unserem momentanen Wachstum alle 2-3 Monate einen Domainsplit machen.

Dies wäre beim Layer3 VPN unnötig und sollte die Zielvorgabe sein.

Eher würde ich Ipv6 im Mesh deaktivieren (Ja das ist nicht schön!) denn der meiste Hintergrund Traffic ist ICMPv6 (Neighbor Solication und Neighbor Advertisements). Dies natürlich nur mit der „User Experience - Schnelles Netz“ im Hinterkopf ;). Denn der „normale“ User hat von Ipv6 nichts wenn er auf Facebook und Co surft oder Whatsapp auf seinem Handy nutzt.

Doch, ausgerechnet Facebook unterstützt vorbildlich IPv6. Die Paderborner haben mir Mal erzählt, dass bei denen 40% Verkehrs ins Internet IPv6 ist.

Kann ich hier so bestätigen. Seit ich nen Sixxs Tunnel in unser Netz kippe ist der IPv6 Traffic fast gleichauf mit dem von IPv4. Alle großen verwenden IPv6. Apple, Google, Youtube, Facebook, Yahoo und Heise! :wink:
Nur Microsoft schwächelt noch ein wenig.

2 Likes

Vor allem bei Webseiten der großen Anbieter ist die Erreichbarkeit mittels v6 mittlerweile schon sehr gut gegeben.

Das ist richtig, es geht aber um den Nutzer. Der kennt nicht mal Ipv4, für ihn kommt da „Internet“ raus :wink:
Und für den Nutzer ist Ipv6 total egal, sofern Facebook auch über V4 erreichbar ist.

Absolut, das ist natürlich auch richtig!

Zumal v4 aufgrund der sonstigen Dienste eben noch wichtiger ist, da dort, aus den Altlasten heraus, so ziemlich alle Dienste drüber möglich sind.

Android priorisiert IPv6. Bekomme ich sowohl eine IPv4- als auch IPv6-Adresse, die IPv6-Konnectivität ist aber gestört, funktionieren auf diesem Smartphone Facebook & Co nicht.

Richtig, dem Anwender ist es egal, der kennt nix von IPv4 oder IPv6, der sieht nur: Freifunk geht nicht.