Software Migrationsstrategien (batman-adv, MTU, 11s etc)


#25

es gibt keine Quelle, das wurde im IRC so erwähnt

Eine Unterstützung wird vielleicht kommen - ist aber von einigen communities schon selbst gemacht worden, es haben ja schon einige große gewechselt.
Wir z.b. haben einfach 2 Tage Parallel-Mesh-Betrieb gemacht, die sonderlocke “autoupdater-wifi-fallback” ist dann nur noch für mesh knoten ,die während der 2 Tage durchgehend offline waren. Diese Sonderlocke muss man aber frühzeitig ausrollen, sprich Wochen/Monate VOR der Umstellung.
Wer ein Freifunk-Netz betreibt sollte sich schon stetig aktiv selbst informieren - selbst wenn man nur im Forum lesen sollte, dann wüsste man vieles schon.

Alles stabil, wird schon von einigen communities seit Monaten genutzt.

@Tarnatos vielleicht kannst du die letzten Beiträge hier ja in den Thread “Software Migrationsstrategien” schieben?


#27

On 18.05.2017 10:19, rotanid wrote:

Eine Unterstützung wird vielleicht kommen […] Wir z.b. haben einfach 2 Tage Parallel-Mesh-Betrieb gemacht, […]

Von parallel wurde immer wieder abgeraten, unklar nur, ob die kolportierten Stabilitätsprobleme damals von AdHoc+802.11s oder eher den Treibern in Chaos Calmer generell kamen. Nicht ohne Grund wechselten anfangs Communities von auf Gluon v2016.1-basierenden Firmwares wieder auf ältere zurück und einige größere (wie z. B. Hamburg) erst jetzt auf Gluon 2016.2.

Wer ein Freifunk-Netz betreibt sollte sich schon stetig aktiv selbst informieren […]

Ich bin sehr dankbar für die, die auf jeden neuen Zug beherzt aufspringen, anders kann es keinen Fortschritt geben. Wir haben dafür nicht die Resourcen und so wiegt jedes negative Feedback doppelt schwer bei der Bewertung der Risiken, an grundlegenden Parametern zu drehen.


#28

Weder noch.
Das Problem ist die damit quadratisch anwachsende Größe der Routingtabelle im Batman und allen daraus resultierenden Effekten.
Plus einem beständiger Flappen der Routen vom belasteten Link zum vermeintlich unbelasteteren.

Wo der Sweetspot zwischen Leidensfähigkeit und “No Router left behind” liegt, also wieviel Tage Parallelbetrieb: Entscheidung der Community.


#29

kann mich adorfer nur anschließen: umso länger man wartet, umso größer das Netz, desto schmerzhafter wird der Parallelbetrieb - und desto kürzer wird man ihn halten wollen.


#30

Ich halte von Parallelbetrieb nicht viel; sofern der AU-Fallback der Paderborner funktioniert, ist ersterer auch nicht notwendig und löst letzterer mehr, als ein Parallelbetrieb brächte.


#31

Gibt es da eigentlich mittlerweile ein fertiges Paket für die Autoupdater-Verbindung-als-Client-Fallback-Lösung?


#32

Ich bin noch auf der Suche nach einem Paket und einer nachvollziehbaren Dokumentation, wo dieser Fallback wirklich genutzt wurde (und funktioniert hat bei mindestens den üblichen “Wifimesh-Only”-Modellen. Auf die Probleme bei den Dualband-Exoten will ich also hier gar nicht anspielen. Nur damit ich nicht falsch verstanden werde.)

Mag aber sein, dass ich schlicht immer nur von den falschen Paketen gebaut habe und die Versuche daher hier im letzten Jahr allesamt kläglich selbst auf “strunznormalen 841ern” gescheitert sind.
Weshalb wir dann Wohl oder Übel auf “Parallelbetrieb” für eine Woche gegangen sind.


#33

wir haben den fallback im Dezember eingebaut in einer 2016.1.6 Firmware und dann Anfang Februar mit einer 2016.2.3 Firmware umgestellt auf 11s

Der Fallback hat bisher noch den Nachteil, dass er einen OpenWRT-Patch (und somit gluon-Patch) benötigt.

Vielleicht wird das aber irgendwann upstream kommen - wenn’s jemand macht…


#34

Funktioniert das zuverlässig?


#35

Was ist für dich die Definition von zuverlässig? Ich habe es bei 2-3 Geräten getestet, dann deployed.


#36

Mich würde jetzt eher die Definition von “das” interessieren.
Parallelbetrieb? Den habe ich bei lokalen Meshes mit >5 Wifilinks pro Node als unzuverlässig erlebt.
Die UserExperience war sehr, sehr mau und das zweite Update auf “11s-only” nach einer Woche war dem geschuldet. Eigentlich wollten wir das länger tun.

