Ich würde gerne in der Regio Aachen dem Bespiel einiger anderen Communities folgen und zusammen mit dem Update von Gluon 2015.1 auf 2015.1.1 die Zahl der VPN Tunnel auf einen reduzieren.
Dies reduziert in erheblichem Maße unseren Overhead.
Der ursprüngliche Zweck des zweiten Tunnels ist beim Ausfall eines Supernodes schneller einen alternativen Supernode zu Verfügung zu haben.
Seit unsere Domäne im produktiven Betrieb ist hatten wir jedoch keine Ausfälle bei den Supernodes die über einen Reboot wegen einer durch Batman induzierten Kernel Panic hinaus gingen. Wie Test gezeigt haben sind diese Reboot Zeiten von unter einer Minute jedoch selbst für den Failover zwischen zwei bereits aktiven VPN Tunneln zu kurz.
Sollen wir das direkt machen oder auf dem CT am 7.7 besprechen?
auch wenn ich nicht zu Aachen gehöre kann ich zumindest von unserer Erfahrung in Rheinufer berichten.
Zunächst muss ich, zumindest was den Overhead angeht, euch den Wind ein wenig aus den Segeln nehmen.
Der Overhead wird nicht geringer, dies liegt daran da Pakete niemals zwei mal repliziert werden, diese müssen immer eine neue Sequenznummer haben.
Allerdings wird die CPU auf den Plasteroutern sowie Supernodes halbiert, dies ist sehr schön in diesem Graphen zu sehen:
Ansonsten passiert nichts, das Hintergrundrauschen ist ein Problem welches durch ersetzen von Batman-advanced auf der VPN Seite behoben werden kann. Dies ist allerdings noch in Planung.
Andere Konzepte haben dies eleganter gelöst, so gibt es bei Libremesh z.b. mini Kollisionsdomänen die durch einen Cloud Identifier begrenzt werden, dieser kann frei für jede Node gewählt werden kann (z.b. eine Kollisionsdomain für Einkaufsstraße X, eine für das Einkaufszentrum etc). Ansonsten wird über das Mesh nur BMX6 besprochen, eine Layer3 Variante des Batman Algorythmus.
Generell ist bei Batman-advanced und kleinen DSL-Anschlüssen etwa bei 200~Nodes schluss, bei mehr wird der Overhead einfach zu groß als das dieser zu vernachlässigen ist.
Außerdem sei angemerkt das die Pakete für Libre-Mesh sicherlich auch für Gluon portiert werden könnten und wir so Domains jenseits der 1000 - 2000 Nodes schaffen können falls sich das Konzept bewährt.
Ansonsten solltet ihr natürlich die Tunnelanzahl auf 1 reduzieren, aus Lübeck habe ich die Info das dies ursprünglich wegen oft abstürzender Supernodes so gewählt wurde und bei uns gar keinen Sinn ergibt
Weshalb braucht ein fastd Tunnel denn CPU Leistung? Doch wohl zum Verschlüsseln von Paketen?! Wenn sich also die CPU Last auf den supernodes durch eine Halbierung der fastd Tunnel halbiert, gehe ich davon aus, dass nun weniger Pakete als zuvor verschlüsselt werden.
Die Verschlüsselung von Paketen verbraucht fast gar keine CPU-Leistung im vergleich zum eigentlichen Problem, dies ist ein generelles Missverständnis. Die meiste Leistung geht bei Context-Switches verloren da Fastd ja ein Dienst ist der im Userspace läuft. D.h. ein Paket kommt rein, geht über den Kernel-Space in den User-Space, wird dort von Fastd verarbeitetet und fließt dann zurück zum Kernel-Space (Soll ja bei bat0 ankommen). Von dort gehts dann ins Internet via Tunnel zum Backbone.
Durch diese Switches geht ziemlich viel Leistung verloren, natürlich werden bestimmte Pakete von Bat0 verworfen da diese evtl schon mal vorbei gekommen sind. Aber dies wird trotzdem erstmal mindestens 2 Context-Switches brauchen (Von der Ethernetkarte (Kernel-Space) zu Fastd (User-Space) und dann zu Batman-advanced (Kernel Space).
