WEBVTT

1
00:00.000 --> 00:04.560
Now the primary way that a network is going to keep the accurate and same time

2
00:04.560 --> 00:05.200
across multiple

3
00:05.200 --> 00:09.560
devices, for example, multiple switches, multiple routers, multiple servers, is

4
00:09.560 --> 00:10.800
to use one of the

5
00:10.800 --> 00:14.740
time protocols that's available on those systems. And the grandfather of them

6
00:14.740 --> 00:15.840
all is a protocol

7
00:15.840 --> 00:21.690
called NTP, which is an acronym for network time protocol. And specifically, it

8
00:21.690 --> 00:23.200
is UDP port 1, 2,

9
00:23.200 --> 00:27.460
3. That would be the destination port for a network time protocol request. And

10
00:27.460 --> 00:28.320
as far as how we can

11
00:28.320 --> 00:32.160
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

11
00:28.320 --> 00:32.160
set it up, we could do something like this. We'd have an atomic clock or GPS

12
00:32.160 --> 00:33.760
system up in the cloud.

13
00:33.760 --> 00:37.840
That is an authorized time source. And we'd have our routers connecting to that

14
00:37.840 --> 00:39.040
as an NTP client

15
00:39.040 --> 00:42.400
making requests. So here we'd have our server, and here we have our client. So

16
00:42.400 --> 00:43.200
perhaps our one

17
00:43.200 --> 00:46.490
is synchronizing to one time source. And our two is synchronizing to yet

18
00:46.490 --> 00:47.840
another time source. So

19
00:47.840 --> 00:51.810
we'll call a source one and source two. And it's also assumed that they're both

20
00:51.810 --> 00:52.560
authoritative time

21
00:52.560 --> 00:55.940
servers tied to some atomic clock or something similar to that. Then once we

22
00:55.940 --> 00:56.640
have these two

23
00:56.640 --> 00:59.460
routers that are connected to these two time sources, what we can also do is

24
00:59.460 --> 01:00.640
take other devices in our
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

24
00:59.460 --> 01:00.640
take other devices in our

25
01:00.640 --> 01:04.370
networks, which is routers and servers, etc. And make them clients to these

26
01:04.370 --> 01:05.360
existing routers. So

27
01:05.360 --> 01:09.960
we can have, for example, our three act as a client to R1. And our four could

28
01:09.960 --> 01:11.200
actually client over here

29
01:11.200 --> 01:14.930
to R2. So it would just be a client and to be a server. So this case, our one

30
01:14.930 --> 01:16.080
would be a client

31
01:16.080 --> 01:20.420
out to the atomic time source out on the internet. Or through some mechanism,

32
01:20.420 --> 01:21.680
it has locally connected

33
01:21.680 --> 01:25.330
to it that's getting the time from an atomic clock. And it's also acting as a

34
01:25.330 --> 01:26.400
server and feeding the

35
01:26.400 --> 01:30.240
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

35
01:26.400 --> 01:30.240
time down to our three as a client. Now another option that we have is we could

36
01:30.240 --> 01:32.000
also configure R1

37
01:32.000 --> 01:36.660
and R2 to act as peers to each other. Now what would be the benefit of that?

38
01:36.660 --> 01:38.400
Well, if for example,

39
01:38.400 --> 01:42.260
this time source was no longer available, instead of just leaving R1 on its own

40
01:42.260 --> 01:43.200
, it could go ahead

41
01:43.200 --> 01:47.070
and synchronize and kind of blend the time between it and the time that R2 is

42
01:47.070 --> 01:48.240
getting in an attempt

43
01:48.240 --> 01:52.140
to keep the time accurate across the network. And that's important because if

44
01:52.140 --> 01:52.880
other devices like

45
01:52.880 --> 01:57.010
R3 are relying on R1 for accurate time, we want to make sure that R1 isn't

46
01:57.010 --> 01:58.240
without a time source.

47
01:58.240 --> 02:01.360
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

47
01:58.240 --> 02:01.360
So if everything's up and running the primary time source for R1 would be up in

48
02:01.360 --> 02:01.840
the cloud at

49
02:01.840 --> 02:05.540
source one. And if it wasn't available, then it could go ahead and synchronize

50
02:05.540 --> 02:06.480
its time over with

51
02:06.480 --> 02:10.860
R2. Now one thing I've noticed about NTP over the last couple decades is the

