Ständige Neustarts in der Domäne Ruhrgebiet

In Ordnung ist es nicht, es gibt nach wie vor massiv die Fehler in den Nodes:

20:38:32 FF-OB-LIP-OBone-03 kern.warn kernel: [ 4213.640000] ipv6: Neighbour table overflow.

Gemacht habe ich:

  • ganz stumpf erstmal apt-get update / upgrade auf allen Servern, um die jeweils jüngste Version aller Systemdienste zu bekommen
  • dann fastd auf allen Servern auf die v16 geupgraded
  • fastd Methodenliste umgestellt, so dass die Server untereinander das neuere umac benutzen, die Nodes weiterhin gmac da sie es noch nicht können (wird erst in der 2014.4 implementiert)
  • ein wenig aufgeräumt und Altlasten deinstalliert

…eben alles was man noch irgendwie machen konnte in der Hoffnung ein wenig das Netz zu entlasten / zu stabilisieren…

Dabei hat bb0 dann seine v6 Device Route auf br0 vergessen, deshalb ging kurz der v6 Traffic nicht durch. Die habe ich dann manuell wieder rein genommen, da mir gerade nicht der Sinn nach einem Neustart stand. :wink:

That’s all - performed zwar kurzfristig ganz ordentlich, aber noch lange keine Entwarnung für die Neighbour Overflow Fehler samt entsprechender Auswirkungen, erstmal nur ein wenig stabilisiert!

Hi Chris,

danke. Die Updates sollten ja „eigentlich“ keinen Einfluss haben. Aber mir scheint so als ob die Router nun ein wenig stabiler laufen.

Die Kernelparameter habe ich mal eingespielt.
Kurzzeitig wird der Router dann ein wenig träge aber er fängt sich.

Glaube ja nicht so ganz das es „nur“ an dem memory Leak liegt.

  1. Problem tritt nu im Ruhrgebiet auf.
  2. Das ist ja schon ein sehr alter Bug.

Ich bin ja mal gespannt ob hier noch jemand was rausbekommt.
Spannend ist das ganze ja schon ein wenig, wenn auch gleich sehr nervig … für alle Beteiligten.

Hoffe ja sehr, das wir etwas daraus lernen können!

Gruß
Thomas

Laut der Gluon Experten ist im fastd massiv viel für große Netze entwickelt worden und wir haben soeben von v12 auf v16 geupgraded, also doch schon einen deutlichen Sprung gemacht.

Hinzu kommt das wir im Ruhrgebiet ca. 370 Router laufen haben, was das gesamte Netz dann ohnehin sehr stark in Anspruch nimmt.

Der Memory Leak und die verursachenden Probleme des ipv6 sind wohl in der 2014.4 gefixt worden. Von Haus aus deutlich größere Neighbour Table und sonstige Veränderungen…

2 „Gefällt mir“

@CHRlS Wie gerade in #h#gluon geschrieben baue ich gerade einen neuen Satz Experimental-Images mit dem „umac“ aus dem 2014.4 gluon-master für ffruhr.
Mal gucken, wie die laufen. Melde mich.

2 „Gefällt mir“

Hm, ein Memory Problem konnte ich auch kurz vor einem Reboot aber auf meinem TL-WR841N/ND v9 nicht ausmachen (s. oben).

So, nachdem das Fahrwasser jetzt wieder ein wenig ruhiger geworden ist, habe ich mich noch einmal des Problems mit den Kernel Warnings „ipv6: Neighbour table overflow“ angenommen. Mit den Kernel Settings

sysctl -w net.ipv6.neigh.default.gc_thresh1=512
sysctl -w net.ipv6.neigh.default.gc_thresh2=2048
sysctl -w net.ipv6.neigh.default.gc_thresh3=4096*

treten sie diese Meldungen z.Z. nicht mehr auf :slight_smile: .

Und auf dem bb0 sieht der fastd jetzt auch viel entspannter aus :sunny: .

Wagemutige vor, vorzugsweise solche, die auch in der Lage sind, ihren Plasterouter ggf. wieder zu unbricken, schient aber prinzipiell zu funktionieren.
http://www.nadeshda.org/ff/gluon-ruhr/sysupgrade/
(nicht davon irritieren lassen, dass im Configmode das Ding teilweise behauptet, ein 2014.3 zu sein. Ist es nicht, ist barrier-breaker.)

