Unable to join pool: IPv4 fails, IPv6 OK, external tests pass

For about a week, I’ve tried and failed to add the IPv4 address of a server to the pool.

I get “Could not check NTP status” every time. The first time, I added the server by name (it has both addresses). The IPv6 worked, the IPv4 failed. Since then, I’ve tried several times to add the server by IPv4 address. Same error.

This message is not helpful; there is no information in it to allow diagnosis.

What I do know is that this NTP Test Tool (IPv4 & IPv6) is happy with both addresses. So it’s not a local firewall or configuration issue.

I sent a note to the “if you have trouble with the system” e-mail address on the joining the pool page, but no response.

I don’t know how to proceed. Is whatever test is behind the “Could not check NTP status” message broken? Its server down? A routing issue from there to here? Is it getting a response from my server that it doesn’t like? No response at all? Or it’s not even trying to talk to it?

If anyone wants to look at this, the hostname is ntp.litts.net, the IPv4 address is 96.233.62.59.

I’d rather not give up, but with nothing to go on, doesn’t seem to be much choice.

It shouldn’t be this hard to volunteer.

1 Like

I’m just starting to look into this for you. Some quick questions:

  • Are you certain both IP’s point to the same server?
  • Your reverse DNS records are different (IPv4 is ns1, and IPv6 is ntp). Are you sharing multiple services on IPv4 and dedicating IPv6 to NTP?
  • Your IPv4 looks like it’s routed through Verizon, and IPv6 through Hurricane Electric. Are you using Tunnelbroker.net?

Some of those items likely don’t matter, but could be helpful to know.

Here’s what I see for ntp.litts.net:

You’re absolutely right. How long ago did you send the email asking for support? Some of us in the community here are trying to figure out where those emails go, and as far as we can tell, there’s only one person who handles everything.

There are a lot of great folks here in the community, and we’ll work to help get you set up.

That may likely not the reason of the trouble, but having multiple PTR records in the reverse zone for the same name is not recommended:

$ host 96.233.62.59
59.62.233.96.in-addr.arpa domain name pointer femto.sb.litts.net.
59.62.233.96.in-addr.arpa domain name pointer ns1.v4.litts.net.
59.62.233.96.in-addr.arpa domain name pointer postq.v4.sb.litts.net.
59.62.233.96.in-addr.arpa domain name pointer postq.sb.litts.net.
59.62.233.96.in-addr.arpa domain name pointer ntp.litts.net.
59.62.233.96.in-addr.arpa domain name pointer ns1.litts.net.

Thanks for looking into this for me.

Answers:

I am dead certain that both IPs point to the same server. Here is its config (the 172 address is an inside NAT address for 96.233.62.59:123):
IP Addrs

  • 172.22.149.45/24
  • 2001:470:8f95:943::45/64
  • fe80::3b:eff:fefd:5c7e/64

The router’s map:
ip nat inside source static udp 172.22.149.45 123 96.233.62.59 123 extendable no-payload

The reverse dns is complicated. “Not recommended” is a matter of point of view. (you mean multiple PTRs (names) for 1 IP address) When IP addresses were cheap/free, it was easy enough to dedicate one per service. That’s not been the case for a long time. And as an individual, I have many more services than I’m willing to buy IP addresses for.

If the NTP pool registration checker is insisting on one PTR/address, it’s broken.

Probably more than you want to know, but it looks like this: I use distinct names so I can shuffle services around. At times I have PTRs for all the services, but “modern” resolvers tend to only return one. At random. And that upsets some SMTP servers. So… some of my static IPs end up with one reverse name, but many forward. NTP should not be one of those services. There are other services that demand a valid PTR - but can resolve all the PTRs and are happy if one matches. And due to technical issues with the server and the way the other IP addresses that I own are allocated, I don’t have an available dedicated (or 1 PTR) IP address for this server.

Yes, 96.233.62.59 is static via Verizon FiOS (fiber) for Business.

Yes, despite years of promises, Verizon won’t provide IPv6 even with business class service, so my IPv6 is via hurricane (tunnelbroker.net). I have a /48. My gateway router terminates the tunnel, so inside everything thinks it has native IPv6.

None of this should prevent this server from joining the pool. My other hosts happily talk to the pool servers, so NTP traffic gets in and out from all over the net.

To me, this seems like an issue with the “check” that the registration page is doing.

