Gateways, PPPoE: random degradation and halt



  • 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



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



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

    Thank you for now!



  • 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% 
    
    


  • 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 ...


Log in to reply