Analyse zur Anzahl der Tunnel

[MrMM]

Im Regelbetrieb haben wir in der Regio Aachen vier Supernodes für unsere gut 500 Knoten, es werden jeweils zwei Tunnel aufgebaut.

Durch diese zwei Tunnel entsteht eine enorme Vielzahl an möglichen Wegen wie sich Knoten indirekt über die Supernodes zu erreichen können.

Konkret zu sehen mittels „batctl o“, teilweise sind einige hunderttausend Next Hops verfügbar.

Nachdem andere Domänen sehr gute Erfolge mit der Reduzierung der VPN Tunnel auf einen pro Knoten gemacht haben, aber ich versuchsweise zwie von unseren vier Supernodes abgeschaltet. Da wir bereits mein einem Feature aus Gluon 2015.1 erzwingen, dass zu den verbleibenden Supernodes insgesamt nur ein Tunnel aufgebaut wird habe ich damit effektiv die Zahl der Tunnel annähernd halbiert.

Mit dem Abschalten der Nodes 3&4 wurde der Traffic zum Rheinland Backbone wie erwartet von Node 1&2 übernommen:

Erstaunlich ist dabei, dass der Gesmatträffic auf Node 1&2 dabei nicht zugenommen hat:

Der Overhead hat also massiv abgenommen, ohne dass es zu einer deutlichen Mehrbelastung gekommen ist:

Effektiv ist die load auf den Supernodes 1&2 beim zuschalten von 3&4 sogar gestiegen.Effektiv ist die load auf den Supernodes 1&2 beim wieder zuschalten von 3&4 sogar gestiegen. Wobei das zuschalten notwendig war, da Video Streaming nicht mehr in HD möglich war.

Auf Seite der nomalen Knoten fehlt mir leider ein Knoten mit dem ich deutlich zeigen kann ob der Hintergrund Traffic deutlich gefallen ist (Testzeitraum 24. Tagsüber), ich habe mal einen mit wenig User Traffic raus gesucht:

Immerhin, ein Rückgang der CPU Last ist zu erkennen:

Was lernen wir daraus:

• Wir könnten derzeit die Domäne Aachen auch mit zwei Supernodes betreiben, wenn man sich die Last genau anschaut, bei geringen Abstrichen in Sachen Perfomance vermutlich sogar mit einem.
• Weniger VPN Tunnel sorgen für eine deutlich geringere Belastung der Infrastruktur, insbesondere in Sachen Bandbreite.

[Felix]

Besten Dank für diese Auswertung!

[yayachiken]

@MrMM

Wobei das zuschalten notwendig war, da Video Streaming nicht mehr in HD möglich war.

Bin nicht ganz überzeugt dass es mit den Tunneln zusammenhing. Nach Zuschalten des zweiten Tunnels ging es zwar wieder, aber danach gab es am selben Tag noch einmal Probleme. Würde es gefühlsmäßig einfach auf einen komischen Batman-Effekt schieben

[MPW]

@MrMM

Auf Seite der nomalen Knoten fehlt mir leider ein Knoten mit dem ich deutlich zeigen kann ob der Hintergrund Traffic deutlich gefallen ist (Testzeitraum 24. Tagsüber)

Das Hintergrundrauschen wird durch das Abschalten des zweiten Tunnels nicht reduziert, da die fastd-Tunnel für Batman nicht sichbar sind und Batman pro Schnittstelle am Router seine Pakete versendet, und da gibt es nur einmal mesh-vpn.

[MrMM]

Die Supernodes kennen durch zwei Tunnel einige 100.000 verschiedene Potential Next Hops indirekt über die Knoten die mit zwei Supernodes verbunden sind.

Die normalen Freifunk Knoten empfangen ebenfalls über beide fastd Tunnel die Batman Informationen.

Das ist einiges an Rauschen das verschwinden sollte.

[MrMM]

In der Zwischenzeit laufen nur noch gut 100 unserer 560 Router auf einer Firmware mit zwei Tunneln, hier ein Zwischenstand für den Bericht beim heutigen CT in Aachen.

Zur Bewertung sollten immer gleiche Wochentage miteinander vergleichen werden.

Die CPU Last auf den Supernodes ist bereits auf etwa die Hälfte zurück gegangen:

Beim ausgehenden Traffic ist der Rückgang weniger deutlich, aber 50Mbit weniger Last ist auch nicht schlecht.

Beim eingehenden Traffic erkenne ich keinen Rückgang.

Das Volumen zum Backbone blieb in der Zeit weitgehend konstant, das ist sozusagen der Referenzwert um zu bestimmen was overhead ist. Ohne jeglichen overhead hätten wir diesen Traffic *2 auf eth0

[adorfer]

Magst Du die Graphen noch mit ein paar Worten unterlegen? Ich vermag da leider gerade nicht zu erkennen, wo ich da genau hinschauen solltest und welche Schlussfolgerungen Du ziehst. Denn zumindest eingangs im Thread klang es bei Dir so, als ob es durchaus lohnenswert wäre.
Daher eigentlich schade, dass da jetzt die Ernüchterung folgt.
„Durchaus messbar“ ist für mich das Fazit für etwa
„Man sieht es, aber es hat den Aufwand kaum gelohnt“.
Korrekt?

Woran hat’s denn gelegen, dass sich der Trend nicht fortgesetzt hat?

[yayachiken]

@adorfer

„Man sieht es, aber es hat den Aufwand kaum gelohnt“.

Uns ist nicht mehr wirklich ein Grund eingefallen der für Multitunnel spricht. Wenn ein Supernode abschmiert ist der innerhalb von wenigen Sekunden automatisch wieder da. Da ist BATMAN viel zu träge, das Routing umzustellen. Der Benutzer hat also absolut gar nichts von den zwei Tunneln, nichtmal Redundanz.

Daher ist die Schwelle für „Das hat sich gelohnt“ ziemlich gering

[MrMM]

Ich habe den Text ergänzt, zusätzlich hier noch zur Ergänzung Graphen von WAN eines normalen Nodes mit wenig Kundschaft. Der Rückgang ist entsprechend gering, aber immerhin:

An der load hat sich leider auch nur wenig getan:

Zum Vergleich ein Offloader für eine viel genutzten Wolke aus 10 Nodes (es existieren dort 2 weitere Uplinks), hier ist schon eher etwas zu erkennen:

Wenn die letzten 100 Knoten auch auf der neuen Firmware sind sollte sich der Effekt, insbesondere auf den Supernodes, noch weiter verstärken.

[adorfer]

Danke.

Als möglichen Nachteil sehe ich Szenarien in denen eine Community „auf Vorrat“ gleich ein ganzes Dutzend FQDNs als fastd-server in den Plasteroutern hat, aber nur 3-4 davon aktiv nutzt.
Wenn dort nur ein Tunnel aktiv ist und dieser zusammenklappt, dann kann es (bei sinnvollen Timeouts) doch ein paar Minuten dauern, bis wieder ein neuer fastd-tunnel aufgebaut ist.

In diesem Fall wäre eine Mechanik vielleicht sinnvoll, bei Verbindungsabbruch gleich 3 tunnel parallel aufzubauen und die Versuche nach dem ersten Connect bei den anderen beiden zu stoppen.

Obwohl… wenn dann mal ein fastd-server „verstirbt“ und die Hinterbliebenen das auffangen müssen, dann freuen die sich bestimmt nicht, wenn sie gleich die dreifache Menge an Connection-Requests hineinbekommen.

[hinkelstein]

Kleines Beispiel von mir:
ffac-jakobstr28-01 (http://map.freifunk-aachen.de/v2/#!n:e8de2765a8cd) ist der Router mit dem VPN-Tunnel.
ffac-jakobstr28-02 und ffac-jakobstr28-03 sind per Mesh an die -01 angebunden.

Mitte KW33 habe ich den -01 von 2 auf 1 VPN-Tunnel umgestellt. Auf meiner Firewall konnte ich folgendes beobachten:

Der Grundtraffic hat sich offensichtlich nach halbiert.

[MrMM]

Auch von mir noch ein Langfristiger Graph zur Nachlese:

Dazu noch der Traffic:

[MrMM]

Damit man die Daten besser interpretieren kann hier die Userzahlen, die haben wir leider nicht im schicken Zabbix sonder nur im oldschool Munin: