Network Time Protocol (NTP) on Cisco Routers

Posted on

Network Time Protocol (NTP) is easy to configure but full of little tricks and hard to troubleshoot (or at least I think so)! In this section I want to configure NTP in my sample topology.

Why do I need NTP?

A lot of reason may lead us toward NTP. The most iportant one is troubleshooting. When you need to compare logs on different devices (and not necessarily routers) to find the reason of an event that has affected more than one device (perhaps a section or a subnet) you need to have synchronised time on these devices. Timestamping your log messages when debugging make your screen a little fussy but logs without timestamp are difinitely useless!
CCIE_Topology
You cannot configure clocks on different devices accurately and even if you could (that is very improbable) you cannot guarantee that those devices have a common standard. Some of them may be a little faster and some a little slower. This means you need to have a mechanism in place that changes their clocks constantly to a standard time.

NTP uses UDP port 123

You need to have a time source such as a radio clock, an atomic clock or a GPS based time source. The NTP server that connected directly to one of these sources is said to be a stratum 1 time server. You can define a chain of servers to receive their time from each other up to this server, so their stratum would be 2 or more (regarding their level). The maximum level is 16. Default stratm for a Cisco router is 8. Time information is advertised every 1024 seconds.

NTP modes

NTP operates in three modes:

  • master / slave: slave (client) periodically sends request synchronization messages to a master (server)
  • peer: both NTP devices synchronize one another. One of the peers should be active, otherwise no communication happens.
  • broadcast (or in some platforms multicast): a large number of devices synchronize. For multicast mode, multicast-routing must be enabled.

Setting time on a Cisco device

This is a little tricky in that you set time in privilege mode and no config mode! Here is a sample configuration and verification:

R1#R01#sh clock
*00:04:52.103 UTC Fri Mar 1 2002
R01#
R01#clock set 16:00:00 July 2 2015
R01#
R01#
*Jul  2 16:00:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 00:04:57 UTC Fri Mar 1 2002 to 16:00:00 UTC Thu Jul 2 2015, configured from console by console.
R01#                              
R01#sh clock                      
16:00:07.163 UTC Thu Jul 2 2015

The rest of commands are executed in golobal configuration mode such as setting time-zone:

R01(config)#clock timezone EST -5 0 
(config)#
Jul  2 16:03:35.267: %SYS-6-CLOCKUPDATE: System clock has been updated from 21:03:35 EST Thu Jul 2 2015 to 11:03:35 EST Thu Jul 2 2015, configured from console by console.
R01(config)#

You must assign a name for the timwzone and then specify the number of hours and minutes from UTC. This changes the clock an I prefer to set timezone first and then set the clock. Otherwise I may have to change it again:

R01(config)#do clock set 16:07:00 July 2 2015
R01(config)#
Jul  2 21:07:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 11:05:46 EST Thu Jul 2 2015 to 16:07:00 EST Thu Jul 2 2015, configured from console by console
R01(config)#
R01(config)#
R01(config)#do sh clock detail
16:07:30.331 EST Thu Jul 2 2015
Time source is user configuration

Udemy-CCNP ROUTE-Ad

Configuring NTP server

In my topology R1 is going to be NTP server and active peer to R2. The rest of the routers and devices are client to these two server. I won’t change the default stratum. I also configure R1 to adjust for daylight saving time:

R01(config)#ntp master   
R01(config)#ntp peer 110.2.2.2
R01(config)#ntp source loopback0

R1 is sourcing messages from its loopback interface. It also peers with R2’s loopback interface. The same configuration goes on R2.

R02(config)#ntp master
R02(config)#ntp peer 110.1.1.1
R02(config)#ntp source loopback0

It is wise to configure authentication between peers and between clients and servers. I configure two keys, one for peers and the other for client/server communication:

R01(config)#ntp authenticate
R01(config)#ntp authentication-key 12 md5 cisco12
R01(config)#ntp authentication-key 1 md5 cisco1  
R01(config)#
R01(config)#ntp trusted-key 12
R01(config)#ntp peer 110.2.2.2 key 12

The first command is to force the router to authenticate the other side. R1 authenticates R2 and R2 authenticates R1. The second and the third command define keys. the 4th command sends key 12 as trusted key. The fifth command says R1 should send the trusted key to the other side.
R2 has the same configuration:

R02(config)#ntp authenticate
R02(config)#ntp authentication-key 12 md5 cisco12
R02(config)#ntp authentication-key 2 md5 cisco2  
R02(config)#
R02(config)#ntp trusted-key 12
R02(config)#ntp peer 110.1.1.1 key 12

You can add an access-list to the peer configuration to limit the router from receiving updates from other sources. For this you need to use ntp access-group peer access-list and make sure that in your access-list you have permitted peer’s IP address and 127.127.127.1 (the local source).

Configuring NTP clients

Other routers synchronize with these masters. Here is a sample configuration on R3. The rest of routers have the same configuration:

R03(config)#ntp authenticate
R03(config)#ntp authentication-key 1 md5 cisco1
R03(config)#ntp authentication-key 2 md5 cisco2
R03(config)#ntp trusted-key 1
R03(config)#ntp trusted-key 2
R03(config)#ntp server 110.1.1.1 key 1
R03(config)#ntp server 110.2.2.2 key 2

Configuring NTP broadcast and multicast

Any router (and not necessarily NTP servers) can relay NTP messages using broadcast or multicast to a subnet. Use ntp broadcast command on the interface connected to the subnet that needs to receive NTP broadcast messages on any NTP client router.
For NTP multicast configuration use ntp multicast client multicast_ip_address. Note that multicast routing must be in place beforehand.

Enabling timestamps for log and debug messages

The following command activates timestamping for log and debug messages. You need to execute this command on all routers for the sake of consistency:

R01(config)#service timestamps log datetime 
R01(config)#service timestamps debug datetime

To have the precise timestamps you may add msec to the end of these commands. This way, you can have millisecons as well.

Verifying NTP

Two commands are essential in verifying NTP. Here is the result of these commands on R3 (a client):

R03#sh ntp status
Clock is synchronized, stratum 9, reference is 110.2.2.2
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**18
reference time is D94031BB.564F2DF7 (21:55:07.337 UTC Thu Jul 2 2015)
clock offset is 25827.5904 msec, root delay is 35.83 msec
root dispersion is 29824.43 msec, peer dispersion is 3996.83 msec

This command tells us if client is synchronized and if yes whether it is synchronized with the right server. The first line has the most important information.

R03#sh ntp associations 
      address         ref clock     st  when  poll reach  delay  offset    disp
 ~110.1.1.1        127.127.7.1       8   991  1024  377    35.8  3330.9   252.9
*~110.2.2.2        127.127.7.1       8    55    64  377    35.8  25827.  3996.8
 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

This command shows the servers this client is associates to.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s