NTP Packetloss

[#1]

Hi,

I was hoping someone could help with packetloss for UDP 123 traffic (NTP) It seems when it hits BT's core they start dropping packets. 

This test was run using the follwing in linx. The IP tested is the station for NTP Pool.

mtr -C 139.178.64.42 --udp --port 123

Thanks.

[#2]

You perhaps aren't seeing quite what you think you're seeing.

The mtr port option isn't valid for UDP, so these are just the usual vaguaries of udp traceroute. If you run the same test with the default ICMP packets, you'll see different "loss" rates for different routers. None of which means that there is any packet loss along the route, as such.

I'm not sure why you need to, but it's hard to get a figure for any real packet loss specifically to and from the NTP port because if there is a server running on it, it won't respond to empty packets, only properly formed NTP requests.

So I can ping another UDP port at that ip address:

Starting Nping 0.7.01 ( https://nmap.org/nping ) at 2020-02-29 16:34 GMT
SENT (0.0069s) UDP 192.168.1.75:53 > 139.178.64.42:58995 ttl=64 id=963 iplen=28 
RCVD (0.0905s) ICMP [139.178.64.42 > 192.168.1.75 Port unreachable (type=3/code=3) ] IP [ttl=51 id=19035 iplen=56 ]

Max rtt: 83.622ms | Min rtt: 83.622ms | Avg rtt: 83.622ms
Raw packets sent: 1 (28B) | Rcvd: 1 (56B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.01 seconds

But port 123 gives no response:

Starting Nping 0.7.01 ( https://nmap.org/nping ) at 2020-02-29 16:37 GMT
SENT (0.0074s) UDP 192.168.1.75:53 > 139.178.64.42:123 ttl=64 id=54387 iplen=28 

Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 1 (28B) | Rcvd: 0 (0B) | Lost: 1 (100.00%)
Nping done: 1 IP address pinged in 1.01 seconds

nmap, however, will confirm that the port is open and reachable:

Starting Nmap 7.01 ( https://nmap.org ) at 2020-02-29 16:39 GMT
Nmap scan report for monewr1.ntppool.net (139.178.64.42)
Host is up (0.083s latency).
PORT    STATE SERVICE
123/udp open  ntp
Nmap done: 1 IP address (1 host up) scanned in 0.42 seconds

Given the connectionless nature of UDP (note the ICMP response to the UDP ping above,) ordinary ICMP ping should give a good idea of whether there is any packet loss occurring between you and the NTP server you're interested in (assuming it is a single server...)

--- 139.178.64.42 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 83.895/84.189/84.455/0.174 ms

[#3]

Just to add, if you're experiencing problems, it could well be down to bufferbloat in the network.

[#4]

I was curious about this, and had a moment, so I set up a monitor in Dejal Simon (which is a handy MacOS application).

The connection is an ostensibly good Plusnet line, using their own Hub One: 9ms ping to their servers and a sync speed of  19999 / 79106.

I'm afraid I eschewed ethernet, so any and all issues are probably due to that. The horrors of low-latency full-signal 5Ghz wireless are truly beyond imagination. Although even if I had used a cable it would (obviously) be faulty, or some other application running on the same machine/LAN would be interferring with these teeny tiny packets. So make of the result what you will. But testing every 2 seconds from here seems to result in successful responses less than half the time, for whatever reason...

[#5]

Hi InterZoom,

Thanks for your reply's with this. Essentially that IP is the pool monitor and it checks members of the pool providing correct time reachable ext. My device keeps getting thrown out due to I/O Errors so im trying to find out if something inside plusnet's routing or even outside is effecting it.

If you take a look at the forums for the NTP pool https://community.ntppool.org/ you will see a few people have a simmilar issue although spread out around the world. 

This is the log of my connection https://www.ntppool.org/scores/81.174.133.68/log?limit=200&monitor=*

I have a server in Hertzer (germany) which does not have this issue.

Traceroute from Server

root@Ubuntu-1910-eoan-64-minimal ~ # traceroute 139.178.64.42
traceroute to 139.178.64.42 (139.178.64.42), 30 hops max, 60 byte packets
1 static.129.71.9.5.clients.your-server.de (5.9.71.129) 0.330 ms 0.295 ms 0.306 ms
2 core23.fsn1.hetzner.com (213.239.245.109) 0.421 ms core24.fsn1.hetzner.com (213.239.245.149) 0.469 ms core23.fsn1.hetzner.com (213.239.245.109) 0.415 ms
3 core1.fra.hetzner.com (213.239.229.77) 4.905 ms core1.fra.hetzner.com (213.239.203.153) 4.897 ms 4.986 ms
4 zayo.fra.ecix.net (62.69.146.139) 5.110 ms 5.105 ms 5.090 ms
5 ae1.cs1.fra9.de.eth.zayo.com (64.125.29.64) 82.301 ms 82.301 ms 82.287 ms
6 ae0.cs1.fra6.de.eth.zayo.com (64.125.29.54) 82.703 ms 81.037 ms 81.121 ms
7 ae2.cs1.ams17.nl.eth.zayo.com (64.125.29.59) 80.996 ms 80.976 ms 81.045 ms
8 ae0.cs1.ams10.nl.eth.zayo.com (64.125.29.80) 80.925 ms 81.020 ms 80.999 ms
9 ae2.cs1.lhr15.uk.eth.zayo.com (64.125.29.17) 81.001 ms 80.997 ms 80.984 ms
10 * * *
11 * * *
12 ae15.er1.lga5.us.zip.zayo.com (64.125.29.221) 81.048 ms 81.076 ms 81.055 ms
13 64.125.54.26.available.above.net (64.125.54.26) 129.226 ms 127.315 ms 127.280 ms
14 0.et-0-0-1.bsr2.ewr1.packet.net (198.16.6.237) 82.286 ms 82.785 ms 82.769 ms
15 0.ae2.dsr1.ewr1.packet.net (198.16.4.213) 102.658 ms 0.ae2.dsr2.ewr1.packet.net (198.16.4.215) 103.745 ms 98.045 ms
16 147.75.98.107 (147.75.98.107) 95.102 ms 147.75.98.105 (147.75.98.105) 102.830 ms 147.75.98.107 (147.75.98.107) 102.293 ms
17 monewr1.ntppool.net (139.178.64.42) 81.773 ms 81.726 ms 81.762 ms

From plusnet connection

traceroute to 139.178.64.42 (139.178.64.42), 30 hops max, 60 byte packets
1 router.local (192.168.93.1) 0.570 ms 0.573 ms 0.678 ms
2 195.166.130.248 (195.166.130.248) 11.179 ms 12.512 ms 12.481 ms
3 84.93.253.71 (84.93.253.71) 12.636 ms 84.93.253.67 (84.93.253.67) 12.785 ms 12.552 ms
4 195.99.125.136 (195.99.125.136) 13.687 ms 195.99.125.144 (195.99.125.144) 13.461 ms 195.99.125.136 (195.99.125.136) 13.420 ms
5 109.159.252.138 (109.159.252.138) 14.017 ms core4-hu0-1-0-1.faraday.ukcore.bt.net (195.99.127.50) 13.696 ms core2-hu0-1-0-1-1.colindale.ukcore.bt.net (195.99.127.9) 13.468 ms
6 166-49-209-194.eu.bt.net (166.49.209.194) 14.078 ms 195.99.127.66 (195.99.127.66) 12.095 ms 166-49-209-194.eu.bt.net (166.49.209.194) 19.440 ms
7 * * 166-49-209-194.eu.bt.net (166.49.209.194) 24.790 ms
8 * ae11.mpr2.lhr2.uk.zip.zayo.com (64.125.30.52) 24.623 ms 24.425 ms
9 ae11.mpr2.lhr2.uk.zip.zayo.com (64.125.30.52) 24.880 ms 13.743 ms 13.660 ms
10 * ae27.cs1.lhr11.uk.eth.zayo.com (64.125.30.236) 79.320 ms *
11 ae15.er1.lga5.us.zip.zayo.com (64.125.29.221) 79.386 ms * 80.492 ms
12 ae15.er1.lga5.us.zip.zayo.com (64.125.29.221) 81.579 ms 81.539 ms 81.496 ms
13 64.125.54.26.available.above.net (64.125.54.26) 79.907 ms 0.et-0-0-1.bsr2.ewr1.packet.net (198.16.6.237) 130.650 ms 130.606 ms
14 0.ae2.dsr1.ewr1.packet.net (198.16.4.213) 95.770 ms 0.et-0-0-1.bsr2.ewr1.packet.net (198.16.6.237) 130.530 ms 122.294 ms
15 147.75.98.107 (147.75.98.107) 90.526 ms 0.ae2.dsr2.ewr1.packet.net (198.16.4.215) 98.587 ms 98.465 ms
16 monewr1.ntppool.net (139.178.64.42) 82.847 ms 82.629 ms 83.020 ms

[#6]

It is pointing towards the difference in transatlantic carrier, isn't it?

But that will be tough to isolate as an ISP customer. (And could be more of a problem to be addressed by the monitor.)

I'd already noticed that the Hub One has a low MTU and reduced the client's, so probably not that.

Similar stats with 64s poll interval (and first poll not successful,) so unlikely to be straighforward rate-limiting.

ntp.plus.net is 100% success, as is uk.pool.ntp.org

Not sure I can shed any more light... but at least it helps to fill out your picture a bit.

( Although, clearly, I can't rule out wifi problems, and haven't yet tried tracerouting to somewhere irrelevant for you  🙄 😃  )

[#7]

---

difference in transatlantic carrier

---

Or, rather, the peering with that carrier.

[#8]

Thanks for your post @danb9 and apologies for the delayed staff response.

I'm sorry to see you're experiencing connection problems. I've been testing your line and the tests aren't showing any issues with your router getting a sync speed of 79.9mbps and no drops in the past 38 days.

To try to get to the bottom of this for you, what real world issues is this causing? Slow speeds, dropping connection etc?