CONFIGURING NTP ON A CISCO ROUTER

Configuring NTP On A Cisco Router

Network Time Protocol (NTP) is a vital service not only for Cisco devices but almost every network device. Any computer-based device needs to be accurately synchronised with a reliable time source such as an NTP server.

When it comes to Cisco routers, obtaining the correct time is extremely important because a variety of services depend on it. The logging service shows each log entry with the date and time - very critical if you're trying to track a specific incident or troubleshoot a problem.

Generally, most Cisco routers have two clocks (most people are unaware of this!): a battery-powered hardware clock, referenced as the 'calendar' in the IOS CLI, and a software clock, referenced as the 'clock' in the IOS CLI.

The software clock is the primary source for time data and runs from the moment the system is up and running. The software clock can be updated from a number of sources:

• NTP Server
• SNTP (Simple NTP)
• VINES Time Source
• Hardware clock (built into the router)

Because the software clock can be configured to be updated from an external source, it is considered more accurate in comparison to the hardware clock. The hardware clock can be configured to be updated from the software clock.

Example Scenario

This article will show you how to configure your Cisco router to synchronise its software clock from external sources such as NTP servers. We will also show you how to configure your router to act as an NTP server for your internal network devices, ensuring all devices are synchronised.

First example involves setting up the router to request NTP updates and synchronise itself from a public NTP server. This will ensure the router's time is constantly synchronised, however it will not act as an NTP server for internal hosts:

We'll need to configure the router to resolve FQDN using our ISP's name server:

R1(config)# ip nameserver 195.170.0.1

Now we instruct our Cisco router to obtain its updates from the public NTP server.

R1(config)# ntp server 1.gr.pool.ntp.org

As soon we issue the command, the router will resolve the FQDN into an ip address and begin its synchronisation. Right after issuing the command, we can verify the router is correctly configured and awaiting synchronisation:

R1# show ntp associations
address.............. ref clock ........st ..when ..poll ..reach ..delay ..offset ..disp
~195.97.91.220 .131.188.3.221...2 ....30 ....64 ....1 .....0.000 -1539.9 .7937.5
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

R1# show ntp status
Clock is unsynchronised, stratum 16, no reference clock
nominal freq is 250.0000 Hz, actual freq is 250.0006 Hz, precision is 2**24
reference time is 00000000.00000000 (02:00:00.000 Greece Mon Jan 1 1900)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.00 msec, peer dispersion is 0.00 msec
loopfilter state is 'FSET' (Drift set from file), drift is -0.000002405 s/s
system poll interval is 64, never updated.

The 'show ntp associations' command shows that the system is configured (~) to synchronise with our selected NTP server, however, it is not yet synchronised. When it is, expect to see the star (*) symbol in front of the tilde (~). The 'ref. clock' column shows the IP address of the NTP server from which our public server (1.gr.pool.ntp.org) is synchronising.

It is also worth noting the column named 'st' which is equal to two (2). This represents the stratum level. The higher the stratum, the closer to the Atomic clock source we are. As a general rule, always try to synchronise with a server that has a low stratum.

The 'show ntp status' command confirms that we are yet to be sy