Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a problem setting up NTP to maintain time on a stand-alone network. This will be an island time-zone. The problem is that the time drifts apart, even after they have been initially synchronised.

There are two redundant NTP servers running RHEL 5.4 and several Windows XP clients. The requirements are that the network syncs to server A whilst server B acts as a backup. We do have a GPS that acts as a time server controlling both server A and server B, but it is not always available. When the GPS is present, both servers sync to the GPS.

The XP clients seem to divide into two groups once the servers drift apart; with some following server A and others server B.

How can I prevent my two servers from drifting apart?

Can I control which server the XP clients follow?

The two ntp.conf files are as follows

ntp.conf for Server A (10.203.224.13)

# Tweek NTP's behavior
tinker panic 0 step 0.01 stepout 64

# GPS
server 10.203.220.12 burst iburst minpoll 4 maxpoll 6

# Server A
server 10.203.224.13 burst iburst minpoll 4 maxpoll 6

# Server B
server 10.203.224.14 burst iburst minpoll 4 maxpoll 6

# Configure the local clock to serve from
server 127.127.1.1
fudge 127.127.1.1 stratum 11

# Establish the drift file location
driftfile /etc/ntp.drift 

ntp.conf for Server B (10.203.224.14)

# Tweek NTP's behavior
tinker panic 0 step 0.01 stepout 64

# GPS
server 10.203.220.12 burst iburst minpoll 4 maxpoll 6

# Server A
server 10.203.224.13 burst iburst minpoll 4 maxpoll 6

# Server B
server 10.203.224.14 burst iburst minpoll 4 maxpoll 6

# Configure the local clock to serve from
server 127.127.1.1
fudge 127.127.1.1 stratum 13

# Establish the drift file location
driftfile /etc/ntp.drift

On Server A

[root@serverA]# ntpq -p

     remote           refid          st t when poll reach   delay   offset  jitter
==============================================================================
 10.203.220.12   .INIT.          16 u    -   64    0    0.000    0.000   0.000
 10.203.224.13   .INIT.          16 u    -   64    0    0.000    0.000   0.000
 10.203.224.14   LOCAL(1)        14 u   27   64  377    0.312  359.753   0.289
*LOCAL(1)       .LOCL.          11 l   55   64  377    0.000    0.000   0.001

On Server B

[root@serverB]# ntpq -p

     remote           refid          st t when poll reach   delay   offset  jitter
==============================================================================
 10.203.220.12   .INIT.          16 u    -   64    0    0.000    0.000   0.000
 10.203.224.13   LOCAL(1)        12 u   55   64  377    0.346  -359.56   0.107
 10.203.224.14   .INIT.          16 u    -   64    0    0.000    0.000   0.000
*LOCAL(1)       .LOCL.          13 l   54   64  377    0.000    0.000   0.001
share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

On server A, remove the lines pointing to itself and server B, leaving only the "fudge" local clock line and the GPS. On server B, remove the "fudge" line and the server B line, leaving only the server A line and the GPS.

The idea is that server A should use the GPS if it's available, otherwise it should trust its own clock. Server B should use server A, howsoever server A is getting time, or the GPS. If server B is allowed to trust itself, it will advertise a reliable time source to its clients, even though that time is different from server A's - which is what you're seeing.

share|improve this answer
    
Thanks MadHatta. Will Server B still be able to send its time if Server A is offline? –  DanS Nov 13 '12 at 14:28
    
Yes, provided the GPS is online; but if neither is available, it won't. If you want that, you have a problem; you've asked for two independent clock sources which don't drift with respect to each other, and that requires better hardware than motherboard clocks. –  MadHatter Nov 13 '12 at 15:00
    
Not really an ideal situation, but as a failure case. We need to ensure that the WinXP clients follow the available server. –  DanS Nov 13 '12 at 16:49
    
And if you'd constructed a situation with only one available server at any given time, that'd be no issue. Your problem is that you can at some times have two available servers, and then you're surprised that some clients follow each. –  MadHatter Nov 13 '12 at 19:15
    
Can the tos orphan command be used in this case so Server B can serve its own (inaccurate) time but only if there is no better option? –  DanS Nov 14 '12 at 16:12
show 1 more comment

There are a number of problems here:

  1. The GPS device isn't working correctly. This is most likely a connectivity issue. Either a firewall is blocking the packets or it isn't listening on the correct interface or it can't reach a GPS signal or something similar. It could be that intermittent unavailability that you mentioned. If so, try to show an ntpq -p from when it's working.
  2. The GPS is stratum 16. When it's working, this should be 1. Anything higher than 11 is going to cause the same issue you are having because server A will trust it's local clock more than anything at 11 or higher.
  3. Server A is configured to get time from Server B and Server B is configured to get time from Server A. This kind of setup should be a peering relationship rather than a circular master/slave relationship. Use the peer keyword rather than the server keyword for this.
  4. Server A and Server B are both set up to use themselves as a time source via the ntp protocol. This is redundant and isn't working. Either the connection is failing or the current stratum is 16 and can't go any higher.
  5. Both servers have selected their own clocks as the most reliable time source (indicated by the * next to the LOCAL source. They have also both managed to connect to each other. I'm not sure why Server B didn't choose Server A as the best time source as it has the lowest stratum value but it's probably because it has a significantly higher jitter than the LOCAL time source.

Get the GPS working, change the two servers to peer with each other and remove the lines to get time from their own IP address. (The local clock is fine but adding in the latency of a network protocol for a local clock is silly.)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.