Hi zusammen,
Die neue Gluon 2015.1 wurde als Stable Version für die Domain Rheinufer bereitgestellt.
Alle Nodes werden sich innerhalb der nächsten 24 Std das neue Update herunterladen und installieren.
Auf unserer Seite hat sich nur eine Sache geändert, Gluon nutzt jetzt nur noch einen VPN Tunnel um den Uplink der Nodes zu entlasten und mehr Nodes mit der vorhandenen Infrastruktur zu unterstützen.
Zudem klappte das Failover auf den zweiten Tunnel niemals zeitnah und ist daher überflüssig.
Den Changelog von Gluon 2015.1 findet man in der Doku:
http://gluon.readthedocs.org/en/v2015.1/releases/v2015.1.html
Edit: Eine Kleinigkeit die wir geändert haben ist mir noch eingefallen, wir haben kein ULA-Prefix mehr. Es wird von den Nodes direkt die Public V6 von Rheinufer verteilt.
Gruß
Cyrus
3 „Gefällt mir“
Das hört sich gut an.
Wenn ihr eine neue experimental bauen möchtet, dann überlegt doch mal, ob ihr in der radv.conf das
MaxRtrAdvInterval auf das maximum von 1800 und die MinDelayBetweenRAs auf 40 zu setzen.
Die beiden Werte sollten eigentlich nichts ändern da radvd nur im Scope der Clients läuft (wird nicht über bat0 weitergeleitet). Aber können wir gerne mal ausprobieren, evtl wäre es sinnvoller das auf den Gateways mal auszuprobieren? 
Edit: Eine Kleinigkeit die wir geändert haben ist mir noch eingefallen, wir haben kein ULA-Prefix mehr. Es wird von den Nodes direkt die Public V6 von Rheinufer verteilt.
Das ist meiner Meinung nach keine Kleinigkeit, aber es war notwendig, das schnell umzusetzen, da wir irgendwie den Broadcast-Traffic runterschneiden mussten. Ich hoffe, dadurch geht für euch nichts kaputt. Wir rechnen damit, dass die Dienste entweder per Link-Local (fe80::/64) oder per Rheinufer AS (2a03:2260:40::/64) erreicht werden.
1 „Gefällt mir“
ULA ist doch schon ein wenig länger „weg“. Von daher: Ja, ich bin damit zufrieden.
[radvd-intervals]
hmm, stimmt. Probiert es doch mal. Roaming funktioniert nach meinem Gefühl sowieso nicht so toll.
(ein Monitoring für die DHCP-Server wäre ebenfalls sinnvoll. Also irgendein fastd-shutdown auf supernodes auf denen der lokale dhcp-server als ‚nicht leistend‘ erkannt wurde.)
Kleiner Zwischenstand der CPU Auslastung auf den Supernodes:
4 „Gefällt mir“
Hier noch einzelne Graphen über die vergangene Woche. Die Vorwoche wird in graun hinterlegt dargestellt Man sieht sehr schön, wie groß die Entlastung ist:
(der erste Supernode war abgestürzt und hat dementsprechend kaum etwas zu tun gehabt, da sich die Nodes auf die anderen Supernodes verteilt haben und bei diesen verblieben sind.)
3 „Gefällt mir“
