Configure and verify NTP operating in a client and server mode

Configure and verify NTP operating in a client and server mode

NTP (Network Time Protocol) is used to allow network devices to synchronize their clocks with a central source clock. For network devices like routers, switches or firewalls this is very important because we want to make sure that logging information and timestamps have the accurate time and date. If you ever have network issues or get hacked, you want to make sure you know exactly what and when it happened.

Normally a router or switch will run in NTP client mode which means that it will adjust its clock based on the time of a NTP server. Basically the NTP protocol describes the algorithm that the NTP clients use to synchronize their clocks with the NTP server and the packets that are used between them. A good example of a NTP server is ntp.pool.org. This is a cluster of NTP servers that many servers and network devices use to synchronize their clocks.

Understanding How NTP Works

NTP synchronizes timekeeping among a set of distributed time servers and clients. With this synchronization, you can correlate events to the time that system logs were created and the time that other time-specific events occur. An NTP server must be accessible by the client switch.

NTP uses the User Datagram Protocol (UDP) as its transport protocol. All NTP communication uses Coordinated Universal Time (UTC), which is the same as Greenwich Mean Time. An NTP network usually gets its time from an authoritative time source, such as a radio clock or an atomic clock that is attached to a time server. NTP distributes this time across the network. NTP is extremely efficient; no more than one packet per minute is necessary to synchronize two machines to within a millisecond of one another.

NTP uses a stratum to describe how many NTP hops away a machine is from an authoritative time source. A stratum 1 time server has a radio or atomic clock that is directly attached, a stratum 2 time server receives its time from a stratum 1 time server, and so on. A machine running NTP automatically chooses as its time source the machine with the lowest stratum number that it is configured to communicate with through NTP. This strategy effectively builds a self-organizing tree of NTP speakers.

NTP has two ways to avoid synchronizing to a machine whose time might be ambiguous:

  • TP never synchronizes to a machine that is not synchronized itself.
  • NTP compares the time that is reported by several machines and does not synchronize to a machine whose time is significantly different from the others, even if its stratum is lower.

The communications between machines running NTP, known as associations, are usually statically configured; each machine is given the IP addresses of all machines with which it should form associations. An associated pair of machines can keep accurate timekeeping by exchanging NTP messages between each other. However, in a LAN environment, you can configure NTP to use IP broadcast messages. With this alternative, you can configure the machine to send or receive broadcast messages, but the accuracy of timekeeping is marginally reduced because the information flow is one-way only.

Cisco’s implementation of NTP does not support stratum 1 service; it is not possible to connect to a radio or atomic clock. We recommend that you obtain the time service for your network from the public NTP servers available on the IP Internet. If the network is isolated from the Internet, Cisco’s NTP implementation allows a machine to be configured so that it acts as though it is synchronized using NTP, when it actually has determined the time using other methods. Other machines synchronize to that machine using NTP.

NTP Configuration

Below shows the default NTP configuration

FeatureDefault Value
Broadcast client modeDisabled
Client modeDisabled
Broadcast delay3000 microseconds
Time zoneNot specified
Offset from UTC0 hours
Summertime adjustmentDisabled
NTP serverNone specified
Authentication modeDisabled
Configuring NTP on the Switch

Enabling NTP in Broadcast-Client Mode

Enable the switch in NTP broadcast-client mode if an NTP broadcast server, such as a router, regularly broadcasts time-of-day information on the network. To compensate for any server-to-client packet latency, you can specify an NTP broadcast delay (a time adjustment factor for the receiving of broadcast packets by the switch). To enable NTP broadcast-client mode on the switch, perform this task in privileged mode:

TaskCommand
Step 1 Enable NTP broadcast-client mode.set ntp broadcastclient enable
Step 2 (Optional) Set the estimated NTP broadcast packet delay.set ntp broadcast delay microseconds
Step 3 Verify the NTP configuration.show ntp [noalias]

This example shows how to enable NTP broadcast-client mode on the switch, set a broadcast delay of 4000 microseconds, and verify the configuration:

Console> (enable) set ntp broadcastclient enable
NTP Broadcast Client mode enabled
Console> (enable) set ntp broadcastdelay 4000
NTP Broadcast delay set to 4000 microseconds
Console> (enable) show ntp

Current time: Tue Jun 23 1998, 20:25:43
Timezone: '', offset from UTC is 0 hours
Summertime: '', disabled
Last NTP update:
Broadcast client mode: enabled
Broadcast delay: 4000 microseconds
Client mode: disabled

Configuring NTP in Client Mode

Configure the switch in NTP client mode if you want the client switch to regularly send time-of day requests to an NTP server. You can configure up to ten server addresses per client. To configure the switch in NTP client mode, perform this task in privileged mode:

TaskCommand
Step 1 Specify the IP address of the NTP server.set ntp server ip_addr
Step 2 Enable NTP client mode.set ntp client enable
Step 3 Verify the NTP configuration.show ntp [noalias]

This example shows how to configure the NTP server address, enable NTP client mode on the switch, and verify the configuration:

Console> (enable) set ntp server 172.20.52.65
NTP server 172.20.52.65 added.
Console> (enable) set ntp client enable
NTP Client mode enabled
Console> (enable) show ntp

Current time: Tue Jun 23 1998, 20:29:25
Timezone: '', offset from UTC is 0 hours
Summertime: '', disabled
Last NTP update: Tue Jun 23 1998, 20:29:07
Broadcast client mode: disabled
Broadcast delay: 3000 microseconds
Client mode: enabled

Leave a Reply
Your email address will not be published. *

This site uses Akismet to reduce spam. Learn how your comment data is processed.