I have two issues with it:

  1. it’s not accepting my server :frowning:
  2. The error message is useless

I started on 25-Dec (the server was my holiday present to myself :-). I got a reply from ask to a dead link note I sent at abiout the same time, but nothing on this issue, even after a follow-up. I know he’s a one-person show…

That’s one of @Ask private email addresses and it could be that he is currently on vacation.
Thereis help@ntppool.org which goes to the ticketsystem (don’t know on which website it mention) and there is on the mange site, where you add your ip address the email server-owner-help@ntppool.org which also goes into the ticket system.

Please create an account under manage-beta.grundclock.com and try to add your server there.
Maybe the system will accept the IPv4 addresse.

I started monitoring the IPv4 address from monsjc2. I don’t see any “background NTP pool” queries heading to 96.233.62.59. Also when I examine the NTP pool account I see the IPV6 address, but not the IPv4.

Manual NTP queries from monsjc2 work.

Are you certain that the IPv4 address was added to the account?

They work fine:

https://servertest.online/ntp

IPv4 test results
Result:OK
Server:96.233.62.59
Stratum:1
Offset:0.001688
Delay:0.13385

IPv6 test results
Result:OK
Server:2001:470:8f95:943::45
Stratum:1
Offset:0.002097
Delay:0.11902

Maybe some routing glitch somewhere?

We have IPv4 and IPv6 blocks routed via Verizon – last week, we had the same issue as OP when attempting to add the IPv4 address for our NTP server.

The solution was to re-try in rapid succession and eventually it will “work”.

We tried via the Grundclock site and experienced the same issue as in the production site – where it would only sometimes successfully pick up the IPv4 server (but always work on IPv6)

It’s probably worth highlighting that we’re not FIOS customers, but rather have a dedicated enterprise circuit from Verizon (so our IPv6 address is routed via Verizon as well – and not a tunnel)

EDIT: Here are the server details, if helpful: pool.ntp.org: AP Foundation's pool servers

I’ve watched the IPV4 address 96.233.62.59 for the past week and found no evidence that the NTP server was being polled by the monsjc2 NTP pool monitoring system.
The server doesn’t show up in the user account either. [IPv6 is there.]

Would the server admin try to re-add the IPv4 address?

1 Like

Came across the same issue today. Can add IPv6 cannot add IPv4.

Seems the monitor has issues reaching some networks or prefixes ?

Have the same issue right now for mexico zone.

I opened 18 tabs in the browser and had the input form primed to submit the server’s hostname. Submitted all 18 in rapid succession. No dice. 18/18 times it offers to add IPv6 but IPv4 is "Could not check NTP status "

Sent a ticket to server-owner-help@ntppool.org

The main monitoring server, monsjc2.ntppool.net, showed no IPv4 traffic when the add IPv4 server was attempted. I’m not familiar with the front-end software & can’t investigate.

Hi everyone!

This thread (and some similar emails in the weeks before) made me realize that it doesn’t help much if the monitoring system has multiple monitors on different networks if a single monitor is still the gatekeeping for adding a new server to the system!

Since this evening the beta system will check new additions from multiple monitors as well (and add the NTP server as long as any monitor gets a healthy NTP response).

@tlhackque (and others), it’d be great if you can try it out. :slight_smile:

6 Likes

Hmmm, looks like someone added it for me. It seems to be happy with a score of 20 on both IPv4 and IPv6 !

It still would be helpful if when there are failures, the details were provided - e.g. where the probe was coming from, a traceroute, etc. We can’t do anything unless we can provide a details to our ISPs. And of course, the pool monitors could also simply raise the issue from their end. (e.g. if I’m reachable from 1 or 2 monitors, but not all, then issue is in the network. Well, unless I’m blocking some IP addresses - which I’m currently not, for NTP.)

@ stevesommars: Note that I could not add the server to the account - that was the problem :slight_smile:

Thanks everyone for all the support, and @ask for improving the process.

Oh, and grundclock also said “Could no check status”.

Just for fun I tried adding this system there today - and it still does.

Anyhow, I’m happy now - more importantly, my server is.

I have also noticed for several days now that the beta system will not allow me to add a server that the production system does. I’ve mostly tested with IPv4 address 96.9.224.210 but just now I also tried with hostname ntp.davehart.net.

Most often, the failure has been a 500 Server Error page, but I’ve also seen “unable to check NTP status”.