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


#1

moin moin,

aktuell nutzen wir in Magdeburg folgende Konfiguration mit 2 Gateways. Das dritte GW ist im Aufbau.

  • Gluon 2016.1
  • batman-compat lvl 14
  • MTU: 1426 (port 10000)
  • Adhoc-Mesh
  • fastd17

Im Rahmen unser Überlegungen für die nächste Firmware würden wir gerne wechseln auf:

  • batman-adv15
  • MTU 1280 (anderer Port)
  • 11s Mesh
  • fastd18

Für diesen Wechsel suchen wir aktuell eine Strategie die bisherigen Knoten zu aktualisieren ohne die mesh-only Knoten abzuhängen.

Der einfachste Wechsel wäre sicherlich die MTU, einfach eine neue fastd instanz auf den Gateway auf einen anderen port aktivieren und dann mit dem normalen firmware update ausrollen.

Batman und mesh können wir so nicht aktualisieren, da man die alte und die neue Version nicht parallel laufen lassen kann auf den Knoten.

Hat jemand aus der Community schon ähnliche Wechsel durchgeführt? Wie waren die Strategien für den Wechsel bei euch?

danke und Grüße


Archer C25 - Freifunk tauglich machen
#2

Wenn ich


sauber(!) und zuverlässig(!) ans Laufen bekäme, so das sichsicher wäre, dass es wirklich bei allen Nodes läuft, dann wäre das die Lösung.


Kanal von 1 auf 9 ändern?
#3

Streng genommen benutzen wir batman-adv compat lvl 14 und fastd v18 gibt es noch nicht, aber ja. :wink:


#4

Was macht das Package?


#5

Wenn ein Knoten keine Wifimesh-Netze und keinen VPN-Uplink hinbekommt (er sich also als “Allein auf der Insel” wähnt), dann versucht er einmal im Tag nach einem offenen Nachbarnetz (vorzugweise “Freifunk”) als Client einzuloggen und dann dort von der hoffentlich erreichbaren URL eines Autoupdate-Servers ein für ihn passend signiertes Immage zu laden und zu flashen. Sofern es denn eines gibt.


#6

Hallo,

wir haben gerade eine Aufteilung unseres Netzes und die Umstellung auf Batman 15 hinter uns. Wichtig ist, dass man eben zuerst die Mesh-Knoten und später die VPN-Knoten umzieht.

@descilla hatte da aufgefeilte Skripte geschrieben, die das alles aus der nodes.json der Karte ziehen und die Knoten in Updatewellen einteilen.

Dann haben wir per nginx-Konfiguration und dem geo-Filter-Paket für einzelne IPv6-Knoten festgelegt, ob ein Knoten schon umziehen soll, oder noch keine neue Firmware bekommt.

Grüße
Matthias


#7

Ja, das ist leider sehr viel Handarbeit, weil man die Netze erstmal inventarisieren muss. Gerade bei Meshketten über 3 und mehr(!) Hops.
Und dann mit Routern, die auch mal tageweise nicht angeschaltet sind, weil Leute “in Urlaub” sind und dann “Strom sparen”.
Ich halte daher den Ansatz mit dem “ap-wifi-fallback” für sicherer. Damit man eben nicht 2-5% der Router bei so einer Aktion verliert. (Wie bisher erlebt, trotz aller Vorplanung.)


#8

Das haben wir im Script gelöst. Man kann die Teil-Netze/Domänen anhand von Queries Beschreiben, die dem OSM/Nominatim Schema entsprechen. Und dann durch und+oder Verknüpfungen seine “Suchmaske” zusammenschrauben. Leider arbeitet die Nominatim-API bei ganz kleinen Gebietsteilen nicht ganz so sauber, wie erwartet. Aber bis auf die Stadtteil-Ebene runter funktioniert es sehr gut. Mesh-Wolken, wo nur manche Knoten Geo-Daten haben werden komplett berücksichtigt. Hier findest du das Tool. Es sind ein paar Änderungen noch nicht commited (branch, Erkennung nicht korrekt). Und eine readme bin ich auch noch schuldig.

Ja, das habe ich leider nicht eingebaut. Konzept war: Ich lade eh schon seit jeher einmal stündlich die nodes.json und mesh.json herunter. Man hätte dann einen Zeitraum angeben können, in dem eine Mesh-Verbindung bestehen haben muss, um berücksichtigt zu werden. Hatte aber seinerzeit kein Feedback aus meiner Community diesbezüglich bekommen und es daher nicht eingebaut.