52
02:10.860 --> 02:12.240
fact that it's very,

53
02:12.240 --> 02:16.860
very slow to converge if you need it to. Now when would be a time that you

54
02:16.860 --> 02:17.920
needed to? Well,

55
02:17.920 --> 02:22.290
I remember back in 2001 when I was thinking my first CCIA exam for route switch

56
02:22.290 --> 02:24.480
, NTP was on there.

57
02:24.480 --> 02:28.810
And it took a long time for it to converge. And it was intentional for them to

58
02:28.810 --> 02:29.440
actually do that,

59
02:29.440 --> 02:32.410
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

59
02:29.440 --> 02:32.410
I believe, because they wanted to make sure we understand how it worked, how to

60
02:32.410 --> 02:32.960
configure it,

61
02:32.960 --> 02:37.570
and then give it time once it was up and running to go ahead and converge. So

62
02:37.570 --> 02:38.000
there are some

63
02:38.000 --> 02:41.550
techniques we can use to make it converge faster, including sitting at the

64
02:41.550 --> 02:42.400
timers to make them a

65
02:42.400 --> 02:47.180
little more frequent. We can also set the initial time on the devices closer to

66
02:47.180 --> 02:48.640
what the agreed-upon

67
02:48.640 --> 02:51.840
time is. And that way it'll be quicker to synchronize as well. If for example,

68
02:51.840 --> 02:53.440
there's only a five-minute

69
02:53.440 --> 02:58.450
or five-second differential between R1 and R3, that's going to synchronize a

70
02:58.450 --> 02:59.440
lot faster than if

71
02:59.440 --> 03:03.870
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

71
02:59.440 --> 03:03.870
there's five days of differences or five years of differences with the time

72
03:03.870 --> 03:05.760
between those two devices.

73
03:05.760 --> 03:08.640
And that's why having some hands-on practice, which we're going to have at the

74
03:08.640 --> 03:09.200
tail end of the

75
03:09.200 --> 03:13.360
set of videos is important. You can actually see and feel it happening. And

76
03:13.360 --> 03:14.080
also, I'll walk

77
03:14.080 --> 03:17.700
through some debug as well to help troubleshoot it if it's not synchronizing

78
03:17.700 --> 03:18.560
quite as fast as you

79
03:18.560 --> 03:21.810
think it should. Also with network time protocol, we can specify multiple

80
03:21.810 --> 03:22.960
servers. So we could tell,

81
03:22.960 --> 03:26.680
for example, R7, that we want R1 to be the primary server or the preferred

82
03:26.680 --> 03:27.760
server. And then we can

83
03:27.760 --> 03:31.450
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

83
03:27.760 --> 03:31.450
also specify R2 in the event that R1 is not reachable. There's also the ability

84
03:31.450 --> 03:32.240
with NTP to do

85
03:32.240 --> 03:35.730
authentication. And that way you can validate that you're only getting the time

86
03:35.730 --> 03:36.640
from authenticated

87
03:36.640 --> 03:40.160
time source that you trust. Now with NTP, there could be some latency as well.

88
03:40.160 --> 03:41.040
For example, R7,

89
03:41.040 --> 03:45.440
if it's making a crust up to R1 as the NTP server, it gives a response back.

90
03:45.440 --> 03:46.720
Maybe that response took

91
03:46.720 --> 03:51.440
a few hundred milliseconds. And if that's the case, then R7 and its clock

92
03:51.440 --> 03:52.480
information could be

93
03:52.480 --> 03:56.710
off just by a little bit. Not significantly, but a few hundred milliseconds. So

94
03:56.710 --> 03:57.520
to help compensate

95
03:57.520 --> 04:02.210
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

95
03:57.520 --> 04:02.210
for that, there's yet another time protocol out there and it's called PTP. So

96
04:02.210 --> 04:03.200
let me go ahead and

97
04:03.200 --> 04:07.410
clear this up a little bit. And let's talk about the precision time protocol.

98
04:07.410 --> 04:08.080
And with precision

99
04:08.080 --> 04:13.090
time protocol, we can get accuracy in subseconds, meaning once it's all set up

100
04:13.090 --> 04:14.400
and running, we can

101
04:14.400 --> 04:18.590
have very accurate time on all of our devices in our time domain. And for time

102
04:18.590 --> 04:19.440
domain, I was

103
04:19.440 --> 04:23.190
referring to the devices that are participating as part of precision time

104
04:23.190 --> 04:24.480
protocol. Now, so the

105
04:24.480 --> 04:29.410
terms in precision time protocol include the concept or term ordinary clock. So

106
04:29.410 --> 04:29.760
let's imagine

107
04:29.760 --> 04:34.400
this device right here, R3 is running precision time protocol. And the ordinary
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

107
04:29.760 --> 04:34.400
this device right here, R3 is running precision time protocol. And the ordinary

108
04:34.400 --> 04:35.200
clock could be a

109
04:35.200 --> 04:40.630
provider of time or it could be a client of time, a server or a client. Now, in

110
04:40.630 --> 04:42.720
the actual RFCs for

111
04:42.720 --> 04:46.740
PTP, they still refer to the terms of master and slave. At some point in the

112
04:46.740 --> 04:47.920
future, I believe that

113
04:47.920 --> 04:51.180
will be removed. They'll rename those. But for now, that's what they refer to

114
04:51.180 --> 04:52.320
the mass. A master

115
04:52.320 --> 04:56.830
is providing the time and a slave is receiving the time from that master. Now,

116
04:56.830 --> 04:57.840
of all the clocks

117
04:57.840 --> 05:03.110
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

117
04:57.840 --> 05:03.110
involved in a PTP domain, the one that's identified, this can be the master

118
05:03.110 --> 05:03.600
clock,

119
05:03.600 --> 05:07.440
it's going to be called the grand master thing of it, like the root of time,

120
05:07.440 --> 05:09.040
the definitive source

121
05:09.040 --> 05:13.080
for time for all the devices participating as part of the precision time

122
05:13.080 --> 05:14.640
protocol domain. So one of

123
05:14.640 --> 05:18.110
the questions that may come up is, okay, how do we decide out of all these

124
05:18.110 --> 05:19.520
devices that have clock?

125
05:19.520 --> 05:22.410
One of the questions that's going to come up is which of these devices will be

126
05:22.410 --> 05:23.680
the grand master

127
05:23.680 --> 05:27.440
or root of the time for the domain? And there's a protocol that helps determine

128
05:27.440 --> 05:27.680
that. It's

129
05:27.680 --> 05:32.950
called the best master clock algorithm. And that considers several factors,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

129
05:27.680 --> 05:32.950
called the best master clock algorithm. And that considers several factors,

130
05:32.950 --> 05:33.920
including the clock

131
05:33.920 --> 05:38.850
quality and how accurate it is and how stable that clock is. And there's also a

132
05:38.850 --> 05:39.920
concept of a

133
05:39.920 --> 05:43.150
boundary clock. So I'm going to go ahead and put that right here. Let me go

134
05:43.150 --> 05:43.920
ahead and clean up my

135
05:43.920 --> 05:47.530
ink over here on the right. And let's talk about a boundary clock. So let's

136
05:47.530 --> 05:48.800
imagine that R1 right

137
05:48.800 --> 05:52.860
here. And this also doesn't apply just to router, for example, we also have

138
05:52.860 --> 05:54.240
switches that support

139
05:54.240 --> 05:57.600
the precision time protocol as well. Now, not every single Cisco router and

140
05:57.600 --> 05:58.880
switch supports it.

141
05:58.880 --> 06:02.160
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

141
05:58.880 --> 06:02.160
But as far as the ones that do, there are routers that support it. And there's

142
06:02.160 --> 06:02.960
also switches that

143
06:02.960 --> 06:07.890
support it. So in this topology here, let's imagine that R1 is the grand master

144
06:07.890 --> 06:09.200
clock. So to be acting

145
06:09.200 --> 06:14.090
as a master, then R3 here would be a client or in the current terminology for

146
06:14.090 --> 06:15.120
the IETF for this,

147
06:15.120 --> 06:18.800
it'd be referred to as a slave. So the master is acting as a server and the

148
06:18.800 --> 06:19.680
slave is acting as a

149
06:19.680 --> 06:23.320
client getting the time from a server. And then we have R3 providing the time

150
06:23.320 --> 06:24.320
down here to R5.

151
06:24.320 --> 06:28.460
R3 can be referred to as a boundary clock providing the time between two

152
06:28.460 --> 06:30.080
different network segments.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

