Continuing Packet Loss

Right since I started using Tooway, my monitoring device (a RIPE Atlas monitor) has been recording periods of packet loss on the Tooway network. I’ve raised this several times with Avonline’s technical support but never received a meaningful answer, or indeed one that demonstrates that they understand the issues. Periods of packet loss do not appear to correlate with heavy precipitation.

So, until proven otherwise, we have to assume that this is an inherent property of their service. So what does that mean?

  1. Loss of secure web services: my outgoing email (secure connection to Google) frequently fails; bank, messaging connections that use SSL regularly keel over as the connection has effectively been interrupted to the point where it drops and therefore can’t be re-established without re-authentication. Annoying.
  2. Router failover. I use a dual-WAN router, with our ADSL connection (such as it is) running as a backup. The router is continually testing the Tooway connection and switches to ADSL should the Tooway connection drop. This is happening on a fairly regular basis.

As it’s just happened, I can have an immediate look at what’s going on with the network:

Firstly, ping records to google.com – these taken immediately after the point when my ssl connections failed:

PING www.google.com (173.194.40.115): 56 data bytes
64 bytes from 173.194.40.115: icmp_seq=0 ttl=52 time=841.753 ms
64 bytes from 173.194.40.115: icmp_seq=1 ttl=52 time=759.992 ms
64 bytes from 173.194.40.115: icmp_seq=2 ttl=52 time=760.803 ms
64 bytes from 173.194.40.115: icmp_seq=3 ttl=52 time=761.905 ms
64 bytes from 173.194.40.115: icmp_seq=4 ttl=52 time=757.925 ms
64 bytes from 173.194.40.115: icmp_seq=5 ttl=52 time=796.410 ms
64 bytes from 173.194.40.115: icmp_seq=6 ttl=52 time=795.633 ms
Request timeout for icmp_seq 7
64 bytes from 173.194.40.115: icmp_seq=7 ttl=52 time=1234.462 ms
64 bytes from 173.194.40.115: icmp_seq=8 ttl=52 time=1193.086 ms
64 bytes from 173.194.40.115: icmp_seq=9 ttl=52 time=1152.343 ms
64 bytes from 173.194.40.115: icmp_seq=10 ttl=52 time=751.312 ms
64 bytes from 173.194.40.115: icmp_seq=11 ttl=52 time=760.803 ms
64 bytes from 173.194.40.115: icmp_seq=12 ttl=52 time=751.184 ms
64 bytes from 173.194.40.115: icmp_seq=13 ttl=52 time=749.693 ms
64 bytes from 173.194.40.115: icmp_seq=14 ttl=52 time=750.580 ms
64 bytes from 173.194.40.115: icmp_seq=15 ttl=52 time=746.799 ms
64 bytes from 173.194.40.115: icmp_seq=16 ttl=52 time=746.015 ms
^C
— www.google.com ping statistics —
18 packets transmitted, 17 packets received, 5.6% packet loss
round-trip min/avg/max/stddev = 746.015/841.806/1234.462/165.004 ms

Having shown that we are going through a period of packet loss, now for the recent packet loss history for my connection (red stripes are periods of packet loss):

Screen Shot 2013-11-12 at 13.45.07

There does appear to be some lag on RIPE’s reporting, hence the current time not showing in red.

Now, having demonstrated that we have ongoing packet loss issues, the next step is to look what’s been happening with our network connection itself:

Internet Address: Controller Connected: Connect at: Disconnect at: Connected time: Disconnected time (until next connection):
176.227.xxx.xxx ctr-ams04, NL 2013-11-12 10:43:18 UTC (still connected) 0d, 2h, 56m (still connected)
176.227.xxx.xxx ctr-ams04, NL 2013-11-11 15:57:33 UTC 2013-11-12 10:40:50 UTC 0d, 18h, 43m 0d, 0h, 2m
81.174.xxx.xx ctr-ams04, NL 2013-11-10 14:07:26 UTC 2013-11-11 15:51:37 UTC 1d, 1h, 44m 0d, 0h, 5m
176.227.xxx.xxx ctr-ams04, NL 2013-11-05 10:23:07 UTC 2013-11-10 13:57:32 UTC 5d, 3h, 34m 0d, 0h, 9m
81.174.xxx.xx ctr-ams04, NL 2013-11-05 10:13:58 UTC 2013-11-05 10:20:20 UTC 0d, 0h, 6m 0d, 0h, 2m
176.227.xxx.xxx ctr-ams04, NL 2013-11-05 04:53:09 UTC 2013-11-05 10:03:56 UTC 0d, 5h, 10m 0d, 0h, 10m
176.227.xxx.xxx ctr-ams04, NL 2013-11-02 10:32:59 UTC 2013-11-05 04:51:17 UTC 2d, 18h, 18m 0d, 0h, 1m
176.227.xxx.xxx ctr-ams04, NL 2013-11-01 05:42:50 UTC 2013-11-02 10:30:44 UTC 1d, 4h, 47m 0d, 0h, 2m
81.174.xxx.xx ctr-ams04, NL 2013-10-31 18:55:19 UTC 2013-11-01 05:39:58 UTC 0d, 10h, 44m 0d, 0h, 2m
176.227.xxx.xxx ctr-ams04, NL 2013-10-31 13:44:34 UTC 2013-10-31 18:39:19 UTC 0d, 4h, 54m 0d, 0h, 16m
176.227.xxx.xxx ctr-ams04, NL 2013-10-29 20:10:08 UTC 2013-10-31 13:36:48 UTC 1d, 17h, 26m 0d, 0h, 7m
176.227.xxx.xxx ctr-ams04, NL 2013-10-28 14:28:46 UTC 2013-10-29 20:08:06 UTC 1d, 5h, 39m 0d, 0h, 2m
81.174.xxx.xx ctr-ams04, NL 2013-10-28 11:20:43 UTC 2013-10-28 14:17:36 UTC 0d, 2h, 56m 0d, 0h, 11m
176.227.xxx.xxx ctr-ams04, NL 2013-10-28 11:02:25 UTC 2013-10-28 11:19:55 UTC 0d, 0h, 17m 0d, 0h, 0m
176.227.xxx.xxx ctr-ams04, NL 2013-10-25 23:49:10 UTC 2013-10-28 11:01:30 UTC 2d, 11h, 12m 0d, 0h, 0m
81.174.xxx.xx ctr-ams04, NL 2013-10-25 19:08:40 UTC 2013-10-25 23:47:10 UTC 0d, 4h, 38m 0d, 0h, 2m
176.227.xxx.xxx ctr-ams04, NL 2013-10-22 18:11:07 UTC 2013-10-25 19:05:22 UTC 3d, 0h, 54m 0d, 0h, 3m
81.174.xxx.xx ctr-ams04, NL 2013-10-22 15:36:54 UTC 2013-10-22 18:09:10 UTC 0d, 2h, 32m 0d, 0h, 1m
176.227.xxx.xxx ctr-ams04, NL 2013-10-22 12:47:40 UTC 2013-10-22 15:29:09 UTC 0d, 2h, 41m 0d, 0h, 7m
81.174.xxx.xx ctr-ams04, NL 2013-10-21 21:52:52 UTC 2013-10-22 12:40:18 UTC 0d, 14h, 47m 0d, 0h, 7m
176.227.xxx.xxx ctr-ams04, NL 2013-10-10 17:15:44 UTC 2013-10-21 21:47:14 UTC 11d, 4h, 31m 0d, 0h, 5m
176.227.xxx.xxx ctr-ams04, NL 2013-10-10 16:01:57 UTC 2013-10-10 16:55:11 UTC 0d, 0h, 53m 0d, 0h, 20m
5.61.xxx.xxx ctr-ams04, NL 2013-10-10 08:43:47 UTC 2013-10-10 13:38:30 UTC 0d, 4h, 54m 0d, 2h, 23m
5.61.xxx.xxx ctr-ams04, NL 2013-10-09 11:30:30 UTC 2013-10-10 08:42:32 UTC 0d, 21h, 12m 0d, 0h, 1m
5.61.xxx.xxx ctr-ams04, NL 2013-10-07 16:25:22 UTC 2013-10-09 11:24:44 UTC 1d, 18h, 59m 0d, 0h, 5m
5.61.xxx.xxx ctr-ams04, NL 2013-10-04 22:07:48 UTC 2013-10-07 16:19:48 UTC 2d, 18h, 12m 0d, 0h, 5m

Looking at this, you can see when the connections drop and when they fail to the point where the backup ADSL line kicks in – anything showing an IP address starting with 81.174… is the ADSL in use.

And today is a bright clear day in Scotland. It’s also clear and bright in Turin, where Tooway’s primary ground link is apparently situated, with no precipitation in the last 24 hours.

So this remains a continuing concern with Tooway’s network and with Avonline’s ability to respond to a reported problem.

Leave a Reply

Your email address will not be published. Required fields are marked *