Time and Date and the Cisco IOS

All Cisco IOS routers support manual and dynamic time services. Time services allow the router to keep track of the current date and time. Having your networking equipment synchronized to the same date and time is important when attempting to troubleshoot problems from syslog messages. This section discusses how to configure time on your router manually, as well as how to use the Network Time Protocol (NTP) to assign the time on your router dynamically. The following sections cover time sources that the router can use and how to configure the date and time manually as well as using NTP.

Router Time Sources

Most Cisco routers have a hardware and software clock, which can be managed separately. The following two sections discuss these two clocks.

Hardware Clock

The hardware clock, often called a system calendar clock, is a battery-powered clock that keeps track of the date and time even when the router is powered off. Most routers have a hardware clock. If no other time source is available, the router uses its hardware clock to provide the date and time. Because the clock is powered by a battery, if the battery dies, the clock defaults to a hard-configured date and time, as shown here:


00:00:00.000 UTC Mon Mar 1 1993

Software Clock

The router's software clock is the primary source for the date and time. It begins when the router starts up and ends when the router shuts down. Initially, the software clock gets the date and time from the hardware clock, when the router is booting up; however, the software clock can get its date and time from a number of sources, including these:

NTP
Simple Network Time Protocol (SNTP)
CLI commands

Because the software clock can be updated dynamically from a more reliable source, like NTP, it typically has a more accurate date and time than the hardware clock.

The router uses the software clock to provide the date and time to the following services:

The hardware clock
NTP, if the router is an NTP server
Log messages
Debug messages
Various show commands
Time ranges in ACLs

The default time zone of the software clock is Coordinated Universal Time (UTC), which also is referred to as Greenwich Mean Time (GMT). However, you can override this with a manual configuration, in which you can specify the router's time zone as well as daylight savings time, sometimes referred to as summer time.

Manual Time and Date Configuration

If the hardware clock's battery is dead and you have no other time source to synchronize your router with, you can manually configure the current date and time after the router boots up. However, you should use this only as a last resort because you would have to change the time setting manually every time the router reboots. The following sections discuss how to configure your router's time settings manually.

Time Zone

As I mentioned at the beginning of this section, the default time zone is UTC. To change the time zone, use the clock timezone command, shown here:


Router(config)# clock timezone zone_name hours_offset

  [minutes_offset]

The zone_name parameter is the name of time zone. This is the standard acronym, such as EST for Eastern Standard Time. The hours_offset parameter is the number of hours, plus or minus, different from UTC. For example, New York City would be ?5. Typically, the minutes_offset parameter is not used; however, certain time zones, such as Atlantic Canada Standard Time (AST) is 3.5 hours different from UTC. This is represented as ?3 30. Here is a simple example for setting the time zone for a router in Orlando, Florida:


Router(config)# clock timezone EST -5

TIP

If you will be logging messages from routers in different time zones to a syslog server, Cisco recommends that you use UTC as the time zone on all your routers. This alleviates any confusion about two attacks occurring in two different time zones and determining whether the attacks are occurring simultaneously. This recommendation also applies to troubleshooting problems.

Daylight Saving Time

If your time zone follows daylight saving time (DST), commonly referred to as summer time, you can configure this setting on your router with the clock summer-time command. If your time zone uses the standard times and dates for the beginning and end of the summer time clock change, you can use this command to set up DST:


Router(config)# clock summer-time zone_name recurring

  [1-4 | first | last] [day month hh:mm day month hh:mm [offset_value]]

After you specify the name of the time zone, specify which week the time change occurs: 1 through 4 is the number of the week, first is the first week of the month, and last is the last week. If you do not specify the week, day, month, and time, it defaults to the standard for the time change. Likewise, if you omit the offset value, it defaults to 60 minutes, which is added to the current time when the first time is reached in the spring, and then is subtracted from the current time when the second time is reached in the fall. Here is a simple example, using the default settings, for Orlando, Florida:


Router(config)# clock summer-time EDT recurring

If your router uses nonstandard days for changing your clock's time, use either of the following two commands:


Router(config)# clock summer-time zone_name date

  month day year hh:mm month day year hh:mm [offset]

or:


Router(config)# clock summer-time zone_name date

  day month year hh:mm day month year hh:mm [offset]

