32116 - TPD Server's Time Has Gone Backwards

Alarm Group:

PLAT

Description:

This alarm indicates the server's current time precedes the timestamp of the last known time the servers time was good.

Severity:

Critical

Instance:

May include AlarmLocation, AlarmId, AlarmState, AlarmSeverity, and bindVarNamesValueStr

HA Score:

Normal

Auto Clear Seconds:

0 (zero)

OID:

tpdNTPTimeGoneBackwards

Alarm ID:

TKSPLATCR17

Recovery:

1. Verify NTP settings and NTP sources are providing accurate time.
   1. Ensure ntpd service is running with correct options: -x -g
   2. Verify the content of the /etc/ntp.conf file is correct for the server.
   3. Type /usr/sbin/ntpdc -c sysinfo to check the current state of the ntpd daemon.
   4. Verify the ntp peer configuration; execute ntpq -p; and analyze the output. Verify peer data, such as tally code (first column before remote), remote, refid, stratum (st), and jitter, are valid for server.
   5. Execute ntpstat to determine the ntp time synchronization status. If not synchronized or the stratum is not correct for server, then ping the ntp peer to determine if peer can be reached.
2. If ntp peer is reachable, then restart the ntpd service.
3. If problem persists, then a reset the NTP date may resolve the issue.

   Note:

   Before resetting the ntp date, the applications may need to be stopped; and subsequent to the ntp reset, the application restarted.
   1. Reset ntpd:
   • sudo service ntpd stop
   • sudo ntpdate <ntp server ip>
   • sudo service ntpd start
4. Conform to recommended NTP topology and strategy.
   • No fewer than tree references are recommended.
   • If selecting a different number, the number should be odd.
   • No intermediate reference should be a virtualized server.
   • Additional recommendations and topology are available in NTP Strategy section in the DSR Hardware and Software Installation 1/2 customer document
5. If the problem persists, it is recommended to contact unresolvable-reference.htm#GUID-DD0927BD-FD0B-4CEB-86E9-98A33C12D4E0.