[chrony-users] Many servers became unreachable |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
Hi,
I have a strange situation with chronyd on our company network.
We have a small network with a Debian server, which runs chrony (version
1.24 from Debian squeeze) amongst other things. Chrony is configured to use
3 upstream time servers.
That setup has worked nicely for quote some time, but today suddenly it
failed: chrony can't connect to its upstream servers anymore, and I have no
idea why. I added three servers from the Debian pool; 3 of those are also
unreachable, 1 fortunately still works. Output from "chronyc sources":
210 Number of sources = 7
MS Name/IP address Stratum Poll LastRx Last sample
============================================================================
^? ntp1.belbone.be 0 7 10y +0ns[ +0ns] +/- 0ns
^? ntp1.telenet-ops.be 0 7 10y +0ns[ +0ns] +/- 0ns
^? daedalus.belnet.be 0 7 10y +0ns[ +0ns] +/- 0ns
^? 79.132.231.103.static.edp 0 7 10y +0ns[ +0ns] +/- 0ns
^? ssh2.ulyssis.student.kule 0 7 10y +0ns[ +0ns] +/- 0ns
^* rumst.verbert.be 2 6 49 -28ms[-2397us] +/- 33ms
^? 79.132.231.104.static.edp 0 7 10y +0ns[ +0ns] +/- 0ns
My first thought was an error in our firewall, our perhaps a firewall at our
ISP. But then 185.77.199.1 wouldn't work. Also, I tried "ntpdate -q
ntp1.belbone.be" and that *does* work. And it seems the other servers do
reply, but only once, as can be seen from this tcpdump trace:
$ sudo tcpdump -i eth0 tcp port 123 or udp port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:35:59.534560 IP rack02.tresco.41820 > ntp1.telenet-ops.be.ntp: NTPv3,
Client, length 48
17:35:59.559284 IP ntp1.telenet-ops.be.ntp > rack02.tresco.41820: NTPv3,
Server, length 48
17:35:59.559392 IP rack02.tresco.41820 > ntp1.telenet-ops.be.ntp: NTPv3,
Client, length 48
17:35:59.583403 IP ntp1.telenet-ops.be.ntp > rack02.tresco.41820: NTPv3,
Server, length 48
17:35:59.583462 IP rack02.tresco.41820 > ntp1.telenet-ops.be.ntp: NTPv3,
Client, length 48
17:35:59.607389 IP ntp1.telenet-ops.be.ntp > rack02.tresco.41820: NTPv3,
Server, length 48
17:35:59.607479 IP rack02.tresco.41820 > ntp1.telenet-ops.be.ntp: NTPv3,
Client, length 48
17:35:59.631380 IP ntp1.telenet-ops.be.ntp > rack02.tresco.41820: NTPv3,
Server, length 48
17:35:59.734705 IP rack02.tresco.41820 > daedalus.belnet.be.ntp: NTPv3,
Client, length 48
17:35:59.758341 IP daedalus.belnet.be.ntp > rack02.tresco.41820: NTPv3,
Server, length 48
17:35:59.758392 IP rack02.tresco.41820 > daedalus.belnet.be.ntp: NTPv3,
Client, length 48
17:35:59.781458 IP daedalus.belnet.be.ntp > rack02.tresco.41820: NTPv3,
Server, length 48
17:35:59.781514 IP rack02.tresco.41820 > daedalus.belnet.be.ntp: NTPv3,
Client, length 48
17:35:59.805471 IP daedalus.belnet.be.ntp > rack02.tresco.41820: NTPv3,
Server, length 48
17:35:59.805513 IP rack02.tresco.41820 > daedalus.belnet.be.ntp: NTPv3,
Client, length 48
17:35:59.860138 IP daedalus.belnet.be.ntp > rack02.tresco.41820: NTPv3,
Server, length 48
17:36:01.540042 IP rack02.tresco.ntp > ntp1.belbone.be.ntp: NTPv3, Client,
length 48
17:36:03.861352 IP rack02.tresco.ntp > rumst.verbert.be.ntp: NTPv3, Client,
length 48
17:36:03.861373 IP rack02.tresco.ntp > 79.132.231.104.static.edpnet.net.ntp:
NTPv3, Client, length 48
17:36:03.861382 IP rack02.tresco.ntp > 79.132.231.103.static.edpnet.net.ntp:
NTPv3, Client, length 48
17:36:03.861393 IP rack02.tresco.ntp > ssh2.ulyssis.student.kuleuven.be.ntp:
NTPv3, Client, length 48
17:36:03.861401 IP rack02.tresco.ntp > daedalus.belnet.be.ntp: NTPv3,
Client, length 48
17:36:03.861409 IP rack02.tresco.ntp > ntp1.telenet-ops.be.ntp: NTPv3,
Client, length 48
17:36:03.894164 IP rumst.verbert.be.ntp > rack02.tresco.ntp: NTPv3, Server,
length 48
17:36:03.894312 IP rack02.tresco.ntp > rumst.verbert.be.ntp: NTPv3, Client,
length 48
17:36:03.927595 IP rumst.verbert.be.ntp > rack02.tresco.ntp: NTPv3, Server,
length 48
17:36:03.927707 IP rack02.tresco.ntp > rumst.verbert.be.ntp: NTPv3, Client,
length 48
17:36:03.962826 IP rumst.verbert.be.ntp > rack02.tresco.ntp: NTPv3, Server,
length 48
17:36:03.963200 IP rack02.tresco.ntp > rumst.verbert.be.ntp: NTPv3, Client,
length 48
17:36:03.993066 IP rumst.verbert.be.ntp > rack02.tresco.ntp: NTPv3, Server,
length 48
17:36:03.993352 IP rack02.tresco.ntp > rumst.verbert.be.ntp: NTPv3, Client,
length 48
17:36:04.024304 IP rumst.verbert.be.ntp > rack02.tresco.ntp: NTPv3, Server,
length 48
17:36:09.540677 IP rack02.tresco.ntp > ntp1.belbone.be.ntp: NTPv3, Client,
length 48
17:36:13.862246 IP rack02.tresco.ntp > 79.132.231.104.static.edpnet.net.ntp:
NTPv3, Client, length 48
17:36:13.862260 IP rack02.tresco.ntp > 79.132.231.103.static.edpnet.net.ntp:
NTPv3, Client, length 48
17:36:13.862267 IP rack02.tresco.ntp > ssh2.ulyssis.student.kuleuven.be.ntp:
NTPv3, Client, length 48
17:36:13.862274 IP rack02.tresco.ntp > daedalus.belnet.be.ntp: NTPv3,
Client, length 48
17:36:13.862281 IP rack02.tresco.ntp > ntp1.telenet-ops.be.ntp: NTPv3,
Client, length 48
17:36:17.541421 IP rack02.tresco.ntp > ntp1.belbone.be.ntp: NTPv3, Client,
length 48
17:36:21.863260 IP rack02.tresco.ntp > 79.132.231.104.static.edpnet.net.ntp:
NTPv3, Client, length 48
17:36:23.863232 IP rack02.tresco.ntp > 79.132.231.103.static.edpnet.net.ntp:
NTPv3, Client, length 48
17:36:23.863392 IP rack02.tresco.ntp > ntp1.telenet-ops.be.ntp: NTPv3,
Client, length 48
17:36:25.863211 IP rack02.tresco.ntp > ssh2.ulyssis.student.kuleuven.be.ntp:
NTPv3, Client, length 48
17:36:25.863359 IP rack02.tresco.ntp > daedalus.belnet.be.ntp: NTPv3,
Client, length 48
17:36:25.863507 IP rack02.tresco.ntp > ntp1.belbone.be.ntp: NTPv3, Client,
length 48
17:36:29.864156 IP rack02.tresco.ntp > 79.132.231.104.static.edpnet.net.ntp:
NTPv3, Client, length 48
17:36:31.864115 IP rack02.tresco.ntp > 79.132.231.103.static.edpnet.net.ntp:
NTPv3, Client, length 48
We have another server at another location which uses the same version of
Debian with the same version of Chrony using the same servers; that one
still runs without problems.
Is it possible that a number of servers are actively blocking us? But then
why do "ntpdate -q" and chrony on our other server still work?
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.