Free CCNA | NTP | Day 37 | CCNA 200-301 Complete Course

Welcome to Jeremy’s IT Lab. This is a free, complete course for the CCNA. If you like these videos, please subscribe to follow along with the series.

Also, please like and leave a comment, and share the video to help spread this free series of videos. Thanks for your help. In this video we will cover NTP, Network Time Protocol.

All computers have an internal clock, including network devices. For a variety of reasons that we will cover in this video, it’s important that these devices have an accurate clock that is synchronized with other devices. That’s the purpose of NTP.

NTP is covered in exam topic 4. 2, which says that you must be able to configure and verify NTP operating in client and server mode. Over the next section of the course I will be covering all of these subtopics in section 4.

0, IP Services. This video on NTP will be the first. Here’s what we’ll cover in this video.

First I’ll briefly explain why time is important for network devices. Then I’ll show you how to manually configure the time on a device, without using NTP. Then we’ll cover the basics of NTP, Network Time Protocol.

Finally I’ll show you how to configure NTP on Cisco devices. Make sure to watch until the end of the video for a bonus question from Boson Software’s ExSim for CCNA. ExSim practice exams simulate the style and difficulty of the real CCNA better than any other practice exams.

I used them myself, and I highly recommend them. If you want to get Boson ExSim, follow the link in the video description. First, let me briefly introduce time on network devices and why it’s important.

All devices have an internal clock. That includes routers, switches, your PC, smart phones, whatever. In Cisco IOS, you can view the time with the SHOW CLOCK command.

Here’s some sample output. So, I used this command at 12:16 AM, 0 seconds, 857 milliseconds. On Saturday, December 26th 2020.

The time zone is the default of UTC. Remember that, the default time zone is UTC, Coordinated Universal Time. If you use the SHOW CLOCK DETAIL command you can see the time source of the device.

In this case it is using the hardware calendar as its time source. The hardware calendar is the built-in internal clock of the device. This is the time source by default.

However, notice this asterisk here. It means that this time is not considered authoritative. The device isn’t confident that this time is accurate.

The internal hardware clock of a device will drift over time, so it is not the ideal time source. Now, why is it important to have an accurate time source? From a CCNA perspective, or really the perspective of most network engineers, the most important reason to have accurate time on a device is to have accurate logs for troubleshooting.

Devices keep logs of various events that occur, such as an interface being enabled or disabled, OSPF neighbor relationships being formed or broken, device restarts, etc. Syslog, the protocol used to keep device logs, is a CCNA exam topic and will be covered in a later video. But let’s take a quick look at some device logs now.

The command to view a device’s logs is SHOW LOGGING. Let’s say I’m a network admin and I got a phone call around 1AM saying that the network connection has been unstable. So, to investigate I log into one of the devices and check the logs.

Here’s a portion of the output from one of the devices, R2. Notice this series of messages about OSPF neighbor relationships. There are multiple messages about neighbor 10.

0. 0. 6 moving to the FULL state and to the DOWN state.

You can see the timestamps here, indicating when these events occurred, from about 1:06AM to 1:09AM. Note that I will cover these log messages in depth in a later lesson about Syslog, so don’t worry about the details for now. I just want to show why time is important.

Anyway, I then checked the device’s clock and the current time is 1:17AM on December 27th 2020. Then I log into R2’s neighbor 10. 0.

0. 6, which in this case is R3, to investigate further. Here’s some of the output from SHOW LOGGING.

You can see those same messages about an OSPF neighbor moving between the FULL and DOWN states, and also some messages about an interface going UP and DOWN. However, the timestamps show a totally different time than on R2. After checking the clock I realize that R3 thinks it’s 4:30PM on May 23rd 2008.

This is going to make it much more difficult to correlate the logs of these devices. In this case, it’s a fairly simple issue. We can see that an interface going down caused some problems, so we can investigate why that happened.

But when you have to troubleshoot more complex issues on devices with logs full of thousands of messages, it gets much more difficult and accurate time is very important. So let’s see how to manually configure the time on a device. You can manually configure the time on the device, the clock in the software of the device, with the CLOCK SET command.

Let me walk you through it. I entered CLOCK SET and used the question mark to see the options. Using the format of hours, minutes, seconds, I entered the time.

The next option is either the day of the month or the month itself. You can enter them in either order. I entered the day first, and then the month.

The next option is the year. I entered the year, 2020, and checked the options. CR, carriage return, basically means press the enter key to enter the command.

There are no other options. After entering the time I checked with SHOW CLOCK DETAIL, and the newly configured time is displayed. The time source also has changed to ‘user configuration’.

Notice that all of these commands are done from privileged-exec mode, not global config mode. These clock configurations aren’t part of the device’s running configuration, they are separate. Here’s one more point a lot of people might not be aware of.

Although the hardware calendar (the built-in clock) is the default time-source, the hardware clock and software clock are separate and can be configured separately. So let’s see how to configure the hardware clock. You can manually configure the hardware clock with the CALENDAR SET command.

So, from now on I will use the term ‘clock’ to refer to the clock in the software of the device, and ‘calendar’ to refer to the hardware clock. So, the command syntax is the same as CLOCK SET, only the keyword CALENDAR is different. Set the time, and then either the day or the month.

I set the day, and then the month, and the next option is the year. Then I set the year, and then used the command SHOW CALENDAR to view the time. Typically you want to synchronize the clock and calendar.

I can’t think of a good reason not to sync them. Use the command CLOCK UPDATE-CALENDAR to sync the calendar to the clock’s time. The calendar will update its time to match the clock.

Or, use the command CLOCK READ-CALENDAR to sync the clock to the calendar’s time. In this case the clock will update its time to match the calendar. Let me demonstrate.

First let me demonstrate CLOCK UPDATE-CALENDAR. I viewed R2’s clock, and the time was about 2:38 PM on December 27th 2020, and let’s say that’s the correct time. However the calendar was about 12:00AM.

So, I used the CLOCK UPDATE-CALENDAR command. And now you can see the calendar has been updated to match the time of the clock. Next let’s see the opposite situation, when the calendar’s time is correct but the clock’s time is incorrect.

The clock says it’s about 12AM on September 6th 1993. The calendar has the correct time of 2:55PM on December 27th 2020. So, I used the command CLOCK READ-CALENDAR.

And the clock updated its time to match the calendar’s time. Next let’s see how to configure the timezone. You can configure the time zone with the CLOCK TIMEZONE command.

Let me walk you through it. First I used the DO SHOW CLOCK command to view the time, around 3:13PM in the default time zone of UTC. Notice I used DO SHOW CLOCK from global config mode, not privileged exec mode like the other commands.

That’s because the timezone is configured from global config mode and becomes part of the running config of the device. So, here’s the CLOCK TIMEZONE command. The first option is the name of the time zone.

This is just a word, the device doesn’t actually check if it’s the name of a real time zone. So, I configured JST for Japan Standard Time, and the next option is the hours offset from UTC. JST is 9 hours ahead of UTC, so I entered 9 and checked the options.

For JST I don’t have to enter the minutes offset, so I entered the command as is, CLOCK TIMEZONE JST 9. Then I viewed the clock. Notice the time zone has changed from UTC to JST, but also the time itself has jumped 9 hours ahead.

This is because the previous time configurations were done in UTC. When changing the time zone to JST, 9 hours ahead, the clock automatically changed. But currently the time actually is about 3:15 PM JST, so I adjusted the clock once more, and now it displays the correct time in the correct time zone.

The time zone is important because, as you’ll see soon, NTP only uses UTC, so you have to adjust each device to the correct time zone. There’s one more aspect of manual time configuration to cover. That is daylight saving time, also known as summer time, depending on the country.

Not all countries do this, but in many countries we adjust our clocks forward once a year and then back once a year. You can configure Cisco devices to do that automatically. Now, I live in Japan at the moment and Japan doesn’t do daylight saving time, so I’ll use my home country of Canada as an example.

In most parts of Canada we set the clocks forward one hour on the second Sunday of March at 2AM, and then set the clocks back one hour on the first Sunday of November at 2AM. The command to configure this is CLOCK SUMMER-TIME, and this is also done from global config mode. The first option is the name of the time zone.

My time zone back in Canada is EST, but during daylight saving time the name changes to EDT, so that’s what I set. Then we can set a specific date to change to daylight saving time with the keyword DATE, but the more useful option is the second one, RECURRING. This makes summer time start and end on the specified days every year.

After recurring, we specify which week in the month it will start. In Canada it starts on the second Sunday of March, so I specified 2. Next is the weekday, so I entered Sunday.

After that it’s the Month, March for Canada. Finally the time, I entered 2AM. Okay, so that’s all for the start time.

Now we enter the end of daylight saving time in the same order. 1 for the first week, the weekday, Sunday, the month, November, and finally the time, 2AM again. Optionally you can specify the offset, but the default is 60 minutes and I think that’s what most countries use by default.

So, that’s all for the command. Notice the dollar signs here. This command is a little long, too long for one line, so these dollar signs mean that some of the output is cut off and can’t be displayed on a single line in the terminal.

So, I typed it out here. CLOCK SUMMER-TIME, the time-zone name, RECURRING, and then the start of daylight saving time and the end of daylight saving time. Okay, that’s the CLOCK SUMMER-TIME command.

So, that’s all for manual time configuration. Here are the time commands we just looked at. The CLOCK SUMMER-TIME command is a little long so I simplified the format.

Just remember that for the ‘start’ and ‘end’ you need to specify the week, weekday, month, and time. Okay, let’s move on to the next topic. And the next topic is the main topic of this video, NTP, Network Time Protocol.

Manually configuring the time on devices is not scalable. In a large network, manually configuring the time on every router, every switch, firewall, PC, phone, etc, would be a huge task and a huge waste of time. Not only that, the manually configured clocks will drift, resulting in inaccurate time.

NTP allows automatic syncing of time over a network to NTP servers. The device you’re using to watch this video is almost certainly using NTP. For example, on my Windows 10 PC you can see that my computer is set to automatically synchronize with time.

windows. com. That is an NTP server somewhere on the Internet.

And actually, you can configure this. So, for example, if I wanted my PC to synchronize to a different NTP server, for example Google’s server, I can change it here. This point is separate from the topic, but those names like ‘time.

windows. com’ are resolved to IP addresses using the protocol DNS. DNS will be covered in a future video, it’s an important CCNA topic.

In the CLI of my Windows PC, I used the command NSLOOKUP time. windows. com.

It contacted the DNS server I’m using, which is Google’s DNS server with an IP address of 8. 8. 8.

8. Then Google’s server gave me the answer. The actual IP address of the Windows NTP server is 20.

43. 94. 199.

I tried the same with Google’s NTP server, NSLOOKUP time. google. com.

Again, my PC asked the Google DNS server for the IP address of time. google. com, and here is the answer.

You can see four IPv6 addresses and four IPv4 addresses used by time. google. com.

Anyway, DNS will be covered in detail in another video, I just wanted to give you a little preview. Okay, back to NTP. So, NTP clients request the time from NTP servers, and then they synchronize their time to the time of the server.

It’s possible for a device to be an NTP server and client at the same time. So, it will sync its time to a server, and then other devices will sync their time to it. These are rough numbers, they can vary, but NTP allows accuracy of time within about 1 millisecond if the NTP server is in the same LAN, or within about 50 milliseconds if connecting to the NTP server over a WAN or the Internet.

Some NTP servers are ‘better’ than others. The ‘distance’ of an NTP server from the original reference clock is called stratum. The farther away from the reference clock, the higher the stratum.

If the stratum level of a server is high, it is considered less accurate. NTP uses UDP port 123 to communicate. Remember that one, in addition to the ones we covered in the TCP&UDP video.

Let me briefly introduce those reference clocks. 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.

They are as close to the time source as possible, because they are the time source. NTP servers directly connected to reference clocks are stratum 1. You’ll see more about this NTP hierarchy in the next slide.

Here’s an example of a reference clock, this one is from a United States Naval observatory. Cisco devices aren’t able to get their time directly from a stratum 0 reference clock like this, but they can get their time from a stratum 1 NTP server. This diagram demonstrates the NTP hierarchy.

These reference clocks are stratum 0, they are the original time sources like the US Navy clock we saw in the last slide. The servers directly connected to those reference clocks are stratum 1 servers. Then, stratum 2 NTP servers get their time from stratum 1 servers.

And stratum 3 servers get their time from stratum 2 servers. That’s how the NTP hierarchy works. However, stratum 15 is the maximum.

Anything above that is considered unreliable and the device will not synchronize to it. Another aspect of NTP shown in this diagram is NTP peering. Devices can peer with devices at the same stratum to provide more accurate time.

This also acts as a backup, in case they lose access to the lower-stratum NTP server. This mode is called ‘symmetric active’ mode. So, Cisco devices can operate in three NTP modes.

Server mode, Client mode, and symmetric active mode. They can be in all three of those modes at the same time, too. And finally, an NTP client can sync to multiple servers.

For example, in this diagram this stratum 2 server is getting its time from these two stratum 1 servers. Here’s some extra terminology you should know. NTP servers which get their time directly from reference clocks are also called primary servers.

They sync their time directly to a reference clock, they are stratum 1 servers. NTP servers which get their time from other NTP servers are called secondary servers. They operate in server mode and client mode at the same time.

So, servers with stratum 2 or above are secondary servers. Okay I think that’s enough lecturing, let’s get more practical and I’ll explain some more aspects of NTP as we configure it on some Cisco routers. Here’s the network topology I’ll be using for this demonstration.

I’m showing you an actual screenshot of my GNS3 topology to show you this. The Internet cloud. Through this Internet cloud in GNS3, these virtual routers are actually connected to the real Internet, and in this demonstration I will make R1 sync to Google’s NTP servers over the Internet.

This is a cool part of GNS3 that isn’t available in simulators like Packet Tracer. Now, you might be wondering why this point-to-point connection between R1 and the Internet is using a /24 prefix length. That’s just how this cloud is configured by default in GNS3.

For a real point-to-point connection to an Internet Service Provider I’d use a /30 or /31. So let’s configure R1 to sync to Google’s NTP servers. Once again, here’s the NSLOOKUP I did for Google’s NTP servers.

I’ll be configuring all four of these IPv4 addresses on R1 as NTP servers. Here’s the command. NTP SERVER, followed by the server IP address.

The order of these doesn’t matter. R1 will ask all of them for the time and select whichever gives the best, quickest responses. And the one it selects to sync to might change if the currently selected server’s responses start slowing down or it stops responding altogether.

So, it’s best to specify multiple NTP servers so that R1 can always have a reliable source of time. Now, if you want to manually make the device prefer one of the configured servers, you can add PREFER to the end of the command. So, this would make 216.

239. 35. 0 the preferred NTP server, and the others will be backups.

But for this demonstration, I didn’t use the PREFER keyword, and in the next slide we’ll see which of these NTP servers was selected as the best. Here’s a very important SHOW command for NTP, SHOW NTP ASSOCIATIONS. It shows all of the NTP servers we just configured.

Here are the servers. Now, you don’t have to understand all of the output of this command, but let me point out a few things. Notice the asterisk next to 216.

239. 35. 0, meaning ‘sys.

peer’. This means that this is the NTP server that R1 is currently syncing to. This plus sign next to the other servers means they are candidates, but R1 is not currently syncing its time to them.

The tilde next to all of the servers simply means that they were configured, which I did in the previous slide with the NTP SERVER command. If you see an NTP server marked as an ‘outlyer’ or ‘falseticker’ it means R1 will not sync to that server, for example R1 might think its time is inaccurate. The details of these states are beyond the CCNA, you just need to know the basics.

Here you can see the reference clock of each NTP server. All of these servers are using Google’s own reference clock as their reference. That is a stratum 0 reference clock, so here in the ‘st’ column you can see that all four of these servers have a stratum level of 1.

I used the SHOW NTP ASSOCIATIONS command again, and now you can see that R1 has selected 216. 239. 35.

4 as the server it wants to sync to. This will constantly change as R1 continues interacting with the servers and decides which one is the best to sync to. Now let’s look at another useful NTP SHOW command.

That command is SHOW NTP STATUS. There’s a lot of information here that you don’t need to look at, but let’s check out the top line. Clock is synchronized, that’s good.

It means that at least one of the NTP servers we configured was good and R1 was able to sync to it. Stratum 2, this is R1’s stratum. Because R1 is synchronizing its time to Google’s NTP severs, it automatically becomes an NTP server itself with a stratum level 1 higher than Google’s NTP servers.

So, that’s why R1’s stratum level is 2. Finally you can see the address of the reference clock. This time it’s not 216.

239. 35. 0 or .

4, it’s . 12. Now let’s check R1’s clock and calendar again.

I used DO SHOW CLOCK DETAIL. The time is correct, however the time zone is not. NTP uses only the UTC time zone.

You must configure the appropriate time zone on each device. I haven’t configured R1’s time zone yet, so I’ll do that. I also used the DO SHOW CALENDAR command.

Notice that the time is not synced up with the software clock. NTP doesn’t update the calendar by default, but let’s set it so that it does update the calendar. So, I configured my time zone of JST here on R1.