152
06:28.460 --> 06:30.080
different network segments.

153
06:30.080 --> 06:34.270
Again, these could be routers or switches. And in that sense, R3 the master and

154
06:34.270 --> 06:34.640
R5,

155
06:34.640 --> 06:38.910
this example would be the slave receiving time from that boundary clock. So

156
06:38.910 --> 06:40.160
maybe R5 right here

157
06:40.160 --> 06:44.290
is just acting as an ordinary clock that's receiving its time via precision

158
06:44.290 --> 06:45.360
time protocol.

159
06:45.360 --> 06:48.250
Now, for a boundary clock, there's actually a couple different options. One is

160
06:48.250 --> 06:49.280
a transparent.

161
06:49.280 --> 06:53.600
And with a transparent boundary clock, not only is it passing the time down to

162
06:53.600 --> 06:54.320
other clients down

163
06:54.320 --> 06:57.930
below it, but it's also taking into account the delays involved with the timest

164
06:57.930 --> 06:58.640
amps involved,

165
06:58.640 --> 07:02.190
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

165
06:58.640 --> 07:02.190
so it can actually modify the timestamps so that the client down here can

166
07:02.190 --> 07:03.680
actually get the accurate

167
07:03.680 --> 07:08.510
time. And that's how precision time protocol can get very accurate time across

168
07:08.510 --> 07:09.680
many devices in a

169
07:09.680 --> 07:13.680
time domain. Because even if our time is being processed and propagated and

170
07:13.680 --> 07:15.360
delegated to multiple

171
07:15.360 --> 07:19.310
boundary clocks, they have the ability to adjust the timestamps to accommodate

172
07:19.310 --> 07:20.640
the propagation delays

173
07:20.640 --> 07:23.790
from the original time information for the grandmaster all the way down until

174
07:23.790 --> 07:24.880
it reaches a downstream

175
07:24.880 --> 07:29.100
device. So as I was looking at my gear in my lab and also in my home office and

176
07:29.100 --> 07:29.840
also in my

177
07:29.840 --> 07:34.090
virtualized environment, I was looking for some devices that support PTP. And
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

177
07:29.840 --> 07:34.090
virtualized environment, I was looking for some devices that support PTP. And

178
07:34.090 --> 07:35.200
that is not easy to

179
07:35.200 --> 07:39.680
come by in a virtualized environment, including with viral and CML. I was not

180
07:39.680 --> 07:40.800
able to find it.

181
07:40.800 --> 07:44.760
But I did want to give you an overview of the precision time protocol with an

182
07:44.760 --> 07:45.440
emphasis that

183
07:45.440 --> 07:49.780
it's used if two things are happening. Number one, our gear supports it. And

184
07:49.780 --> 07:50.960
secondly, if we need to

185
07:50.960 --> 07:55.830
have sub millisecond accuracy for our timestamps across multiple devices. The

186
07:55.830 --> 07:57.200
other thing I want to

187
07:57.200 --> 08:01.140
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

187
07:57.200 --> 08:01.140
point out too is that if we have devices to do support PTP, we could have for

188
08:01.140 --> 08:02.240
example, the device

189
08:02.240 --> 08:06.610
acting to the grandmaster actually use PTP to get its time. And then it could

190
08:06.610 --> 08:08.880
be an actual NTP server

191
08:08.880 --> 08:12.840
with normal NTP delivering that information to the rest of the network without

192
08:12.840 --> 08:13.520
the benefits

193
08:13.520 --> 08:18.080
of PTP across our entire enterprise. So that way, if we do have some devices

194
08:18.080 --> 08:18.880
that support precision

195
08:18.880 --> 08:23.620
time protocol and others that just support NTP, we can still leverage PTP where

196
08:23.620 --> 08:24.080
we can

197
08:24.080 --> 08:28.480
to get the most accurate time and then NTP everywhere else. So now that we have

198
08:28.480 --> 08:29.440
the opportunity to take

199
08:29.440 --> 08:32.970
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

199
08:29.440 --> 08:32.970
a big picture look at a couple different time protocols in the next video, I'd

200
08:32.970 --> 08:33.760
like to start

201
08:33.760 --> 08:38.010
walking through the step by step configuration and verification of NTP in a

202
08:38.010 --> 08:39.200
Cisco environment.

203
08:39.200 --> 08:43.120
So I'll see you there in just a moment.