pfSense Latenzspitzen

[Flole]

Es ist genauer gesagt der radvd der alle 30 Sekunden eine latenzspitze verursacht. Wenn du möchtest das es behoben wird solltest du im pfsense Forum dazu was schreiben, die Entwickler interessiert das nämlich nicht wirklich. Wenns genug Leute sind die es melden, wird sich das hoffentlich ändern.

[sch4kal]

Es ist genauer gesagt der radvd der alle 30 Sekunden eine latenzspitze verursacht. Wenn du möchtest das es behoben wird solltest du im pfsense Forum dazu was schreiben, die Entwickler interessiert das nämlich nicht wirklich. Wenns genug Leute sind die es melden, wird sich das hoffentlich ändern.

Werde ich gleich tun, im Gegensatz zu dir nutze ich aber kein LACP, wohl aber VLANs.
Deaktivierst du den radvd/dhcpv6-server nur auf dem betroffenen Interface oder auf Allen ?

[Flole]

Ich hab den überall abgeschaltet (auf unmanaged gestellt). Witzigerweise läuft es wenn ich eine der Intel NICs rausschmeiße.

[sch4kal]

Ich hab den überall abgeschaltet (auf unmanaged gestellt). Witzigerweise läuft es wenn ich eine der Intel NICs rausschmeiße.

Bei mir läuft es gerade problemlos wenn ich den dpinger6 stoppe, also das ipv6 interface monitoring deaktiviere.
Das muss trotzdem irgendwie mit einem CMTS-Problem zusammenhängen, er überwacht ja die fe80::1:1, also das Standardgateway von IPv6.

[Flole]

Auch gut, ich hatte IPv6 auf dem WAN Interface aktiv und auch überall sonst konfiguriert, solange der radvd nicht genutzt wurde war alles gut, mit dem gab's Probleme.

[sch4kal]

Okay, also ich hab jetzt den radvd aktiv und mein LAN auf managed stehen inkl. DHCPv6-Server.
Bisher ohne Spikes...

Btw. gerade scheint wohl 2.4.4_1 erschienen zu sein, meldet mir mein Dashboard

*edit* Jupp, kann es perfekt nachstellen, sobald im Gateway Log ein dpinger-Eintrag wie

Code: Alles auswählen

WAN_DHCP6 fe80::1%igb0: Clear latency 20048us stddev 42949us loss 18%

auftaucht habe ich auch ein Spike im Pingplotter.

[Flole]

Uiii, da muss ich ja nachher Mal updaten Da wurde aber soweit ich weiß das radvd Problem noch nicht angegangen. Allerdings irgendwas am dpinger soll wohl gemacht worden sein....

[Flole]

Jetzt wo wir unseren eigenen Thread dafür bekommen haben kann man darüber auch ausgiebig diskutieren und rätseln

Reichen die 18% loss denn aus um das Gateway als down zu markieren? Ich hab da grad eine dieser tausenden State-Killing funktionen im Verdacht die können durchaus sowas zur Folge haben. Wobei das ganze auch eine Konsequenz daraus sein könnte (das Problem hatte ich nämlich dann auch auf 6 Gateways gleichzeitig, und die sind bestimmt nicht alle gleichzeitig weg gewesen, da hat pfsense einfach kurzzeitig nix mehr gemacht und hat dementsprechend wurde das auch vom dpinger registriert)

[sch4kal]

Naja diese Option lässt sich ja deaktivieren, daher erwarte ich, dass die State Table nur dann gelöscht wird wenn das Gateway auch als „Down“ markiert wurde. Sonst gäbe so eine Markierung ja keinen Sinn. Hast du mal in den Github Issues zu dpinger gestöbert ? Kanns mir momentan nicht anschauen. Meine Probleme sind jetzt seit Deaktivierung von dpinger komplett verschwunden. Auch der Broadband-Graph sieht wesentlich besser aus.

[sch4kal]

Reichen die 18% loss denn aus um das Gateway als down zu markieren?

Code: Alles auswählen

Dec 3 21:55:28	dpinger		WAN_DHCP6 fe80::1%igb0: Alarm latency 11169us stddev 10148us loss 21%
Dec 3 21:55:26	dpinger		WAN_DHCP6 fe80::1%igb0: Clear latency 11315us stddev 10138us loss 18%
Dec 3 21:55:03	dpinger		WAN_DHCP6 fe80::1%igb0: Alarm latency 11595us stddev 6917us loss 21%
Dec 3 21:55:00	dpinger		WAN_DHCP6 fe80::1%igb0: Clear latency 16076us stddev 45244us loss 19%
Dec 3 21:54:45	dpinger		WAN_DHCP6 fe80::1%igb0: Alarm latency 21581us stddev 63860us loss 21%
Dec 3 21:54:34	dpinger		WAN_DHCP6 fe80::1%igb0: Clear latency 20069us stddev 59709us loss 10%
Dec 3 21:54:17	dpinger		WAN_DHCP6 fe80::1%igb0: Alarm latency 21234us stddev 63862us loss 21%
Dec 3 21:54:08	dpinger		WAN_DHCP6 fe80::1%igb0: Clear latency 20709us stddev 61034us loss 14%
Dec 3 21:53:55	dpinger		WAN_DHCP6 fe80::1%igb0: Alarm latency 17501us stddev 44885us loss 21%
Dec 3 21:53:52	dpinger		WAN_DHCP6 fe80::1%igb0: Clear latency 17095us stddev 44683us loss 20%
Dec 3 21:52:58	dpinger		WAN_DHCP6 fe80::1%igb0: Alarm latency 10677us stddev 5375us loss 21%
Dec 3 21:52:57	dpinger		WAN_DHCP6 fe80::1%igb0: Clear latency 10444us stddev 5255us loss 20%
Dec 3 21:52:43	dpinger		WAN_DHCP6 fe80::1%igb0: Alarm latency 10028us stddev 4051us loss 21%

Ab 21 %, hatte den falschen Eintrag kopiert.