der neue umac ist als primärer codec drin und auch obige net.ipv6.neigh.default.gc_thresh-Einstellung.

Fri Nov 21 00:14:44 2014 daemon.info fastd[1312]: new session with <mesh_vpn_backbone_peer_ruhrgebiet1> established using method `salsa2012+umac'.
Fri Nov 21 00:14:46 2014 daemon.info fastd[1312]: new session with <mesh_vpn_backbone_peer_ruhrgebiet2> established using method `salsa2012+umac'.
2 „Gefällt mir“

Nach einem normalen sysupgrade ging es noch.
Dann habe ich mal ein sysupgrade „mit Parameterclear“ versucht, jetzt bekomme ich den Node nicht registriert?
Zumindest bekomme ich kein mesh-VPn aufgebaut
Er dreht sich in der Schleife:

Fri Nov 21 03:10:34 2014 daemon.info fastd[2655]: sending handshake to <mesh_vpn_backbone_peer_ruhrgebiet3>[37.252.124.177:10000]...
Fri Nov 21 03:10:34 2014 daemon.info fastd[2655]: resolving host `ffrg3.freifunk-ruhrgebiet.de' for peer <mesh_vpn_backbone_peer_ruhrgebiet3>...
Fri Nov 21 03:10:34 2014 daemon.info fastd[2655]: resolved host `ffrg3.freifunk-ruhrgebiet.de' successfully

Die uptimes laufen wunderbar hoch… Noch sieht es gut aus! Wir hatten in der letzten Woche allerdings immer mal wieder Momente, in denen Uptimes bis auf 12h+ hochgekommen sind.

Danke an alle hier für die zeitnahe(n) Lösung(sversuche).

1 „Gefällt mir“

Ich möchte noch einmal auf das oben beschriebene Problem hinweisen - das ist nicht gelöst.

Und ich habe eine Bitte:

Ich werde immer mal wieder gefragt, warum Freifunk so langsam ist oder nicht funktioniert. Es wäre sehr hilfreich, wenn es eine Übersetzung der Problembeschreibung, des Lösungsweges und der Lösung gäbe.
Im aktuellen Fall weiß ich z.B. nicht, ob nun das Problem gefunden und gelöst ist, ob es nur eine temporäre Lösung ist, neue Ups-Downs vorprogrammiert sind und und und.
Wahrscheinlich kann man das von den Leuten (wieviele eigentlich?) die an der Lösung arbeiten, nicht verlangen. Würde zusätzlich Zeit stehlen.
Vielleicht gibt es aber jemand außerhalb dieses Kreises, der das kann.

Nachtrag: die Frage der „Nachhaltigkeit“ wurde von Seiten der Politik auch gestellt - wer bzw. wieviele Leute machen die Programmierung, halten das am Laufen etc. - begibt man sich in die Abhängigkeit nur ganz weniger Personen, was ist wennn die wegbrechen. Kurz und gut Transparenz ist Pflicht, auch bei Angaben darüber, wie technische / soft / firmware Probleme gelöst werden.

1 - Kosmos / Abrazo:

Kein echtes Problem, lediglich ein Anzeigefehler.

Einfach den Alfred auf Kosmos neustarten, dann ist die Node wieder sichtbar und der Uplink auch wieder der richtigen Node zugeordnet…wird ebenfalls in 2014.4 besser, da dort Alfred stabiler laufen soll, ist nicht durch uns manipulierbar, da müssen wir auf die Gluon Entwickler hoffen…

2 - warum ist Freifunk so langsam / funktioniert nicht

Das kann an diversen Dingen liegen, sehr oft leider nicht an der Infrastruktur, ich würde sogar soweit gehen und sagen eher selten an der Infrastruktur. Die meisten Fehler treten lokal auf, durch schlechte Internetleitungen, wegbrechende Uplinks, zu geringem Durchsatz bei weit entfernten Routern in der Luft, usw usw. In Gelsenkirchen wird es massiv lokale Probleme geben, ganz sicher sogar, trust me…

2a - Übersetzung

Viel zu übersetzen ist ja eigentlich nicht gewesen.

Ich habe auf Seite der Infrastruktur diverse, die allgemeine Performance beeinflussende, Dinge auf Stand gebracht. Man merkt dass die Last auf den Nodes dadurch reduziert wurde und die Performance durch diese Entlastung massiv gesteigert wurde. Erstmal ist es besser und bleibt auch so.