With these two commands, you must specify the exact date and time when summer time begins and ends.

Software Clock Settings

If your router's software clock is synchronized to an external time source, such as an NTP server, it is not necessary to configure the software clock's time settings manually. However, if your router is not synchronized to an external time source, you can manually change the time on the router to set it correctly. This is accomplished with either of the following privileged EXEC commands:


Router# clock set hh:mm:ss date month year

or:


Router# clock set hh:mm:ss month date year

Here is a simple example:


Router# clock set 12:34:00 November 19 2003

If you want to resynchronize the software clock with the hardware clock, use this command:


Router# clock read-calendar

To view the time and date of the software clock, use the show clock command, as in Example 18-10.

Example 18-10. Viewing the Date and Time of the Software Clock


Router# show clock

12:34:58.015 EST Wed Nov 19 2003

The show clock detail command displays the current time as well as your clock settings, as shown in Example 18-11.

Example 18-11. Using the show clock detail Command


Router# show clock detail

12:35:51.431 EST Wed Nov 19 2003

Time source is user configuration

Summer time starts 02:00:00 EST Sun Apr 4 2004

Summer time ends 02:00:00 EDT Sun Oct 31 2004

Hardware Clock Settings

Normally, the only time that the hardware clock is used is initially to give the software clock the correct date and time when the router boots up. After this, the software clock is responsible for ensuring that the hardware clock is updated with the correct time. This way, if you are using NTP and the clock battery in your router is dead, NTP will update the software clock, which, in turn, updates the hardware clock with the correct date and time. The software clock does this at regular intervals.

To change the time of the hardware clock manually, use either of the two following commands:


Router# calendar set hh:mm:ss day month year

or:


Router# calendar set hh:mm:ss month day year

Note that the calendar set command is not supported on all router models. Use the show calendar command to view the time of the hardware clock.

To set the hardware clock from the software clock, use the following command:


Router# clock update-calendar

Network Time Protocol Overview

NTP, which runs on top of UDP, is an IP protocol used to synchronize time across devices in a network. NTP supports three versions; the newest version, version 3, is defined in RFC 1305. NTP uses a client/server function.

Time Distribution

The server is an authoritative source of time and, as such, should have the most correct time among all devices. This can be supplied by a radio or atomic clock, or even a GPS device. NTP uses the term stratum to describe how many hops away the source of time is. For example, a stratum 1 time source is the NTP master server with a reliable clocking mechanism that the server uses to derive time. Each part of your network might have an additional NTP server. These servers are stratum 2 time sources because they derive their time from the NTP master server. The servers are responsible for giving the time to other lower-stratum servers as well as clients.

NOTE

Cisco routers can be NTP servers. In this function, I highly recommend that you not use the router's hardware clock. Instead, attach an external timing device. Cisco routers do not support radio or atomic clocks for external timing devices, but they do support certain GPS devices. I discuss this later in the "NTP: Server" section.

Distribution of time can be accomplished by the server periodically broadcasting the time or the client requesting the time periodically from the server. When the broadcast method is used in a Layer 2 network, it ensures that, because only one packet is sent, all devices typically have the same time, within a millisecond or so of each other. However, broadcasting has two problems:

It is easy to spoof, so your timing information could be corrupted.
It does not work well in a Layer 3 network.

Because of these problems, most NTP implementations have the clients periodically request the time from the server. NTPv3 does support authentication, which greatly reduces the likelihood that a spoofing attack will occur on your timing infrastructure; however, this feature is supported only in client polling, not broadcasting.

Simple Network Time Protocol

A simplified form of NTP, called the Simple Network Time Protocol (SNTP), can be used on clients to derive time, but not to pass time to other devices. For example, when using SNTP, the old (and discontinued) Cisco 1000 series routers, can only accept time from an NTP server; they cannot, in turn, pass the timing information to devices behind them. Unlike the NTP distribution method, SNTP typically provides accuracy of time within 100 milliseconds, and it does not support authentication (NTPv3). Because of these limitations, SNTP should be used only if your router does not support NTPv3.

The remaining part of this section deals with how to configure NTP on your router. I focus on three areas: how to configure your router as a client, how to configure your router as a server, and how to verify your NTP configuration.

Router Client Configuration for NTP

By default, NTP is disabled on all your router's interfaces. Your router, acting as a client, can use two methods to gain the most up-to-date time from an NTP server: periodically polling an NTP server or listening for periodic broadcasts from NTP servers. The following two sections discuss the configuration of both of these services.

Poll-Based Configuration

Clients can use two different polling modes to acquire their timing information from NTP servers:

Client mode
Symmetric active mode

In client mode, the client polls all NTP servers in its configuration for the time and then picks one server to use. This mode is a client/server mode, with the router acting as a client. This mode typically is used if the router will not be sending time to other devices. The ntp server command is used to specify the information to access the NTP servers.

In symmetric active mode, the router polls the configured time servers for the current time and also sends time to time servers. This mode typically is used to synchronize the group of NTP servers themselves at the same stratum level. The ntp peer command is used to specify the other NTP server peers of the router.

TIP

In either mode, a large number of polling requests by a router can affect memory and CPU resources. You should limit the number of peerings that a router has, as well as the number of clients that a router passes time to. In large networks, it is not uncommon to have a hierarchy of time sources to reduce this burden. An alternative solution for large Layer 2 networks is to use broadcasts to disseminate time, as discussed in the next section.

Here is the router command to define other NTP servers:


Router(config)# ntp {server | peer} IP_address [version number]

  [key keyid] [source interface] [prefer]

If the router is functioning as only a client, use the server parameter; otherwise, if the router is acting as a server and is peering to other servers, use the peer parameter. Following this is the IP address of the remote NTP server. If you do not specify the version number for NTP, it defaults to 3 (NTPv3). The optional keyid parameter references authentication information to be used to verify the server or peer's timing communications. I discuss this later. The source parameter specifies what IP address on the router to use as the source address in the IP packet header when sending communications to the remote NTP server. If you omit this parameter, it defaults to the address of the outgoing interface. When you are entering multiple NTP servers, you can use the prefer parameter, which specifies that this NTP server is preferred over other servers for synchronization purposes.

NOTE

If you are attempting to use NTPv3 and time synchronization is failing, you might want to try using NTPv2. However, remember that NTPv2 does not support authentication and is thus susceptible to spoofing attacks.

Broadcast-Based Configuration

Broadcast-based synchronization is preferred in larger Layer 2 networks, especially in networks where bandwidth, memory, and CPU resources are limited. Only one mode exists for broadcast-based configuration: broadcastclient mode. Unlike poll-based synchronization, in broadcastclient mode, the client passively listens for NTP broadcasts from an NTP server. Obviously, for this to work, the client and server must be in the same subnet. Enabling broadcastclient mode is done under a router's interface:


Router(config)# interface type [slot_#/]port_#

Router(config-if)# ntp broadcast client

Router(config-if)# ntp broadcastdelay microseconds

Enable this command only on the interface(s) on which you have NTP servers, to reduce the likelihood of an NTP server spoofing attack. The ntp broadcast client command enables the NTP client function on the specified interface to accept time broadcasts from NTP servers. The ntp broadcastdelay command is optional. By default, the router compensates for the time delay between the NTP server and the router by adding 3000 microseconds to the NTP servers' advertised time, to adjust for travel delay. You can change this to more accurately affect the delay. This value ranges from 1 to 999,999 microseconds.

SNTP Configuration

SNTP should be used only on routers that do not provide support for NTP. Some Cisco routers that do not provide support for NTP are the 1000, 1600, and 1700 series, depending on the software version running on them.

If your router will be polling the NTP server periodically, use this command:


Router(config)# sntp server {IP_address | hostname} [version number]

You need to specify only the IP address or hostname of the NTP server. The version number defaults to 1 if you omit it.

If your router will be using time synchronization broadcasts from an NTP server, use this command:


Router(config)# sntp broadcast client

NOTE

If you configure both of these commands, the router prefers the time from the configured server over broadcasts received from an NTP server. Also, because SNTP does not use authentication, it should be used only as a last resort for a time-synchronization solution.

Router Server Configuration for NTP

Besides performing client functions, a router can be an NTP server. This is very useful in remote office environments, in which the perimeter router at these locations can function as both a client and a server, acquiring timing information from the corporate NTP servers and then, acting as a server, passing this information to the remote office devices behind it.

Distributing Timing Information

I already discussed how to set up peer relationships between routers acting as NTP servers at the same stratum level (ntp peer command), as well as how a router can access timing information directly from a server at a higher level (ntp server command).

If your router, acting as an NTP server, will be using broadcasts to disseminate timing information, you need to configure the following command on each interface where you want your router to advertise its time synchronization information:


Router(config)# interface type [slot_#/]port_#

Router(config-if)# ntp broadcast [version number]

If you omit the version, it defaults to 3 (NTPv3).

Configuring an External Clock

As I mentioned at the beginning of the "Time Distribution" section, you can have your router act as an NTP server and obtain clocking information from an externally attached device. You would choose this option if you want your router to be the master NTP server in your network.

Cisco does not support stratum level 1 clocking services, such as atomic or radio clocks; however, it does support certain GPS-based devices (stratum level 2) that you can attach to your router. Your router then can use these devices to obtain timing information, which, in turn, can be redistributed through NTP. When attaching a GPS to a Cisco router, you need a free line. Typically, most administrators do not use the auxiliary port on the router for WAN or CLI communications, so you can attach the GPS device to this.

Not all routers support the attachment of an external clock to them. Cisco supports two types of GPS clocks:

Trimble Palisade NTP synchronization kit (works only with the 7200 series routers)
Symmetricom (Telecom-Solutions) GPS clock kit (works only with certain router models)

NOTE

Before you buy a GPS clock for your router, make sure that Cisco supports the GPS product and that your router has the capability to obtain timing information from it?only certain routers support this feature. If your router does not support this feature, you need some other device to use as a master time reference. Most UNIX and Windows server products support external GPS devices.

If you have the Trimble GPS clock and are attaching it to the auxiliary port of a 7200 router, you need to configure the following on your router:


Router(config)# line aux 0

Router(config-line)# ntp refclock trimble pps none stratum 1

The ntp refclock command tells the 7200 that it has a Trimble GPS clock attached. The pps parameter indicates the type of pulse-per-second reference support: In the case of Trimble, this is set to none. Because this is probably the root time source for your network, you define the time source as a stratum service level of 1.

If you are connecting a Symmetricom GPS product to your router's auxiliary port or TTY line, you use the following configuration:


Router(config)# ntp refclock telecom-solutions pps {cts | ri | none}

   [inverted] [pps-offset number]

   [stratum number] [timestamp-offset number]

Depending on the Symmetricom GPS product, you need to choose the pulse-per-second (PPS) option as either CTS, RI, or none. The inverted option indicates that the PPS pulse is inverted; the pps-offset option indicates the PPS pulse offset, in milliseconds. The stratum option refers to the NTP stratum level of service that this router will provide as a clock source. This can range from 0 to 15. If this router is the master clock, choose 1. You also can apply an offset to any time stamp that the router generates with the timestamp-offset option, which is specified in milliseconds.

Setting Up the NTP Server

If your router will be an authoritative NTP server, as typically would be the case if you attached a GPS unit to it, you must configure the following on your router:


Router(config)# ntp master [stratum_level]

NOTE

Be careful about using this command in a network that has other master NTP servers. The stratum level appropriately should affect the router's source of clocking information. If this router has the same stratum level of other NTP servers, time-keeping instability issues can arise if the NTP servers do not have their timing information synchronized.

NTP Security

You can take two security measures to create a more secure NTP environment for your router:

Use access groups to restrict who can access the router's NTP resources.
Use authentication with the MD5 hashing function to restrict NTP communications between trusted devices.

The following two sections discuss these solutions.

Access Groups

Access groups enable you to define a standard ACL that is used to filter types of NTP messages that the router receives. This feature is useful if your router is an NTP server and you want to restrict NTP access to it. The syntax of the command is as follows:


Router(config)# ntp access-group {query-only | serve-only |

  serve | peer} standard_ACL_#

Table 18-4 explains the different control options. When matched with a permit or deny statement in the specified standard ACL, only those communication processes are allowed or prohibited. If you have more than one ntp access-group statement defined, the first statement that matches in the first ntp access-group statement is used.

