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!
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 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
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 18.104.22.168 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 22.214.171.124 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 126.96.36.199 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 188.8.131.52 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 184.108.40.206 key 1 R03(config)#ntp server 220.127.116.11 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.
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 18.104.22.168 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 ~22.214.171.124 127.127.7.1 8 991 1024 377 35.8 3330.9 252.9 *~126.96.36.199 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.