Not able to add new server: IPv6 2003đź…°47f:abe4::1

Server operators
#1

I currently got the problem that I can´t add any server with an IPv6 adress, which is part of T-Systems (German Telekom).

e.g. If I try to add 2003:a:47f:abe4::1 to the pool, the monitoring/probe will not get a valid response and does not allow to add it to the pool.

Same is true for e.g. 2003:a:157f:b76d::2

Does anyone know what to do here?

It was once in the pool, but I had to remove it due to not being reachable anymore by the monitoring system.

https://www.ntppool.org/scores/2003:a:157f:b76d::2

Any ideas?

#2

Hi @kashra and welcome. I’ve put the first address into two different “try my NTP server” sites and they both report connectivity ok.

What output does “mtr --udp -P 123 2604:1380:2:6000::15” give you? (traces route over UDP port 123 to the monitoring server)

#3

It does output this error:

mtr: mtr-packet reported invalid argument

I tried using regular ICMP probes, which work just fine, but mtr does not send udp probes at all.
I tried several machines with several linux flavors on them like Ubuntu server 18.04, 19.10 and 20.10

IPv6 however is configured correctly and works just fine.

#4

Hi, I did some digging in the code for the error message you get when trying to add the server and the pool code appears to be calling this url: https://trace2.ntppool.org/ntp/2003:a:157f:b76d::2

Which returns this error:

{“Op”:“read”,“Net”:“udp”,“Source”:{“IP”:“2604:1380:2:6000::15”,“Port”:59995,“Zone”:""},“Addr”:{“IP”:“2003:a:157f:b76d::2”,“Port”:123,“Zone”:""},“Err”:{}}

With my own IP I get this output:

{“Time”:“2020-05-19T21:36:08.130390579Z”,“ClockOffset”:261505,“RTT”:78756427,“Precision”:119,“Stratum”:1,“ReferenceID”:1347441408,“ReferenceTime”:“2020-05-19T21:35:54.039874817Z”,“RootDelay”:0,“RootDispersion”:1205444,“RootDistance”:40583657,“Leap”:0,“MinError”:0,“KissCode”:"",“Poll”:8000000000}

Given the “test my NTP server” sites work fine, I guess the restrictions on your NTP server are too strict. There’s a page here with suggestions for how to configure. If that doesn’t help could you post the relevant lines from your ntp config file please.

1 Like
#5

Well, the problem is, the servers worked just fine in the past, up to beginning of Feb. 2020 and stopped working all at once, with no changes made to the config for over a year by now.
In addition to that my other servers are syncing to them just fine + they are in active production use with my customers, there are no restrictions which could cause this, even following the recommended config.

I tried this: Connected server to a Vodafone Business Cable static IPv6 subnet, see here:

https://www.ntppool.org/scores/2a02:8106:19::1

Works just fine.
The very same server hooked to a T-Systems (German Telekom IP) at 2003:a:157f:b76d::0

No luck at all.

Can anyone add/test 2003:a:157f:b76d::0 to verify?

I did ntpsweep -l 2003:a:157f:b76d::0 from several locations, works fine.

#6

Three NTP servers in 2003:a::./32 stopped responding to the Newark montior’s NTP queries at about the same time: 2020-01-28 10:18. They are still unreachable from Newark.

traceroute6 can only probe up to telia:
1 gateway (2604:1380:2:6000::14) 71.010 ms 70.963 ms 70.915 ms
2 0.xe-0-0-17.dsr2.ewr1.packet.net (2604:1380:2:64::slight_smile: 5.684 ms 5.660 ms 5.617 ms
3 0.ae3.bsr1.ewr1.packet.net (2604:1380:2:102::1d2) 1.745 ms 0.ae2.bsr2.ewr1.packet.net
(2604:1380:2:102::1d4) 1.162 ms 0.ae2.bsr1.ewr1.packet.net (2604:1380:2:102::1d0) 1.690 ms
4 0.et-0-0-1.bsr1.ewr2.packet.net (2604:1380:2:102::291) 33.846 ms 33.825 ms 33.787 ms
5 nyk-b2-link.telia.net (2001:2000:3080:1bdf::1) 1.224 ms 1.202 ms 1.173 ms
6 ldn-b4-v6.telia.net (2001:2000:3018:b4::1) 77.372 ms 75.789 ms 79.937 ms
7 * * *

It looks like an IPv6 routing problem. What does the output from
traceroute6 2604:1380:2:6000::15
show?

1 Like
#7

It shows:

trace6

#8

per traceroute man page: “!N means network unreachable”
2003:0:1504:e400::2 is Deutsche Telecom.

You should ask your ISP for help. IPv6 routing problems are not rare.

1 Like
#9

I’ve asked Packet if it’s possible for them to route this a different path than Telia, too.

It’s sorta nice to for once have an obvious and clear cut (I hope) routing problem rather than the random packet drops. :slight_smile: