Time is a very critical piece of information in a network setup. Network servers, user workstations, network devices like routers, switches, etc., all need accurate time to produce trustworthy information like usage history or access and activity logs. Maintaining synchronized and coordinated time is therefore a critical part of a networked digital infrastructure.

That’s where an NTP setup becomes useful.

The Network Time Protocol maintains time synchronized among devices in a network. Time information will flow down a tree structure where the levels are known as strata in NTP, every next level having less accuracy with the root of the tree having the most accurate time of the particular network. In an NTP setup time is always passed in UTC.

The NTP devices form pair-wise relationships where every device in a pair has one of the following roles:

  • Server role: Supplies time but does not adjust local clock to client’s clock.
  • Client role: Only adjusts to clock information from the NTP server.
  • Peer role: Synchronizes each other’s clock and are usually on the same stratum level.

For example, servers receiving their time from atomic clocks or GPS devices are stratum 2 devices and may be peers to synchronize each other. The lower the device’s stratum the more accurate the time it produces is considered. The lowest stratum is stratum 1.

For security purposes, the NTP clock updates can be authenticated between the NTP client and the NTP server or between NTP peers.

To provide authentication between NTP devices, NTP (similar to EIGRP routing protocol, for example) uses MD5 where each packet carries a key number and an MD5 signature, with the receiving side using the key number to determine the right key in its local database. The corresponding key number should select matching MD5 signatures on both sides. In the case of NTP, the client will authenticate the server’s signed updates to make sure it is receiving the updates from the right server.

Another useful feature of NTP is its ability to also use Access Control Lists to be selective about what client to send updates to and share time information with.

Authentication and access control lists are very useful to prevent Denial of Service attacks from unknown and unwanted hosts.

GNS3 Labs

In our GNS3 lab we will be using three Cisco 7200 routers VXR NPE-400 with a C7200-SPSERVICESK9-M image as shown in the screenshot below.

We will start with IP connectivity between two adjacent routers and this IP connectivity will be tested with ping tests.

Basic NTP

Our first lab will show how to synchronize time between MASTER_NTP as a server and SLAVE_NTP as a client.

The two devices have two local times set far apart. One device shows Feb 3 2015 while the other shows Mar 1 2002. Actually the second device doesn’t have a hardware clock and the time is reset to the default time of Mar 1 2002 on each reload.

To reduce the amount of time they will take to synchronize, we set the time on SLAVE_NTP closer to the time on MASTER_NTP, barely within a one minute interval. This is not mandatory since whatever the gap between the two clocks they will eventually synchronize.

Now let’s do the “real deal” configuration.

We tell the chosen NTP server to act as a master NTP server with the stratum level of 3:

We configure the chosen NTP client to periodically poll the NTP server at 192.168.0.1:

It’s that easy! The two NTP devices are now going to synchronize.

SLAVE_NTP will transmit an update request to MASTER_NTP which will send back updates.

To see the periodic updates between our SLAVE_NTP router and the reference clock on the MASTER_NTP router, we set debug on.

The debug output shows us the following (among many other things):

The NTP client transmitted (xmit) a packet to NTP server at 192.168.0.1 declaring it to be at stratum level 4 and using NTP version 3.

The NTP client received in return a packet from the NTP server at 192.168.0.1 with stratum level 3 as was set on the CLI.

Let’s check the NTP status on the SLAVE_NTP router.

It first appears to be unsynchronized and at stratum 16:

After synchronization, it shows a stratum level 4 (since it’s synchronizing with a stratum 3 server) and has as reference the MASTER_NTP at 192.168.0.1:

Another couple of show commands can reveal more on what is happening under the hood – show ntp associations and show ntp associations details:

The show ntp associations output shows that the SLAVE_NTP is associated with the MASTER_NTP at 192.168.0.1 of stratum level 3 with the last update 27 seconds ago while the poll interval is 64 seconds.

The show ntp associations details gives us more details:

NTP AUTHENTICATION

As seen earlier, the NTP traffic can be authenticated with a key and an MD5 signature.

To configure authentication for NTP, on “clean” routers, we issue the following commands:

And:

The MD5 word has to be the same on both routers, otherwise the authentication will fail.

Setting “debugging on” on all the three routers:

The debug Output on MASTER_NTP router reveals that:

  • Transport protocol is UDP (stateless transmit packet).
  • Authentication is used for communication between MASTER_NTP and SLAVE_NTP.
  • No authentication is used for router SLAVE_NTP_2 since it was not configured to use MD5 authentication.

Debug output on SLAVE_NTP_2 router:

The debug output on SLAVE_NTP router doesn’t show any use of MD5 authentication:

Let’s check the NTP processes on the three routers:

On MASTER_NTP:

On SLAVE_NTP:

On SLAVE_NTP_2:

We see that the three clocks are synchronized.

Let’s take SLAVE_NTP_2 clock back to the past, prior to the year 2000 when the Y2K bug was a hot topic J and ICQ was the coolest stuff on the internet JJ

Time is set to Jan 1 1999:

The debug output shows back and forth communications:

That results one more time in synchronization:

We can see from the previous examples that the NTP client is the one that decides whether it wants to authenticate the update responses or not.

Individual clients can choose to authenticate or not and still receive the right information from the same NTP server.

NTP and Access Control List

We can also get selective about who we send our time information updates to. For that, Access Control Lists shall come in handy.

Let’s tell our MASTER_NTP to only send NTP responses to SLAVE_NTP (192.168.0.2) and ignore queries from anyone else. This will prevent SLAVE_NTP_2 (192.168.0.6) from receiving updates.

Let’s tell the MASTER_NTP to apply the ACL number 1 to NTP and provide only server access.

Now the following is seen in the debug output.

NTP packets going to SLAVE_NTP are being allowed while the updates going to SLAVE_NTP_2 being filtered out and denied.

We see the results as SLAVE_NTP is transmitting update requests and receiving updates responses:

SLAVE_NTP_2 is no longer receiving time information updates from its configured NTP server. The debug output shows only the packets transmitted (xmit) and not received (rcv).

If we also prevent our MASTER_NTP router to reach 127.127.7.1, its source of time updates:

The MASTER_NTP router shows that it no longer has a reference clock and positions itself at stratum 16 levels:

However, since the MASTER_NTP router is no longer able to receive any updates and synchronize with its source of time information updates, the SLAVE_NTP router will receive updates from the MASTER_NTP router, the latter pretending to be at stratum 0 level.

NTP and MULTICAST

NTP can also use multicast traffic type for authentication, updates and synchronization. Multicast is one of the three network traffic types:

  • Unicast: For any single session or flow a host sends traffic to a single specific destination.
  • Multicast: For any single session or flow a host can send traffic to multiple specific destinations.
  • Broadcast: For any single session or flow a host sends traffic to all members of a subnet (the broadcast domain).

The multicast traffic constitutes an efficient communication type in that it sends only one packet to only the interested parties.

We apply the multicast configurations at the interface level.

The command tells the MASTER_NTP router to send NTP updates to the 224.1.1.1 multicast address:

And also to NTP clients to listen on the 224.1.1.1 multicast address for time information updates from the NTP server.

Since the multicast configurations are applied on the interfaces on both ends of the connection, the MASTER_NTP router on our topology will have two interfaces, each one configured to issue NTP traffic in multicast.

Initially, both the NTP client(s) and the NTP server have a bidirectional communication xmit and rcv packets visible in the individual debug outputs.

The debug output on the SLAVE_NTP router:

Debug output on the MASTER_NTP router:

When the clocks are eventually synchronized, the beauty of multicast kicks in: the server only transmits the periodic updates and the client receives only the periodic updates from the server thus reducing by half the amount of NTP traffic seen on the network.

The following debug output show two packets sent for two NTP updates sent by the MASTER_NTP router.

One packet goes to SLAVE_NTP:

The second packet goes to SLAVE_NTP_2.

If you like this feature, you will love it more in a broadcast environment where the MASTER_NTP router has only to send one multicast packet and the update gets to every multicast member. This can dramatically shrink the NTP traffic and preserve the bandwidth available for use by other protocols or user data.

The following topology will help us to illustrate the multicast NTP in a switched environment.

One multicast packet from the MASTER_NTP router to 224.1.1.1 will reach the two NTP clients. Clients are not transmitting any update requests after clock synchronization has happened on both NTP clients.

This was a brief tutorial on CISCO IOS and time synchronization between network devices with the NTP protocol. I hope the tutorial was clear, concise and useful.