Then I used the NTP UPDATE-CALENDAR command. This configures the router to update the hardware clock, the calendar, with the time learned via NTP. So I checked the clock and the calendar again, and now they are both synced.

You might be wondering why you would want to sync the hardware clock. The hardware clock tracks the date and time on the device even if it restarts, power is lost, etc. When the system is restarted, the hardware clock is used to initialize the software clock.

So, it’s a good idea to keep the hardware clock accurate, although it’s not totally essential. Now we’re going to move on to R2 and configure NTP on it as well. Usually in a small network like this you’d just configure all of the devices to sync to public NTP servers like Google’s.

But for the purpose of this lesson I’ll configure R2 to use R1 as an NTP server. But before doing that, I’ll configure a loopback interface on R1. Note that I’ve configured OSPF in this network so all of these routers are sharing routes, including the route to R1’s loopback interface.

I also instructed R1 to use loopback0 as the source of its NTP messages with the NTP SOURCE loopback0 command. So, any NTP messages it sends will come from the address 10. 1.

1. 1. Why configure a loopback interface?

Well, let’s say I configured R2 to use 10. 0. 0.

1, R1’s G0/1 interface, as an NTP server. In normal situations it would be able to send NTP request messages and get replies from R1. But what if the interface failed for some reason?

R2 would suddenly lose its NTP server, because the availability of address 10. 0. 0.

1 is dependent on the status of R1’s G0/1 interface. But what if we configure this loopback interface on R1 and tell R2 to use its address, 10. 1.

1. 1, as its NTP server? Even if the closest path to R1, via R2’s G0/0 interface, is down, R3 will still advertise a route to 10.

1. 1. 1 to R2 and therefore R2 will still be able to communicate with its NTP server, R1.

I gave a similar demonstration of why loopback interfaces are useful in the OSPF videos. Basically they are useful because they provide the router an address you can use to reach it which isn’t dependent on the status of any particular physical interface. Okay, so on R2 I configured NTP SERVER 10.

1. 1. 1, and then checked DO SHOW NTP ASSOCIATIONS.

Notice the asterisk next to 10. 1. 1.

1, that means R2 has selected R1 to sync to. R1’s reference clock is displayed here. This is the IP address of one of Google’s NTP servers, because that’s the server that R1 is syncing to.

And here R1’s stratum level of 2 is displayed. Google’s reference clock is stratum 0, Google’s NTP servers are stratum 1, and now R1 is stratum 2. So, what stratum is R2?

I checked with DO SHOW NTP STATUS. R2’s stratum is 3, because it got its time from a stratum 2 server, R1. R2’s reference of 10.

1. 1. 1, R1, is displayed also.

As a reminder, remember to use the NTP SOURCE command to specify the loopback interface as the source of NTP packets on R1, if you don’t do that R2 and R3 won’t want to sync with R1. Finally I configured NTP on R3. Here are the configurations.

By the way, I configured a loopback interface on R2 as well, that’s 10. 2. 2.

2. I configured both R1 and R2 as NTP servers to demonstrate an important point. Between R1, 10.

1. 1. 1, and R2, 10.

2. 2. 2, which NTP server do you think R3 will prefer, and why?

Let’s check. R1 is the preferred NTP server. Why is that?

It’s because of the stratum levels. NTP servers with lower stratum levels are preferred, because they are closer to the source. So, they are considered more accurate.

Okay, so I’ve shown you how to make a Cisco device sync to an NTP server using the NTP SERVER command. For the next few concepts I’ll use a different network, as shown below. If a device is already syncing to an NTP server, meaning it’s an NTP client, it automatically acts as an NTP server too and other devices can sync to it.

But what if there is no NTP server to sync to? You probably still want the devices in the network to have the same time, even if it is slightly inaccurate compared to the actual time. So, how can you manually configure a Cisco device to operate as an NTP server, even though it isn’t synced to another NTP server?

This is the command. NTP MASTER. As the description says it makes the device act as an NTP master clock.

So, on R1 I used the NTP MASTER command. Notice that I can specify the stratum of R1. However I chose to just enter the command, which means it will use the default stratum level.

What’s the default? Let’s check. I used SHOW NTP ASSOCIATIONS.

The address of R1’s NTP server is now 127. 127. 1.

1. What kind of address is that? It’s a loopback address.

Remember, the entire 127. 0. 0.

