Network Time Protocol
Each networking device has some concept of a date and a time-of-day clock. For instance, the log messages discussed in the first major section of this chapter had a timestamp with the date and time of day listed. Now imagine looking at all the log messages from all routers and switches stored at a syslog server. All those messages have a date and timestamp, but how do you make sure the timestamps are consistent? How do you make sure that all devices synchronize their time-of-day clocks so that you can make sense of all the log messages at the syslog server? How could you make sense of the messages for an event that impacted devices in three different time zones?
Routers, switches, other networking devices, and pretty much every device known in the IT world has a time-of-day clock. For a variety of reasons, it makes sense to synchronize those clocks so that all devices have the same time of day, other than differences in time zone. The Network Time Protocol (NTP) provides the means to do just that
NTP gives any device a way to synchronize their time-of-day clocks. NTP provides protocol messages that devices use to learn the timestamp of other devices. Devices send timestamps to each other with NTP messages, continually exchanging messages, with one device changing its clock to match the other, eventually synchronizing the clocks.
Setting the Time and Time Zone:
NTP’s job is to synchronize clocks, but NTP works best if you set the device clock to a reasonably close time before enabling the NTP client function with the ntp server command. For instance, my wristwatch says 8:52 p.m. right now. Before starting NTP on a new router or switch so that it synchronizes with another device, I should set the time to 8:52 p.m., set the correct date and timezone, and even tell the device to adjust for daylight savings time — and then enable NTP. Setting the time correctly gives NTP a good start toward synchronizing.
A typical configuration of setting time can be seen as shown below.
R1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# clock timezone EST -5
R1(config)# clock summer-time EDT recurring
R1(config)# ^Z
R1#
R1# clock set 20:52:49 21 October 2015
*Oct 21 20:52:49.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 00:36:38
UTC Thu Oct 22 2015 to 20:52:49 UTC Wed Oct 21 2015, configured from console by console.
R1# show clock
20:52:55.051 EDT Wed Oct 21 2015
Observe the command clock timezone EST -5, the clock timezone is used to define the time zone of the router and we specified EST -5 that means the time zone to be set is 5 hours behind the EST.
The clock summer-time part of the second command defines what to do, again with the “EDT” being a field in which you could have used any value. However, you should use a meaningful value. This is the value shown with the time in show commands when daylight savings time is in effect, so I chose EDT because it is the acronym for daylight savings time in that same EST time zone. Finally, the recurring keyword tells the router to spring forward an hour and fall back an hour automatically over the years.
The clock set EXEC command then sets the time, day of the month, month, and year. However, note that IOS interprets the time as typed in the command in the context of the time zone and daylight savings time. In the example, the clock set command lists a time of 20:52:49 (the command uses a time syntax with a 24-hour format, not with a 12-hour format plus a.m./p.m.). As a result of that time plus the two earlier configuration commands, the show clock command (issued seconds later) lists that time, but also notes the time as EDT, rather than UTC time.
Basic NTP Configuration:
Cisco supplies two ntp configuration commands that dictate how NTP works on a router or switch, as follows:
■ ntp master {stratum-level}: NTP server mode — the device acts only as an NTP server, and not as an NTP client. The device gets its time information from the internal clock on the device.
■ ntp server {address | hostname}: NTP client/server mode — the device acts as both client and server. First, it acts as an NTP client, to synchronize time with a server. Once synchronized, the device can then act as an NTP server, to supply time to other NTP clients.
For an example showing the basic configuration syntax and show commands, consider Figure above. With this simple configuration:
■ R3 acts as an NTP server only.
■ R2 acts in client/server mode — first as an NTP client to synchronize time with NTP server R3, then as a server to supply time to NTP client R1.
■ R1 acts in client/server mode — first as an NTP client to synchronize time with NTP server R2. (R1 will be willing to act as a server, but no devices happen to reference R1 as an NTP server in this example.)
! Configuration on R1:
ntp server 172.16.2.2
! Configuration on R2:
ntp server 172.16.3.3
! Configuration on R3:
ntp master 2
R1# show ntp status
Clock is synchronized, stratum 4, reference is 172.16.2.2
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**21
ntp uptime is 1553800 (1/100 of seconds), resolution is 4000
reference time is DA5E7147.56CADEA7 (19:54:31.339 EST Thu Feb 4 2016)
clock offset is 0.0986 msec, root delay is 2.46 msec
root dispersion is 22.19 msec, peer dispersion is 5.33 msec
loopfilter state is ‘CTRL’ (Normal Controlled Loop), drift is 0.000000009 s/s
system poll interval is 64, last update was 530 sec ago.
From the above information we can state that the clock has been synchronized which confirms the NTP client has completed the process of changing its time to match the server’s time and it is at stratum 4(Layer 4). It also confirms the IP address of the server — this device’s reference clock — with the IP address configured as above.
R1# show ntp associations
! This output is taken from router R1, acting in client/server mode
address ref clock st when poll reach delay offset disp
*~172.16.2.2 172.16.3.3 3 50 64 377 1.223 0.090 4.469
* sys.peer, # selected, + candidate, — outlyer, x falseticker, ~ configured
R2# show ntp associations
! This output is taken from router R2, acting in client/server mode
address ref clock st when poll reach delay offset disp
*~172.16.3.3 127.127.1.1 2 49 64 377 1.220 -7.758 3.695
* sys.peer, # selected, + candidate, — outlyer, x falseticker, ~ configured
Next, look at the show ntp associations command output from both R1 and R2 as shown above. This command lists all the NTP servers that the local device can attempt to use, with status information about the association between the local device (client) and the various NTP servers. Beginning with R1, note that it has one association (that is, relationship with an NTP server), based on the one ntp server 172.16.2.2 configuration command on R1. The * means that R1 has successfully contacted the server. You will see similar data from the same command output taken from router R2.
NTP Reference clock and Stratum:
NTP servers must learn the time from some device. For devices acting in NTP client/server mode, the device uses the NTP client function to learn the time.
For instance, when configured with the ntp master command, a Cisco router/switch uses its internal device hardware to determine the time. All computers, networking devices included, need some means to keep time for a myriad of reasons, so they include both hardware components and software processes to keep time even over periods in which the device loses power.
Additionally, NTP servers and clients use a number to show the perceived accuracy of their reference clock data based on stratum level. The lower the stratum level, the more accurate the reference clock is considered to be. An NTP server that uses its internal hardware or external reference clock sets its own stratum level. Then, an NTP client adds 1 to the stratum level it learns from its NTP server, so that the stratum level increases the more hops away from the original clock source.
You can see the NTP primary server (R3) with a stratum of 2. R2, which references R3, adds 1 so it has a stratum of 3. R1 uses R2 as its NTP server, so R1 adds 1 to have a stratum of 4. These increasing stratum levels allow devices to refer to several NTP servers and then use time information from the best NTP server, best being the server with the lowest stratum level.
If you take a look at the ntp status of R3 in above example, you can see that the reference clock is mentioned as 127.127.1.1, which represents that it is using the internal clock of the router. Where as the R2 and R3 gives reference clock as the ip address of the neighbor ntp servers.
Redundant NTP Configuration:
For good design, the enterprise NTP configuration ought to refer to at least two external NTP servers for redundancy. Additionally, just a few enterprise devices should refer to those external NTP servers and then act as both NTP client and server. The majority of the devices in the enterprise, like those shown at the bottom of the figure, would act as NTP clients.
From the above figure we can say that the R1 and R2 are acting as the NTP servers for the routers in stratum 3. The routers R1 and R2 get their reference clock from the server and they can be configured as below.
ntp server time-a-b-nist.gov
ntp server time-a-g.nist.gov
But if in a case when the server becomes unreachable to the routers then they can’t get their reference clocks and hence they will be unable to act as ntp servers for the rest of the network. This issue can be solved by following the steps mentioned below.
1. Establish an association with the NTP servers per the ntp server command.
2. Establish an association with your internal clock using the ntp master stratum command.
3. Set the stratum level of the internal clock (per the ntp master {stratum-level} command) to a higher (worse) stratum level than the Internet-based NTP servers.
4. Synchronize with the best (lowest) known time source, which will be one of the Internet NTP servers in this scenario
That means simply we will give a backup reference clock which si just the internal clock of the router. The configuration looks something like this.
ntp server time-a-b-nist.gov
ntp server time-a-g.nist.gov
ntp master 7
NTP Using a loopback for better availability:
For instance, consider the topology in Figure above, with router R4 on the right acting as NTP server and the other routers acting as clients. R4 has three IP addresses that the clients could put in their ntp server address commands. Now consider what happens when one interface on R4 fails, but only one. No matter which of the three interfaces fails, that IP address on that interface cannot be used to send and receive packets. In that case, for any NTP clients that had referred to that specific IP address
■ There would likely still be a route to reach R4 itself.
■ The NTP client would not be able to send packets to the configured address because that interface is down.
What is needed is a way to send a packet to R4, a way that is not tied to the state of any one interface. That is, as long as there is some path to send packets to R4 itself, allow NTP to keep working. The goal is to avoid the case in which a single interface failure on router R4 also causes NTP to fail.
Cisco uses the router loopback interface to meet that exact need. Loopback interfaces are virtual interfaces internal to Cisco IOS, created via the command interface loopback number, where the number is an integer. Once configured, that loopback interface exists inside that router and is not tied to any physical interface. A loopback interface can be assigned an IP address, routing protocols can advertise about the subnet, and you can ping/traceroute to that address. It acts like other physical interfaces in many ways, but once configured, it remains in an up/up state as long as
■ The router remains up.
■ You do not issue a shutdown command on that loopback interface.
The configuration of a loopback can be seen as shown in the figure below.
! Configuration on R1, a client
ntp server 172.16.9.9
! Configuration on R2 for its server function
interface loopback 0
ip address 172.16.9.9 255.255.255.0
!
ntp master 4
ntp source loopback 0
! Verification on router R2
R2# show interfaces loopback 0
Loopback0 is up, line protocol is up
Hardware is Loopback
Internet address is 172.16.9.9/24
! lines omitted for brevity