- [Instructor] You might have heard the saying
that a man with one watch always knows what time it is,
but a man with two watches is never quite sure.
Well, when it comes to our network devices,
we want to be sure about what time it is.
We want our network devices to agree
on the authoritative time,
and a way to do that is to use a protocol called NTP,
the Network Time Protocol.
But first, let's answer the question,
why is it important that our devices agree?
Well, there are a couple of reasons.
One reason is it can be useful when we're interpreting logs.
Maybe we're look at debug messages,
or we're looking at syslog messages,
and we're trying to correlate one event with another event.
This event correlation might let us look at a debug app
which has said,
"Oh, this router did this at 2:00 a.m. last night,
"and this other device did something at 2:01 a.m.,"
by doing that event correlation
we can better go about our troubleshooting.
Another reason it's important to have accurate time
is digital certificates.
If we're using digital certificates with RSA,
where we have a private key and a public key,
and we have a certificate authority server
out on the internet.
Well, that certificate that we're exchanging
has an expiration.
We want to make sure that we're using a valid certificate
based on date and time.
And yet, another reason I didn't even list here
that we need accurate time,
is on something like our Cisco IP phones,
it displays time on the phone that came
from our Communications Manager server,
which is probably learning time via NTP.
And those are a few reasons why we need accurate time,
and we said that NTP could give that to us,
but how does it work?
Well, out on the internet,
we have these hyper-accurate atomic clocks,
and these atomic clocks use the element of cesium,
specifically cesium-133,
and a little over 9 billion oscillations of cesium-133
equals one second.
And these atomic clocks can then communicate that time,
that doesn't drift, it's very, very accurate,
they can communicate that time using NTP.
And NTP is a UDP-based protocol,
and it uses UDP Port 123.
And here's a memory aid for you,
I remember the old Jackson 5 song,
ABC easy as 123,
well, it's the same thing here.
Just think, NTP easy as 123,
because it uses UDP Port 123.
And there's a way to measure how authoritative,
or how believable a time source is,
and it's using a stratum number.
A stratum number is a sign to an NTP time source,
and the lower the number,
the more believable that time source.
Now, these atomic clocks I was telling you about,
they have a stratum number of zero,
they're the most believable.
But there are a lot internet-based NTP servers
that can learn from those atomic clocks.
Those internet-based servers, from which we can get time,
they would have a stratum value of one.
And then, we could, let's say,
have R1 learn from a Stratum = 1 time source,
and we could then give out time to our network devices.
Well, since I learned from a Stratum = 1 time source,
I'm now a Stratum = 2 time source.
You see, it increments by one
each time we go to another time source.
And then, I once I learned that on R1,
I can push time out to my network devices locally.
And while we typically want to do it like this,
where we're learning time from the internet,
there is a way,
I wouldn't recommend it, but maybe for a lab environment,
you might want to do it.
I just want you to be aware
that there is a way to have something like a Cisco router
be it's own time source.
It doesn't have to learn from anybody,
we can say,
"You are an NTP master clock."
The Cisco routers though,
they're not really known for their hyper-accurate clocks.
So, I wouldn't use that in production,
but you might want to mock it up in a lab environment.
Now, let's go out and take a quick look
at how we can configure NTP.
Well, in this example,
we're sitting on a router that we're pretending is
out on the internet somewhere.
This is going to be our clock source.
Again, you probably don't want to do this
to a Cisco router in production.
Again, Cisco routers are not known
for having really accurate clocks that don't drift,
but it works in a lab environment.
Here's what we're going to do.
On this internet time source,
I'm going to say, clock set,
we'll use some context-sensitive help
and we see the format of the time.
Let's just say that it's noon at the moment.
We'll say 12:00:00.
Use some more context-sensitive help,
and we see that we can put in the day of the month,
and I'll say it is the 8th of January 2020,
And let's go into Global Configuration mode
and set the timezone.
Now, we'll pretend that this internet-based clock is
providing UTC time, Universal Time Coordinated.
We'll say clock timezone,
UTC is the name of the timezone,
and it is, use some context-sensitive help,
it is zero hours of offset from UTC, because it is UTC.
So, I'll say clock timezone UTC 0.
And I'm going to configure this router to be an NTP master.
So, I'll say ntp master,
and I'll give a stratum value of a three.
Oh, by the way, before I give that,
let me show you some context-sensitive help.
Notice, we're not even allowed to say
that a Cisco router has a stratum value of zero.
That's what those atomic clocks
on the internet are assigned,
but we cannot even pretend that our Cisco router is
that authoritative when it comes to time.
We can only set values in the range of one through 15,
with 15 being believable, but it's the least believable.
If we ever have a stratum value of a 16,
that's not going to be believable.
But I'll say I've got a stratum value of,
we'll pretend, it's a three.
And I'm done configuring my NTP time source here
out on the internet.
Now, let's go over to router R1.
And we'll pretend this is on our network,
and we want to learn from that internet-based time source.
Here's how we do it.
We're going to go into Global Configuration mode,
and I'll say NTP server,
and I'll point to the IP address of that server,
that router I just configured,
it's got a loopback interface
with an IP address of 1.1.1.1.
So, we'll point there,
and I'll set the timezone here.
I'll say clock timezone.
And I'm in Eastern Standard Time, and that's UTC minus five,
but where I live, we do observe Daylight Savings Time,
and if I want to enable that,
so when we spring forward and fall back,
we'll do that.
I'll say clock summer-time.
When we're in summer-time,
we're not Eastern Standard Time,
we're Eastern Daylight Time.
And I'll just say that's recurring.
And for me, I don't know about you, but for me,
I always have trouble remembering
exactly when is it in March that we spring forward,
and when is it in November that we fall back.
Well, if we have fairly recent Cisco IOS,
we can just say recurring,
and it's going to apply the appropriate
spring forward and fall back dates and times.
But you can, if you use context-sensitive help,
you can see how you can go in and specify
exactly when you spring forward and fall back.
But I'll just say recurring, 'cause I don't remember.
And we ll say end,
to get out of that.
And we'll say show clock.
Now, right now that does not look like the date or time
that I set.
It says it's November the 15th 2019,
when I set it for a very different time on the internet.
So, what's going on here?
Let's check our NTP status.
If I do a show ntp status and press Enter,
notice it says that our stratum is 16.
We don't have a believable time source.
Well, that's curious.
I could've sworn that we pointed to 1.1.1.1.
Well, actually, this is expected behavior.
Because what we're doing here on modern Cisco IOS,
is reusing version four of NTP.
And it normally takes
about 15 minutes minimum to converge.
So, we're not going to be able to do a show ntp status
and see that we are synchronized, for quite some time.
If I do a show ntp, let's use some context-sensitive help,
I'll do a show ntp config.
We can see that we are configured
for an IP address of 1.1.1.1.
Can I reach it?
Can I ping 1.1.1.1?
I sure can.
So, I'm talking to my time source,
I'm configured for that time source,
but just the way NTP slowly approaches the time
of our time source.
It doesn't want to believe anybody just immediately.
It's going to have to vet it over time is what's happening,
we're going to have to wait a while.
And I don't want you to have to wait during this video.
So, what we're going to do right now,
is I'm going to pause the video,
and I'm going to come back in about 15 or 20 minutes,
and I'll resume the video.
And we'll see if we have time at that point.
So, we'll go ahead and pause the video,
and I'll see you back in just a moment.
All right, we're back.
It's been about 15 minutes,
so let's see if we have learned time now.
Prior to this, just a moment ago in this video,
we saw that the stratum was 16.
We didn't have a time source.
Well, take a look now.
Let's do a show ntp status.
And it says, we now have a stratum of four,
and that's because we learned from a router
that had a stratum value of a three
that we configured a few moments ago.
And it knows that our reference is 1.1.1.1.
If I do a show clock,
it now knows the date and time,
adjusted for the different timezone
that we configured on this router,
based on what it learned
from the internet-based time source,
what we're calling our internet-based time source.
And that's a look at how we can learn time
from an internet-based NTP server.
And the cool thing is,
now that R1 knows the time,
I could have other routers at our site,
maybe I've got a Cisco Unified Communications Manager server
that wants to learn time,
I could point it to router R1.
There's no need to go into router R1,
and say NTP master, we don't have to give that command.
It knows time that it learned
from our, quote, unquote, internet-based time source.
And now, other devices can get time from router R1.
And that's a look at Network Time Protocol.