I'd be more inclined to believe peering is the root culprit (probably
transatlantic issues no less). Also, dig -6 ntplax7.ntppool.net only
uses IPv6 as the medium that makes a query to the DNS server. You'd want
dig AAAA ntplax7.ntppool.net to get the IPv6 address of the monitoring
station.
My Home Desktop's view:
C:\Users\Aelita>nslookup ntplax7.ntppool.net 8.8.8.8
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
Name: ntplax7.ntppool.net
Addresses: 2607:f238:2::17
207.171.3.17
View from my linux droplet in DigitalOcean's NYC3 Datacenter:
root@crius:~# dig AAAA ntplax7.ntppool.net
; <<>> DiG 9.10.3-P4-Ubuntu <<>> AAAA ntplax7.ntppool.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55011
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 15
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ntplax7.ntppool.net. IN AAAA
;; ANSWER SECTION:
ntplax7.ntppool.net. 7200 IN AAAA 2607:f238:2::17
;; AUTHORITY SECTION:
ntppool.net. 168719 IN NS anyns.pch.net.
ntppool.net. 168719 IN NS ns2.us.bitnames.com.
ntppool.net. 168719 IN NS ns-g2.bitnames.com.
ntppool.net. 168719 IN NS ns3.us.bitnames.com.
ntppool.net. 168719 IN NS ns1.us.bitnames.com.
ntppool.net. 168719 IN NS ns2.eu.bitnames.com.
ntppool.net. 168719 IN NS ns-g1.bitnames.com.
ntppool.net. 168719 IN NS ns1.eu.bitnames.com.
;; ADDITIONAL SECTION:
ns1.eu.bitnames.com. 168719 IN A 94.242.223.200
ns1.eu.bitnames.com. 168719 IN AAAA 2a01:608:ffff:a011::200
ns1.us.bitnames.com. 168719 IN A 207.171.3.21
ns1.us.bitnames.com. 168719 IN AAAA 2607:f238:2::53:21
ns2.eu.bitnames.com. 168719 IN A 92.243.1.21
ns2.eu.bitnames.com. 168719 IN AAAA
2001:4b98:dc0:41:216:3eff:fe3f:42c5
ns2.us.bitnames.com. 168719 IN A 107.170.182.174
ns3.us.bitnames.com. 168719 IN A 207.171.7.85
anyns.pch.net. 70923 IN A 204.61.216.4
anyns.pch.net. 157321 IN AAAA 2001:500:14:6004:ad::1
ns-g1.bitnames.com. 168719 IN A 208.78.70.20
ns-g1.bitnames.com. 168719 IN AAAA 2001:500:90:1::20
ns-g2.bitnames.com. 168719 IN A 192.5.4.1
ns-g2.bitnames.com. 168719 IN AAAA 2001:500:2e::1
;; Query time: 94 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun May 21 13:58:47 EDT 2017
;; MSG SIZE rcvd: 544
As far as the claim that the problem inherently resides with the
monitoring node because of RIPE Atlas probes goes, that would be foolish
to say the least. Peering issues are a very real thing. Only the windows
desktop had a missed probe on one of the hops (timed out) and the hop
before and after it were with the same network (Comcast, who is my ISP).
I'm really inclined to suspect transatlantic issues at this time. If
someone has a server they can probe over into the UK from somewhere like
Ashburn, Virginia: please probe with a traceroute over IPv6. North
America Peering seems solid at the moment.
Lucas
On 5/21/2017 12:45 PM, Daniel 'hackbyte' Mitzlaff wrote:
Strangely my stratum2 seems to be still reachable for the monitoring
station.
But trying to get IPv6 adresses for it already fails:
root@heraklon:~# date && dig -6 ntplax7.ntppool.net
Sun May 21 17:42:37 UTC 2017
; <<>> DiG 9.9.5-9+deb8u11-Debian <<>> -6 ntplax7.ntppool.net
;; global options: +cmd
;; connection timed out; no servers could be reached
(from my host listedon.ignorelist.com /
http://www.pool.ntp.org/user/ddsc4jcbx37okrcgvgob9 )
Greetings from Hamburg,
hacky
2017-05-21 18:52 GMT+02:00 Adam Jacobs <[email protected]>:
My servers have been dropped from the pool as well, but connectivity
appears fine.
Agree, seems to be a monitoring problem.
Someone should ask Ask about it (I've been waiting years to use that line
:)
On May 21, 2017, at 09:50, Marco Senft <[email protected]> wrote:
Hello everybody,
According to https://status.ntppool.org/, the number of active IPv6
servers went down today from ~1150 servers before 08:40 UTC to a bit more
than 800 within one hour. Two of the servers removed from the pool are
operated by me, and after checking my infrastructure I cannot confirm any
problems on my side. I suspect something to be wrong with the monitoring
system rather than one third of all pool servers concurrently having a
problem.
If I’m right, the monitoring system is ntplax7.ntppool.net. I created a
RIPE Atlas measurement of this system’s connectivity which you can look at
here:
https://atlas.ripe.net/measurements/8758007/#!probes
This measurement also shows about one third of all probes not being able
to reach the monitoring system.
Can somebody confirm a problem with IPv6 pool monitoring?
Best regards,
marco
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
