NTP and Cisco Time - Part 1

Background:

• The current NTP version is 3 and defined in RFC 1305
• Provides synchronisation services for NTP Servers and Clients, enables services such as SNMP and Syslog to utilise accurate time stamps, this facilitates Troubleshooting, Fault Analysis and Incident tracking (think FCAPS).
• NTP polling can take place from 64 to 1024 seconds depending on network conditions.
• NTP uses two me     thods to ensure that the source is reliable firstly it won’t synchronise with a system that isn’t already synchronised, it will also compare with other systems and won’t synchronise with a system that shows a significant deviation from them. 
• If a Cisco device is acting as a server and configured to synchronise against an internet source then it can be configured to pretend that it has remained synchronised.
•  Cisco Devices maintain two clocks the hardware clock which is an example of an (RTC = Real Time Clock) and a software clock the following section shows how these two interact and can be manipulated.

Introduction:

For me it is: 18:31 on Sunday the 23^rd of March 2014 I know this because the clock on my computer tells me it is, if my clock was wrong it could easily be the 2:00 am on Saturday the 5^th of August 1845 how do I tell?  Well I have to believe my computer, and my computer has to believe someone else.. Get the picture..  It’s pretty much the same on the network.

“The future is something which everyone reaches at the rate of sixty minutes an hour, whatever he does, whoever he is.”

CS Lewis

The rate at which time passes is the same for all of us (I think Einstein would disagree) however if you arrive and everyone disagrees on the arrival time who is right?  If only all clocks where synchronized to the beginning of time; if we knew when time began (now there’s an argument to get the astro physicists going).

I have lost count of the networks I have worked on where there is no time-synchronisation.  This is one of those largely hidden facilities that don’t get noticed until you need it, usually when you need to make sense of a particular log to find out when something occurred.

Time and Management FCAPS:

Keeping accurate time on your Cisco devices is vital for a host of network services.  From an FCAPS perspective accurate time assists with:

Fault Management – knowing the exact time a fault occurs can be vital to the troubleshooting process.

Configuration Management – Knowing the exact time a configuration took place helps with historical troubleshooting.

Accounting Management – Knowing when a particular change was made helps backtrack the who when and why of a change.

Performance Management – Imagine a scenario where you are seeing daily reports of network slowness knowing exactly when those high utilization times occur can significantly reduce your troubleshooting time!

Security Management – Knowing exactly when any of the above issues occurred can be vital to security management, imagine your system has been deliberately sabotaged from within, to find the culprit you are relying on Forensic network analysis, knowing when something occurred can often narrow your suspects down!  

A good example of this is when your ISP contacts your organisation to say that they have reports of one of your IP Addresses being a source of malaware.  When you check your firewall logs to see what internal address was allocated a particular external address you can use the time to narrow down who exactly was logged onto that machine during this time.  This way  you have the machine with the infection, the user and what time it occurred!

 Manually Manipulating the time on a Cisco Device:

 Is your clock authoritative on not?

If you issue a show clock detail you will see an asterisk in front of the time which indicates it’s not authoritative.  If you then set the clock manually and reissue a show clock detail you will get a response that shows the clock is now authoritative and set by the user as per the example below,

Show clock [shows the time and date from the software clock not the hardware clock]

NOTE: if you are using GNS3 instead of live hardware you will see a “no time source” response in the initial output instead of the “Time source is hardware calendar” which is the response from live kit.

Setting the Hardware Clock

Unfortunately the time set by the set clock command is not persistent, when you reboot the clock is resynchronised with the hardware or in the case of GNS3 it is simply reset as there is no RTC (real time clock) in gns3.   

You can however update and check the time on the hardware clock in real devices by issuing the following commands:

Clock update-calendar [synchronises the hardware clock to the software clock]

If you want to check that the current time and date settings for the hardware clock :

show calendar  [shows the time and date for the hardware (rtc) not the software clock]

TIMEZONES:

In order to ensure that your time is set to the correct time-zone and daylight savings, you can utilise the following commands:

Clock timezone [this defaults to UTC] 

Here are some well known keywords for the clock timezone command:

Timezone Keyword	Full Name and offset to UTC
GMT	Grenwich Meantime (same as UTC)
BST	British Summer Time UTC + 1
IST	Irish Summer Time UTC +1

Note: UTC (coordinated universal time) is the standard by which the world sets it’s time.  Historically this was GMT however it has been replaced by UTC.  This time business can be a whole business of it’s own trust me do a search for TIME in Google and you will find a couple of hours have magically passed..

Keeping the time automatically:

Setting the time and date accurately is a step forward however, imagine that multiplied by a hundred or even a thousandfold.  With a large round of applause into the room steps NTP aglow in the adoration of sys admins everywhere.  NTP (Network Time Protocol) will allow you to synchronise the time across your devices automatically and in a resilient manner. 

The rest of this guide will cover configuring your cisco devices as both a client and server, I will be covering the client configuration first as this is probably the most commonly performed task and the least complex, secondly I will cover configuring a device as a time source.  Unless you are carrying out a Greenfield network install or changing  a network design at a high level it is unlikely that you are ever going to have to do this, however having an understanding of how it’s done can greatly aid you in troubleshooting time related issues and just simply figuring out what’s broken.

Configuring your Cisco Device to be an NTP Client:

Specify your NTP Server:

You can specify your NTP Servers in global configuration mode with the following command:

Device(config)#ntp server  192.168.4.5 source vlan 4
device(config)#ntp server 192.168.4.7 source vlan 4

The above commands configure two servers to synchronise against, note the use of the source keyword this optional keyword specifies which interface to use as the source of the NTP communications, in this case the NTP servers are located on VLAN 4 and the vlan 4 interface of this device has been specified.

A note on synchronisation time: According to RFC 1305 the clients clock can only be updated by a certain amount at a time.  To reduce the time to synchronisation a good practice is to first manually set the clock close to the ntp servers time to reduce the gap for synchronisation.

You can check which servers your device has associated to with the following command:

Device#show ntp associations

This will give a similar output to the one below: 

time_test#show ntp associations

      address         ref clock                st  when poll    reach  delay  offset     disp

*~192.162.4.5     .PPS.                     1   211      1024  357     10.3     -0.82      2.3

+~192.162.4.6     193.62.22.82      2   455    1024  375      9.0       -0.74      1.6

+~192.162.4.7     193.62.22.74      2   128    1024  377      5.1        -0.69     4.3

* master (synced), # master (unsynced), + selected, - candidate, ~ configured

 Some useful information can be gained from examining this output:

 A * shows that this device is currently synced against the peer 192.168.4.5
The poll column shows that the device is configured to poll the ntp server every 1024 seconds or roughly every 17 minutes minutes.
The when column shows the time that has elapsed since the last NTP packet was received.

 

time_test#show ntp associations detail

193.62.4.5 configured, our_master, sane, valid, stratum 1

ref ID .PPS., time D6D9BB42.E2B46107 (19:57:54.885 UTC Sun Mar 23 2014)

our mode client, peer mode server, our poll intvl 1024, peer poll intvl 1024

root delay 0.00 msec, root disp 0.24, reach 357, sync dist 19.623

delay 10.30 msec, offset -0.8193 msec, dispersion 2.33

precision 2**22, version 3

org time D6D9BB43.D291C3D6 (19:57:55.822 UTC Sun Mar 23 2014)

rcv time D6D9BB43.D4192800 (19:57:55.828 UTC Sun Mar 23 2014)

xmt time D6D9BB43.D171A00F (19:57:55.818 UTC Sun Mar 23 2014)

filtdelay =    10.30   11.81   24.29   10.41   10.27   10.30   36.59   11.72

filtoffset =   -0.82   -1.10   -7.21    0.95    1.20    1.30  -11.71    1.05

filterror =     0.02   15.64   31.27   46.89   78.14   93.77  109.39  140.64

I have removed the output for servers 193.62.4.6 and 193.62.4.7

A final note on multiple servers:

 It is possible to set a server to be the preferred time source over all of the others configured on your device.  Previous show ntp associations output gave 193.62.4.5 as the NTP master, what if we wanted this client to use 193.62.4.6 as the preferred and master?  This can be accomplished as follows:

Time_test(config)#ntp server 193.62.4.6 prefer source vlan 1

Note if you configure this command it can take a long time to take effect as of the time of writing and my research there is no method to force the device to do an immediate ntp synchronization!!

Final Check:

As a final check you can issue the show ntp status command:

Time-test#show ntp status

Clock is synchronized, stratum 2, reference is 193.62.4.6

nominal freq is 381.4697 Hz, actual freq is 381.4701 Hz, precision is 2**17

reference time is D6D9D645.16CE9FB6 (21:53:09.089 UTC Sun Mar 23 2014)

clock offset is -1.2050 msec, root delay is 10.27 msec

root dispersion is 2.23 msec, peer dispersion is 0.75 msec

OK Folks, that’s it for tonight I will complete the next part at a later date It’s 21:55 according to my computer clock and in this universe that will do for me J