High packet loss on server Ancha (The Netherlands)

[BitWanderer 0]

On server Ancha (The Netherlands) i have a lot of packet loss (> 50%) since a couple of hours.
The connection to my ISP is fine so it looks like the problem is not on my end.

[OpenSourcerer 1442]

5 hours ago, blancken said:

The connection to my ISP is fine so it looks like the problem is not on my end.

Well, probably wrong.
https://airvpn.org/servers/Ancha/
No packet loss reports in the last 24 hours. Definitely something on your end.

[BitWanderer 0]

19 hours ago, OpenSourcerer said:

Well, probably wrong.
https://airvpn.org/servers/Ancha/
No packet loss reports in the last 24 hours. Definitely something on your end.

I'm not sure: Rebooted all network devices, though everything was stable except the VPN connection to Ancha.
ISP connection is OK, no hiccups or loss or slowness whatsoever. Speed test shows full speed.
Tested with server Alcyone, all OK, zero packet loss.

Moreover, traceroute indicates a problem with Ancha:

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                            172.29.230.1 -    0 |  352 |  352 |    0 |   10 | 1329 |    1 |
|                           192.168.100.1 -    0 |  352 |  352 |    0 |   10 | 1330 |    1 |
|                            xxx.xxx.xxx.xxx -    0 |  352 |  352 |    6 |   18 | 1315 |   11 |
|                           xxx.xxx.xxx.xxx -    0 |  352 |  352 |    5 |   20 | 1315 |    6 |
|                           xxx.xxx.xxx.xxx -    0 |  352 |  352 |    6 |   16 | 1315 |   16 |
|                          80.249.212.159 -    0 |  352 |  352 |    6 |   17 | 1317 |   11 |
|                           37.123.210.79 -    1 |  301 |  300 |   15 |  524 | 4621 |  137 |
|                         213.152.162.167 -   17 |  217 |  182 |    0 |   45 | 2109 |   32 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v0.92 GPL V2 Edited ... by OpenSourcerer
Slight edit to remove something felt like advertising

[OpenSourcerer 1442]

What I can confirm from my end:

$ sudo traceroute -T ancha.airvpn.org
traceroute to ancha.airvpn.org (213.152.162.164), 30 hops max, 60 byte packets
1  _gateway (192.168.110.1)  1.226 ms  1.583 ms  1.894 ms
2  p3e9bf2fc.dip0.t-ipconnect.de (62.155.242.252)  12.224 ms  12.310 ms  12.401 ms
3  217.5.116.86 (217.5.116.86)  17.824 ms  17.996 ms  18.572 ms
4  80.156.162.158 (80.156.162.158)  18.122 ms  18.220 ms  18.314 ms
5  ae5-2074.ams10.core-backbone.com (81.95.2.138)  22.808 ms  23.744 ms  25.571 ms
6  core-backbone.global-layer.com (80.255.15.206)  31.128 ms  29.985 ms  30.050 ms
7  37.123.210.79 (37.123.210.79)  190.199 ms  132.735 ms  183.054 ms
8  164.162.152.213.in-addr.arpa (213.152.162.164)  26.676 ms  25.597 ms  26.816 ms

A bit high for that nameless router there. Similar for you, 137 ms. Maybe the problem is there.

[arteryshelby 25]

22 hours ago, OpenSourcerer said:

What I can confirm from my end:

$ sudo traceroute -T ancha.airvpn.org
traceroute to ancha.airvpn.org (213.152.162.164), 30 hops max, 60 byte packets
1  _gateway (192.168.110.1)  1.226 ms  1.583 ms  1.894 ms
2  p3e9bf2fc.dip0.t-ipconnect.de (62.155.242.252)  12.224 ms  12.310 ms  12.401 ms
3  217.5.116.86 (217.5.116.86)  17.824 ms  17.996 ms  18.572 ms
4  80.156.162.158 (80.156.162.158)  18.122 ms  18.220 ms  18.314 ms
5  ae5-2074.ams10.core-backbone.com (81.95.2.138)  22.808 ms  23.744 ms  25.571 ms
6  core-backbone.global-layer.com (80.255.15.206)  31.128 ms  29.985 ms  30.050 ms
7  37.123.210.79 (37.123.210.79)  190.199 ms  132.735 ms  183.054 ms
8  164.162.152.213.in-addr.arpa (213.152.162.164)  26.676 ms  25.597 ms  26.816 ms

A bit high for that nameless router there. Similar for you, 137 ms. Maybe the problem is there.

Its normal for router to not answer to ICMP packets with high priority, nothing to worry about.
ICMP is send to routing-engine while fowarding is done in asic hardware. As long as the target has normal ping / no loss, thats nothing to be conserned about.

However, the initial trace of blancken shows loss at the target, which indicates loss on the back-route from server --> home dsl, or maybe the server itself, hard to tell without any conrect traceroutes from both sides to multiple targets within  both destinations.

 

[OpenSourcerer 1442]

2 hours ago, arteryshelby said:

Its normal for router to not answer to ICMP packets with high priority, nothing to worry about.

Be advised of the -T switch to traceroute.

-T, --tcp
             Use TCP SYN for probes

If a router needs 150 ms on average to answer to TCP connections, this is something to be aware of. I've given up using ICMP for traceroutes because of the relatively high block rate. Some hops in between simply don't answer.

[arteryshelby 25]

23 minutes ago, OpenSourcerer said:

Be advised of the -T switch to traceroute.

-T, --tcp
             Use TCP SYN for probes

If a router needs 150 ms on average to answer to TCP connections, this is something to be aware of. I've given up using ICMP for traceroutes because of the relatively high block rate. Some hops in between simply don't answer.

Keep in mind that the same principial applies, router answer every packet directly send to the router (e.g. not forwarding) in software by the cpu. It does not matter if you use ICMP/UDP or TCP in a traceroute for this. So the same high latency) might be observed.
 

[OpenSourcerer 1442]

Of course, I never denied it. But I reject your shrugged-off "nothing to worry about". There does seem to be a connectivity bottleneck if a connection must be IGPed through Liberty Global's backbone. If I do these tests with other servers, most of which take a route through Cogent, no problem.

[arteryshelby 25]

My input was just taking your traceroutes into consideration.
The original trace shows indeed loss on the target which might high server load or something else.

All i said was that the internal gateway of global layer (i think you mixed up global layer and liberty global?) 37.123.210.79 (37.123.210.79)  190.199 ms  132.735 ms  183.054 ms
is nothing to be conserned about in general.

So "nothing to worry about" just referenced to router answering UDP/ICMP/TCP packet for traceroute, not the initial problem - might have come accros wrong

 

Quote

A bit high for that nameless router there. Similar for you, 137 ms. Maybe the problem is there.

[BitWanderer 0]

The next morning it seemed the packet loss was gone, but later that day it came back.
Ancha was just not stable. So I switched to the server Merga and we are on 0% packet loss since.

There was definitively something wrong with Ancha, but after changing server it works for me.