Time, Network Time Protocol (NTP)

Why Does Time Matter (In Networking)?

All devices in a network, routers, switches, and end-hosts, have an internal clock. These clocks are not always configured correctly. Even if they are, due to manufacturing &/or computational imprecision, they will drift over time. There are many instances in computing where having an accurate time is important; in the world of Networking specifically, one of the most important reasons to have accurate time keeping is to have accurate logs for troubleshooting.

Example

Imagine if there were some error with the link between two routers. An engineer checks the logs for both devices, and finds an error in each, but they are separated by several hours, or even by many months or years. Perhaps the engineer then assumes the two errors can’t be related and moves on, when in fact one of the devices simply had the wrong time. A great deal of time could be wasted, which would have been prevented if both routers had accurate, ideally identical, time.

For more information about logging, check Syslog.

On Software/Hardware Clocks

Network devices generally have separate software and hardware clocks, referred to as the ‘clock’ and ‘calendar’ respectively. They can be verified and configured using the commands listed at the end of this page. While these two clocks are separate, and can keep separate times, they should generally be synchronized (almost always — I don’t know of any reason not to).

While leaving an offset between the hardware and software clocks won’t cause any issues in itself, remember that the hardware clock is used to keep time in the event of a power outage or system restart. Logs generated during those times will have timestamps from the hardware clock, which could make troubleshooting difficult.

Network Time Protocol (NTP)

Manually configuring the time on devices is cumbersome at the best of times, especially if your network is in a nation with daylight-savings time. More importantly, manually configuring the time does not scale well. In larger networks an automated solution is necessary. Even if it were feasible, the inaccuracies of each device would cause time to drift significantly.

NTP enables automatic time synchronization over a network. Nearly all devices on all networks use NTP by default, including end-hosts. The device you’re viewing this page on is likely using NTP to synchronize its time.

• There are 3 NTP modes: Server, Client, and Symmetric Active
  • NTP Clients request the time from NTP Servers
    • An NTP Client can sync to multiple servers
  • A device can be both a NTP Server and a NTP Client simultaneously
  • Symmetric Active NTP nodes peer with other nodes to provide more consistent time and redundancy, see Peering
• NTP allows accuracy of within ~1 millisecond within the same LAN, or ~50 milliseconds over the Internet/WAN
• Some NTP servers are ‘better’ than others. The ‘distance’ of an NTP server from the original reference clock is called stratum
  • Longer distance = higher stratum
  • Servers with a higher stratum are considered less accurate
• NTP uses UDP port 123 to communicate

Reference Clocks, Strata

• A reference clock is usually a very accurate time device like an atomic clock or a GPS clock.
• Reference clocks are stratum 0 within the NTP hierarchy
• Servers directly connected to the reference clock are stratum 1
  • Stratum 2 servers receive their time from stratum 1 servers, and so on…
• Stratum 1 servers are also called **primary servers
• Servers with stratum 2 or greater are called secondary servers
• Stratum 15 is the maximum. Anything above is considered unreliable, and a device will not synchronize with it.

Peering

multiple devices of the same strata can ‘peer’ with each other to provide more accurate time, and to provide some amount of resilience to losing connection to lower strata. This is called symmetric active mode. A device can be in symmetric active and server and/or client mode at the same time.

Authentication

NTP Authentication is an optional feature that can be configured. It allows NTP clients to ensure they only sync to the intended servers using a password.

NTP Configuration Notes

• View the basic commands in [[#Configuration#NTP Configuration]]
• It is best to configure multiple NTP Servers - in case one fails or cannot be reached
• NTP only uses UTC — you must configure the time zone correctly on each device for it to display the correct local time
• By default, NTP does NOT update the hardware clock (the calendar) — use ntp update-calendar to keep the hardware clock updated with NTP.
• For NTP devices to operate in symmetric active mode, they must each have the other configured as a peer

Verification (‘show’ Commands)

• show clock {detail}
  • Display the current time of the device’s software clock. The optional detail flag will also display the time source (e.g. the internal clock, or via NTP). A leading asterisk in the time means that the device does not consider the time authoritative/cannot be assumed to be accurate.
• show calendar
  • Display the current time of the device’s hardware clock.
• show ntp associations
  • Displays all the configured NTP servers, and which server is currently being used for synchronization.
• show ntp status
  • Displays whether the device’s clock is synchronized, it’s current stratum (the local device’s stratum), and the IP of the reference clock, among other useful data.

Configuration

Manual Time Configuration

• clock set hh:mm:ss {month | day} {day | month} year
  • Manually set the time of the device’s software clock. You can specify the day first or month first, but only specify one of each!
  • Note this is run from privileged EXEC mode, not global config. Clock settings are not stored in the running-config.
  • This command updates the software clock, not the hardware clock. See calendar set for hardware clock configuration.
• calendar set hh:mm:ss {month | day} {day | month} year
  • Manually set the time of the device’s hardware clock.
• (config)#clock update-calendar
  • Sync the calendar to the clock’s time. (Sync hardware to software) — Keeps them synced; not just a one-off
• (config)#clock read-calendar
  • Sync the clock to the calendar’s time. (Sync software to hardware) — Keeps them synced; not just a one-off
• clock timezone tz-abbreviation
  • Configure the time zone. The tz-abbreviation for your time zone can be found in this list.
• (config)#clock summer-time tz-abbreviation {date | recurring} …
  • Configure daylight-savings/summer time. You can configure to offset clocks once, or on a recurring basis. There will be more necessary inputs depending on which you choose.

NTP Configuration

• (config)#ntp server ip-address {prefer}
  • Add an NTP server to sync time from. Add the optional prefer tag to set one server as the preferred NTP server.
• (config)#ntp source interface-id
  • Use a particular interface as the ‘source’ of NTP messages. Usually, a loopback interface would be used for this.
• (config)#ntp peer ip-address
  • Designate an NTP server as a symmetric active peer.
• (config)#ntp authenticate
  • Enable NTP authentication. Possibly unnecessary, depending on other device configurations.
• (config)#ntp authentication-key key-number md5 key
  • Configure an NTP authentication key (password). You can create multiple keys.
• (config)#ntp trusted-key key-number
  • Identify that a key is trusted.
• (config)#ntp server ip-address key key-number
  • Specify which key to use for which server.
• (config)#ntp master {stratum-number}
  • Force the device to act as a NTP server, even if it is not connected to another NTP server. You can optionally define a stratum; the default is 8.
• (config)#ntp update-calendar
  • Keep the hardware clock (calendar) updated with NTP.