NTP (Network Time Protocol) allows machines to synchronize their time and date with a master server that is always considered to be accurate. There are several reasons why accurate time and date on the NetScaler are important:
- Authentication protocols such as Kerberos and SAML rely on timestamps to check that the tokens issued are still valid. Authentication will fail if the time on the NetScaler is incorrect.
- Caching relies on the time set on the NetScaler to determine if
httpobjects are still valid. - When performing log analysis and trace analysis, it is important that the date and time correspond across different devices, to be able to match the times across various logs.
Before discussing troubleshooting, here's a quick summary of the steps that happen when a NetScaler is configured to synchronize its time with an NTP server:
- The NetScaler contacts the NTP Server and sets the original timestamp field to a time in the past, to indicate that it needs to synchronize:
- The server responds with its value of time, always considered accurate, using the receive timestamp.
- Several exchanges of timestamps occur, each involving similar requests and responses as Steps 1 and 2. This process generally takes several minutes.
- Eventually, the NetScaler updates itself to the Server indicated time. At this point, the origin and receive timestamps will both have the same value:
If your NetScaler is configured for NTP but shows the date and time incorrectly, start by checking the status of NTP on the NetScaler. To do this, use the following command:
'> show ntp status'
This output will provide a number of useful bits of information. The preceding output is taken from a working NTP setup. The important fields are as follows:
remote: The IP address/DNS name of the serverrefid: The IP address of the source of the time for the NTP server itself—a higher stratum serverst: The stratum level of the serverwhen: How much time has passed since the last responsepoll: How often, in seconds, the NetScaler will poll this serverreach: How many attempts by the NetScaler to reach the server were successfuldelay: Round trip time to the NTP ServerOffset: This value indicates the time difference between the NetScaler and the server
Following on from the previous screenshot, the time skew of 127,414 milliseconds (127.414 seconds) will result in a clock_step update. This will be visible in /var/log/ntpd.log, which is the NTP log file:
Jitter in NTP verifies several samples of time, which is why the convergence takes time. Jitter is a value indicative of the differences in time between those samples.
Let's now look at a failing NTP setup. In this case, the status will be stuck in INIT and the delay, offset, and Jitter will all show zeroes:
As part of troubleshooting, you can also query the NTP server using the ntpdate –q command, which will help you identify any communication issues. If the command returns errors because the NetScaler cannot reach the NTP server, you will need to investigate this as a network issue.
You can also use the ntpdate –u <ntp_server_ip> shell command to update the time instantaneously and let NTP maintain the time from then on:
