Um möglichst viele Leute zu erreichen poste ich das hier auch nochmal :).
Besonders seien Leute gewarnt, die Ihre eigenen Setups verwenden. Nähere Infos findet ihr hier:
Viele Grüße
Viel Erfolg bei der Migration 
.
3 „Gefällt mir“
Danke! 
Das wird schon einiges, aber die Tests haben bis jetzt einwandfrei funktioniert.
Wir sehen uns dann auf der anderen Seite mit BATMAN_V und vxlan meshing ;).
1 „Gefällt mir“
Aus Neugier: Jetzt mit 4 Tagen Abstand, wie groß war die Verlustrate?
- % der Knoten die kein Update ziehen obwohl sie sollten
- % der Knoten die länger als 24h verschwunden sind, aber doch wiederkamen
- % der Knoten, die bislang verschwunden sind
- % der Knoten, die jetzt in einer Updateloop (z.B. „FW-Load, Reboot, wieder alte FW“, alle 60 minuten") hängen.
(Bei uns stehen in einigen Domains auch größere Migrationsschritte wie z.B. Wireguard, vxlan an und wären über Entscheidungshilfen dankbar, weil es auch Schwarzmalende gibt, die das grundsätzlich ablehnen „wegen befürchtetem Routerverlust“)
Oder anders gefragt: Wenn ihr es nochmal machen müsstet, was würdet ihr anders machen?
2 „Gefällt mir“
- % der Knoten die kein Update ziehen obwohl sie sollten
Das sind wirklich erstaunlich wenige in etwa noch so 10 Knoten also unter 0,01% - % der Knoten die länger als 24h verschwunden sind, aber doch wiederkamen
Bis jetzt reden wir hier wohl so von maximal 20 knoten - % der Knoten, die bislang verschwunden sind
Fast nicht meßbar, vielleicht 5 Knoten gesamt? - % der Knoten, die jetzt in einer Updateloop (z.B. “FW-Load, Reboot, wieder alte FW”, alle 60 minuten") hängen.
Hatten wir ganz kurz mindestens 2-3 Knoten in der letzten Experimental, nachdem wir aber viele Besitzer schnell per E-Mail erreichen war es kein großes Problem.
Alles davon hat natürlich die Unschärfe, dass wir unser legacygw auch neuaufgesetzt haben um die alte Hardware schnell loszubekommen. Dh wer sich auch nicht mehr zu dem LegacyGW verbunden hat, ist für uns nicht mehr sichtbar.
Im Moment hängen noch folgende Nodes auf unserem LegacyGW, einige Besitzer davon haben wir aber angeschrieben und es werden immer weniger.
Lessons learned sind:
- Das ganze schonmal 2-3 Wochen in Testing und Experimental testen ist wichtig.
- Die großen Knotenbetreiber ins Boot zu holen und deren Meshes mal manuell migrieren zu lassen. War eine sehr gute Idee und findet fast alle Fehler die so auftreten können.
- Keine schnell, schnell Änderungen machen kurz vor Release. Und wenn auch Testing - Experimental Releases einhalten (wir hatten noch kurzfristig ein drittes GW bereitgestellt und uns ist ein Typo beim FastD Port passiert, was zu einer Segmentbrücke führte. Gut dass das Release nur bis Testing kam)
- Ein Segment rauspicken, welches man vorab nochmal migrieren lässt (taten wir mit muc_cty)
- Ein LegacyGW bereitstellen ist nicht verkehrt aber wie man sieht kein unbedingtes muss.
Ansonsten hatten wir auch bedenken, aber wir haben viel getestet und möglichst viele große Knotenbetreiber direkt im Boot gehabt.
Wie bei allem irgendwann hilft dann nur noch Augen zu und durch ;).
9 „Gefällt mir“
Für alle die nicht aktiv auf Twitter mitlesen, wir haben unsere Nutzerzahlen nach der Umstellung veröffentlicht. Wie man sieht muss man keine Angst haben, dass durch verschiedene SSIDs die Nutzer wegfallen und nicht wieder kommen.
3 „Gefällt mir“