Now the primary way that a network is going to keep the accurate and same time
across multiple
devices, for example, multiple switches, multiple routers, multiple servers, is
to use one of the
time protocols that's available on those systems. And the grandfather of them
all is a protocol
called NTP, which is an acronym for network time protocol. And specifically, it
is UDP port 1, 2,
3. That would be the destination port for a network time protocol request. And
as far as how we can
set it up, we could do something like this. We'd have an atomic clock or GPS WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
set it up, we could do something like this. We'd have an atomic clock or GPS
system up in the cloud.
That is an authorized time source. And we'd have our routers connecting to that
as an NTP client
making requests. So here we'd have our server, and here we have our client. So
perhaps our one
is synchronizing to one time source. And our two is synchronizing to yet
another time source. So
we'll call a source one and source two. And it's also assumed that they're both
authoritative time
servers tied to some atomic clock or something similar to that. Then once we
have these two
routers that are connected to these two time sources, what we can also do is
take other devices in our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
take other devices in our
networks, which is routers and servers, etc. And make them clients to these
existing routers. So
we can have, for example, our three act as a client to R1. And our four could
actually client over here
to R2. So it would just be a client and to be a server. So this case, our one
would be a client
out to the atomic time source out on the internet. Or through some mechanism,
it has locally connected
to it that's getting the time from an atomic clock. And it's also acting as a
server and feeding the
time down to our three as a client. Now another option that we have is we could WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
time down to our three as a client. Now another option that we have is we could
also configure R1
and R2 to act as peers to each other. Now what would be the benefit of that?
Well, if for example,
this time source was no longer available, instead of just leaving R1 on its own
, it could go ahead
and synchronize and kind of blend the time between it and the time that R2 is
getting in an attempt
to keep the time accurate across the network. And that's important because if
other devices like
R3 are relying on R1 for accurate time, we want to make sure that R1 isn't
without a time source.
So if everything's up and running the primary time source for R1 would be up in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if everything's up and running the primary time source for R1 would be up in
the cloud at
source one. And if it wasn't available, then it could go ahead and synchronize
its time over with
R2. Now one thing I've noticed about NTP over the last couple decades is the
fact that it's very,
very slow to converge if you need it to. Now when would be a time that you
needed to? Well,
I remember back in 2001 when I was thinking my first CCIA exam for route switch
, NTP was on there.
And it took a long time for it to converge. And it was intentional for them to
actually do that,
I believe, because they wanted to make sure we understand how it worked, how to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I believe, because they wanted to make sure we understand how it worked, how to
configure it,
and then give it time once it was up and running to go ahead and converge. So
there are some
techniques we can use to make it converge faster, including sitting at the
timers to make them a
little more frequent. We can also set the initial time on the devices closer to
what the agreed-upon
time is. And that way it'll be quicker to synchronize as well. If for example,
there's only a five-minute
or five-second differential between R1 and R3, that's going to synchronize a
lot faster than if
there's five days of differences or five years of differences with the time WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
there's five days of differences or five years of differences with the time
between those two devices.
And that's why having some hands-on practice, which we're going to have at the
tail end of the
set of videos is important. You can actually see and feel it happening. And
also, I'll walk
through some debug as well to help troubleshoot it if it's not synchronizing
quite as fast as you
think it should. Also with network time protocol, we can specify multiple
servers. So we could tell,
for example, R7, that we want R1 to be the primary server or the preferred
server. And then we can
also specify R2 in the event that R1 is not reachable. There's also the ability WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
also specify R2 in the event that R1 is not reachable. There's also the ability
with NTP to do
authentication. And that way you can validate that you're only getting the time
from authenticated
time source that you trust. Now with NTP, there could be some latency as well.
For example, R7,
if it's making a crust up to R1 as the NTP server, it gives a response back.
Maybe that response took
a few hundred milliseconds. And if that's the case, then R7 and its clock
information could be
off just by a little bit. Not significantly, but a few hundred milliseconds. So
to help compensate
for that, there's yet another time protocol out there and it's called PTP. So WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for that, there's yet another time protocol out there and it's called PTP. So
let me go ahead and
clear this up a little bit. And let's talk about the precision time protocol.
And with precision
time protocol, we can get accuracy in subseconds, meaning once it's all set up
and running, we can
have very accurate time on all of our devices in our time domain. And for time
domain, I was
referring to the devices that are participating as part of precision time
protocol. Now, so the
terms in precision time protocol include the concept or term ordinary clock. So
let's imagine
this device right here, R3 is running precision time protocol. And the ordinary WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this device right here, R3 is running precision time protocol. And the ordinary
clock could be a
provider of time or it could be a client of time, a server or a client. Now, in
the actual RFCs for
PTP, they still refer to the terms of master and slave. At some point in the
future, I believe that
will be removed. They'll rename those. But for now, that's what they refer to
the mass. A master
is providing the time and a slave is receiving the time from that master. Now,
of all the clocks
involved in a PTP domain, the one that's identified, this can be the master WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
involved in a PTP domain, the one that's identified, this can be the master
clock,
it's going to be called the grand master thing of it, like the root of time,
the definitive source
for time for all the devices participating as part of the precision time
protocol domain. So one of
the questions that may come up is, okay, how do we decide out of all these
devices that have clock?
One of the questions that's going to come up is which of these devices will be
the grand master
or root of the time for the domain? And there's a protocol that helps determine
that. It's
called the best master clock algorithm. And that considers several factors, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
called the best master clock algorithm. And that considers several factors,
including the clock
quality and how accurate it is and how stable that clock is. And there's also a
concept of a
boundary clock. So I'm going to go ahead and put that right here. Let me go
ahead and clean up my
ink over here on the right. And let's talk about a boundary clock. So let's
imagine that R1 right
here. And this also doesn't apply just to router, for example, we also have
switches that support
the precision time protocol as well. Now, not every single Cisco router and
switch supports it.
But as far as the ones that do, there are routers that support it. And there's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But as far as the ones that do, there are routers that support it. And there's
also switches that
support it. So in this topology here, let's imagine that R1 is the grand master
clock. So to be acting
as a master, then R3 here would be a client or in the current terminology for
the IETF for this,
it'd be referred to as a slave. So the master is acting as a server and the
slave is acting as a
client getting the time from a server. And then we have R3 providing the time
down here to R5.
R3 can be referred to as a boundary clock providing the time between two
different network segments. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
different network segments.
Again, these could be routers or switches. And in that sense, R3 the master and
R5,
this example would be the slave receiving time from that boundary clock. So
maybe R5 right here
is just acting as an ordinary clock that's receiving its time via precision
time protocol.
Now, for a boundary clock, there's actually a couple different options. One is
a transparent.
And with a transparent boundary clock, not only is it passing the time down to
other clients down
below it, but it's also taking into account the delays involved with the timest
amps involved,
so it can actually modify the timestamps so that the client down here can WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so it can actually modify the timestamps so that the client down here can
actually get the accurate
time. And that's how precision time protocol can get very accurate time across
many devices in a
time domain. Because even if our time is being processed and propagated and
delegated to multiple
boundary clocks, they have the ability to adjust the timestamps to accommodate
the propagation delays
from the original time information for the grandmaster all the way down until
it reaches a downstream
device. So as I was looking at my gear in my lab and also in my home office and
also in my
virtualized environment, I was looking for some devices that support PTP. And WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
virtualized environment, I was looking for some devices that support PTP. And
that is not easy to
come by in a virtualized environment, including with viral and CML. I was not
able to find it.
But I did want to give you an overview of the precision time protocol with an
emphasis that
it's used if two things are happening. Number one, our gear supports it. And
secondly, if we need to
have sub millisecond accuracy for our timestamps across multiple devices. The
other thing I want to
point out too is that if we have devices to do support PTP, we could have for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
point out too is that if we have devices to do support PTP, we could have for
example, the device
acting to the grandmaster actually use PTP to get its time. And then it could
be an actual NTP server
with normal NTP delivering that information to the rest of the network without
the benefits
of PTP across our entire enterprise. So that way, if we do have some devices
that support precision
time protocol and others that just support NTP, we can still leverage PTP where
we can
to get the most accurate time and then NTP everywhere else. So now that we have
the opportunity to take
a big picture look at a couple different time protocols in the next video, I'd WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a big picture look at a couple different time protocols in the next video, I'd
like to start
walking through the step by step configuration and verification of NTP in a
Cisco environment.
So I'll see you there in just a moment.