3 - Nachhaltigkeit

Das ist in der heutigen Zeit eine eher belustigende Frage, es sei denn man wählt als Hotspot Anbieter die Telekom. Jedes andere Unternehmen kann auch morgen den Bach runter gehen und liefert dann nicht mehr.

Insgesamt ist festzuhalten das unsere Technik wesentlich komplexer ist als bei den gewöhnlichen Hotspot Anbietern. Dies ist dem Umstand geschuldet, dass wir in der Luft meshen. Gib jedem Freifunkrouter einen eigenen Uplink, dann hast Du die Probleme des Mesh in der Luft zumindest nicht mehr. Stell das ganze Netz darauf um nicht mehr in der Luft zu meshen, dann hast Du gar keine Probleme mehr, denn dann kannst Du direkt Layer3 statt Layer2 auf die Nodes fahren, allerdings dann komplett ohne Funktionen die unser Netz besonders machen, wie beispielsweise das uplinklose meshen in der Luft, Roaming über alle Router hinweg, etc.

Was wollen wir also,

  • die technisch anspruchsvollere Lösung mit entsprechenden Mehrwerten, aber auch mehr Arbeit und mehr notwendiges Know How vor Ort?
  • oder ein ruhigeres Leben, geringes Know How notwendig, dafür aber ein Netz auf dem technischen Niveau der proprietären Hotspot Anbieter, die nichts können ausser einen normalen Internetzugang zum autarken WLAN Hotspot zu machen?

das sind keine Restarts, der Node hat eine Uptime von 860h!
Ihr müsst die Probleme differenzieren.

Die Aussage, dass bei euch in GE das Freifunk so langsam ist, habe ich auch in einem Kommentar bei FB gelesen. Ich vermute stark, dass zumindest einige eurer Uplinks überlastet sind! Das hat aber auch nix mit Restarts zu zun.

Man sieht aber auch, dass die Load wieder signifikant auf den früheren Wert zurückgegangen ist. Ich bin zuversichtlich.

Bitte mich jetzt richtig falsch zu verstehen:

@Chris
Phillip hat den Kosmos Router online überprüft - ich gehe davon aus, dass er den Alfred neugestartet hat. Falls nicht, könnte er es - im Gegensatz zu mir - nachholen. Ich kenne den Befehl etc. dafür nicht.

@Reka
in dem kleinen Bereich haben wir 7 uplinks - es waren hier noch nie mehr als 40 Clients gleichzeitig online. Wenn ich es recht verstanden habe, kann man sich aber auf keine der Anzeigen wirklich verlassen. Was Up angezeigt wird, kann down sein, was Down angezeigt wird kann Up sein. Ich habe keine Möglichkeit einzelne Uplink Router auf Geschwindigkeitsprobleme zu überprüfen.

1 - Kosmos / Abrazo:

Kein echtes Problem, lediglich ein Anzeigefehler.

Einfach den Alfred auf Kosmos neustarten, dann ist die Node wieder sichtbar und der Uplink auch wieder der richtigen Node zugeordnet…wird ebenfalls in 2014.4 besser, da dort Alfred stabiler laufen soll, ist nicht durch uns manipulierbar, da müssen wir auf die Gluon Entwickler hoffen…

2 - warum ist Freifunk so langsam / funktioniert nicht

Das kann an diversen Dingen liegen, sehr oft leider nicht an der Infrastruktur, ich würde sogar soweit gehen und sagen eher selten an der Infrastruktur. Die meisten Fehler treten lokal auf, durch schlechte Internetleitungen, wegbrechende Uplinks, zu geringem Durchsatz bei weit entfernten Routern in der Luft, usw usw. In Gelsenkirchen wird es massiv lokale Probleme geben, ganz sicher sogar, trust me…

2a - Übersetzung

Viel zu übersetzen ist ja eigentlich nicht gewesen.

Ich habe auf Seite der Infrastruktur diverse, die allgemeine Performance beeinflussende, Dinge auf Stand gebracht. Man merkt dass die Last auf den Nodes dadurch reduziert wurde und die Performance durch diese Entlastung massiv gesteigert wurde. Erstmal ist es besser und bleibt auch so.

3 - Nachhaltigkeit

