Cisco Network Time Protocol Configuration
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
As discussed in the previous Network Time Protocol (NTP) concepts article, the configuration of NTP is not overly complex. The first thing that needs to be determined is the method of NTP operation that best fits the requirements for the target network; once this decision has been made, the steps shown in this article can be used to implement NTP and get the target device’s clock time synchronized.
NTP Configuration Steps
The first thing that must be established in an NTP deployment is where is the master clock going to be coming from; for example, is it coming from an Internet time source, from a local timing device, or from a specific network device (not recommended). From a Cisco perspective, getting the clock from an Internet time source and/or from a local timing device both require the same command (ntp server). To have a specific network device consider itself as a reference clock source, another command is used (ntp master). Table 1 covers the commands that are required to set a network reference clock source:
Table 1 - Reference Clock Source Configuration
|
1 |
Configure the local device to use a remote NTP clock source. |
router(config)#ntp server {ip-address | hostname} |
|
or |
|
1 |
Configure the local device as a NTP reference clock source. Note: The stratum-numbercan be from 1 to 15 and indicates the advertised accuracy of the local reference clock. |
router(config)#ntp master stratum-number |
Once a couple main centrally located devices have configured with a reference clock source, they can then be used within the network as a local time source to all other devices within the network. This prevents all of the devices in the network from requiring external network access to accurately keep time. Typically, these internal time sources are configured in Symmetric active NTP mode; what this means is that if any of these sources were to lose contact with its external time source, it would reference the other internal time sources to synchronize and adjust its time (they act as both server and client to each other).
It is important to note, however, that if all of the master reference clocks are lost within a network, regardless if a device is configured as a NTP client or NTP peer, it will still no longer synchronize itself or other clients. To get around this situation, it is possible to configure NTP orphan mode; while in this mode, if a device loses its primary clock source, it will then begin to announce its internal clock as a reference clock source. It is important to configure the orphan mode with a Stratum level that is less than the current primary reference source.
Table 2 covers the commands that are required to set up devices in Symmetric active NTP mode.
Table 2 - Symmetric Active NTP Mode Configuration
|
1 |
Configure the local device to use a remote NTP clock source (client only). |
router(config)#ntp server {ip-address | hostname} |
2 |
Configure the local device to peer with another NTP device (server and client). |
router(config)#ntp peer {ip-address | hostname} |
3 |
(Optional) Configure NTP Orphan mode. |
router(config)#ntp orphan stratum-number |
It is important to note that the ntp server(because it enables the local NTP process) command will enable other clients to synchronize their clocks to the local device (yes, this seems counterintuitive); for example, the scenario ntp master -> ntp server -> ntp serverwill work. However, these other clients will need to be individually configured. When using the ntp peercommand, the local device will automatically configure the remote device as a peer; however, for this remote configuration to work, the remote device must have NTP enabled (e.g., using the ntp master, ntp server or ntp peercommands). When configuring NTP in this way, the local device is considered in Active Symmetric mode while the remote device is considered in Passive Symmetric mode. If two devices configure each other as peers with the ntp peercommand, then they will both be considered in Active Symmetric mode.
The “normal” clients within a network would typically be configured in one of two ways: using NTP client mode or using NTP broadcast. When configured in NTP client mode, a device will actively poll the NTP time source to ensure that its clock maintains accuracy and synchronization with the time source. When using NTP broadcast, a client will listen for the broadcasts from an NTP broadcast server (time source); when it receives one of these broadcasts, it takes the information contained within the packet to synchronize its clock.
For the most accurate clock, client mode would be preferred over broadcast mode; however, it does require that each device send polling traffic that raises network utilization; in networks with high utilization, this may be a factor in selecting an NTP operational mode.
Table 3 covers the commands that are required to set up devices in Client mode and in Broadcast mode.
Table 3 - Client Mode and Broadcast Mode Configuration
|
1 |
Configure the local device to use a remote NTP clock source (client only). |
router(config)#ntp server {ip-address | hostname} |
|
or |
|
1 |
Configure an NTP broadcast server Note: This command would be configured on a device that is configured to receive time from a reference clock or that is a reference clock. This command is configured on an interface that contains the NTP broadcast clients. |
router(config-if)#ntp broadcast |
2 |
Configure an NTP broadcast client. Note: This command is configured on an interface that contains the NTP broadcast server. |
router(config-if)#ntp broadcast client |
NTP Configuration Scenarios
To pull together the commands that were covered in the previous section (and the concepts that were covered in the previous NTP concepts article), this section covers a couple of common configuration scenarios. You learn the configuration of two devices that separately connect to primary remote clock sources and peer together, and a second scenario where some clients are configured to use a local NTP server and other clients are configured to use NTP broadcast.
Symmetric Active Scenario
In this section, devices R1 and R2 are separately connected to a known high-level clock source and are configured to peer to each other; should the connection to this primary source fail, the peers with synchronize clock between each other. Figure 1 shows the scenario’s topology.
)
Figure 1 Symmetric active scenario topology
Table 4 covers the steps that are required to configure NTP on both devices R1 and R2.
Table 4 - Symmetric Active Scenario Configuration
|
1 |
Enter privileged EXEC mode. |
R1>enable |
2 |
Enter global configuration mode. |
R1#configure terminal |
3 |
Configure R1 to use a primary clock source. |
R1(config)#ntp server 192.5.41.40 |
4 |
Configure R2 as a NTP peer. |
R1(config)#ntp peer 10.10.10.2 |
5 |
Configure R1 to act as an NTP orphan server should its primary clock fail. |
R1(config)#ntp orphan 3 |
|
|
|
1 |
Enter privileged EXEC mode. |
R2>enable |
2 |
Enter global configuration mode. |
R2#configure terminal |
3 |
Configure R2 to use a primary clock source. |
R2(config)#ntp server 192.5.41.40 |
4 |
Configure R1 as a NTP peer. |
R2(config)#ntp peer 10.10.10.1 |
5 |
Configure R1 to act as an NTP orphan server should its primary clock fail. |
R1(config)#ntp orphan 3 |
NTP Client/NTP Broadcast Client Scenario
In this section, two separate sub-scenarios will be covered. First, devices R3 and R4 will be configured in an NTP broadcast server/client relationship with R3 broadcasting a clock source that is received and used by R4 as its clock source. Second, device R5 will be configured as a NTP polled client using devices R1 and R2 as reference clock sources.
Figure 2 shows these scenarios’ topology.
)
Figure 2 NTP client/NTP broadcast client scenario topology
Table 5 covers the steps that are required to configure NTP on devices R3, R4 and R5.
Table 5 - NTP Client/NTP Broadcast Client Scenario Configuration
|
1 |
Enter privileged EXEC mode. |
R3>enable |
2 |
Enter global configuration mode. |
R3#configure terminal |
3 |
Configure R1 as a primary clock source. |
R3(config)#ntp server 1.1.1.1 |
4 |
Configure R2 as a primary clock source. |
R3(config)#ntp server 2.2.2.2 |
5 |
Enter interface configuration mode. |
R3(config)#interface fa0/0 |
6 |
Configure R3 as an NTP broadcast server. |
R3(config-if)#ntp broadcast |
|
|
|
1 |
Enter privileged EXEC mode. |
R4>enable |
2 |
Enter global configuration mode. |
R4#configure terminal |
3 |
Enter interface configuration mode. |
R4(config)#interface fa0/0 |
4 |
Configure R4 as an NTP broadcast client. |
R4(config-if)#ntp broadcast client |
|
|
|
1 |
Enter privileged EXEC mode. |
R5>enable |
2 |
Enter global configuration mode. |
R5#configure terminal |
3 |
Configure R1 as a primary clock source. |
R5(config)#ntp server 1.1.1.1 |
4 |
Configure R2 as a primary clock source. |
R5(config)#ntp server 2.2.2.2 |
Summary
As can be seen from this article, the configuration of NTP in almost any scenario is not overly complex from a basic configuration standpoint. The real thing that needs to be done on a network that includes multiple LAN’s is to plan how the time structure is organized. Generally speaking, it is best if any network nodes have at least a Stratum 2 or better clock source directly configured. Hosts, on the other hand, can be configured with a Stratum 3 clock source without much effect on perceived clock accuracy. Remember that for every NTP hop away (notice: not network hop), the clock accuracy goes down by a single stratum level. Now take the information learned within this article and the concepts article, and get NTP configured!