Oder meinst Du mit “das” den (welches der vielen Pakete) Wifi-Client-Fallback-Hack?


#37

Mich würde interessieren, ob damit mal ein Meshnetz mit zwei oder drei Stufen in zufälliger Reihenfolge umgezogen wurde.


#38

ja, sowohl Darmstadt als auch wir und einige andere haben die Migration so gemacht, ohne Reihenfolge-Planung sondern mit Parallelbetrieb. Wir eben zusätzlich noch mit wifi-client-fallback für die Knoten die während der Umstellung offline sind.
Die Umstellung muss man wie schon gesagt gut und rechtzeitig planen, z.B. mit der vorherigen Ausspielung (Wochen, besser Monate vorher) einer FW die den fallback integriert hat. Dann signiert man das Manifest der Parallelbetrieb-FW mit einem Datum das deutlich vor dem Tag liegt, an dem man es zur Verfügung stellt, damit innerhalb weniger Stunden alle Nodes im Parallel-Betrieb sind sodass man dann in der darauffolgenden Nacht, mit einem ebenfalls schon vorher vorbereiteten und mit frühem Datum versehenen Manifest, das 11s-only update ausspielen kann.

Also zum letzten Mal, viele haben es schon gemacht, Planung ist das halbe Leben, Magie ist keine dabei, Probleme gab es auch keine.


#39

Diese Antwort lese ich aber als “Nein”, gemäß der Frage von MPW.
Sofern seine Frage sich auf “via wififallback” bezogen haben sollte. Oder ging es etwa doch mit seiner Frage um den Parallelbetrieb?
Und falls doch “ohne Prallelbetrieb”: Welches war denn das Paket, das genutzt wurde (Bitte Link mit Commit-ID).


#41

Wieso liest du das als “Nein”? Falls du die Frage nach Umzug in zufälliger Reihenfolge meinst: eindeutig JA.
Komplett ohne Parallel-Betrieb halte ich für wenig sinnvoll, da es da doch zu längeren Ausfällen an manchen Standorten kommen. Ich kann aus unserer Erfahrung absolut die Vorgehensweise empfehlen, die man in meinem letzten Beitrag hier nachlesen kann.


#42

Ob es “wenig sinnvoll” ist: Das musst Du @MPW fragen. Spätestens bei einem Batman-adv-Wechsel (steht ja auch noch in einigen Communites an) gibt’s schlicht keine Möglichkeit von Parallelbetrieb. (siehe auch Topic dieses Threads)

MPW fragte: “Hat es jemand schonmal erfolgreich gemacht ohne Parallelbetrieb, nur mit dem Wificlient-Fallback und mehrstufigem Wifimesh”.
Und darauf konnte zumindest bislang niemand “Ja” antworten.
(Wobei es mich freuen würdenn es trotzdem jemand täte).

(“Hat hier schonmal jemand an seinem Auto vorn Sommerreifen und hinten Winterreifen gefahren” - “Ja, wir haben allerdings vorn und hinten gleich Winterreifen draufgetan, Sommerreifen war nur das Ersatzrad”.)


#43

ok, dann ist nun klar was du willst (oder für jemand anderen erläuterst) und in dem Fall kann ich dir tatsächlich nicht helfen.
Weiterer möglicher zukünftiger Fall ohne Parallelbetrieb: Umstieg von batman-adv auf babel/l3roamd


#44

Okay, also scheinbar wurde der noch nicht in der Praxis getestet, das ist ja auch nicht schlimm.

Eine weitere brennende Frage ist auch, ob er unter „normalen Umständen“ genauso zuverlässig funktioniert, wie der klassische Autoupdater. Wäre nichts ärgerlicher, als einen kaputten Autoupdater rauszuschieben.


#45

Ich habe es mit dem hier referenzierten versucht und war nicht erfolgreich. Die Konoten blieben nachhaltig offline und haben es auch mit “hochgesetzter Cron” irgendwie nicht hinbekommen, sich in der benachbarten Freifunk-SSID einzuloggen und eine FW zu ziehen.
Eventuell gibt es noch weitere Randbedingungen, damit das funktioniert. Geht das dann evtl. “nur” per IPv4?

Vermutlich habe ich aber auch von einem falschen Paket/CommitID gebaut.


#46

Wir machen das ja gerade bei 1200 Knoten. Also Wechsel von BATMAN 14 auf compat 15 sowie auf 11s.

Wenn das durch ist kann ich ja mal einen kleinen Erfahrungsbericht schreiben.