Gateways, PPPoE: random degradation and halt

MartinBrugnara

Sometime my gateway is reported as down and does not came back automatically.
The only way I can bring it up again is by disabling the interface and enabling again.

In the log I see this pattern:
Jul 6 19:42:39 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 192.168.133.17 bind_addr 213.21.161.5 identifier "WAN_PPPOE "
Jul 6 19:42:27 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 192.168.133.17 bind_addr 213.21.161.5 identifier "WAN_PPPOE "
Jul 6 19:41:43 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 192.168.133.17 bind_addr 213.21.161.5 identifier "WAN_PPPOE "
Jul 6 19:41:31 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 192.168.133.17 bind_addr 213.21.161.5 identifier "WAN_PPPOE "
Jul 6 17:51:08 dpinger WAN_PPPOE 192.168.133.17: Alarm latency 0us stddev 0us loss 100%
Jul 6 17:50:53 dpinger WAN_PPPOE 192.168.133.17: Alarm latency 573433us stddev 1590911us loss 89%
Jul 6 17:50:06 dpinger WAN_PPPOE 192.168.133.17: Alarm latency 356354us stddev 918984us loss 21%
Jul 6 17:49:54 dpinger WAN_PPPOE 192.168.133.17: Clear latency 262377us stddev 496919us loss 4%
Jul 6 17:49:43 dpinger WAN_PPPOE 192.168.133.17: Alarm latency 573778us stddev 641602us loss 11%

I've tried to enable the ' cron based reset' on 'week' basis. But does not goes better.

I am running with qemu+kvm the card is attached via 'PCI-Passthrough'.

Does someone have any idea on how can I improve this situation?

Thank you,
– Martin

aGeekhere

Try this, in gateways edit wan gateway and under Advanced reset the value to default, try also setting Data Payload to 1.

MartinBrugnara

I changed my configuration,
I will see how it works then I will report here.

Thank you for now!

MartinBrugnara

Things starts getting better (I suppose):
I do not see anymore lines like this

 Jul 6 22:24:31 	dpinger 		send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 192.168.133.17 bind_addr 213.21.161.5 identifier "WAN_PPPOE "

But only random enormous latency, I can not identify if this is sill related to the configuration or if is an ISP problem…
Do you have any suggestion how can I improve this or when I can look for others insights on this problem?

Thank you,
-- Maritn

New random latency:


Jul 9 17:12:04 	dpinger 		WAN_PPPOE 192.168.133.17: Alarm latency 1739458us stddev 2355872us loss 15%
Jul 9 17:11:50 	dpinger 		WAN_PPPOE 192.168.133.17: Alarm latency 789578us stddev 1310749us loss 22%
Jul 9 17:11:41 	dpinger 		WAN_PPPOE 192.168.133.17: Alarm latency 519905us stddev 936166us loss 14%
Jul 9 17:11:22 	dpinger 		WAN_PPPOE 192.168.133.17: Clear latency 263164us stddev 250816us loss 1%
Jul 9 17:09:41 	dpinger 		WAN_PPPOE 192.168.133.17: Alarm latency 504127us stddev 757965us loss 3%
Jul 8 13:18:03 	dpinger 		WAN_PPPOE 192.168.133.17: Clear latency 410880us stddev 416248us loss 1%
Jul 8 13:17:53 	dpinger 		WAN_PPPOE 192.168.133.17: Alarm latency 500082us stddev 460452us loss 1%
Jul 8 13:17:31 	dpinger 		WAN_PPPOE 192.168.133.17: Clear latency 444778us stddev 474467us loss 2%
Jul 8 13:15:11 	dpinger 		WAN_PPPOE 192.168.133.17: Alarm latency 501533us stddev 422319us loss 0%
Jul 8 10:20:55 	dpinger 		WAN_PPPOE 192.168.133.17: Clear latency 3697us stddev 7537us loss 0%
Jul 8 10:19:46 	dpinger 		WAN_PPPOE 192.168.133.17: Alarm latency 656967us stddev 2221152us loss 13%
Jul 7 21:06:29 	dpinger 		WAN_PPPOE 192.168.133.17: Clear latency 444738us stddev 275866us loss 0%
Jul 7 21:03:49 	dpinger 		WAN_PPPOE 192.168.133.17: Alarm latency 503668us stddev 381298us loss 4%
Jul 7 21:03:38 	dpinger 		WAN_PPPOE 192.168.133.17: Clear latency 483457us stddev 363421us loss 4%
Jul 7 21:02:36 	dpinger 		WAN_PPPOE 192.168.133.17: Alarm latency 503290us stddev 307719us loss 5%
Jul 7 20:56:06 	dpinger 		WAN_PPPOE 192.168.133.17: Clear latency 472369us stddev 443454us loss 6%
Jul 7 20:51:40 	dpinger 		WAN_PPPOE 192.168.133.17: Alarm latency 514838us stddev 364600us loss 4%
Jul 7 19:53:27 	dpinger 		WAN_PPPOE 192.168.133.17: Clear latency 252733us stddev 254546us loss 0%
Jul 7 19:52:05 	dpinger 		WAN_PPPOE 192.168.133.17: Alarm latency 505103us stddev 424070us loss 0%
Jul 7 19:51:44 	dpinger 		WAN_PPPOE 192.168.133.17: Clear latency 437136us stddev 376030us loss 0%
Jul 7 19:51:32 	dpinger 		WAN_PPPOE 192.168.133.17: Alarm latency 500869us stddev 429424us loss 0%
Jul 7 19:07:39 	dpinger 		WAN_PPPOE 192.168.133.17: Clear latency 399430us stddev 264101us loss 1%
Jul 7 19:07:22 	dpinger 		WAN_PPPOE 192.168.133.17: Alarm latency 511596us stddev 406245us loss 1%

MartinBrugnara

If this can help I found out that each time there is a degradation in the connection on the system logs there are this lines:


Jul  9 17:12:59 magneton check_reload_status: updating dyndns WAN_PPPOE
Jul  9 17:12:59 magneton check_reload_status: Restarting ipsec tunnels
Jul  9 17:12:59 magneton check_reload_status: Restarting OpenVPN tunnels/interfaces
Jul  9 17:12:59 magneton check_reload_status: Reloading filter

Not sure if it is a consequence or cause

– edit:
BTW: I do not have any ipsec tunnel defined ...