Table 18-4. NTP Access Group Control Options
Parameter	Description
query-only	Allows only NTP control queries from NTP devices in permit statements in the ACL
serve-only	Allows only time requests from NTP devices in permit statements in the ACL
serve	Allows time requests and NTP control queries from NTP devices in permit statements in the ACL
peer	Allows time requests and NTP control queries, and allows the router to synchronize to servers from NTP devices in permit statements in the ACL

Authentication

NTP supports authentication, which is used to validate NTP messages received from another NTP device. This authentication is similar to that used by routing protocols, such as OSPF and EIGRP, and PPP's CHAP. MD5 is used to create a cryptographic checksum, which is attached to the NTP message. A key, known to both sides, is used to create the authentication checksum. When enabled, if the checksum cannot be verified, the NTP message is ignored. One advantage that authentication has over access group control is that access group control is susceptible to IP spoofing attacks. Authentication does not rely on the IP address for authentication?instead, a shared secret key is used.

NOTE

Because NTP authentication can be CPU intensive, depending on the router model, this might add a slight slew (where the router's time and the NTP server's time is slightly off) in your router's time value. The slower the router's processor is, the higher the slew value is. If timing is critical, you might want to forego authentication for smaller-end routers and use only access groups.

You need to configure three commands to set up authentication:


Router(config)# ntp authenticate

Router(config)# ntp authentication-key key_# md5 key_value

Router(config)# ntp trusted-key key_#

