Configuring the Cisco IOS NTP Client

In this lab you will learn how to configure a Cisco Router or Switch as a Network Time Protocol (NTP) Client to query and automatically sync the time/date to a specified NTP server.

NOTICE: You may encounter problems when attempting this lab on GNS3. R1 may max out the CPU utilization and lock up and you will not be able to change the IDLEPC value as the only available IDLEPC value is 0×00000000 [1000]. The lab instruction provided in this lab is demonstrated using REAL Cisco hardware (2x 2600XM platforms running 12.4(15)T14 Advanced Enterprise Services.)

Real World Application & Core Knowledge

I’m sure at least once a day you wonder what time it is right? Well just like us Cisco devices have a very good reason to know what time it is as well. When you look at the SYSLog’s on a Cisco device they are all date/time stamped which indicates obviously when the event occurred. For example such as such T1 went to link state down on January 14th 2010 @ 5:32:53AM.

Another reason as to why a Cisco device will need to know the exact time is due to key chain security which is commonly used as secret passwords so to speak to ensure no unauthorized routers attempt to become neighbors with EIGRP enabled routers. These “keys” have a life time on them specified by a valid date range. Eg; Jan 1st 2010 at 12:00am through Jan 1st 2011 12:00am. Keep in mind though that EIGRP security is not part of the CCNA exam curriculum.

A real good day to day beneficial reason as to why to have the correct date and time on a Cisco device which is to record the last time the running configuration was modified. Whenever you make changes to the running configuration it will also save the time and date along with the username of who changed the config when showing the running or startup configuration.

Of course the reasons are endless; none the less it is important that all devices in your network have synchronized time and with that being said; Network Time Protocol (NTP) is the right technology for the job.

Network Time Protocol as defined in RFC958 simply lays out a method for a device to obtain the time and date over the network with several variables taken into consideration such as latency and processing delay to ensure the most accurate synchronization.

Today’s networks use the new and approved standard NTPv3 (Network Time Protocol version 3). In a nut shell NTP uses the User Datagram Protocol (UDP) on port 123 and is actually one of the oldest protocols on the internet in use today. NTP was designed by David Mills at the University of Delaware and is still maintained by David and a team of selected volunteers.

The Network Time Protocol is based on a tiered model known as the Clock Strata which is short for Stratum meaning “one of a series of layers” in Latin.

When working with a Cisco device there are 15 Stratum layers you’re able to configure, 1 through 15 with 1 being the most trusted time source and 15 being the least. In common deployments most Cisco devices are a stratum layer 4 or higher as an atomic (caesium, rubidium) clock is a stratum 0 which is commonly directly connected via serial interface to a stratum 1 device. Stratum 2 devices are refereed to as “Time Servers” query their time to from stratum 1 devices and provide the time to stratum 3 devices which commonly reside in a local area network as the local time server. NTP Servers can query other NTP Servers as long as they are in the same stratum layer and this can occur to ensure the most accurate synchronization of time. A Stratum 4 device retrieves their time from the LAN time server(s) which in properly designed network would be a stratum 3.

One bit of information to really keep in mind when dealing with NTP to save a lot of frustration and headaches is that an NTP client will not sync with a server that has an earlier date/time.

Okay so enough with the jibber jabber and lets get down to business. To configure the NTP client on a Cisco device you’ll use the ntp server x.x.x.x command in global configuration. You can specify multiple NTP servers if you have multiple servers in your network; this ensures that a cisco device has NTP redundancy and can still obtain the time from a server if one were to fail. However the catch to this configuration is that the servers are processed top down in the configuration but you have the ability to specify a “preferred server” using the command ntp server x.x.x.x prefer.

Another way of configuring NTP servers on a cisco device is to use the ntp peer x.x.x.x command in global configuration. This command will allow you to use multiple NTP servers in a peer group and the server that is the most accurate with the lowest stratum number will become the NTP server of the peer group.

To verify that your Cisco device is learning the time via NTP you’ll need to use the show ntp associations which will show you the current NTP peers on the device and additional information including the NTP Peers reference clock, their stratum #, poling interval, reach, delay and offset.

In this lab you will configure R2 as an NTP client which queries its time from the preferred NTP server; R1. In this labs lab R1 is pre-configured as an stratum 3 NTP Server.

Familiarize yourself with the following new command(s) listed below;

ntp server x.x.x.x – This command is executed in global configuration and configures an NTP server as to which the device will query for the time.

ntp server x.x.x.x prefer – This command is executed in global configuration and configures an NTP server as a preferred server when multiple servers are configured.

ntp peer x.x.x.x – This command is executed in global configuration mode and configures a peer group of multiple specified NTP servers whereas the most accurate lowest stratum server becomes the NTP Server of the peer group.

show ntp associations – This command is executed in user or privileged mode to view the current NTP peers and their NTP related information.

The following logical topology shown below is to be used in this lab;

Lab Prerequisites

• Load the Free CCNA Workbook GNS3 topology; start and establish a console session with R1 and R2 then load their initial configurations included below by copying the config from the textbox and pasting it into the routers console.

included below by copying the config from the textbox and pasting it into the routers console.

Initial Configurations

!################################################### !#  Free CCNA Workbook Lab 11-7 R1 Initial Config  # !################################################### ! enable configure terminal ! hostname R1 no ip domain-lookup ! interface Serial1/1  description ### PPP LINK TO R2 ###  encapsulation ppp  ip address 10.50.12.1 255.255.255.252  no shut  exit ! ntp master 3 ! line con 0  logging sync  no exec-timeout ! end

!################################################### !#  Free CCNA Workbook Lab 11-7 R2 Initial Config  # !################################################### ! enable configure terminal ! hostname R2 no ip domain-lookup ! interface Serial1/1  description ### PPP LINK TO R1 ###  encapsulation ppp  ip address 10.50.12.2 255.255.255.252  no shut  exit ! line con 0  logging sync  no exec-timeout ! end

Lab Objectives

• Configure the time and date on R1 as 00:00:00 Jan 1, 2010 to ensure the configured time is different then the actual time to demonstrate NTP.
• Configure R2 to use the NTP server located at 10.50.12.1.
• Verity that R2 has obtained the correct date and time from R1 via NTP by viewing the NTP associations and the local clock.

Lab Instruction

Objective 1. – Configure the time and date on R1 as 17:00:00 Jan 1, 2005 to ensure the configured time is different then the actual time to demonstrate NTP.

R1#clock set 00:00:00 1 jan 2010 R1#

Objective 2. – Configure R2 to use the NTP server located at 10.50.12.1.

R2#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R2(config)#ntp server 10.50.12.1 R2(config)#end R2#

Objective 3. – Verity that R2 has obtained the correct time and date from R1 via NTP by viewing the NTP associations and the local clock.

R2#show ntp associations address ref clock st when poll reach delay offset disp *~10.50.12.1 127.127.7.1 3 58 64 7 5.1 -0.93 3875.2 * master (synced), # master (unsynced), + selected, - candidate, ~ configured R2#show clock 00:05:18.467 UTC Fri Jan 1 2010 R2#

As shown above by the show ntp associations command you’ll see that the server 10.50.12.1 is the master (synced) server as denoted by the *. Once viewing the clock you can confirm that the time has indeed been synchronized via NTP.