0/8 address range is reserved for loopback addresses. Loopback addresses and loopback interfaces are different concepts, although the names are similar, so don’t confuse the terms. Loopback interfaces are virtual interfaces in the router and their addresses can be advertised to other devices using OSPF etc.

Loopback addresses are a totally different concept, these addresses are totally internal to the local device and can’t be reached by other devices. Basically, R1 is using itself as its reference clock. Anyway, the stratum level of this server is 7.

So, what is the actual stratum level of R1? I used SHOW NTP STATUS to check, and the answer is 8. So, remember that the default stratum of the NTP MASTER command is 8.

And I configured R2 and R3 to use R1 as their NTP server. We’ve already covered that enough so let’s move on to the next topic, symmetric active mode. So let’s configure symmetric active mode between R2 and R3.

They both have a stratum level of 9, so they are equals in terms of NTP. They can become peers and help each other sync their time, and also act as backups in case they lose contact with R1. The command to configure symmetric active mode is NTP PEER, followed by the peer’s address.

So, I configured R3 as R2’s peer. And here is the entry for R3 in R2’s NTP association table. R3’s reference clock is R1, 10.

0. 12. 1.

Its stratum level is 9, because R1’s is 8. I did the same configurations on R3, specifying R2 as the peer. Again, the reference clock is R1 and the stratum level is 9.

Okay the final topic for today is NTP authentication. I can’t say for sure if this is on the exam or not, some study resources include it and some don’t. But I recommend learning these few commands just in case there are some questions about NTP authentication on the CCNA exam.

NTP authentication can be configured, but it is optional. You don’t need to configure it. It allows NTP clients to ensure that they only sync to the intended servers.

They will check that the server is using the same password as them, and only sync if they are the same. Here’s how you configure NTP authentication in Cisco IOS, make sure the server and clients are configured the same. First, enable NTP authentication with the command NTP AUTHENTICATE.

Then you create the authentication key or keys. You can create multiple keys, but don’t worry about that for the CCNA-level. So, for the ‘key-number’ field just use a number of 1, and then the ‘key’ field is the password itself.

Then you have to specify which key or keys are trusted. Don’t forget this step. Creating the key uses one command, NTP AUTHENTICATION-KEY, and specifying that it is trusted uses another command, NTP TRUSTED-KEY.

Finally you must specify which key to use for each server. This command isn’t needed on the server itself. Now let’s look at these configurations on R1, R2, and R3.

Here are the configurations. On all three routers I used NTP AUTHENTICATE, NTP AUTHENTICATION-KEY 1 MD5 with a password of jeremysitlab, and NTP TRUSTED-KEY 1. Then on the clients R2 and R3 only, I used the command NTP SERVER 10.

0. 12. 1 KEY 1.

So, they will use key number 1, which is jeremysitlab, to authenticate R1. I also did one extra command, NTP PEER, followed by the peer address, and KEY 1. This adds authentication to the peer relationship between R2 and R3.

Okay, so that’s all you need to configure NTP authentication for the CCNA. In addition to the manual time configuration commands, we just covered a lot of NTP commands. To help you review, here are the commands we looked at.

If you don’t remember any of these, go back in the video to review. Before moving on to the quiz, let’s review what we covered. We looked at why time is important for network devices.

The main reason from a CCNA perspective is for accurate logging of events on your network devices. Then we looked at how to manually configure the time and date in Cisco IOS. Then we looked at the basics of NTP and how to configure it.

We covered a lot already, but there is so much more to learn about NTP. However I think the information we covered in this video will be more than enough for the CCNA exam. Make sure to watch until the end of the quiz for a bonus practice question from Boson Software’s ExSim for CCNA, the best practice exams for the CCNA.

Okay, let’s go to quiz question 1. Which of the following commands will cause the router to adjust its software clock to match the hardware clock? Here are the commands.

Pause the video to think about your answer. The answer is C, CLOCK READ-CALENDAR. This will cause the router to adjust its software clock to match the hardware clock.

D will do the opposite, it will cause the router to adjust its hardware clock to match the software clock. A and B are not valid commands. Okay, let’s go to question 2.

Which of the following commands can be used to configure the time zone of the device? Here are the commands. Pause the video to think about your answer.

The answer is D. From global config mode, CLOCK TIMEZONE, then the timezone name and offset. Unlike some other time commands, this command is done from global config mode and not privileged exec mode.