The ntp authenticate command enables NTP authentication. The ntp authentication-key command defines a reference number for the key (key_#) as well as the authentication key (the same key_value must be configured on the remote NTP device). Finally, the ntp trusted-key command specifies which NTP devices should be trusted with authentication, which prevents an accidental synchronization to a system that is not trusted. Notice that a reference number is used. This reference number must match the one used in the ntp authentication-key command. By using a key number, you can create multiple keys; this means that you can update keys more easily and can have different keys for different peers.

After you have defined authentication, you need to reference the key number in the ntp {server | peer} command, which tells the router which key to use when sending messages to specific peers.

Other NTP Commands

This last section on NTP configuration covers three miscellaneous commands. Earlier, I discussed how to specify the source IP address to be used in communications with other NTP devices (using the ntp {server | peer} command). However, you globally can specify the source IP address to use with the following NTP command:


Router(config)# ntp source interface

If you configure the interface in the ntp {server | peer} command, this configuration overrides the global configuration.

For routers that have a hardware clock, you can have the router update the hardware clock from the software clock; however, this is advisable only if the software clock is updated from a reliable NTP source. This is sometimes necessary because the hardware clock can drift slightly over time. To update the hardware clock from the software clock when using NTP, use the following command:


Router(config)# ntp update-calendar

Chapter 4, "Disabling Unnecessary Services," discussed disabling unnecessary services. With NTP, you can enable or disable it on an interface-by-interface basis. To prevent NTP attacks, disable NTP on interfaces that you will not be using to obtain time. For example, if you have a three-interface router?inside, outside, and DMZ?and your NTP server is off the inside interface, I highly recommend that you disable NTP on the other two interfaces. To disable NTP on an interface, use the following configuration:


Router(config)# interface type [slot_#/]port_#

Router(config-if)# ntp disable

NTP Verification

After you have configured NTP on your router, you can use various show commands to examine your configuration and troubleshoot problems. To see the current time on the router's software clock, use the show clock command; to see the time of the hardware clock, use show calendar.

NTP Commands

You use two basic commands to examine NTP information:

show ntp associations
show ntp status

The first command displays associations with other NTP devices. Example 18-12 displays sample output from the show ntp associations command.

Example 18-12. Using the show ntp associations Command


Router> show ntp associations

  address     ref clock   st when  poll reach delay offset  disp

*~192.1.2.11  192.1.2.11   2   31  1024  377    4.1  -8.38   1.5

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

    ~ configured

In Example 18-12, the first set of leading characters displays synchronization information:

*	This router is synchronized to this peer.
#	This router is almost synchronized to this peer.
+	The peer has been selected for possible synchronization.
-	The peer is a candidate for synchronization.
~	The peer has been statically configured.

The address column lists the addresses of the NTP peer devices. The ref clock column lists the addresses for where peers in the address column are getting their time. The st column indicates the stratum level of the peer. The when column indicates the time since the last NTP message was received from this peer. The poll column indicates the polling interval, in seconds, that this router is using to contact the specified peer. The reach column indicates the peer's reachability, in octal. The delay column displays the roundtrip delay, in milliseconds, to the peer. The offset column displays the relative time of the peer's clock to the local router's clock, in milliseconds.

The show ntp status command displays the status of NTP on the router. Example 18-13 shows sample output of the show ntp status command.

Example 18-13. Using the show ntp status Command


Router# show ntp status

Clock is synchronized, stratum 2, reference is 192.1.2.11

nominal freq is 250.0000 Hz, actual freq is 249.9990 Hz, precision is 2**19

reference time is AFE2525E.70597C87 (00:10:39.511 EDT Thu Jan 1 2004)

clock offset is 6.21 msec, root delay is 83.98 msec

root dispersion is 81.96 msec, peer dispersion is 2.02 msec

In Example 18-13, the router is synchronized with the NTP server at 192.1.2.11, which provides a stratum level 2 service.

NOTE

I want to point out that NTP updates to time on a device such as a router are done in small incremental changes. Therefore, when you first boot up your router, it might take a while before the router's software clock completely is synchronized with the NTP server. You will see this from the output of the show ntp status command. One way to speed up the synchronization is to configure the software clock on the router manually to be close to the time that the NTP server is advertising. I highly recommend this approach if your router has a dead battery for its hardware clock and you need to reboot it: After it has rebooted, manually set the time on the router to speed up the synchronization.

SNTP Command

Only one command is used to verify the configuration and operation of SNTP: show sntp. Example 18-14 shows sample output.

Example 18-14. Verifying SNTP


Router# show sntp

SNTP server     Stratum   Version    Last Receive

192.1.2.11        2         3        00:00:34     Synced  Bcast

Broadcast client mode is enabled.

In Example 18-14, one NTPv3 server, 192.1.2.11, provides a stratum level 2 service to this router. This router is learning about the time from this server through local broadcasts.

NTP Configuration Example

Now that you have a basic understanding of NTP and its configuration, take a look at a simple example in which a perimeter router at a corporate network needs to synchronize its time to an internal NTP server. Figure 18-1 is used to illustrate this example. Example 18-15 shows the router's configuration.

Example 18-15. Configuring NTP on Your Router, Acting as a Client


Router(config)# ntp server 192.1.2.11 key 99 source ethernet0

Router(config)# ntp authenticate

Router(config)# ntp authentication-key 99 md5 55ab8971F

Router(config)# ntp trusted-key 99

Router(config)# ntp update-calendar

Router(config)# access-list 1 permit 192.1.2.11 0.0.0.0

Router(config)# ntp access-group peer 1

Router(config)# interface ethernet1

Router(config-if)# ntp disable

Router(config)# interface ethernet2

Router(config-if)# ntp disable

In this example, the NTP server is 192.1.2.11, which is specified in the first command. The next three commands set up authentication and refer back to the first command with the key reference number of 99. Notice that the hash key is 55ab891F, which also must be configured on the NTP server. This router has a hardware clock, so the ntp update-calendar command updates the hardware clock from the software clock. The access-list and ntp access-group commands restrict NTP interaction with only 192.1.2.11. Finally, NTP is disabled on the outside and DMZ interfaces. As you can see, setting up NTP is straightforward.

Time Attack

I once had a client that was using NTP in broadcast mode to disseminate clocking information. One of the internal devices in this client's network was compromised, and the hacker set up shop. One of the things the hacker did was to install an NTP server and set the stratum level of service to 1; he sent broadcasts every 10 seconds, whereas the client's server was doing it every 5 minutes. The hacker used this process to hide his attacks by changing the time (and date, in some circumstances), making it very confusing when examining the log files on the syslog server. It took about 3 weeks before any of the administrators at the client's facility noticed that something unusual was occurring with the logging information and another 2 days to track down the compromised UNIX workstation. From this experience, they changed their NTP time-sharing method to client polling and also set up authentication with NTP, to make it much harder for this kind of problem to occur again.