Eine Anmerkung noch: Zu beginn hatten wir den Ansatz in (einheitlichen) Wellen umzuziehen. D. h. erst alle “level2”-Nodes (also Knoten, die 2 Hops bis zum nächsten Knoten mit VPN Verbindung brauchen) umgezogen, dann alle level1-Nodes, dann alle level-0 Nodes (die mit VPN). In der Theorie ganz toll, in der Praxis nicht so. Leider sträuben sich ein paar Prozent der Knoten einige Stunden bis Tage, bis sie das Update endlich ziehen. Daher bin ich dann dazu übergegangen mehrere Ziele je Domäne zu definieren, die dann räumlich kleiner waren.

Wenn ich es jetzt noch mal schreiben müsste, würde ich direkt ein Ziel je lokaler Wolke generieren lassen und die Erstellung und Überwachung der Config automatisieren.

Um festzustellen, ob ein Knoten umgezogen ist, habe ich entsprechende Einträge aus dem nginx access.log gegrept und dann versucht den Knoten unter seiner (erwarteten) neuen Adresse anzupingen, falls erreichbar (== Umzug hat geklappt), falls nicht erreichbar und auch unter seiner alten Adresse nicht erreichbar (aber FW geladen) im Kommentar den Status auf “ready” gesetzt, da es sich typischerweise um Level x (x>0) Knoten handelt, die noch auf ihren VPN-Knoten warten um wieder online zu kommen…

Da ich diese Thematik bei der Erstellung der Scripte komplett außen vor gelassen hatte, gab das hinterher ein kleines bash Script mit einem doch recht langen Aufruf mit diversen verknüpfungen und pipes. :stuck_out_tongue:

Das kommt bei unserem Verfahren schon hin. Es haben sich aber die meisten Betroffenen schon bei uns gemeldet (oder wir bei denen). Der Rest muss noch in der Nacharbeitung “gefunden” werden.


#9

Wow, das klingt für mich nach enormem technischen Aufwand. Meine Idee war der sehr viel fatalistischer. Zusätzliches Gateway mit dem neuen Kram (MTU, batman, usw.), neue Firmware rausbringen. Alle hinten liegenden Mesh-Only Knoten, an die man rankommt, remote updaten. Dann Autoupdate scharf schalten. Und für den Rest der Knoten mit den Kontaktadressen aus dem Mesh rumlatschen. Dann kommt man endlich auch mal mit den Knotenbetreibern persönlich in Kontakt. :wink:

(Und wenn das soweit durch ist die Gateways mit dem alten Stack umstellen.)


#10

Ich will nicht in Abrede stellen, dass ich es ggf. unnötig kompliziert gemacht habe. Dafür habe ich nämlich ein Händchen.:stuck_out_tongue:

Bei ~5000km² Fläche und ~1300 Knoten stand das bei uns nicht zur Debatte.


#11

Naja wir reden bei uns grad von weniger als 300 Knoten, viele davon sowieso keine Mesh-Only-Knoten und das Stadtgebiet von Magdeburg ist zwar groß, aber begrenzt. Außerdem muss ja nicht einer allein rumfahren und alles reparieren. :wink:

Wie auch immer, ich bin durchaus an Vorschlägen oder Erfahrungen interessiert. :slight_smile:


#12

Bei uns war bei vielen Knoten auch einfach keine Adresse hinterlegt, daher ging das nicht.

Und mal ehrlich, nach den ersten 20 Knoten hat man da auch keine Lust mehr drauf :).


#13

Das Mesh-Update kann mit Parallelbetrieb klappen, ist bei uns in Lippe gerade im Zuge des Umstiegs auf Gluon 2016.1 durchgezogen worden (ca. 150 Knoten). Erst gab es eine Firmware mit beiden Mesh-Varianten, ein paar Tage später dann ein 2. Upgrade mit nur noch 11s.


#14

Da drücke ich dann mal ernsthaft alle Daumen.
Denn der Parallebetrieb von adhoc und 11s hat bei mir auf vielenen 32MB-RAM-Geräten zu erheblichen Problemen geführt.


#15

wir sind von bat15 auf bat14 mit 800 kisten retour gewechselt … ;(


#16

was waren die Gründe der ReMigration auf bat14?


#17

Wir haben unter last den kernel auf den supernodes mit mehr als 1 core nicht stabil bekommen.


#18

Scheint soweit geklappt zu haben, laut Meshviewer sind bis auf ein paar Knoten alle bei der 11s-only Firmware angekommen. Waren auch nur 2 Tage mit der Übergangsfirmware.


#19

@LeSpocky und @Adorfer für Batman Update haben wir hier ein kleines Script geschrieben und probieren das gerade aus. Sehr vielversprechend


#20

Mögliches GluonPacket für Multi-MTU Auswahl: https://github.com/freifunk-ffm/packages/tree/master/ffffm/ffffm-fastd-auto-mtu