Das ist in der heutigen Zeit eine eher belustigende Frage, es sei denn man wählt als Hotspot Anbieter die Telekom. Jedes andere Unternehmen kann auch morgen den Bach runter gehen und liefert dann nicht mehr.

Insgesamt ist festzuhalten das unsere Technik wesentlich komplexer ist als bei den gewöhnlichen Hotspot Anbietern. Dies ist dem Umstand geschuldet, dass wir in der Luft meshen. Gib jedem Freifunkrouter einen eigenen Uplink, dann hast Du die Probleme des Mesh in der Luft zumindest nicht mehr. Stell das ganze Netz darauf um nicht mehr in der Luft zu meshen, dann hast Du gar keine Probleme mehr, denn dann kannst Du direkt Layer3 statt Layer2 auf die Nodes fahren, allerdings dann komplett ohne Funktionen die unser Netz besonders machen, wie beispielsweise das uplinklose meshen in der Luft, Roaming über alle Router hinweg, etc.

Was wollen wir also,

  • die technisch anspruchsvollere Lösung mit entsprechenden Mehrwerten, aber auch mehr Arbeit und mehr notwendiges Know How vor Ort?
  • oder ein ruhigeres Leben, geringes Know How notwendig, dafür aber ein Netz auf dem technischen Niveau der proprietären Hotspot Anbieter, die nichts können ausser einen normalen Internetzugang zum autarken WLAN Hotspot zu machen?
1 „Gefällt mir“

Belastet bitte nur den Philip nicht zu sehr. Er hat eigentlich gänzlich andere Aufgaben als Alfred Dienste auf Routern vor Ort neu zu starten.

Die Map ist als Diagnosewerkzeug aktuell zumindest „ungünstig“, solange der Alfred in der Firmware der Nodes noch Probleme hat…

1 „Gefällt mir“

@Chris
Phillip war auf dem Router und hat das Alfred Problem überprüft. Ich gehe davon aus, dass er ihn auch neu gestartet hat - oder? Das Problem besteht immer noch.

Thema „Nachhaltigkeit“
Damit ist Manpower gemeint. Konkret: wie groß ist die Personaldecke. Was passiert, wenn Leistungsträger aus dem Bereich Technik im Bündel nach Irland weggekauft werden oder als Gang im Silicon Valley für viele Dollar tätig werden, statt unbezahlt Freifunk weiter zu machen. Das sind ernst gemeinte Fragen der Politik, die ich vor Ort auch beantworten muss.

Thema „Übersetzung“
am Ende ist es ja meistens nicht viel, was gemacht werden musste. Die Techniker verstehen die Lösung, wenn sie die „Suchwege“ nachvollziehen. Ich muss aber hier alle bedienen - technik affine Politiker, die Router-Bettreiber und die „Endkunden“ - und das alles ohne Technik-Sprech auf Kleine-Mann-von-der-Straße-Sprech runter brechen zu können.

Nachtrag zur Nachhaltigkeit:

Wir suchen fortlaufend nach fähigen Linux Experten, um das lokale Ruhrgebiets Admin Team zu verstärken.

„Der Papa“ hatte die letzten Wochen wegen zu vieler Projekte und einem privaten Fiasko leider nicht so viel Zeit wie üblich. Ich will nun gar nix schön reden, aber vielleicht haben die Probleme eben auch daran gelegen das ich zu wenig Zeit für das Netz verwendet habe. Zumindest hätte man es schneller lösen können…

Einen mutigen Admin Kandidaten haben wir noch in der Pipeline, da bin ich noch nicht zu gekommen mich zu kümmern, aber das Admin Team zu verstärken ist unumgänglich, da es für die allgemeine Administration derzeit nur aus mir besteht - auch wenn ich noch die Hoffnung hege, dass der Jörg sich auch in die allgemeine Administration reinmischt. :wink:

1 „Gefällt mir“

kann ich bestätigen nach einem einfachen sysupdate :smiley:

Die Personaldecke sieht derzeit so aus:

Chris: Administration global
Philip (@pberndro): PR, Firmwarekompilierung/Firmwarebetreuung (aktuell auch noch zusätzlich allgemeiner Support)
Jörg: Administration DNS / Mail / Security
Thomas (@thomasDOTwtf): Notfalladmin fürs Ruhrgebiet, Admin der Domäne Möhne
Thomas (@fragstone): aktuell Admin Bewerber

3 „Gefällt mir“