You cannot configure the time zone with the CLOCK SET command. Okay, let’s go to question 3. Examine the output below.

Which of the following commands was configured on R1? Here are the options. Pause the video now to think about your answer.

The answer is A, NTP MASTER 9. Because the address of R1’s NTP association is 127. 127.

1. 1, a loopback address, we know that the NTP MASTER command was used. However, in this case the stratum must have been specified as in A, NTP MASTER 9.

The default stratum of the NTP MASTER command is 8, so both C and D would have the same effect. In that case, however, SHOW NTP ASSOCIATIONS should display a stratum of 7. In this output the stratum is 8, so the command NTP MASTER 9 must have been used.

Regarding option B, the command NTP SERVER 127. 127. 1.

1 would be rejected by the router. You can’t manually configure a loopback address as the NTP reference clock, even though it displays this way when the NTP MASTER command is used. Okay, let’s go to question 4.

Which of the following commands configures the router to operate in NTP client mode? Here are the options. Pause the video now to think about your answer.

The answer is C, NTP SERVER 216. 239. 35.

0. It configures R1 to become a client of the NTP server 216. 239.

35. 0. A, NTP PEER, configures symmetric active mode.

B, NTP MASTER, configures server mode. And D, NTP CLIENT, is not a valid command. Okay, let’s go to question 5.

Which of the following commands must be configured on an NTP client to enable NTP authentication? Select all that apply. Here are the options.

Before I show the answers, let me say that in the actual CCNA exam when you have to select multiple answers, the question will always tell you how many to select. Select two, select three, etc. But for a challenge, let’s try ‘select all that apply’.

Okay, pause the video to think about your answers. The answers are C, D, F, and G. C enables NTP authentication on the device.

D creates the authentication key. F specifies that the key is a trusted key. And G specifies the key to use with the server.

Okay, that’s all for the quiz. Now let’s take a look at a bonus question in Boson ExSim for CCNA. Okay here's today's Boson ExSim practice question.

Which of the following is enabled on a Cisco router when you issue the NTP SERVER command from global configuration mode? Select the best answer. Here are the options A, static client mode.

B, symmetric active mode. C, broadcast client mode. D, server mode.

And E, authentication. Okay pause the video now to select the best answer. Okay let's check.

So this is closely related to one of the quiz questions we just did, so hopefully you got the correct answer. When you issue the NTP SERVER command you're telling the router which NTP server it should sync to. So you are making the router an NTP client.

So the answer is either A or C. Now in my lecture video I didn't mention static client and broadcast client. I don't think you need to know this for the CCNA.

So the regular kind of NTP client that you get when configuring the NTP SERVER command is A, static client mode. So that should be the correct answer. I'll click on show answer.

And yes that is correct. So here is Boson's explanation. If you want to read about the broadcast client mode it's written here.

Okay, so you can pause the video to read that. And down here are the bottom there is a reference to some Cisco documentation about the NTP SERVER command. Okay so that's Boson ExSim for the CCNA.

As I have said many times before, these are by far the best practice exams for the CCNA. So if you're preparing to take the real CCNA exam, I highly recommend them. If you want to get Boson ExSim, please follow the link in the video description.

There are supplementary materials for this video. There is a flashcard deck to use with the software ‘Anki’. There will also be a packet tracer practice lab so you can get some hands-on practice.

That will be in the next video. Sign up for my mailing list via the link in the description, and I’ll send you all of the flashcards and packet tracer lab files for the course. Before finishing today’s video I want to thank my JCNP-level channel members.

To join, please click the ‘Join’ button under the video. Thank you to Biraj, Magrathea, Samil, Junhong, Njabulo, Benjamin, Tshepiso, Justin, Prakaash, Nasir, Erlison, Apogee, Marko, Daming, Jhilmar, Ed, Value, John, Funnydart, Velvijaykum, Mark, Yousif, Boson Software, Devin, Lito, Yonatan, and Vance. Sorry if I pronounced your name incorrectly, but thank you so much for your support.

This is the list of JCNP-level members at the time of recording by the way, December 29th 2020. If you signed up recently and your name isn’t on here don’t worry, you’ll be in future videos. Thank you for watching.

Please subscribe to the channel, like the video, leave a comment, and share the video with anyone else studying for the CCNA. If you want to leave a tip, check the links in the description. I'm also a Brave verified publisher and accept BAT, or Basic Attention Token, tips via the Brave browser.

That's all for now.