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.