Ausfall von drei Supernodes

Sehr schön finde ich da die Störungsmeldungen des RZ der RWTH: RWTH Störungsmeldungen (Der Teil ‚Netzwerk‘ als Beispiel).
Falls ein System gestört ist, erfolgt da zeitnah eine kurze Meldung und hinterher ggf. eine Zusammenfassung, was genau das Problem war.

4 „Gefällt mir“

Genau so, muss ja zunächst nicht im Detail beschrieben sein. Wir haben keine 24/7-Admins!
Wüsste z. B. aktuell gerne, was mit Alfred und Liste los ist. Scheint alles wieder weg zu sein. :frowning:
An wen ich Auffälligkeiten melden kann ist auch noch so ein Thema. Ein Tracking-System wäre wohl zu übertrieben.

Momentan ist alles down. Ich habe die ganze Nacht über versucht, das Netz zu stabiliseren. Obwohl ich verschiedene Dinge probiert habe, rennt es jedoch innerhalb kurzer Zeit in einen Broadcast-Sturm. Die Nodes bekommen dann zu viel zurückgespielt, als dass sie es noch verarbeiten könnten und stürzen ab.

Da nützt es also erst einmal nicht, dass wir nun zehn Supernodes bei zwei Providern stehen haben. Das Problem ist hartnäckig und ich hoffe, dass ich nur wegen Schlafmangel nicht auf die Lösung gekommen bin. Ansonsten schafft es vielleicht jemand anderes aus dem Admin-Team, das Netz ans Laufen zu bekommen.

Wenn das nicht zündet, dann möchte ich @anon75826926 einmal bitten, sich des Problems anzunehmen.

5 „Gefällt mir“

Vielen Dank für Deinen Einsatz.
Bedauerlich, dass es sich so schwer eingrenzen lässt.

Für mich klingt es inzwischen so, als ob eine „Not-Teilung“ der Domaine in Viertel eine Option wäre.
Damit man zumindest schauen kann, aus welcher Ecke des Netzes das kommt (oder ein strukturelles Problem ist, was schlicht eine Kettenreaktion aus der Netzgröße ist).

Wie man so ein Not-Update ins Netz bekommt ist dann natürlich ein echtes Problem. Notfalls sind die Reibungsverluste eben unvermeidlich.

Hallo hat schon jemand sein nodes neu registriert,hab ich eben gemacht,
firmware 2014.3 stable-1 komme damit wieder im freifunk rheinufer rein.

Registrierung für das VPN ist nicht mehr notwendig, das wäre dann (höchstwahrscheinlich) nur Zufall, wenn das was geändert hat.

Oder meinst du was anderes?

Auf dem FTP ist jetzt eine neue Gluon version fürs Rheinland bzw Rheinufer zum Download.

Hat die schon jemand der nicht aus dem Admin Team ist ausprobiert?

Wir haben die neue Version auf den Update Server geworfen damit wir sehen ob es hilft.
Momentan sind die Supernodes online (Ohne Public Ip6) aber die Nodes haben große Last.
Ich hoffe das sich die Situation durch die Config-Anpassung bessert.

Ich habe 5 Beiträge in ein neues Thema verschoben: NTP-Konfiguration im Rheinufer

Okay, wird die neue version auch über das Autoupdate verteilt?

Ja dafür haben wir einen Workaround geschaffen, bis jetzt funktioniert dieser. Es kann aber sein das sich manche der Nodes nicht updaten.

1 „Gefällt mir“

:blush:

3 „Gefällt mir“

Oh, Supernodes nun bei OVH? (Mir fehlt gerade die Innenansicht, aber der Ort legt’s nahe)

Hey Admins wie schaut es aus? Gibt es vielleicht einen Zwischenstand?

Oder kann ich Euch vielleicht unterstützen - mit Kaffee, Gebäck oder Chips und Salzstangen?

Ich rechne Euch aufrichtig hoch an, dass Ihr Eure Freizeit da rein steckt!!!
(Musste auch mal gesagt werden!)

6 „Gefällt mir“

Momentan warten wir das genügend Zeit vergangen ist damit ein großteil der Nodes das Update installiert haben.

Anschließend starten wir die Map sowie public IPv6 wieder.

1 „Gefällt mir“

Ihr geht, den FW-Änderungen nach, also davon aus, daß der mitlaufende NTP-Daemon (mit) für Eure Probleme auf den Supernodes verantwortlich war? DNS-Amplification? Frage, weil wir letzten Herbst auch mal ein Wochenende hatten, wo das Netz plötzlich instabil wurde (VMs und physische Hosts stürzten mit Kernel-Panic ab, Alfred streikte), doch der Spuk legte sich nach gut einem Tag (und rausziehen von Alfred auf eigene VM), und ich weiß bis heute leider nicht, was nun eigentlich die Ursache war.

Nein nicht direkt, es gibt Probleme mit IPv6 Neighbor Solications. Der ULA NTP hat das Problem so weit verstärkt das die Nodes abgestürzt sind.

Die Ursache ist noch nicht gelöst:

ICMPv6: NA: someone advertises our address 2a03:2260:0040:0000:fad1:11ff:fe81:164c on br-client!
br-client: received packet on bat0 with own address as source address

Es wäre super wenn alle Nodes die letztes Wochenende aufgesetzt wurden abgeschaltet werden. Wir vermuten eine Node die das Netzwerk stört.
Falls wir so niemanden erreichen wird die VPN Registrierung wieder eingeschaltet und alle vorhandenen VPN Tunnel invalidiert damit wir das Problem lösen können.

Das hatte ich endlos am Samstag… Und es auf eine lokale Fehlconfig geschoben und die betreffenenden Nodes vom Netz genommen. War’s dann wohl aber nicht. (habe mir gestern nochmal versichern lassen, dass das Ding wirklich abgsteckt ist.)

Ich hatte vor 2 Wochen übrigens genau den gleichen Fehler wie ihr im Rheinufer bei uns im Ruhrgebiets Netz - um präzise zu sein am 30.01.

Mich hat es auch erstmal ein paar Stunden gekostet zu verstehen was da genau vor sich ging - wer an dem Abend zufällig im #ffruhr IRC Channel war hat teilweise meine Verzweiflung mitbekommen.

Im Falle des Ruhrgebiets war es eine Infrastruktur eines Herstellers, die im Netz behauptet hat, sie hätte jede IP Adresse.

Neben den Fehlermeldungen

war bei uns enorm viel Traffic im Netz und jede Verbindung wurde im Layer2 auf die Infrastruktur umgeleitet (war nur über batctl zu sehen).

Ich konnte die Infrastruktur dann irgendwann finden und temporär aussperren, bis sich der „Besitzer“ dann bei mir meldete und klar wurde, um was es sich bei der Aufschaltung handelte.

Die Infrastruktur läuft aber nun mitterweile (Layer3 angebunden!) im Ruhrgebiets Netz, entsprechend kann die es nicht mehr sein.

Könnt Ihr nicht über die state.json vom ffmap-backend herausfinden, welche Nodes am Wochenende erstmalig erfasst worden sind?
Dort gibt’s auch einen Key namens firstseen mit Timestamp als Wert.
Dann könnte man diese erstmal auf die Blacklist setzen und sukzessive entfernen.

Edit:
Ok, man müsste dann noch irgendwie von den MAC- oder IP-Adressen auf den Fastd-Key kommen.
Hmmm.