Ausfall von drei Supernodes

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.

Wenn der alfred auch den fastd-key mit übertragen würde, dann würde auch vieles andere sehr viel einfacher werden
(beim Blacklisting… Die Fälle werden zukünftig nicht seltener werden.)

Mein Vorschlag wäre nach wie vor eine „Not-Teilung“ der Rheinufer-Domain in z.B. Rheinturm, Aachen, Bergisches Land, Niederrhein. (Namen sind Schall und Rauch… irgendwie „in Viertel“ halt.)

Zum einen wird es so oder so früher oder später notwendig werden, zum anderen muss ja nicht ein Config-Fehler gleich in Halb-NRW die Lichter ausgehen lassen.

Um ein Splitting werden wir wohl nicht rumkommen, aber die momentane Situation würde auch bei kleinen Kollisionsdomänen arge Probleme verursachen.

Momentan suchen wir die Node „a2:f7:c1:48:cf:2a“
Diese spammt das Netz mit dem ICMP6 traffic zu:

14:36:45.977407 BAT 04:be:ef:ca:fe:07: BCAST, orig a2:f7:c1:48:cf:2a, seq 105893921, Warning - packet contains unknown ether type: 0x86dd

Diese MAC Adresse ist ja scheinbar nicht einmal ganz korrekt. Bzw finde ich keinen Hersteller dieser Hardware. Ist es möglich das Absicht hinter der Störung liegt?

Meine Nodes von tp-Link fangen ja mit C4 an.

Und per alfred meldet sich der nicht?

Kleinere Kollisionsdomainen würde so eine(r) trotzdem noch in den Untergang reißen. Klar.
Aber das wäre dann eine von z.B. vier. Die drei anderen könnten normal arbeiten.

Ich denke mal, dass es sich um irgendeine Form von virtueller hardware handelt (fastd-offloader…), bei deren Einrichtung etwas gewaltig schief gelaufen ist. Und dass der/die Betreiber gar nicht ahnen, dass es ihr Equipment ist, was da das Netz in den Abgrund reisst.

ca. 500m vom mir entfernt steht ein TP-Link TL-WR1043N/ND v1,
dessen Adressen beginnen mit a0:f3:c1: bzw. a2:f7:c1:
daher kann das durchaus ein (älterer) TP-Link Router sein.

1 „Gefällt mir“

Lässt sich der Traffic von der MAC-Adresse nicht irgendwie mittels iptables/ebtables über das Batman-Interface sperren?
Oder ist es da schon zu spät?

Deshalb ist unsere Idee dazu (für die wir nach lokalen Ressourcen suchen und bereits angefangen haben umzusetzen) die Domänen in sinnvolle Segmente (Community bis Kreisgröße) zu zerlegen.

Diese Idee ergibt jedoch erst dann noch mehr gesteigerten Sinn, wenn man die Arbeit, die hierdurch wieder anfällt, sinnvoll dazu nutzt, um zu bildende lokale Admin Teams gleichzeitig einzuweisen und möglichst schon auf lokaler Hardware die neuen Gateway Server dafür installiert.

Kein Unterfangen das nächste Woche fertig ist, zumal der Zuspruch bislang eher gering ist.

Ich habe zwar nur „Gefährliches“ Halbwissen, aber ist es nicht einfach möglich die IP von dem in den iptables auf DROP zu setzen? Notfalls sollte das ja auch über das WebIF vom Hoster laufen. Dort direkt über den Router sperren, oder wie man das Ding im Rechenzentrum auch nennen mag.

Ich gehe einfach mal davon aus das ihr das schon versucht habt. Doch geht es mir ja nur darum zu helfen.

Den gab es um den 1. Januar mal in ffnw (Freifunk-Nordwest)
http://webcache.googleusercontent.com/search?q=cache:EAxYoxc4UUcJ:netmon.freifunk-ol.de/show_crawl_data.php%3Fip_id%3D27641+&cd=3&hl=de&ct=clnk&gl=de
Mit Kontakt „nexthop“ „ae:ee:1a:b0:3d:12“

2 „Gefällt mir“

@bjo ping Kannst Du vielleicht irgendwas in alten Logfiles finden? Ich finde leider keine alte fe80er mehr, die dazu gehört.

Ich habe nun den Public Key der Node in den Supernodes gesperrt, warten wir mal ab :wink:

Wie hast Du ihn denn herausgefunden?
Bin nur neugierig :smile:.