das mag sein, aber warum tritt das nur in Domäne Ruhrgebiet auf und nicht in Domäne Rheinufer?
Ich dachte bisher FW-Version 0.5 von Ruhrgebiet ist die gleiche, wie die 2014.3-stable-1 von Rheinufer?
Zudem glaube ich, dass es auch bei 0.5 nicht von Anfang an war, sondern erst seit einiger Zeit. Irgendwass muss sich seitdem (im Backend?) verändert haben.
Ich hab das mal im sysctl.conf eingetragen und schaue nun mal, wie sich der router verhält. Und ich hatte gerade gespeichert und hatte vi wieder beendet, da fühlte sich das system unglaublich träge an. Es wurde immer schlimmer, und bevor ich schauen konnte, wie die RAM-Auslastung ist, hat das ding unter meinen Fingern rebootet.
Da bleibt nur ein Serial-Adapter. Aber ggfs. können wir es auch so lösen.
Bitte teste mal den Workaround aus dem Ticket und gebe ein Feedback.
Gruß,
Philip
Nach einem Reboot hat es nun auf einem TL-WR841N/ND v9 funktioniert :
root@FF-E-Bdorf-xxx-01:~# sysctl -w net.ipv6.neigh.default.gc_thresh1=512
net.ipv6.neigh.default.gc_thresh1 = 512
root@FF-E-Bdorf-xxx-01:~# sysctl -w net.ipv6.neigh.default.gc_thresh2=2048
net.ipv6.neigh.default.gc_thresh2 = 2048
root@FF-E-Bdorf-xxx-01:~# sysctl -w net.ipv6.neigh.default.gc_thresh3=4096
net.ipv6.neigh.default.gc_thresh3 = 4096
Gruß Jörg
Nope.
Hab die Werte eingetragen, laut sysctl werden sie auch übernommen. Aber trotzdem hatte ich eben wieder einen reboot.
Keine Verbesserung. Weiterhin Reboots. RAM sieht vor dem Reboot auch gut aus:
root@FF-E-Bdorf-XXX-01:~# free
total used free shared buffers
Mem: 29212 23612 5600 0 1692
-/+ buffers: 21920 7292
Swap: 0 0 0
Gruß Jörg
Ich denke mal, 15 gleichzeitig laufende dhcpv6-scripts (auf einem WR841 ohne einen einzigen Client, weder Lan noch Wlan) kann nicht gut sein.
Hallo,
wenn ich meine Router anpinge bekomme ich jetzt ein Hop Limit:
From 2a02:f98:0:25::2 icmp_seq=1 Time exceeded: Hop limit
From 2a02:f98:0:25::2 icmp_seq=2 Time exceeded: Hop limit
From 2a02:f98:0:25::2 icmp_seq=3 Time exceeded: Hop limit
Und das traceroute sieht auch ganz merkwürdig aus:
Gruß Jörg
Hallo,
auch mein lokaler freifunk TP-Link TL-WDR4300 v1 Router, der ohne Probleme funktioniert, zeigt von Außen ein ähnliches Fehlerbild:
Ping:
PING 2a02:f98:0:26:ea94:f6ff:fecd:3248(2a02:f98:0:26:ea94:f6ff:fecd:3248) 56 data bytes
From 2a02:f98:0:25::2 icmp_seq=1 Time exceeded: Hop limit
From 2a02:f98:0:25::2 icmp_seq=2 Time exceeded: Hop limit
Traceroute:
Gruß Jörg
Warte, der Papa macht euch das fertig kicher
Teste nochmal den Traceroute…
Das glaube ich nicht 
IPv4:
root@FF-E-Bdorf-HH-01:~# ping 85.183.110.26
PING 85.183.110.26 (85.183.110.26): 56 data bytes
64 bytes from 85.183.110.26: seq=0 ttl=62 time=2.183 ms
64 bytes from 85.183.110.26: seq=1 ttl=62 time=1.829 ms
64 bytes from 85.183.110.26: seq=2 ttl=62 time=1.511 ms
64 bytes from 85.183.110.26: seq=3 ttl=62 time=1.413 ms
^C
— 85.183.110.26 ping statistics —
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 1.413/1.734/2.183 ms
IPv6:
root@FF-E-Bdorf-HH-01:~# ping6 2001:4dd0:ff96::1
PING 2001:4dd0:ff96::1 (2001:4dd0:ff96::1): 56 data bytes
^C
— 2001:4dd0:ff96::1 ping statistics —
50 packets transmitted, 0 packets received, 100% packet loss
Ich habe gerade schon den HANSER IP-Netze aus dem Bücherregal geholt…
Gruß Jörg
Ahh, es wird besser:
root@FF-E-Bdorf-HH-01:~# ping6 2001:4dd0:ff96::1
PING 2001:4dd0:ff96::1 (2001:4dd0:ff96::1): 56 data bytes
64 bytes from 2001:4dd0:ff96::1: seq=0 ttl=56 time=138.477 ms
64 bytes from 2001:4dd0:ff96::1: seq=1 ttl=56 time=84.713 ms
64 bytes from 2001:4dd0:ff96::1: seq=2 ttl=56 time=81.345 ms
64 bytes from 2001:4dd0:ff96::1: seq=3 ttl=56 time=153.796 ms
64 bytes from 2001:4dd0:ff96::1: seq=4 ttl=56 time=89.625 ms
^C
— 2001:4dd0:ff96::1 ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 81.345/109.591/153.796 ms
Gruß Jörg
Hab schnell mein zerstaubtes Tabellenbuch der Informationstechnologie rausgekramt, um das Netz zu fixen, hat geklappt… 
Hallo,
Langsam scheint sich die Lage auch im Alfred zu entspannen. Die Uptime geht nach oben 
.
Dann kann ich mich ja wieder hinlegen…
Gruß Jörg
jetzt hab ich grad den Workarround ausprobiert und wundere mich, dass die Load wieder niedrig ist.
was hast du denn gemacht, dass es nun wieder funzt?
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:
…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.
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.
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…
@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.
Hm, ein Memory Problem konnte ich auch kurz vor einem Reboot aber auf meinem TL-WR841N/ND v9 nicht ausmachen (s. oben).