WEBVTT

00:00:00.000 --> 00:00:04.520
All right, folks.

00:00:04.520 --> 00:00:09.080
Now we get to jump into our discussion on management protocols and services to get us

00:00:09.080 --> 00:00:12.280
ready for the Encore certification exam.

00:00:12.280 --> 00:00:19.960
So we're going to focus on topics like NTP, PTP, SPAN, RSPAN, ERSPAN, Flexible NetFlow,

00:00:19.960 --> 00:00:22.800
IPSLA, SNMP, Syslog.

00:00:22.800 --> 00:00:27.280
We'll even look at debugging pings and traceroutes, well not debugging pings and traceroutes, we'll

00:00:27.280 --> 00:00:33.080
look at debugging pings and even we'll look at traceroutes.

00:00:33.080 --> 00:00:37.520
So we're not going to be focused on debugging pings and traceroutes, we'll look at ping

00:00:37.520 --> 00:00:38.960
and traceroutes though.

00:00:38.960 --> 00:00:42.960
And then also quality of service in this particular section.

00:00:42.960 --> 00:00:48.720
So a lot of different topics, again, these topics are going to be rather large in the

00:00:48.720 --> 00:00:53.240
real world, but our focus is to get you ready for the exam.

00:00:53.240 --> 00:00:57.400
So we're going to cover the exam relevant information in regards to all of these.

00:00:57.400 --> 00:01:02.480
So let's begin here with network time protocol and precision time protocol with our focus

00:01:02.480 --> 00:01:05.800
on NTP first and then PTP second.

00:01:05.800 --> 00:01:08.640
So this is all about synchronizing time.

00:01:08.640 --> 00:01:13.120
Why is it important for us to synchronize time, right?

00:01:13.120 --> 00:01:23.200
Because there is so many services that exist that our users consume every single day that

00:01:24.160 --> 00:01:26.160
require time to be accurate.

00:01:26.160 --> 00:01:33.000
In addition to that, digital certificates for security are based on time.

00:01:33.000 --> 00:01:40.260
We have the need for event correlation and tracking, which is based on time.

00:01:40.260 --> 00:01:47.040
We have the need to authenticate and authorize users, which again is going to require a component

00:01:47.040 --> 00:01:48.040
of time.

00:01:48.040 --> 00:01:53.040
For example, something like Kerberos, if time is not synchronized properly, then authentication

00:01:53.040 --> 00:01:55.320
will not happen in that case.

00:01:55.320 --> 00:01:57.240
So it's important that we have synchronized time.

00:01:57.240 --> 00:02:01.000
So NTP and PTP allow us to synchronize our time.

00:02:01.000 --> 00:02:05.020
But before we get to those, let's talk about how we can manually synchronize our time on

00:02:05.020 --> 00:02:07.580
all of our Cisco iOS devices.

00:02:07.580 --> 00:02:13.440
We can do that by manually setting our clock, and the command we use to do that is the clock

00:02:13.440 --> 00:02:15.320
set command.

00:02:15.320 --> 00:02:20.720
And then you specify your time, and then you specify your date.

00:02:20.720 --> 00:02:28.480
What you need to be aware of here is that this command is looking for UTC time.

00:02:28.480 --> 00:02:33.020
Now it doesn't know whether you typed in UTC time or not.

00:02:33.020 --> 00:02:34.860
It doesn't know that.

00:02:34.860 --> 00:02:42.840
But it is your responsibility to put in UTC time when you're setting your clock.

00:02:42.840 --> 00:02:44.640
That's what it is expecting.

00:02:44.640 --> 00:02:48.040
That is what it is trusting you to do.

00:02:48.040 --> 00:02:50.300
If you don't do that, it doesn't know.

00:02:50.880 --> 00:02:51.880
So you would set UTC time.

00:02:51.880 --> 00:02:56.580
So you'd have to look it up, do a Google search for UTC time, current UTC time, and you'll

00:02:56.580 --> 00:03:00.140
know what time it is, and you can use a clock set command to manually set that.

00:03:00.140 --> 00:03:01.380
Notice it's in privileged exact mode.

00:03:01.380 --> 00:03:02.900
That is not a typo.

00:03:02.900 --> 00:03:09.180
Right now, when you look here, you're going to see that we have our clock time zone command.

00:03:09.180 --> 00:03:11.240
So what is the clock time zone command?

00:03:11.240 --> 00:03:18.940
The clock time zone command is used to adjust your local clock to your current time zone.

00:03:19.460 --> 00:03:20.460
But wait a second.

00:03:20.460 --> 00:03:21.460
That's kind of misleading.

00:03:21.460 --> 00:03:22.900
I said current time zone.

00:03:22.900 --> 00:03:29.820
For those of you who spring forward and fall back, what it's looking for is the winter

00:03:29.820 --> 00:03:31.760
time, not the summer time.

00:03:31.760 --> 00:03:35.420
So what is it during your darkest hours?

00:03:35.420 --> 00:03:37.260
Your time.

00:03:37.260 --> 00:03:41.860
So for those of you who spring forward and fall back, this is really looking for what

00:03:41.860 --> 00:03:43.300
we call standard time.

00:03:43.300 --> 00:03:44.300
That's what it's looking for.

00:03:44.380 --> 00:03:49.260
What is your standard time when compared to UTC time?

00:03:49.260 --> 00:03:51.140
That's the value you must put in there.

00:03:51.140 --> 00:03:52.860
So it's the offset.

00:03:52.860 --> 00:04:00.000
So in my case, Atlantic standard time, which is less than Eastern time.

00:04:00.000 --> 00:04:03.900
So Eastern time would be minus five compared to UTC time.

00:04:03.900 --> 00:04:07.700
Atlantic time is minus four compared to UTC time.

00:04:07.700 --> 00:04:13.020
You have central time, which would be minus six compared to UTC time.

00:04:13.020 --> 00:04:14.540
So that's what it's looking for.

00:04:14.540 --> 00:04:18.420
But it's looking for it in the winter time, not the summer time.

00:04:18.420 --> 00:04:19.580
In the winter time.

00:04:19.580 --> 00:04:24.780
If you need to adjust your clock based on daylight savings time, you can have your device

00:04:24.780 --> 00:04:30.260
do it automatically for you by using the clock summer time command and then specifying what

00:04:30.260 --> 00:04:31.260
it is.

00:04:31.260 --> 00:04:35.300
So Atlantic daylight time for me or Eastern daylight time, whatever you call it.

00:04:35.300 --> 00:04:37.260
This value here is just for your own reference.

00:04:37.260 --> 00:04:40.100
The device doesn't know what that means, just like the device doesn't know what that means

00:04:40.100 --> 00:04:41.540
right there.

00:04:41.540 --> 00:04:43.820
And that's for you as an administrator.

00:04:43.820 --> 00:04:47.740
And then recurring the second Sunday of March at 2 a.m. and the first Sunday of November

00:04:47.740 --> 00:04:51.660
at 2 a.m. and then it can go ahead and adjust automatically for me.

00:04:51.660 --> 00:04:56.180
So I'm going to go ahead and do this on one of our devices here in our live environment.

00:04:56.180 --> 00:05:01.940
I'm just going to go to ISP1, I'll type in enable, we're going to type in clock and then

00:05:01.940 --> 00:05:06.060
set and then we're going to set the time to UTC time right now.

00:05:06.060 --> 00:05:09.500
So I got to look that up.

00:05:09.500 --> 00:05:15.820
So I'm just going to type in current UTC time in my browser and the current UTC time is

00:05:15.820 --> 00:05:19.940
4.26 p.m. while I'm recording this.

00:05:19.940 --> 00:05:30.620
So that would be 16, 16 colon 26, we'll do 27 because by the time I officially enter

00:05:30.620 --> 00:05:33.460
this 00 and then what is the date?

00:05:33.460 --> 00:05:40.940
The date is going to be October 18th, 2023.

00:05:40.940 --> 00:05:51.860
All right, so now if we type in show clock, we have our clock set right now to UTC time

00:05:51.860 --> 00:05:57.260
14.27 UTC time on Wednesday, October 18th, 2023.

00:05:57.260 --> 00:06:01.220
And that is on our ISP router in this example.

00:06:01.220 --> 00:06:06.700
So if we wanted to now have that displayed in our local time, then we could type in clock

00:06:06.700 --> 00:06:09.420
time zone.

00:06:09.420 --> 00:06:20.740
So if I type in, for example, clock time zone and we said Atlantic Standard Time, we are

00:06:20.740 --> 00:06:22.780
minus four.

00:06:22.780 --> 00:06:27.740
When compared to UTC time, you're going to see now that when we type in do show clock,

00:06:27.740 --> 00:06:31.060
it's now in the adjusted time.

00:06:31.060 --> 00:06:34.220
But right now I am in summertime.

00:06:34.220 --> 00:06:35.580
So that is not actually the correct time.

00:06:35.580 --> 00:06:37.300
It's actually 1.27 here.

00:06:37.300 --> 00:06:39.580
So 13.27, not 12.27.

00:06:39.580 --> 00:06:41.700
So we need to adjust that for summertime.

00:06:41.700 --> 00:06:52.700
So clock, summertime, Atlantic Daylight Time recurring the second Sunday of March, 02 colon

00:06:52.700 --> 00:07:00.540
00 on the first Sunday of November, 02 colon 00.

00:07:00.540 --> 00:07:04.820
Now that's going to adjust and we should see when we type in do show clock that our time

00:07:04.820 --> 00:07:05.820
is now accurate.

00:07:05.820 --> 00:07:10.620
It's a lot of hoops to jump through just to manually set our clocks.

00:07:10.620 --> 00:07:15.180
But most of us have a tendency to leave our clocks in UTC time and we just have all of

00:07:15.180 --> 00:07:16.980
our devices in UTC time.

00:07:16.980 --> 00:07:21.380
So that way there, there's a consistency amongst time amongst all of our different devices

00:07:21.380 --> 00:07:24.060
just by following UTC time around the world.

00:07:24.060 --> 00:07:29.100
But if you need to adjust it at all with summertime or to your time zone, you can go ahead and

00:07:29.100 --> 00:07:31.700
use those commands to do that.

00:07:31.700 --> 00:07:38.260
All right, so there's an example of those two commands right there.

00:07:38.260 --> 00:07:41.540
Now if you're using NTP as an example, these commands still work.

00:07:41.540 --> 00:07:47.340
So if your device is getting time and the time it's receiving is UTC time and you want

00:07:47.340 --> 00:07:50.820
it displayed instead of in UTC time, then you use these.

00:07:50.820 --> 00:07:54.380
So all you're doing with these commands is changing the way it's displayed on your device.

00:07:54.380 --> 00:07:55.380
That's essentially what you're doing.

00:07:55.380 --> 00:08:00.780
So if you're receiving UTC time from an NTP server, then you could still use these commands

00:08:00.780 --> 00:08:04.780
and it would change the clock the way it's displayed on your local device as well.

00:08:05.780 --> 00:08:10.100
All right, so now let's talk about NTP, Network Time Protocol.

00:08:10.100 --> 00:08:14.180
We want to use something like NTP because our devices don't have the ability to keep

00:08:14.180 --> 00:08:16.300
hyper-accurate time all on their own.

00:08:16.300 --> 00:08:21.080
So their internal clocks are going to have a significant amount of drift over time.

00:08:21.080 --> 00:08:25.860
So for example, today we just set the clock on that device, but in a month from now it

00:08:25.860 --> 00:08:28.060
could be off by 15 minutes.

00:08:28.060 --> 00:08:29.060
It could be.

00:08:29.060 --> 00:08:30.060
It could be.

00:08:30.060 --> 00:08:31.060
I'm not saying it would be, but it could be.

00:08:31.260 --> 00:08:36.460
As a result of that, we don't want to rely on our device's local clock to keep hyper-accurate

00:08:36.460 --> 00:08:37.460
time.

00:08:37.460 --> 00:08:44.020
So using a protocol like NTP, we have the ability to synchronize our device's time with

00:08:44.020 --> 00:08:49.120
some authoritative time piece that exists out there.

00:08:49.120 --> 00:08:54.100
So our device will always be checking its time and making sure it is accurate in comparison

00:08:54.100 --> 00:08:56.220
to this authoritative time piece.

00:08:56.220 --> 00:08:59.580
NTP uses UDP port 123.

00:08:59.580 --> 00:09:03.780
It is a client-server model based on what we call stratum levels.

00:09:03.780 --> 00:09:08.380
So for example, you have a clock, so 1, 2, 3.

00:09:08.380 --> 00:09:11.480
This is my authoritative time piece.

00:09:11.480 --> 00:09:17.620
My authoritative time piece, that would essentially have a stratum level of zero.

00:09:17.620 --> 00:09:19.060
A stratum level of zero.

00:09:19.060 --> 00:09:20.980
It is the trusted time piece.

00:09:20.980 --> 00:09:25.060
It is the time piece that is providing time.

00:09:25.060 --> 00:09:31.580
So for example, a global NTP server, a GPS or atomic clock, some sort of master clock

00:09:31.580 --> 00:09:35.300
that is out there that you have that is getting its time.

00:09:35.300 --> 00:09:37.500
We have this authoritative time piece.

00:09:37.500 --> 00:09:42.660
It is the most trustworthy time piece that exists.

00:09:42.660 --> 00:09:46.120
So with that in mind, you're going to need some sort of server.

00:09:46.120 --> 00:09:49.900
So I have a server now that is connected up to that authoritative time piece.

00:09:49.900 --> 00:09:54.380
So you might have purchased what is called a master clock, and that master clock is connected

00:09:54.700 --> 00:09:57.260
to maybe a GPS, maybe an atomic clock, right?

00:09:57.260 --> 00:10:01.540
So the GPS, the atomic clock is the actual authoritative time piece in that case, and

00:10:01.540 --> 00:10:05.540
then that server, that master clock is getting its time from that.

00:10:05.540 --> 00:10:06.540
So now we have what?

00:10:06.540 --> 00:10:11.060
We have a stratum level of one in this particular case, a stratum level of one.

00:10:11.060 --> 00:10:12.060
Why?

00:10:12.060 --> 00:10:16.220
Because we are one time synchronization away from that actual time piece.

00:10:16.220 --> 00:10:18.660
That's what stratum levels are all about.

00:10:18.660 --> 00:10:20.140
So what does that mean?

00:10:20.140 --> 00:10:25.500
It means that, well, let's say this is NIST, National Institute of Standards and Technology,

00:10:25.500 --> 00:10:28.980
and we're getting their time from them, and that is something you absolutely can do.

00:10:28.980 --> 00:10:31.180
Well, how do you connect up to them typically?

00:10:31.180 --> 00:10:32.960
It's going to be over the internet.

00:10:32.960 --> 00:10:37.580
So here's, let's say, a router you have, and you are connected to the internet.

00:10:37.580 --> 00:10:42.860
The internet's eventually connected to NIST, and you are synchronizing.

00:10:42.860 --> 00:10:45.420
You're synchronizing with that server.

00:10:45.420 --> 00:10:48.300
Well now you have a stratum level of two.

00:10:48.300 --> 00:10:50.220
It doesn't matter how many routers are in between you.

00:10:50.220 --> 00:10:53.340
It doesn't matter how many devices are in between you and that server.

00:10:53.340 --> 00:10:54.660
It's who you're synchronizing with.

00:10:54.660 --> 00:10:57.260
So now we're at a stratum level of two.

00:10:57.260 --> 00:11:03.060
So now if we have another router in our environment, and that router's connected up to that router,

00:11:03.060 --> 00:11:07.820
and our synchronization is here to here, that's our synchronization.

00:11:07.820 --> 00:11:11.780
Now we've got a stratum level of three.

00:11:11.780 --> 00:11:15.340
So let's put another router here, another device, doesn't have to be a router.

00:11:15.340 --> 00:11:20.900
And let's say we synchronize over to here.

00:11:20.900 --> 00:11:21.900
What stratum level is this now?

00:11:21.900 --> 00:11:24.180
Well, this is going to be a stratum level of four.

00:11:24.180 --> 00:11:25.180
No, no, no.

00:11:25.180 --> 00:11:27.100
It's going to be three as well.

00:11:27.100 --> 00:11:28.100
Why is it three?

00:11:28.100 --> 00:11:29.460
Because we're synchronizing with two.

00:11:29.460 --> 00:11:30.800
We're synchronizing with two.

00:11:30.800 --> 00:11:32.660
It's who you synchronize with.

00:11:32.660 --> 00:11:34.780
It doesn't matter on the physical connectivity you have.

00:11:34.780 --> 00:11:36.420
It's based on who you synchronize with.

00:11:36.420 --> 00:11:41.860
So does that mean if we had another device here, and we synchronized all the way back

00:11:41.860 --> 00:11:44.940
to here, that this would be a stratum level of two?

00:11:44.940 --> 00:11:46.860
Yes, that's exactly what I'm saying.

00:11:46.860 --> 00:11:53.420
So as you can see, stratum levels are based on the level, the hierarchy of synchronization,

00:11:53.420 --> 00:11:55.860
not the physical hierarchy.

00:11:55.860 --> 00:12:04.160
16 means unsynchronized, means unreachable, it means too far away.

00:12:04.160 --> 00:12:09.660
So if you have 15 stratum levels, if you have a device that is stratum level 15, and you

00:12:09.660 --> 00:12:13.020
have another device that synchronizes to it, it won't synchronize because it's too

00:12:13.020 --> 00:12:14.020
far away.

00:12:14.020 --> 00:12:17.260
15 is the max synchronization number you can have.

00:12:17.260 --> 00:12:21.740
16 is unreachable beyond that, not synchronized, and so on and so forth.

00:12:21.740 --> 00:12:24.340
But again, remember, it doesn't matter on physicality.

00:12:24.340 --> 00:12:32.700
That device could be 100 routers away from the authoritative timepiece, but still be

00:12:32.700 --> 00:12:34.220
a stratum level of what?

00:12:34.220 --> 00:12:37.020
Seven, eight, nine, ten, right?

00:12:37.020 --> 00:12:41.740
The stratum levels are based on who you're synchronizing with, not the physical environment.

00:12:41.740 --> 00:12:44.900
So make sure you understand what stratum levels are.

00:12:44.900 --> 00:12:47.420
Make sure you know 16 is unreachable.

00:12:47.420 --> 00:12:50.180
Make sure you know that the actual clock itself would be zero.

00:12:50.180 --> 00:12:53.580
So the first device connected to the clock, so the device that's actually getting its

00:12:53.580 --> 00:13:01.100
time from the clock, it's going to be a stratum level of one.

00:13:01.100 --> 00:13:05.740
So how do we make this happen with our Cisco devices?

00:13:05.740 --> 00:13:08.180
So let's say we have an NTP server here.

00:13:08.180 --> 00:13:13.060
How do I make this a client of this server?

00:13:13.060 --> 00:13:14.340
It's very easy.

00:13:14.340 --> 00:13:25.100
I use the NTP server command on my router, and I put in the IP address of that device.

00:13:25.100 --> 00:13:31.020
So the NTP server command is what makes my device a client of the NTP server, right?

00:13:31.020 --> 00:13:37.020
The NTP server command makes you a client of that server.

00:13:37.020 --> 00:13:45.260
And so how would I make this device now a client and this device a server?

00:13:45.260 --> 00:13:46.460
That's very easy.

00:13:46.460 --> 00:13:52.780
All I have to do is go to this device, type in NTP server, and put in the IP address of

00:13:52.780 --> 00:13:58.180
the device, which would be this dot one.

00:13:58.180 --> 00:14:08.140
So NTP server 10.10.127.1, and now this becomes a client of this server.

00:14:08.140 --> 00:14:09.140
I'm serious.

00:14:09.140 --> 00:14:11.180
You don't even need that NTP master command.

00:14:11.180 --> 00:14:12.980
Why does this work?

00:14:12.980 --> 00:14:25.340
It works because if this is synchronized using NTP with another server, so if we're synchronized

00:14:25.660 --> 00:14:34.580
using NTP, then if somebody wants to synchronize with me, then I can automatically become their

00:14:34.580 --> 00:14:35.580
server.

00:14:35.580 --> 00:14:41.940
So if I'm a client of another server, then I can become the server of a client behind

00:14:41.940 --> 00:14:43.540
me.

00:14:43.540 --> 00:14:49.780
But if I am not synchronized with a server, then I can't be a server to somebody else.

00:14:49.780 --> 00:14:54.100
So if I'm not a client to a server, then I can't be a server to a client.

00:14:54.100 --> 00:14:57.420
That's how it works.

00:14:57.420 --> 00:14:58.820
So it's really simple to set up.

00:14:58.820 --> 00:15:03.500
You just go to your devices and point them to who you want to point them to, and as everybody

00:15:03.500 --> 00:15:08.860
starts synchronizing, synchronizing, synchronizing, then eventually everybody gets synchronized.

00:15:08.860 --> 00:15:13.060
So you might be asking now, well, what in the world is the NTP master command for?

00:15:13.060 --> 00:15:20.140
So the NTP master command is available on our Cisco devices to make us the authoritative

00:15:20.140 --> 00:15:27.340
timepiece, meaning that we trust our own clocks.

00:15:27.340 --> 00:15:32.340
Our clock, the internal clock, is the master clock.

00:15:32.340 --> 00:15:36.020
It is the authoritative timepiece.

00:15:36.020 --> 00:15:40.260
All right.

00:15:40.260 --> 00:15:42.980
As is, the way I explained it, that's not a good thing, right?

00:15:43.900 --> 00:15:50.940
We don't want our routers or our switches to use their own clocks as the authoritative

00:15:50.940 --> 00:15:51.940
clock.

00:15:51.940 --> 00:15:52.940
Why?

00:15:52.940 --> 00:15:55.260
Because it's not all that accurate.

00:15:55.260 --> 00:16:00.180
So because it's not all that accurate, we'd have clock drift over time, and therefore

00:16:00.180 --> 00:16:03.980
we don't really know what time it is then.

00:16:03.980 --> 00:16:12.700
But if you ever need to have your device be the authoritative timepiece, like maybe

00:16:12.700 --> 00:16:20.780
in a lab environment where you don't have an NTP server set up, you can make your router

00:16:20.780 --> 00:16:25.940
an NTP server, your Cisco IOS device, an NTP server, an authoritative timepiece.

00:16:25.940 --> 00:16:30.260
So if we go to ISPA right now, we're going to do that because I don't have a clock connected

00:16:30.260 --> 00:16:32.380
to this lab environment.

00:16:32.380 --> 00:16:37.860
But if we type in configure terminal, and we type in NTP master, let's give it a stratum

00:16:37.860 --> 00:16:40.660
level of five as an example.

00:16:40.660 --> 00:16:51.020
This has just made me the authoritative timepiece, and my clock is the authoritative clock.

00:16:51.020 --> 00:17:01.180
So if I type in, for example, show NTP associations, you'll see right now that I am synchronized

00:17:01.180 --> 00:17:05.080
with some device called 127.127.1.1.

00:17:05.080 --> 00:17:06.080
That is me.

00:17:06.080 --> 00:17:11.260
I am synchronized with me.

00:17:11.260 --> 00:17:18.620
And my local clock is the time source, the timepiece that we trust.

00:17:18.620 --> 00:17:24.100
Five means my stratum level is five, therefore this is a stratum level of four.

00:17:24.100 --> 00:17:27.140
So you can set the stratum level you want.

00:17:27.140 --> 00:17:32.660
Now production environment, not a great idea, right, because we really want to have some

00:17:32.660 --> 00:17:36.020
sort of more accurate timepiece be the authoritative timepiece.

00:17:36.020 --> 00:17:45.060
But in a lab environment, not a problem, especially when you're playing around with it.

00:17:45.060 --> 00:17:51.100
You may want to do this in the real world, in your production environments, as a fallback

00:17:51.100 --> 00:18:00.340
scenario, meaning if all of a sudden your router, your device, stops getting time from

00:18:00.340 --> 00:18:03.220
the NTP server, let's say out on the internet.

00:18:03.220 --> 00:18:04.220
Why?

00:18:04.220 --> 00:18:05.220
Because the internet connection is down.

00:18:05.220 --> 00:18:12.420
Well, then the router, if it can't get time from the internet, then it can't give time

00:18:12.420 --> 00:18:18.220
to whoever's client's behind it, as an example, because remember, if I am not synchronized,

00:18:18.220 --> 00:18:20.300
I cannot give time.

00:18:20.300 --> 00:18:31.420
So with that in mind, if I get my time, get my time from that NTP server, and then we

00:18:31.420 --> 00:18:35.540
also at the same time configure NTP master, we do both.

00:18:35.540 --> 00:18:41.020
So NTP server is someone out on the internet, and then I say NTP master instead of stratum

00:18:41.020 --> 00:18:43.140
level, then what's that going to make sure?

00:18:43.140 --> 00:18:48.740
It's going to make sure that I synchronize my time, and then I trust my local clock that

00:18:48.740 --> 00:18:52.180
has been synchronized.

00:18:52.180 --> 00:18:56.020
And then if all of a sudden I lose connectivity to the internet, and I can't synchronize my

00:18:56.020 --> 00:19:00.900
time anymore, will I trust my local clock anyways, because my local clock was updated.

00:19:00.900 --> 00:19:05.100
So as long as the internet connection comes back up, and I can synchronize within a matter

00:19:05.100 --> 00:19:06.100
of what?

00:19:06.540 --> 00:19:10.660
Well, before we start getting drift on our local clock, then we're going to be okay.

00:19:10.660 --> 00:19:17.460
It's kind of a fallback kind of situation in that particular case.

00:19:17.460 --> 00:19:21.460
So let's go ahead and do some demonstrations in this environment right here.

00:19:21.460 --> 00:19:25.960
So our NTP server is out there, we just set it up, ISPA as an example, we're pretending

00:19:25.960 --> 00:19:27.700
it has an NTP server.

00:19:27.700 --> 00:19:32.500
So we're going to set up R2 here to get its time from that server.

00:19:37.100 --> 00:19:41.100
So if we go over to R2, let's find out what time it is.

00:19:45.100 --> 00:19:49.100
It's too accurate from the last time I did this demonstration.

00:19:49.100 --> 00:20:02.660
So let's go ahead and say clock set, and we're going to set it to 00 colon 00 colon 01, January

00:20:03.660 --> 00:20:05.660
1, 1999.

00:20:09.660 --> 00:20:11.660
All right, so that's what it's set to now.

00:20:11.660 --> 00:20:17.660
So what we're going to do now is we are going to show you if we type in clock, or configure

00:20:17.660 --> 00:20:22.660
term, I should say, NTP, and then what is the server's IP address?

00:20:22.660 --> 00:20:29.660
Server's IP address is 123, 123, 123, 123.

00:20:29.660 --> 00:20:38.660
So now if we type in do show NTP associations, you'll see here that it says we are synchronizing

00:20:38.660 --> 00:20:46.660
with 123, 123, 123, 123, and 123, 123, 123, 123 gets its time from 127, 127, 11.

00:20:46.660 --> 00:20:52.660
And 127, or 123, 123, 123, 123 is a stratum level of five, which means I should be a stratum

00:20:52.660 --> 00:20:54.660
level of six.

00:20:54.660 --> 00:20:59.660
The tilde, the tilde, that's a tilde if you didn't know that, it means configure.

00:20:59.660 --> 00:21:04.660
So that is what we have configured based on this command.

00:21:04.660 --> 00:21:09.660
And then the star in front, system peer, means we've actually synchronized with them.

00:21:09.660 --> 00:21:18.660
So if we type in show NTP status, you're going to see that I am synchronized, and I am a

00:21:18.660 --> 00:21:22.660
stratum level of six, because they're a stratum level of five, and their clock is a stratum

00:21:22.660 --> 00:21:23.660
level of four.

00:21:23.660 --> 00:21:26.660
And they are 123, 123, 123, 123.

00:21:26.660 --> 00:21:27.660
Right?

00:21:27.660 --> 00:21:28.660
So my clock is now synchronized.

00:21:28.660 --> 00:21:32.660
So do show clock, and there we go.

00:21:32.660 --> 00:21:37.660
That's the time we're getting from that ISP device.

00:21:37.660 --> 00:21:41.660
Now to show you how the stratum levels work, let's go ahead and do R1 in this case.

00:21:41.660 --> 00:21:48.660
So if we go over to R1, and we type in enable, configure terminal, we say NTP server, and

00:21:48.660 --> 00:21:53.660
let's put in the IP address of R2, it's 10.40.23.5.

00:21:53.660 --> 00:21:55.660
So that's this interface right here.

00:21:55.660 --> 00:22:01.660
And we should see here, if we type in do show NTP associations, that we are configured,

00:22:01.660 --> 00:22:05.660
we're just not synchronized yet, because the star is not in front of it, and now we're

00:22:05.660 --> 00:22:06.660
synchronized.

00:22:06.660 --> 00:22:14.660
So do show NTP status, we are synchronized, we're a stratum level of seven.

00:22:14.660 --> 00:22:18.660
As we said, the clock is four, the router's five, this one's six, that one's seven.

00:22:18.660 --> 00:22:21.660
Notice there's not even a physical connection between them.

00:22:21.660 --> 00:22:25.660
So we are synchronizing through the network.

00:22:25.660 --> 00:22:30.660
We are sending our UDP message out to that IP address, that device is responding back

00:22:30.660 --> 00:22:31.660
to us with time.

00:22:31.660 --> 00:22:38.660
So the UDP message gets sent, they process it, they send back the answer with time.

00:22:38.660 --> 00:22:43.660
So do show clock, and there we go.

00:22:44.660 --> 00:22:49.660
Now, one of the things to keep in mind when you are working with any type of management

00:22:49.660 --> 00:22:53.660
protocols and services, and since this is our very first management protocol and service

00:22:53.660 --> 00:22:57.660
discussion, I'm going to bring this up now.

00:22:57.660 --> 00:23:01.660
You need to consider the fact that it's this device generating the actual message.

00:23:01.660 --> 00:23:05.660
So in this case, the NTP message is being generated by this device, and then it has

00:23:05.660 --> 00:23:08.660
to send it to this device here.

00:23:08.660 --> 00:23:12.660
So the question now is, which interface is it going to be leaving?

00:23:12.660 --> 00:23:15.660
It could leave this interface, or it could leave this interface.

00:23:15.660 --> 00:23:19.660
Now, don't forget, every single packet we ship out of any single device in the network

00:23:19.660 --> 00:23:22.660
needs to have a source and destination IP address.

00:23:22.660 --> 00:23:27.660
So what is the source IP going to be in this example?

00:23:27.660 --> 00:23:31.660
What is the destination IP going to be in this example?

00:23:31.660 --> 00:23:35.660
Well, the destination IP in this example would be anything we set in the NTP server command.

00:23:35.660 --> 00:23:37.660
So the NTP server command was what?

00:23:37.660 --> 00:23:41.660
10.40.23.5 we set.

00:23:41.660 --> 00:23:43.660
And what's the source IP?

00:23:43.660 --> 00:23:49.660
The source IP is going to be the IP of exit interface.

00:23:49.660 --> 00:23:51.660
And who determines the exit interface?

00:23:51.660 --> 00:23:53.660
It's the routing table.

00:23:53.660 --> 00:23:56.660
So in this case, R1 would look up, how do I get to 10.40.23.5?

00:23:56.660 --> 00:24:01.660
Oh, right now, I can either go this way or this way for load balancing, and in this particular

00:24:01.660 --> 00:24:06.660
case, right now, my load balancing algorithm is telling me we're going to go this way.

00:24:06.660 --> 00:24:11.660
So that means the source IP in this case is going to be this interface right here.

00:24:11.660 --> 00:24:13.660
But next time, it could be this one here.

00:24:13.660 --> 00:24:15.660
And the time after, it could be this one here.

00:24:15.660 --> 00:24:18.660
And the time after, it could be this one here, and then here, and then here, and then here.

00:24:18.660 --> 00:24:23.660
That makes it really, really hard for us to set proper access control measures when it

00:24:23.660 --> 00:24:26.660
comes to our management protocols and services.

00:24:26.660 --> 00:24:30.660
What we want to have for our management protocols and services is a single IP address for the

00:24:30.660 --> 00:24:32.660
entire device.

00:24:32.660 --> 00:24:34.660
And how can we accomplish that?

00:24:35.660 --> 00:24:40.660
With loopback interfaces and loopback IP address.

00:24:40.660 --> 00:24:44.660
So if I create a loopback interface, like let's say loopback 192, and we give it the

00:24:44.660 --> 00:24:52.660
IP address of 192.168.255.1.32, and then we do the same thing down here, and we say, hey,

00:24:52.660 --> 00:25:03.660
loopback 192, and you are 192.168.255.2.32, and we inject that into OSPF, then these devices

00:25:03.660 --> 00:25:08.660
are going to be able to reach each other and talk to each other.

00:25:08.660 --> 00:25:14.660
So now the source IP, what I can do is I can set the source IP to this IP address here,

00:25:14.660 --> 00:25:19.660
and I can set the destination IP to always be this IP address right here.

00:25:19.660 --> 00:25:24.660
I'm just going to make sure that we're always sending those NTP messages from the same source,

00:25:24.660 --> 00:25:30.660
always going to the exact same destination.

00:25:30.660 --> 00:25:32.660
So let me show you how we can go ahead and do that.

00:25:32.660 --> 00:25:36.660
So let's create our loopback interface here.

00:25:36.660 --> 00:25:52.660
If you already have a loopback interface, then you can use it.

00:25:52.660 --> 00:25:55.660
And let's go to R2 and do the same thing.

00:25:55.660 --> 00:25:57.660
So this is a recommended best practice.

00:25:57.660 --> 00:26:09.660
It's not mandatory, but it is a recommended best practice.

00:26:09.660 --> 00:26:19.660
And then we're going to type in IP OSPF 1, area 0, do ping 192.168.255.1.

00:26:19.660 --> 00:26:21.660
Great, I can ping successfully.

00:26:21.660 --> 00:26:23.660
So we have connectivity between the two.

00:26:23.660 --> 00:26:33.660
Let's go back now to R1 instead and do show run pipe to section NTP.

00:26:33.660 --> 00:26:39.660
Let's go ahead and say no, NTP server, yada, yada, yada, yada.

00:26:39.660 --> 00:26:46.660
And now let's go ahead and type in NTP server 192.168.255.2.

00:26:46.660 --> 00:26:48.660
So reference that IP address instead.

00:26:48.660 --> 00:27:01.660
Also, NTP server, no, NTP source interface, no, NTP source.

00:27:01.660 --> 00:27:03.660
It will just be loopback 192.

00:27:03.660 --> 00:27:08.660
There you go.

00:27:08.660 --> 00:27:13.660
So in this case, this command sets the destination IP address.

00:27:13.660 --> 00:27:15.660
This command sets what?

00:27:15.660 --> 00:27:17.660
The source IP address of the packets.

00:27:17.660 --> 00:27:19.660
And so they're always going to be those same IPs.

00:27:19.660 --> 00:27:22.660
The destination is always going to be the same IP, whatever you specify there.

00:27:22.660 --> 00:27:25.660
But now it doesn't matter which way it goes.

00:27:25.660 --> 00:27:27.660
The packet could come this way.

00:27:27.660 --> 00:27:28.660
The packet could go this way.

00:27:28.660 --> 00:27:30.660
It doesn't matter which interface it comes in.

00:27:30.660 --> 00:27:35.660
Jeez, it could go all the way out here, spend some time out here, have a party, come in this way.

00:27:35.660 --> 00:27:39.660
And it would still get to 192.168.255.2 as an example.

00:27:39.660 --> 00:27:44.660
That's a little extreme, but I'm trying to tell you that we're always referencing that same IP address,

00:27:44.660 --> 00:27:48.660
no matter whether physical interfaces are up, down.

00:27:48.660 --> 00:27:49.660
It doesn't matter.

00:27:49.660 --> 00:27:54.660
As long as there's one physical interface up on that device, we can get to that loopback address.

00:27:54.660 --> 00:27:55.660
Likewise, this way.

00:27:55.660 --> 00:27:56.660
It doesn't matter whether I go this way or this way.

00:27:56.660 --> 00:27:57.660
It doesn't matter.

00:27:57.660 --> 00:28:04.660
The source IP is always going to be 192.168.255.1 based on that command.

00:28:04.660 --> 00:28:15.660
So now let's type in do show NTP status, make sure we're synchronized.

00:28:15.660 --> 00:28:18.660
And we are with 192.168.255.2.

00:28:18.660 --> 00:28:22.660
So now that we've done this, let's talk a little bit about security in this case.

00:28:22.660 --> 00:28:29.660
So when we talk about security, now that we are controlling the source and destination IP addresses,

00:28:29.660 --> 00:28:32.660
on R2 as an example, we can set up an ACL.

00:28:32.660 --> 00:28:34.660
And we can apply that ACL to NTP.

00:28:34.660 --> 00:28:40.660
And what we can do is we can say, hey, only hand out time to the following devices.

00:28:42.660 --> 00:28:45.660
Only hand out time to the following devices.

00:28:45.660 --> 00:28:54.660
So if we are controlling the source IP, then it's really easy for us now to control who we hand out time to.

00:28:55.660 --> 00:29:02.660
So this is a way to make sure that our device is not handing out time to rogue NTP requests.

00:29:02.660 --> 00:29:07.660
We're only allowing it to hand out time to legitimate NTP requests.

00:29:07.660 --> 00:29:08.660
That's the point here.

00:29:08.660 --> 00:29:20.660
So if we go over to R2 as an example, and we type in access list, and we'll just go access list 5.

00:29:20.660 --> 00:29:27.660
We're going to say permit 192.168.255.1, 0.0.0.0.

00:29:27.660 --> 00:29:38.660
And let's say we had all of our management IP addresses were actually .2 and then .3, .4, .5.

00:29:38.660 --> 00:29:39.660
Let's say that entire range.

00:29:39.660 --> 00:29:42.660
So actually, we could do maybe something like this instead.

00:29:42.660 --> 00:29:47.660
192.168.255.0, 0.0.0.25.

00:29:47.660 --> 00:29:51.660
Now, any IP address in that management IP addressing space.

00:29:54.660 --> 00:29:59.660
And so now we're going to make sure that we only hand out time to devices that have an IP address as such.

00:30:00.660 --> 00:30:01.660
And how do we do that?

00:30:01.660 --> 00:30:15.660
You type in NTP access group serve only those listed in access control list number 5.

00:30:15.660 --> 00:30:21.660
So only hand out time to those devices with a source IP address in that range.

00:30:28.660 --> 00:30:34.660
So this is one way that we can provide security when it comes to NTP, controlling who we hand out time to.

00:30:39.660 --> 00:30:42.660
Now, we also have the ability to do authentication.

00:30:43.660 --> 00:30:47.660
Now, authentication is about protecting the client, not the server, the client.

00:30:48.660 --> 00:30:49.660
So what does that mean?

00:30:49.660 --> 00:30:52.660
We are going to, for example, set up authentication between R1 and R2.

00:30:53.660 --> 00:31:07.660
And what this does is it ensures that R1 never accepts NTP messages and synchronizes its time unless it can verify that the server is actually the server it's supposed to be listening to.

00:31:08.660 --> 00:31:14.660
So it's not the server authenticating the client, it's the client who's authenticating the server in this particular case.

00:31:15.660 --> 00:31:18.660
So what we're going to do is we're going to set up.

00:31:23.660 --> 00:31:28.660
We're going to go ahead and set up here on R2 or R1 first.

00:31:28.660 --> 00:31:29.660
I'm going to do R2 first.

00:31:30.660 --> 00:31:33.660
I'm going to say NTP trusted key.

00:31:33.660 --> 00:31:36.660
So what we need is we need a key that can be used.

00:31:37.660 --> 00:31:39.660
In order to do the authentication.

00:31:40.660 --> 00:31:43.660
So I'm going to create a key and you'll see where this key comes into play here shortly.

00:31:43.660 --> 00:31:44.660
I'm going to call it key seven.

00:31:46.660 --> 00:31:49.660
Now what I'm going to do is I am going to.

00:31:53.660 --> 00:31:58.660
Type in NTP authentication key.

00:31:59.660 --> 00:32:02.660
And I'm going to say we're going to use that trusted key of seven.

00:32:03.660 --> 00:32:08.660
So we built the trusted key of seven with this command and now we're using it down here.

00:32:08.660 --> 00:32:13.660
And we only have the ability to use the MD5 hashing algorithm.

00:32:13.660 --> 00:32:19.660
So authentication is using a hashing algorithm with NTP and the hashing algorithm is MD5.

00:32:20.660 --> 00:32:22.660
And then I also need a passphrase to go along with this.

00:32:22.660 --> 00:32:23.660
So I'm just going to create one.

00:32:23.660 --> 00:32:25.660
Give me time is my passphrase.

00:32:26.660 --> 00:32:29.660
So now what's going to happen here is for every single NTP message.

00:32:30.660 --> 00:32:32.660
We have to use the key of seven.

00:32:33.660 --> 00:32:37.660
The passphrase of give me time and the MD5 hashing algorithm to create a hash.

00:32:38.660 --> 00:32:43.660
We then take that hash and we attach it to the plain text UDP message and we send it on the network.

00:32:43.660 --> 00:32:45.660
So there's no encryption here, right?

00:32:45.660 --> 00:32:46.660
It's not encryption.

00:32:46.660 --> 00:32:49.660
It's authentication with a hashing algorithm.

00:32:49.660 --> 00:32:50.660
So it's still in plain text.

00:32:50.660 --> 00:32:55.660
But the idea here is now when R1 receives the message, it can take the key of seven MD5.

00:32:55.660 --> 00:32:56.660
Give me time.

00:32:56.660 --> 00:32:58.660
Create the hash and double check.

00:32:58.660 --> 00:33:02.660
Is this message from somebody that I can authenticate?

00:33:02.660 --> 00:33:05.660
If so, then I'm going to accept the message.

00:33:05.660 --> 00:33:07.660
If not, then I'm going to discard the message.

00:33:09.660 --> 00:33:12.660
And so now I'm going to turn it on NTP authenticate.

00:33:13.660 --> 00:33:19.660
So if I type in do show run pipe to section NTP now, I'm going to copy and paste.

00:33:22.660 --> 00:33:25.660
Those pieces of information over to R1.

00:33:25.660 --> 00:33:26.660
Why?

00:33:26.660 --> 00:33:28.660
Because R1 needs that exact same information.

00:33:29.660 --> 00:33:30.660
So we'll paste it in.

00:33:33.660 --> 00:33:37.660
And so now all I have to do is reconfigure.

00:33:38.660 --> 00:33:40.660
This parameter right here.

00:33:41.660 --> 00:33:44.660
So I'm going to type in no.

00:33:45.660 --> 00:33:51.660
And to be server and now we're going to type in NTP server and then we'll type in key of seven.

00:33:51.660 --> 00:33:53.660
So this is what now triggers it.

00:33:54.660 --> 00:34:01.660
So now any time we are receiving NTP messages from that NTP server.

00:34:01.660 --> 00:34:03.660
Then we have to use the key of seven.

00:34:03.660 --> 00:34:05.660
The key of seven says what?

00:34:05.660 --> 00:34:09.660
The key of seven says we're using seven with MD5 with our hash.

00:34:10.660 --> 00:34:15.660
You take all of that or that passphrase, I should say, which is our hash in the end.

00:34:15.660 --> 00:34:20.660
So the key plus the hashing algorithm plus the passphrase combined together to generate our hash.

00:34:20.660 --> 00:34:24.660
So now I can generate my hash and compare it to the hash that has arrived.

00:34:24.660 --> 00:34:26.660
So I'm going to type in key of seven.

00:34:27.660 --> 00:34:31.660
So now I can generate my hash and compare it to the hash that has arrived.

00:34:31.660 --> 00:34:34.660
If they're the same, then I process the NTP message.

00:34:34.660 --> 00:34:37.660
If they're not the same, I discard the NTP message.

00:34:37.660 --> 00:34:39.660
That's how we authenticate.

00:34:39.660 --> 00:34:46.660
So now if I type in do show NTP associations, you'll see right now I'm configured.

00:34:46.660 --> 00:34:49.660
But I'm not synchronized because there's no star in front of it.

00:34:49.660 --> 00:34:55.660
But if I type in show NTP status, what does it say?

00:34:55.660 --> 00:34:59.660
It says I'm currently on synchronized stratum level of 16.

00:35:00.660 --> 00:35:04.660
But let's take a look at associations detail right now.

00:35:04.660 --> 00:35:08.660
And associations detail says that I'm actually authenticated right now.

00:35:08.660 --> 00:35:13.660
So I'm configured to peer with them and we've authenticated, but I still haven't synchronized my time.

00:35:13.660 --> 00:35:14.660
And that's okay.

00:35:14.660 --> 00:35:16.660
This could take a little bit of time.

00:35:16.660 --> 00:35:21.660
But then once that little bit of time passes, then we'll see that we're sane, we're valid,

00:35:21.660 --> 00:35:24.660
we're synchronized with our certain stratum level.

00:35:24.660 --> 00:35:29.660
And I've seen this take anywhere from 30 seconds during demonstrations

00:35:29.660 --> 00:35:35.660
all the way up to my worst case scenario was 45 minutes, if I recall correctly, doing a demonstration.

00:35:37.660 --> 00:35:39.660
So we'll just let that cook for a bit.

00:35:39.660 --> 00:35:44.660
But I don't want to waste too much of your time as we sit here, wait, wait, wait, wait, wait.

00:35:44.660 --> 00:35:48.660
So what are some of the key takeaways from this particular discussion you're preparing for the exam?

00:35:48.660 --> 00:35:54.660
So number one is know why we use NTP, which we've covered.

00:35:54.660 --> 00:35:58.660
Make sure you understand stratum levels and the purpose of stratum levels.

00:35:59.660 --> 00:36:05.660
Also recognize how to or read an NTP configuration.

00:36:05.660 --> 00:36:08.660
So why do we need NTP master versus NTP server?

00:36:08.660 --> 00:36:12.660
The last thing you want to do is use NTP master when all you have to do is use NTP server

00:36:12.660 --> 00:36:14.660
because they result in two different things.

00:36:14.660 --> 00:36:16.660
So pay attention to what's going on.

00:36:16.660 --> 00:36:20.660
So in our particular case, you know, NTP server on the devices,

00:36:20.660 --> 00:36:25.660
we want to synchronize with some other device because NTP server points to the server's IP address.

00:36:25.660 --> 00:36:27.660
That's what the command does.

00:36:27.660 --> 00:36:30.660
Now, if you're synchronizing, when there's multiple paths available,

00:36:30.660 --> 00:36:33.660
it's better to use a loopback interface as the source.

00:36:33.660 --> 00:36:37.660
And as we saw here, a loopback interface is the destination because then it doesn't matter

00:36:37.660 --> 00:36:41.660
what the physical interfaces are that are being utilized to forward the packets.

00:36:41.660 --> 00:36:43.660
The source IP is always going to be the same.

00:36:43.660 --> 00:36:46.660
The destination IP is always going to be the same.

00:36:46.660 --> 00:36:56.660
And there's two different ways that we can perform security with NTP that we need to know for the exam.

00:36:56.660 --> 00:37:00.660
One is the ACLs that are going to allow us to convey those access groups,

00:37:00.660 --> 00:37:04.660
control which servers we can give time to or what devices we can give time to,

00:37:04.660 --> 00:37:08.660
and an authentication to authenticate the client for the server.

00:37:08.660 --> 00:37:11.660
So to make sure, pardon me, to authenticate the server for the client,

00:37:11.660 --> 00:37:17.660
to make sure the client authenticates the server before it actually processes the messages

00:37:17.660 --> 00:37:23.660
that it's receiving from that particular server.

00:37:23.660 --> 00:37:24.660
All right.

00:37:24.660 --> 00:37:26.660
So it's still not synchronized at this particular point in time.

00:37:26.660 --> 00:37:33.660
I was hoping that little moment we had together would have given us the opportunity to synchronize,

00:37:33.660 --> 00:37:36.660
but it hasn't, and that's okay.

00:37:36.660 --> 00:37:37.660
All right.

00:37:37.660 --> 00:37:39.660
Real world, folks, typically what's going to happen,

00:37:39.660 --> 00:37:44.660
you're probably going to have a server in your environment that is going to be getting its time

00:37:44.660 --> 00:37:48.660
from a trusted time source externally,

00:37:48.660 --> 00:37:52.660
and then you're going to point all of your devices to that trusted time piece,

00:37:52.660 --> 00:37:57.660
and you're probably going to have two time sources in your environment for redundancy sakes,

00:37:57.660 --> 00:37:59.660
and they're getting their time from external.

00:37:59.660 --> 00:38:03.660
So then all the other devices you have point to those two devices to get their time.

00:38:03.660 --> 00:38:07.660
So you're not going to typically be configuring your routers and your switches to get their time externally,

00:38:07.660 --> 00:38:11.660
because that opens up a vulnerability, right, a vulnerability that could be exploited.

00:38:11.660 --> 00:38:13.660
That is, they are now getting out on the Internet,

00:38:13.660 --> 00:38:17.660
and maybe you don't want your devices to be getting out on the Internet for any purpose.

00:38:17.660 --> 00:38:18.660
I wouldn't.

00:38:18.660 --> 00:38:19.660
I never get equipment.

00:38:19.660 --> 00:38:24.660
So in that case, having some sort of trusted time piece inside the environment

00:38:25.660 --> 00:38:29.660
or something that gets its time from a trusted time piece is what we would want to do.

00:38:39.660 --> 00:38:44.660
So NTP currently, what we're running on Cisco devices is version 4, just to let you know.

00:38:44.660 --> 00:38:49.660
So NTP version 4 supports both IPv4 and IPv6.

00:38:49.660 --> 00:38:54.660
NTP version 3, 2, and 1 does not support IPv6.

00:38:54.660 --> 00:38:57.660
So NTP 4 supports IPv4 and IPv6.

00:39:04.660 --> 00:39:05.660
Still not synchronized.

00:39:05.660 --> 00:39:06.660
All right.

00:39:06.660 --> 00:39:08.660
I'll leave that alone.

00:39:08.660 --> 00:39:14.660
So let's now have a discussion on PTP, Precision Time Protocol,

00:39:14.660 --> 00:39:16.660
which is a new addition to this particular exam.

00:39:16.660 --> 00:39:18.660
It wasn't covered in the old version of the exam,

00:39:18.660 --> 00:39:21.660
but it has been added to the new version of the exam.

00:39:23.660 --> 00:39:28.660
So PTP, Precision Time Protocol, is an IEEE standard 1588.

00:39:30.660 --> 00:39:35.660
So if you see 1588 on the exam or IEEE 1588, they're talking about Precision Time Protocol.

00:39:35.660 --> 00:39:37.660
Why would Cisco do that?

00:39:37.660 --> 00:39:39.660
I don't know, but sometimes they do crazy things like that.

00:39:39.660 --> 00:39:43.660
Instead of just typing in Precision Time Protocol, they type in, oh, IEEE 1588.

00:39:44.660 --> 00:39:46.660
So know that that is Precision Time Protocol.

00:39:51.660 --> 00:39:53.660
It's about precise clock synchronization.

00:39:53.660 --> 00:39:55.660
You might be saying, wait, wait, wait, wait.

00:39:55.660 --> 00:39:57.660
Isn't NTP precise clock synchronization?

00:39:57.660 --> 00:40:01.660
Yes, but not as precise as PTP, Precision Time Protocol.

00:40:01.660 --> 00:40:03.660
It's even more precise.

00:40:03.660 --> 00:40:08.660
You see, PTP has been designed specifically for those environments that need super,

00:40:08.660 --> 00:40:13.660
hyper-accurate time with no more than nanosecond differences in devices' time.

00:40:23.660 --> 00:40:26.660
Whereas NTP is more like millisecond.

00:40:28.660 --> 00:40:30.660
PTP is like nanosecond.

00:40:31.660 --> 00:40:35.660
So we're dealing with industrial environments.

00:40:36.660 --> 00:40:41.660
We are dealing with network measurement and control systems.

00:40:44.660 --> 00:40:49.660
It is designed specifically to use minimal bandwidth and have very low processing overhead.

00:40:54.660 --> 00:41:02.660
So when you need super, hyper-accurate time, any scenario that's talking about super, hyper-accurate time,

00:41:03.660 --> 00:41:09.660
I would go with Precision Time Protocol because it is more precise than NTP.

00:41:11.660 --> 00:41:13.660
And how is this going to happen?

00:41:13.660 --> 00:41:17.660
Because with Precision Time Protocol, we can keep track of the delay.

00:41:20.660 --> 00:41:21.660
Where?

00:41:21.660 --> 00:41:26.660
The delay from the device providing time and the device getting time.

00:41:27.660 --> 00:41:31.660
So when you think about your server providing time, so there's my time.

00:41:32.660 --> 00:41:33.660
That's my time source.

00:41:34.660 --> 00:41:37.660
And some device over here that's getting time.

00:41:39.660 --> 00:41:41.660
Think about everything that's happening in between.

00:41:41.660 --> 00:41:44.660
There's a ton of networking equipment in between those devices.

00:41:45.660 --> 00:41:49.660
Some Layer 1 devices, some Layer 2 devices, some Layer 3 devices, whatever it happens to be, right?

00:41:49.660 --> 00:41:51.660
There is delay there.

00:41:51.660 --> 00:41:53.660
And that delay is going to be variable.

00:41:54.660 --> 00:41:57.660
So how do we get our time more accurate?

00:41:58.660 --> 00:42:00.660
More accurate than NTP can do?

00:42:01.660 --> 00:42:09.660
That is where Precision Time Protocol excels

00:42:09.660 --> 00:42:17.660
because we can keep track of that delay between the time providing or the device providing time and the device getting time.

00:42:18.660 --> 00:42:24.660
And then adjustments can be made using that delay information.

00:42:25.660 --> 00:42:36.660
So PTP, a network, can compensate for latency and delay problems by correctly adjusting the device's clocks

00:42:36.660 --> 00:42:41.660
so that they stay synchronized with one another to a nanosecond.

00:42:46.660 --> 00:42:52.660
Let me walk you through an example here using seconds, okay?

00:42:53.660 --> 00:42:57.660
Seconds instead of microseconds or nanoseconds.

00:42:58.660 --> 00:43:01.660
So that way our brains don't melt.

00:43:03.660 --> 00:43:13.660
We're going to focus on synchronizing time from our master clock over here to our PC right there.

00:43:15.660 --> 00:43:21.660
So let's say our time source has a current time of 1,000,000 as we see here.

00:43:21.660 --> 00:43:22.660
That's the current time.

00:43:23.660 --> 00:43:30.660
And for simplicity's sake, let's say our master clock, which is this device right here, the master clock,

00:43:34.660 --> 00:43:37.660
has that time of 1,000,000.

00:43:37.660 --> 00:43:41.660
Now, in reality, there would be like nanosecond difference between the two

00:43:42.660 --> 00:43:48.660
because of the delay of the cable between the actual time piece and the master clock, right?

00:43:48.660 --> 00:43:52.660
But let's just keep it equal here so that way, again, our brains don't melt.

00:43:53.660 --> 00:43:54.660
So now what's going to happen with NTP?

00:43:55.660 --> 00:43:57.660
With NTP, our packet is going to be sent.

00:43:58.660 --> 00:44:01.660
And what is the time going to be listed in that particular packet?

00:44:01.660 --> 00:44:03.660
It's going to be this time right here.

00:44:06.660 --> 00:44:11.660
So let's say it takes one second.

00:44:13.660 --> 00:44:15.660
Again, for simplicity's sake, we're using seconds.

00:44:15.660 --> 00:44:19.660
Let's say it takes one second to go from here, the message, to here.

00:44:22.660 --> 00:44:24.660
What time is it on this device?

00:44:25.660 --> 00:44:29.660
On this device, well, it sees that it's this time right here.

00:44:30.660 --> 00:44:33.660
It's what it sees because that's what the message says.

00:44:34.660 --> 00:44:37.660
But what time is it really now if it took a second to get there?

00:44:38.660 --> 00:44:39.660
The real time is now this, right?

00:44:40.660 --> 00:44:41.660
This is real time.

00:44:46.660 --> 00:44:51.660
So we have a one second, a one second difference, don't we?

00:44:53.660 --> 00:44:54.660
We're one second off.

00:44:57.660 --> 00:45:04.660
So let's now say that we go, it takes a second to go from here to here,

00:45:05.660 --> 00:45:09.660
another second to go from here to here, another second to go from here to here.

00:45:10.660 --> 00:45:11.660
So what time is it over here?

00:45:12.660 --> 00:45:13.660
So what time is it over here?

00:45:13.660 --> 00:45:16.660
It's 1,00,00.

00:45:17.660 --> 00:45:18.660
But over here, what would it be?

00:45:19.660 --> 00:45:20.660
Three seconds off.

00:45:21.660 --> 00:45:22.660
Three total seconds.

00:45:23.660 --> 00:45:24.660
Now we're three seconds off.

00:45:25.660 --> 00:45:28.660
So one second off, two seconds off, three seconds off.

00:45:29.660 --> 00:45:32.660
Now, again, this is for simplicity's sake so you realize what's happening here.

00:45:34.660 --> 00:45:39.660
So if we take this further, there's another second, there's another second.

00:45:39.660 --> 00:45:40.660
Let's say there's another second.

00:45:41.660 --> 00:45:42.660
So what time is it here?

00:45:43.660 --> 00:45:45.660
This is the time because that's what the message says.

00:45:46.660 --> 00:45:48.660
But in reality, this is the time.

00:45:50.660 --> 00:45:52.660
We're six seconds off now.

00:45:53.660 --> 00:45:56.660
Six total seconds off.

00:45:58.660 --> 00:46:01.660
Now remember, in reality, this would be microseconds with NTP.

00:46:02.660 --> 00:46:05.660
And many of you are thinking, okay, whoop-de-doo, big deal, don't care.

00:46:06.660 --> 00:46:07.660
All right, well, here's the thing.

00:46:07.660 --> 00:46:10.660
Most of us will be fine in our production environments like this.

00:46:11.660 --> 00:46:14.660
But there are environments where you may be in in the future or you are in now

00:46:15.660 --> 00:46:21.660
where hyper-accurate time down to nanosecond is really, really, really, really, really important.

00:46:23.660 --> 00:46:25.660
And so where might that be?

00:46:27.660 --> 00:46:34.660
Industrial control systems, financial scenarios, smart grid power automation applications,

00:46:34.660 --> 00:46:39.660
power generators, outage monitoring and management.

00:46:40.660 --> 00:46:42.660
We need precise time accuracy.

00:46:43.660 --> 00:46:44.660
We need stability in our time.

00:46:45.660 --> 00:46:51.660
We need to account for delay in those scenarios of the networking devices that are in between.

00:46:52.660 --> 00:46:54.660
And so that's where PTP comes into play.

00:46:55.660 --> 00:46:56.660
It improves our accuracy.

00:46:57.660 --> 00:47:03.660
And therefore, all those other systems that rely on our devices being within our control system

00:47:04.660 --> 00:47:06.660
within a nanosecond of each other, we can get that.

00:47:07.660 --> 00:47:08.660
So PTP exists.

00:47:09.660 --> 00:47:10.660
We get that hyper-accurate time.

00:47:11.660 --> 00:47:13.660
So here's a table I put together.

00:47:14.660 --> 00:47:17.660
I don't need you to memorize this for the certification exam,

00:47:18.660 --> 00:47:21.660
but you'll see accuracy for PTP is submicrosecond.

00:47:22.660 --> 00:47:24.660
It's nanosecond, whereas NTP is millisecond and submillisecond.

00:47:25.660 --> 00:47:30.660
Highly precise synchronization under clock synchronization and moderate to good synchronization for NTP.

00:47:30.660 --> 00:47:34.660
IEEE 1588 versus NTP4, which is an IETF standard.

00:47:35.660 --> 00:47:44.660
So you don't have to know what you see here, but reading through it once might be a good idea.

00:47:45.660 --> 00:47:48.660
But you're not going to have to memorize that for the certification exam.

00:47:50.660 --> 00:47:53.660
So let's now talk about PTP devices.

00:47:54.660 --> 00:47:57.660
Because there's some specific terminology you're going to have to know for the certification exam.

00:47:57.660 --> 00:48:00.660
So first of all, we have the Grandmaster Clock, the GMC.

00:48:01.660 --> 00:48:05.660
So the Grandmaster Clock is a highly accurate and stable time source.

00:48:06.660 --> 00:48:11.660
So it is typically equipped with precise hardware, precision hardware,

00:48:12.660 --> 00:48:16.660
and is considered the primary reference for time within your PTP network.

00:48:17.660 --> 00:48:20.660
So you're going to have a Grandmaster Clock set up in your network.

00:48:21.660 --> 00:48:26.660
And then a Grandmaster Clock is going to be synchronized to some very precise clock.

00:48:27.660 --> 00:48:29.660
Some very precise time standard.

00:48:30.660 --> 00:48:34.660
Some sort of authoritative time piece, GPS, atomic clock.

00:48:35.660 --> 00:48:38.660
However, if you can't connect them to a GPS or atomic clock,

00:48:39.660 --> 00:48:44.660
they do have the ability to keep relatively highly accurate time themselves.

00:48:45.660 --> 00:48:47.660
And when you are relying on them to be the clock,

00:48:48.660 --> 00:48:51.660
and not rely on the GPS or atomic clock that's out there,

00:48:52.660 --> 00:48:53.660
we call that free-running them.

00:48:53.660 --> 00:48:54.660
They are considered to free-run,

00:48:55.660 --> 00:48:58.660
which means they are using their own internal clocking components for time.

00:48:59.660 --> 00:49:01.660
So this is something you would have to purchase, something you would have to get.

00:49:02.660 --> 00:49:03.660
I'm going to go to Google right now,

00:49:04.660 --> 00:49:09.660
and I'm just going to type in Grandmaster Clock as an example.

00:49:10.660 --> 00:49:12.660
Ooh, beautiful. All right, so we're going to go to this company here.

00:49:13.660 --> 00:49:14.660
I'm not promoting any company at all,

00:49:15.660 --> 00:49:17.660
but here's an example of a Grandmaster Clock going to their website.

00:49:18.660 --> 00:49:19.660
See our network's heartbeat, as they say.

00:49:20.660 --> 00:49:21.660
There you go.

00:49:21.660 --> 00:49:23.660
A device that is designed for what?

00:49:24.660 --> 00:49:25.660
Hyper-accurate time.

00:49:26.660 --> 00:49:27.660
That's what it's designed for.

00:49:28.660 --> 00:49:29.660
So you'd set this up, you'd put it in your environment,

00:49:30.660 --> 00:49:32.660
and it has the ability to keep hyper-accurate time,

00:49:33.660 --> 00:49:37.660
but you can also connect it to an external time piece as well, if you had to.

00:49:38.660 --> 00:49:42.660
Like the GPS or atomic clock to get even better time when it's all said and done.

00:49:43.660 --> 00:49:47.660
So you know that it's synchronizing to world time as opposed to just itself.

00:49:52.660 --> 00:49:54.660
You can only have one per PTP domain.

00:49:55.660 --> 00:49:56.660
So what is a precision time protocol domain?

00:49:57.660 --> 00:50:03.660
A PTP domain is the grouping of devices that are synchronizing their time altogether.

00:50:04.660 --> 00:50:08.660
And so you can only have one Grandmaster Clock per PTP domain,

00:50:09.660 --> 00:50:10.660
but backups are recommended.

00:50:11.660 --> 00:50:13.660
So when you have backups, that means you're going to have multiple devices

00:50:14.660 --> 00:50:15.660
that could become your Grandmaster Clock.

00:50:16.660 --> 00:50:17.660
For example, there's my Grandmaster Clock,

00:50:18.660 --> 00:50:19.660
there's a backup Grandmaster Clock.

00:50:19.660 --> 00:50:22.660
So we need an algorithm that's going to have the ability to ultimately determine

00:50:23.660 --> 00:50:27.660
who is going to be the best time piece at that moment in time.

00:50:28.660 --> 00:50:31.660
And that's where the Best Master Clock algorithm comes into play.

00:50:32.660 --> 00:50:37.660
This Best Master Clock algorithm specifies how each clock on the network

00:50:38.660 --> 00:50:43.660
determines the Best Master Clock in its domain of all the clocks it can see.

00:50:44.660 --> 00:50:45.660
So all the clocks that can see each other,

00:50:46.660 --> 00:50:48.660
all the devices that can see each other are part of the Best Master Clock.

00:50:49.660 --> 00:50:53.660
They're part of that same PTP domain that you've set up using PTP.

00:50:54.660 --> 00:50:56.660
And as a result of that, between them all,

00:50:57.660 --> 00:50:59.660
even your switches, even your routers, if they're participating in PTP,

00:51:00.660 --> 00:51:02.660
they have the opportunity to become a Grandmaster Clock.

00:51:03.660 --> 00:51:04.660
Obviously, you don't want them to be, but they could.

00:51:05.660 --> 00:51:08.660
So the Grandmaster Clock is going to be,

00:51:09.660 --> 00:51:11.660
or all the devices are going to be running the Best Master Clock algorithm

00:51:12.660 --> 00:51:15.660
on all their different ports participating in PTP

00:51:16.660 --> 00:51:20.660
in order to figure out who in the world is going to be that Grandmaster Clock.

00:51:21.660 --> 00:51:24.660
And so you can see here that we have our decision order,

00:51:25.660 --> 00:51:29.660
a Priority 1, Class, Accuracy, Variance, Priority 2, as well as Identity.

00:51:30.660 --> 00:51:34.660
Based on my experience, you don't really have to know these specifically,

00:51:35.660 --> 00:51:36.660
but you never know, right?

00:51:37.660 --> 00:51:39.660
You never know if all of a sudden you get a question on PTP on the exam,

00:51:40.660 --> 00:51:41.660
you're like, oh, I wish I would have known this.

00:51:41.660 --> 00:51:44.660
So I've included it here in case it comes up.

00:51:45.660 --> 00:51:47.660
But when you're looking at the Best Master Clock algorithm

00:51:48.660 --> 00:51:49.660
and you're looking at the output, for example, of Show PTP Clock,

00:51:50.660 --> 00:51:52.660
you'll see Priority 1 is right there.

00:51:53.660 --> 00:51:54.660
So Priority 1, what is that?

00:51:55.660 --> 00:51:56.660
It's just a user-assigned priority.

00:51:57.660 --> 00:52:02.660
And every single device defaults to a value of 128 for Priority 1.

00:52:03.660 --> 00:52:04.660
It's a range from 0 to 255.

00:52:05.660 --> 00:52:06.660
And lower is better.

00:52:07.660 --> 00:52:08.660
So the lower Priority 1, the better.

00:52:08.660 --> 00:52:11.660
And since they're all 128 by default, then we move on to Class.

00:52:12.660 --> 00:52:13.660
So what is Class?

00:52:14.660 --> 00:52:20.660
Class is about what the clock class is that the clock belongs to.

00:52:21.660 --> 00:52:22.660
So depending on the type of clock you have,

00:52:23.660 --> 00:52:24.660
the class is going to be different.

00:52:25.660 --> 00:52:28.660
So for example, Class of 6, for example,

00:52:29.660 --> 00:52:31.660
means that the primary reference clock is a GPS.

00:52:32.660 --> 00:52:35.660
So if you saw 6 here, Class 6, we're dealing with GPS.

00:52:35.660 --> 00:52:38.660
So if this GMC, Grandmaster Clock, was connected to GPS,

00:52:39.660 --> 00:52:40.660
it would have a Class of 6.

00:52:41.660 --> 00:52:43.660
Whereas if this one was not connected to a GPS,

00:52:44.660 --> 00:52:45.660
then it would have something like 248,

00:52:46.660 --> 00:52:49.660
which is a default value, meaning nothing else applies.

00:52:50.660 --> 00:52:52.660
So there are different class categories for different clocks.

00:52:53.660 --> 00:52:55.660
And I didn't provide all the different ones here to you

00:52:56.660 --> 00:52:57.660
because it doesn't matter, right?

00:52:58.660 --> 00:53:00.660
If it does in the future, then I'll add it.

00:53:01.660 --> 00:53:03.660
But if you want to look it up, what are the PTP clock

00:53:03.660 --> 00:53:08.660
or what are the PTP clock class categories?

00:53:09.660 --> 00:53:10.660
And you can find a list out there.

00:53:11.660 --> 00:53:12.660
And the list is not all that intuitive.

00:53:13.660 --> 00:53:18.660
They'd have numbers of 6 and 7 and 13 and 14 and 52 and 248 and 255.

00:53:19.660 --> 00:53:22.660
255 means never become the Master Clock.

00:53:23.660 --> 00:53:24.660
That's what 255 would mean.

00:53:25.660 --> 00:53:26.660
Never become the Master Clock.

00:53:27.660 --> 00:53:29.660
But then there's other values underneath that.

00:53:30.660 --> 00:53:31.660
Accuracy is next.

00:53:31.660 --> 00:53:35.660
So the precision between the clock and UTC time in nanoseconds.

00:53:36.660 --> 00:53:39.660
So if the priority is tied amongst two and then the class is tied,

00:53:40.660 --> 00:53:43.660
the question now is, who is more accurate between the two?

00:53:44.660 --> 00:53:46.660
So right now, accuracy is unknown in this particular example.

00:53:47.660 --> 00:53:50.660
But if accuracy was known, it would be listed in nanoseconds.

00:53:51.660 --> 00:53:54.660
For example, you might see something where one says it's 250 nanoseconds

00:53:55.660 --> 00:53:57.660
and another one that maybe says 260 nanoseconds.

00:53:58.660 --> 00:54:00.660
So the lower the nanoseconds, the better

00:54:01.660 --> 00:54:03.660
because that means you are more accurate.

00:54:04.660 --> 00:54:09.660
Because your accuracy is the variation with the UTC clock.

00:54:10.660 --> 00:54:13.660
And then you've got variance, which is the variability of the clock,

00:54:14.660 --> 00:54:15.660
which is basically the stability of the clock.

00:54:16.660 --> 00:54:17.660
So how stable is it?

00:54:18.660 --> 00:54:19.660
And then you've got priority 2, which is another user-assigned priority.

00:54:20.660 --> 00:54:21.660
So it's just tied, tied, tied, tied.

00:54:22.660 --> 00:54:24.660
You still have the ability to have another priority if you want to.

00:54:25.660 --> 00:54:27.660
And you can see the priority 2 right there.

00:54:28.660 --> 00:54:29.660
But again, default is 128.

00:54:29.660 --> 00:54:31.660
Lower is better with a value from 0 to 255.

00:54:32.660 --> 00:54:33.660
So if all of those other things are the same

00:54:34.660 --> 00:54:35.660
and you want to leave them that way,

00:54:36.660 --> 00:54:38.660
you can use priority 2 to break your tie in that case.

00:54:39.660 --> 00:54:41.660
And then lastly, there's an identity for all of it.

00:54:42.660 --> 00:54:43.660
And there's the identity right there.

00:54:44.660 --> 00:54:45.660
What it is, it takes the base Ethernet MAC address of the device,

00:54:46.660 --> 00:54:50.660
and it uses EUI-64 to come up with a 64-bit identifier.

00:54:51.660 --> 00:54:54.660
And you can always identify anything that's EUI-64

00:54:55.660 --> 00:54:58.660
by looking at the middle of it and seeing FFFE.

00:54:59.660 --> 00:55:00.660
All right.

00:55:01.660 --> 00:55:03.660
So let's say in this particular case,

00:55:04.660 --> 00:55:08.660
this is going to be our Grand Master Clock, our GMC.

00:55:09.660 --> 00:55:12.660
And this is going to be our backup Grand Master Clock

00:55:13.660 --> 00:55:14.660
based on the Best Master Clock algorithm.

00:55:15.660 --> 00:55:16.660
So what is next?

00:55:17.660 --> 00:55:19.660
Well, let's talk about Ordinary Clock.

00:55:20.660 --> 00:55:22.660
So what is an Ordinary Clock?

00:55:23.660 --> 00:55:24.660
Well, Ordinary Clock, let's say,

00:55:25.660 --> 00:55:27.660
Ordinary Clock right here, so this device.

00:55:27.660 --> 00:55:30.660
An Ordinary Clock refers to any device

00:55:31.660 --> 00:55:33.660
within that PTP network, within that PTP domain

00:55:34.660 --> 00:55:35.660
that's going to be synchronizing its time

00:55:36.660 --> 00:55:37.660
with the Grand Master Clock.

00:55:38.660 --> 00:55:40.660
So in this case, I'm synchronizing with the Grand Master Clock.

00:55:41.660 --> 00:55:42.660
That makes me an Ordinary Clock.

00:55:43.660 --> 00:55:45.660
I am synchronizing with the Grand Master Clock.

00:55:46.660 --> 00:55:47.660
That makes me an Ordinary Clock.

00:55:48.660 --> 00:55:49.660
That's all that means.

00:55:50.660 --> 00:55:53.660
So computers and servers, routers, switches, printers,

00:55:54.660 --> 00:55:55.660
IP phones, industrial control systems,

00:55:55.660 --> 00:55:57.660
test and measurement equipment like, what,

00:55:58.660 --> 00:56:01.660
oscilloscopes, signal generators, spectrum analyzers,

00:56:02.660 --> 00:56:04.660
IP-based surveillance cameras, network-attached storage devices,

00:56:05.660 --> 00:56:07.660
Internet of Things devices, and the list goes on and on and on

00:56:08.660 --> 00:56:09.660
and can be Ordinary Clocks.

00:56:12.660 --> 00:56:14.660
So how does synchronization actually happen?

00:56:15.660 --> 00:56:17.660
Well, this is our process we follow here for synchronization

00:56:18.660 --> 00:56:21.660
between the Grand Master Clock and our Ordinary Clock.

00:56:22.660 --> 00:56:23.660
So it doesn't matter where the Ordinary Clock is.

00:56:23.660 --> 00:56:24.660
It doesn't matter where the Ordinary Clock is,

00:56:25.660 --> 00:56:26.660
any one of those devices we just talked about.

00:56:27.660 --> 00:56:28.660
This is what's happening.

00:56:29.660 --> 00:56:30.660
So we have these messages.

00:56:31.660 --> 00:56:32.660
Our first one here is that our Grand Master Clock

00:56:33.660 --> 00:56:34.660
sends out what is called a sync message

00:56:35.660 --> 00:56:36.660
to the Ordinary Clocks

00:56:37.660 --> 00:56:41.660
and notes the time of T1 at which it was sent.

00:56:42.660 --> 00:56:45.660
And then the Ordinary Clock receives that sync message

00:56:46.660 --> 00:56:49.660
and notes the time of reception, T2.

00:56:49.660 --> 00:56:53.660
The Master conveys to the Ordinary Clock the timestamp T1

00:56:54.660 --> 00:56:57.660
by embedding that timestamp T1 in a follow-up message.

00:56:58.660 --> 00:57:00.660
So the follow-up message is the GMC telling the Ordinary Clock,

00:57:01.660 --> 00:57:02.660
hey, T1 was this, by the way.

00:57:03.660 --> 00:57:04.660
So now what does that mean?

00:57:05.660 --> 00:57:07.660
It means the Ordinary Clock has T1 and T2.

00:57:09.660 --> 00:57:11.660
And also the Ordinary Clock can now send a delay request,

00:57:12.660 --> 00:57:14.660
it's called, message to the Master

00:57:15.660 --> 00:57:17.660
and note the time of T3 at which it was sent.

00:57:18.660 --> 00:57:20.660
And then the Master receives the delay request message

00:57:21.660 --> 00:57:22.660
and notes the reception timestamp of T4.

00:57:23.660 --> 00:57:25.660
And then the Master conveys to the Ordinary Clock

00:57:26.660 --> 00:57:29.660
the timestamp of T4 in that delay response message.

00:57:30.660 --> 00:57:32.660
So now the Ordinary Clock has T1, T2, T3, T4.

00:57:33.660 --> 00:57:35.660
It has those four pieces of information

00:57:36.660 --> 00:57:37.660
that are necessary to actually do the calculation

00:57:38.660 --> 00:57:39.660
that it needs to do.

00:57:41.660 --> 00:57:43.660
So the Ordinary Clock processes all four timestamps.

00:57:44.660 --> 00:57:46.660
And so now it can calculate the offset of the Ordinary Clock

00:57:47.660 --> 00:57:48.660
relative to the Master

00:57:49.660 --> 00:57:51.660
and then figure out what time it actually is.

00:57:52.660 --> 00:57:54.660
However, that's not it.

00:57:55.660 --> 00:57:56.660
There's more to it.

00:57:57.660 --> 00:57:59.660
Because remember that PTP provides more accurate time

00:58:02.660 --> 00:58:03.660
versus NTP.

00:58:04.660 --> 00:58:05.660
How?

00:58:06.660 --> 00:58:07.660
We said by keeping track of what?

00:58:08.660 --> 00:58:09.660
Delay from the device providing time

00:58:10.660 --> 00:58:11.660
and the device getting time.

00:58:12.660 --> 00:58:13.660
We need the device that's getting time

00:58:14.660 --> 00:58:15.660
to be able to use that delay

00:58:16.660 --> 00:58:18.660
in order to modify its time

00:58:19.660 --> 00:58:20.660
to get more accurate time.

00:58:25.660 --> 00:58:26.660
See all these devices in between?

00:58:27.660 --> 00:58:28.660
This is what we talked about.

00:58:29.660 --> 00:58:30.660
The time it takes to go from here to here

00:58:31.660 --> 00:58:32.660
to here to here to here to here to here to here.

00:58:33.660 --> 00:58:34.660
Right?

00:58:35.660 --> 00:58:36.660
Or the time it takes to go from here to here

00:58:37.660 --> 00:58:38.660
to here to here to here to here to here to here to here.

00:58:39.660 --> 00:58:40.660
That is what we're talking about.

00:58:41.660 --> 00:58:42.660
That delay.

00:58:43.660 --> 00:58:44.660
The time it takes to go there.

00:58:46.660 --> 00:58:48.660
How does this get taken care of?

00:58:49.660 --> 00:58:51.660
Well, what we need is we need devices

00:58:52.660 --> 00:58:55.660
that understand IEEE 1588.

00:58:56.660 --> 00:58:58.660
They have to be IEEE 1588 enabled devices.

00:58:59.660 --> 00:59:01.660
And what does IEEE 1588 mean?

00:59:07.660 --> 00:59:08.660
It means PTP, right?

00:59:09.660 --> 00:59:10.660
That's what it means.

00:59:12.660 --> 00:59:15.660
So we need PTP enabled devices.

00:59:16.660 --> 00:59:17.660
That's what we need.

00:59:23.660 --> 00:59:27.660
So the PTP enabled device

00:59:28.660 --> 00:59:31.660
has the ability to

00:59:33.660 --> 00:59:36.660
inform the ordinary clock

00:59:37.660 --> 00:59:39.660
about that delay.

00:59:40.660 --> 00:59:42.660
And we have two different types

00:59:43.660 --> 00:59:48.660
of IEEE 1588

00:59:49.660 --> 00:59:50.660
devices we can set up.

00:59:51.660 --> 00:59:53.660
We can set up a transparent device

00:59:54.660 --> 00:59:56.660
or we can set up a boundary device.

00:59:57.660 --> 00:59:58.660
So let's talk about transparent.

00:59:59.660 --> 01:00:00.660
So in this case here,

01:00:01.660 --> 01:00:02.660
let's just take a peek at the transparence.

01:00:03.660 --> 01:00:04.660
So I have a transparent here.

01:00:05.660 --> 01:00:06.660
I have a transparent here.

01:00:06.660 --> 01:00:07.660
I have a transparent here.

01:00:12.660 --> 01:00:13.660
I have a transparent here.

01:00:14.660 --> 01:00:15.660
I have a transparent here.

01:00:17.660 --> 01:00:18.660
I have a transparent here.

01:00:19.660 --> 01:00:20.660
We'd also want a transparent here.

01:00:23.660 --> 01:00:24.660
Right? And transparent.

01:00:25.660 --> 01:00:26.660
So essentially, we'd want all of our devices

01:00:27.660 --> 01:00:28.660
to be transparent.

01:00:29.660 --> 01:00:30.660
So the transparent device, that is our what?

01:00:31.660 --> 01:00:32.660
That is our network device.

01:00:32.660 --> 01:00:33.660
So the transparent clock

01:00:34.660 --> 01:00:35.660
is our device

01:00:36.660 --> 01:00:37.660
that handles PTP packets,

01:00:38.660 --> 01:00:39.660
IEEE 1588 packets,

01:00:41.660 --> 01:00:43.660
differently than a non-PTP device,

01:00:44.660 --> 01:00:45.660
a non-IEEE 1588 device.

01:00:46.660 --> 01:00:48.660
So when we set up this transparent clock feature,

01:00:49.660 --> 01:00:50.660
the transparent clock can actually measure

01:00:51.660 --> 01:00:52.660
the time that the packet is stored in the switch.

01:00:53.660 --> 01:00:54.660
I'll repeat that.

01:00:55.660 --> 01:00:56.660
It can measure the time the packet is stored

01:00:57.660 --> 01:00:59.660
in the actual networking device.

01:01:00.660 --> 01:01:01.660
And then,

01:01:02.660 --> 01:01:03.660
that information can be added

01:01:04.660 --> 01:01:05.660
to the PTP message

01:01:06.660 --> 01:01:07.660
that is being forwarded on.

01:01:09.660 --> 01:01:10.660
And therefore,

01:01:11.660 --> 01:01:12.660
that information that's been added

01:01:13.660 --> 01:01:14.660
can help the ordinary clock

01:01:15.660 --> 01:01:17.660
account for the packet delay,

01:01:19.660 --> 01:01:21.660
therefore getting more hyper-accurate time.

01:01:22.660 --> 01:01:24.660
So when it comes to transparent clocks,

01:01:25.660 --> 01:01:26.660
we've got two different modes.

01:01:27.660 --> 01:01:28.660
We've got end-to-end transparent clocks,

01:01:29.660 --> 01:01:30.660
and we've got PTP transparent clocks.

01:01:31.660 --> 01:01:32.660
All right, so let's make these a little darker

01:01:33.660 --> 01:01:34.660
so we can see them.

01:01:35.660 --> 01:01:36.660
All right, so there we go.

01:01:37.660 --> 01:01:38.660
So here's an example.

01:01:39.660 --> 01:01:40.660
There we've got our transparent clock set up.

01:01:41.660 --> 01:01:42.660
So what would be happening now

01:01:43.660 --> 01:01:44.660
as we go from here to here to here

01:01:45.660 --> 01:01:46.660
to here to here,

01:01:47.660 --> 01:01:48.660
and so on and so forth?

01:01:49.660 --> 01:01:50.660
What is happening?

01:01:51.660 --> 01:01:52.660
Let's zoom into that right now.

01:01:53.660 --> 01:01:54.660
So essentially,

01:01:55.660 --> 01:01:56.660
what would be happening here

01:01:57.660 --> 01:01:58.660
is that the Grandmaster clock,

01:01:58.660 --> 01:01:59.660
when it's sending out that sync,

01:02:00.660 --> 01:02:01.660
you see how the sync

01:02:02.660 --> 01:02:04.660
is going to be going from end-to-end.

01:02:05.660 --> 01:02:06.660
That's why it's called end-to-end.

01:02:07.660 --> 01:02:08.660
That sync message is going from end-to-end.

01:02:09.660 --> 01:02:10.660
But what you need to recognize here

01:02:11.660 --> 01:02:12.660
is that along the way,

01:02:14.660 --> 01:02:15.660
our network devices

01:02:16.660 --> 01:02:19.660
are calculating the time it takes

01:02:20.660 --> 01:02:22.660
to do things like processing.

01:02:29.660 --> 01:02:33.660
And it creates a value called residency time.

01:02:35.660 --> 01:02:37.660
And it adds the residency time

01:02:38.660 --> 01:02:40.660
to that sync message.

01:02:41.660 --> 01:02:42.660
So now when the sync message goes,

01:02:43.660 --> 01:02:45.660
there's the residency time included with it.

01:02:46.660 --> 01:02:47.660
And then this device calculates

01:02:48.660 --> 01:02:49.660
its residency time, adds to it.

01:02:50.660 --> 01:02:51.660
So now we've got the residency time

01:02:52.660 --> 01:02:53.660
added to that as well,

01:02:54.660 --> 01:02:55.660
and so on and so forth.

01:02:56.660 --> 01:02:57.660
So along the way,

01:02:58.660 --> 01:02:59.660
we've got residency time,

01:03:00.660 --> 01:03:01.660
residency time, residency time.

01:03:02.660 --> 01:03:03.660
And then eventually the ordinary clock gets it,

01:03:04.660 --> 01:03:05.660
and what does it have?

01:03:06.660 --> 01:03:07.660
It has the original time

01:03:08.660 --> 01:03:09.660
provided by the Grandmaster clock

01:03:11.660 --> 01:03:12.660
along with what?

01:03:13.660 --> 01:03:14.660
Along with

01:03:15.660 --> 01:03:17.660
all of the residency times,

01:03:18.660 --> 01:03:20.660
how long that particular sync message

01:03:21.660 --> 01:03:23.660
hung out on that device

01:03:24.660 --> 01:03:25.660
while it was doing other things,

01:03:26.660 --> 01:03:27.660
like processing other packets.

01:03:28.660 --> 01:03:29.660
So we've got the device for,

01:03:30.660 --> 01:03:31.660
well, if we go with seconds,

01:03:32.660 --> 01:03:33.660
one second,

01:03:34.660 --> 01:03:35.660
well, at least the residency time

01:03:36.660 --> 01:03:37.660
would say one second.

01:03:38.660 --> 01:03:39.660
Simplification,

01:03:40.660 --> 01:03:41.660
we're talking microseconds here

01:03:42.660 --> 01:03:43.660
as packets flow through our network,

01:03:44.660 --> 01:03:45.660
but so our brains don't explode,

01:03:46.660 --> 01:03:47.660
we're going to stick with seconds

01:03:48.660 --> 01:03:49.660
as our discussion unfolds.

01:03:50.660 --> 01:03:51.660
And then don't forget,

01:03:52.660 --> 01:03:53.660
we also have that secondary forward message

01:03:54.660 --> 01:03:55.660
that comes up to follow up, I should say.

01:03:56.660 --> 01:03:57.660
So that follow up again

01:03:58.660 --> 01:03:59.660
is the time and so on and so forth

01:04:00.660 --> 01:04:01.660
that gets sent down the line.

01:04:02.660 --> 01:04:03.660
So in the end,

01:04:04.660 --> 01:04:05.660
the ordinary clock is still getting T1,

01:04:06.660 --> 01:04:07.660
T2, T3, T4,

01:04:08.660 --> 01:04:09.660
but it's also getting all the residency times as well.

01:04:10.660 --> 01:04:11.660
And so then by taking

01:04:12.660 --> 01:04:13.660
all those times

01:04:14.660 --> 01:04:15.660
and then factoring in

01:04:16.660 --> 01:04:17.660
the residency times,

01:04:18.660 --> 01:04:19.660
it has the ability to figure out

01:04:20.660 --> 01:04:21.660
what time it actually is

01:04:22.660 --> 01:04:23.660
on that Grandmaster clock.

01:04:24.660 --> 01:04:25.660
More hyper-accurate time.

01:04:26.660 --> 01:04:27.660
So we've taken into account what?

01:04:28.660 --> 01:04:29.660
The latency

01:04:31.660 --> 01:04:32.660
of that device,

01:04:33.660 --> 01:04:34.660
the delay that the device is causing.

01:04:35.660 --> 01:04:36.660
But the problem with

01:04:37.660 --> 01:04:38.660
end-to-end transparent, folks,

01:04:39.660 --> 01:04:40.660
is that it doesn't take into consideration

01:04:41.660 --> 01:04:42.660
link delay.

01:04:43.660 --> 01:04:44.660
That's right.

01:04:45.660 --> 01:04:46.660
It's only taking into consideration what?

01:04:47.660 --> 01:04:48.660
The time it takes

01:04:49.660 --> 01:04:50.660
for the device to do its processing.

01:04:51.660 --> 01:04:52.660
We're still missing

01:04:53.660 --> 01:04:54.660
another valuable part.

01:04:55.660 --> 01:04:56.660
And that is the link delay

01:04:57.660 --> 01:04:58.660
between the peers.

01:04:59.660 --> 01:05:00.660
How long it takes the peers

01:05:01.660 --> 01:05:02.660
to actually talk to each other.

01:05:04.660 --> 01:05:05.660
So we could be even more hyper-accurate.

01:05:06.660 --> 01:05:07.660
And how do we do that?

01:05:08.660 --> 01:05:09.660
We've got to do what is called

01:05:10.660 --> 01:05:11.660
P2P transparent.

01:05:12.660 --> 01:05:13.660
So P2P transparent instead,

01:05:14.660 --> 01:05:15.660
this is how the conversation would happen.

01:05:16.660 --> 01:05:17.660
Notice how each

01:05:19.660 --> 01:05:20.660
of the devices

01:05:21.660 --> 01:05:22.660
are essentially

01:05:23.660 --> 01:05:24.660
exchanging messages with each other.

01:05:25.660 --> 01:05:26.660
And then exchanging messages

01:05:27.660 --> 01:05:28.660
with each other.

01:05:28.660 --> 01:05:29.660
And then exchanging messages

01:05:29.660 --> 01:05:30.660
with each other.

01:05:30.660 --> 01:05:31.660
Whereas before,

01:05:31.660 --> 01:05:32.660
it was what?

01:05:32.660 --> 01:05:33.660
End-to-end.

01:05:33.660 --> 01:05:34.660
Message, message, message.

01:05:35.660 --> 01:05:36.660
You see that?

01:05:36.660 --> 01:05:37.660
Whereas with P2P,

01:05:38.660 --> 01:05:39.660
every step along the way

01:05:40.660 --> 01:05:41.660
is an exchange.

01:05:41.660 --> 01:05:42.660
So,

01:05:42.660 --> 01:05:43.660
exchange,

01:05:43.660 --> 01:05:44.660
exchange,

01:05:44.660 --> 01:05:45.660
exchange,

01:05:45.660 --> 01:05:46.660
exchange,

01:05:46.660 --> 01:05:47.660
exchange,

01:05:47.660 --> 01:05:48.660
exchange.

01:05:49.660 --> 01:05:50.660
That's P2P.

01:05:51.660 --> 01:05:52.660
So now with P2P,

01:05:52.660 --> 01:05:53.660
we can also calculate

01:05:53.660 --> 01:05:55.660
not only the residency time,

01:05:55.660 --> 01:05:57.660
but also the time it took

01:05:57.660 --> 01:05:58.660
to talk to each other.

01:05:58.660 --> 01:05:59.660
The time it took to communicate.

01:06:01.660 --> 01:06:02.660
So now you're getting

01:06:02.660 --> 01:06:03.660
everything

01:06:03.660 --> 01:06:05.660
as part of this particular calculation.

01:06:07.660 --> 01:06:08.660
So we have the thing called

01:06:08.660 --> 01:06:09.660
the correction field.

01:06:10.660 --> 01:06:11.660
The correction field

01:06:11.660 --> 01:06:12.660
is going to be taken into consideration.

01:06:13.660 --> 01:06:14.660
The time it took to talk

01:06:14.660 --> 01:06:15.660
plus the residency time.

01:06:15.660 --> 01:06:16.660
The time it took to talk

01:06:16.660 --> 01:06:17.660
plus the residency.

01:06:17.660 --> 01:06:18.660
And then in the end,

01:06:18.660 --> 01:06:19.660
the full calculation can be done

01:06:20.660 --> 01:06:21.660
by the ordinary clock.

01:06:21.660 --> 01:06:22.660
You're not going to have to do

01:06:22.660 --> 01:06:23.660
calculations on the exam, folks.

01:06:23.660 --> 01:06:24.660
So don't worry about it.

01:06:24.660 --> 01:06:25.660
But I'm just trying to show you here

01:06:25.660 --> 01:06:26.660
how we get that

01:06:26.660 --> 01:06:27.660
more hyper-accurate time now.

01:06:35.660 --> 01:06:36.660
So,

01:06:36.660 --> 01:06:37.660
on an exam,

01:06:37.660 --> 01:06:38.660
if they're asking you to choose

01:06:38.660 --> 01:06:39.660
which is more accurate,

01:06:39.660 --> 01:06:40.660
peer-to-peer would be more accurate

01:06:40.660 --> 01:06:42.660
than end-to-end.

01:06:43.660 --> 01:06:44.660
But we still have a few issues here.

01:06:45.660 --> 01:06:46.660
Regardless of whether you're using

01:06:46.660 --> 01:06:47.660
end-to-end or peer-to-peer.

01:06:48.660 --> 01:06:49.660
And that is what?

01:06:49.660 --> 01:06:50.660
Well,

01:06:50.660 --> 01:06:51.660
let's think about what's happening here.

01:06:51.660 --> 01:06:52.660
With transparent mode,

01:06:52.660 --> 01:06:53.660
transparent clocks,

01:06:55.660 --> 01:06:56.660
we are really just dealing with

01:06:57.660 --> 01:06:58.660
forwarding devices.

01:07:02.660 --> 01:07:03.660
They don't generate any

01:07:03.660 --> 01:07:04.660
P2P messages themselves, right?

01:07:05.660 --> 01:07:06.660
What do they do?

01:07:06.660 --> 01:07:07.660
They take the original P2P message

01:07:08.660 --> 01:07:09.660
from the Grandmaster clock.

01:07:10.660 --> 01:07:12.660
They add whatever information

01:07:12.660 --> 01:07:13.660
is necessary for delay,

01:07:14.660 --> 01:07:15.660
for processing,

01:07:15.660 --> 01:07:16.660
things like that.

01:07:17.660 --> 01:07:18.660
By adding the PD field,

01:07:19.660 --> 01:07:20.660
the RT fields,

01:07:20.660 --> 01:07:21.660
different things like that,

01:07:21.660 --> 01:07:22.660
and they pass it on.

01:07:26.660 --> 01:07:27.660
And that

01:07:29.660 --> 01:07:30.660
can

01:07:31.660 --> 01:07:32.660
become extremely overwhelming

01:07:33.660 --> 01:07:34.660
for the network

01:07:34.660 --> 01:07:35.660
and the Grandmaster clock

01:07:35.660 --> 01:07:36.660
when it's all said and done.

01:07:36.660 --> 01:07:37.660
We're going to get to that

01:07:37.660 --> 01:07:38.660
here momentarily.

01:07:39.660 --> 01:07:40.660
Another thing, too,

01:07:40.660 --> 01:07:41.660
is that transparent clocks

01:07:42.660 --> 01:07:43.660
can only basically work

01:07:43.660 --> 01:07:44.660
when the clock is set.

01:07:44.660 --> 01:07:45.660
Transparent clocks

01:07:46.660 --> 01:07:47.660
can only basically work

01:07:47.660 --> 01:07:48.660
in a single VLAN.

01:07:49.660 --> 01:07:50.660
That's right.

01:07:51.660 --> 01:07:52.660
So if you have, for example,

01:07:52.660 --> 01:07:53.660
like a multilayer switch

01:07:53.660 --> 01:07:55.660
servicing multiple VLANs,

01:07:56.660 --> 01:07:57.660
only the native VLAN

01:07:58.660 --> 01:07:59.660
would receive the P2P messages.

01:07:59.660 --> 01:08:00.660
So any other device

01:08:00.660 --> 01:08:01.660
in any other VLAN

01:08:01.660 --> 01:08:02.660
would not get those messages.

01:08:03.660 --> 01:08:04.660
So what we need

01:08:06.660 --> 01:08:07.660
is another mode,

01:08:07.660 --> 01:08:08.660
and that other mode

01:08:08.660 --> 01:08:09.660
is called boundary mode.

01:08:10.660 --> 01:08:11.660
So with boundary mode,

01:08:11.660 --> 01:08:12.660
what do we get?

01:08:12.660 --> 01:08:13.660
Well, a boundary mode

01:08:13.660 --> 01:08:14.660
or boundary clock

01:08:15.660 --> 01:08:16.660
is a device

01:08:16.660 --> 01:08:17.660
that can handle P2P packets

01:08:17.660 --> 01:08:18.660
differently

01:08:18.660 --> 01:08:20.660
than those transparent switches.

01:08:20.660 --> 01:08:21.660
Remember, a transparent switch

01:08:21.660 --> 01:08:23.660
only modifies the P2P packet.

01:08:23.660 --> 01:08:24.660
But see, a boundary clock,

01:08:24.660 --> 01:08:25.660
what it does

01:08:25.660 --> 01:08:26.660
is it gobbles up

01:08:27.660 --> 01:08:28.660
and actually processes

01:08:28.660 --> 01:08:29.660
that P2P packet.

01:08:31.660 --> 01:08:32.660
Therefore, the boundary clock

01:08:32.660 --> 01:08:33.660
is synchronizing

01:08:34.660 --> 01:08:35.660
with the Grandmaster clock.

01:08:35.660 --> 01:08:36.660
You see, the transparent clocks

01:08:37.660 --> 01:08:38.660
don't synchronize

01:08:38.660 --> 01:08:39.660
with the Grandmaster clock.

01:08:40.660 --> 01:08:41.660
It's not part of the standard.

01:08:41.660 --> 01:08:42.660
However,

01:08:42.660 --> 01:08:43.660
your Cisco devices

01:08:44.660 --> 01:08:45.660
might, even though they're

01:08:45.660 --> 01:08:46.660
in transparent mode,

01:08:46.660 --> 01:08:47.660
be synchronizing with

01:08:47.660 --> 01:08:48.660
the Grandmaster clock

01:08:48.660 --> 01:08:49.660
because that is what

01:08:49.660 --> 01:08:50.660
Cisco chose to do.

01:08:50.660 --> 01:08:51.660
But based on the IEEE standard,

01:08:51.660 --> 01:08:52.660
they shouldn't be.

01:08:52.660 --> 01:08:53.660
But if Cisco is doing it,

01:08:53.660 --> 01:08:54.660
then fine.

01:08:54.660 --> 01:08:55.660
So if all of a sudden

01:08:55.660 --> 01:08:56.660
you have transparent clocks,

01:08:56.660 --> 01:08:57.660
you're like,

01:08:57.660 --> 01:08:58.660
well, it is synchronizing.

01:08:58.660 --> 01:08:59.660
Yeah, because Cisco

01:08:59.660 --> 01:09:00.660
made some modifications

01:09:00.660 --> 01:09:01.660
to how they deploy

01:09:01.660 --> 01:09:02.660
transparent clocks.

01:09:02.660 --> 01:09:03.660
But based on the standard,

01:09:03.660 --> 01:09:04.660
a boundary clock

01:09:04.660 --> 01:09:05.660
will 100%

01:09:05.660 --> 01:09:06.660
synchronize with

01:09:06.660 --> 01:09:07.660
the Grandmaster clock

01:09:09.660 --> 01:09:10.660
and gobble up

01:09:10.660 --> 01:09:11.660
the PTP messages.

01:09:12.660 --> 01:09:13.660
And then the boundary clock

01:09:13.660 --> 01:09:14.660
becomes

01:09:14.660 --> 01:09:15.660
the master

01:09:16.660 --> 01:09:17.660
PTP clock

01:09:17.660 --> 01:09:18.660
for anybody

01:09:18.660 --> 01:09:19.660
after it,

01:09:19.660 --> 01:09:20.660
for all downstream devices.

01:09:21.660 --> 01:09:22.660
So it's going to generate

01:09:22.660 --> 01:09:23.660
new PTP messages

01:09:23.660 --> 01:09:24.660
and send them on.

01:09:24.660 --> 01:09:25.660
Why?

01:09:25.660 --> 01:09:26.660
Okay, well, consider this.

01:09:27.660 --> 01:09:28.660
Let's say you have

01:09:28.660 --> 01:09:29.660
10,000 ordinary clocks.

01:09:30.660 --> 01:09:31.660
10,000 ordinary clocks

01:09:31.660 --> 01:09:32.660
between

01:09:32.660 --> 01:09:33.660
all the different

01:09:33.660 --> 01:09:34.660
systems you have

01:09:35.660 --> 01:09:36.660
that need hyper-accurate time.

01:09:36.660 --> 01:09:37.660
You've got like 10,000.

01:09:41.660 --> 01:09:42.660
They are all

01:09:42.660 --> 01:09:43.660
ordinary clocks.

01:09:44.660 --> 01:09:45.660
They need to synchronize

01:09:45.660 --> 01:09:46.660
their time.

01:09:46.660 --> 01:09:47.660
Well, if you have

01:09:47.660 --> 01:09:48.660
10,000 devices

01:09:48.660 --> 01:09:49.660
synchronizing all with

01:09:49.660 --> 01:09:50.660
the Grandmaster clock,

01:09:50.660 --> 01:09:51.660
that can be overwhelming

01:09:51.660 --> 01:09:52.660
for the Grandmaster clock,

01:09:52.660 --> 01:09:53.660
right?

01:09:53.660 --> 01:09:54.660
Absolutely.

01:09:57.660 --> 01:09:58.660
And in all those

01:09:58.660 --> 01:09:59.660
transparent clocks

01:09:59.660 --> 01:10:00.660
in between,

01:10:01.660 --> 01:10:02.660
in end-to-end

01:10:02.660 --> 01:10:03.660
transparent mode

01:10:03.660 --> 01:10:04.660
are going to be

01:10:04.660 --> 01:10:05.660
very, very, very,

01:10:05.660 --> 01:10:06.660
very busy, aren't they?

01:10:06.660 --> 01:10:07.660
Yes, they will be.

01:10:07.660 --> 01:10:08.660
Why?

01:10:08.660 --> 01:10:09.660
Because what are they doing?

01:10:09.660 --> 01:10:10.660
They are synchronizing

01:10:10.660 --> 01:10:11.660
every single PTP message.

01:10:12.660 --> 01:10:13.660
So, let's break up

01:10:13.660 --> 01:10:14.660
the environment

01:10:14.660 --> 01:10:15.660
into multiple

01:10:15.660 --> 01:10:16.660
PTP domains.

01:10:17.660 --> 01:10:18.660
Let's have a PTP domain

01:10:18.660 --> 01:10:19.660
between the Grandmaster clock

01:10:19.660 --> 01:10:20.660
and a Boundary clock

01:10:20.660 --> 01:10:21.660
and another PTP domain

01:10:21.660 --> 01:10:22.660
between Boundary clocks

01:10:22.660 --> 01:10:23.660
and the Ordinary clocks

01:10:23.660 --> 01:10:24.660
in different VLANs.

01:10:26.660 --> 01:10:27.660
Yes.

01:10:29.660 --> 01:10:30.660
So, our Boundary clock

01:10:30.660 --> 01:10:31.660
is synchronizing

01:10:31.660 --> 01:10:32.660
with the Grandmaster clock

01:10:33.660 --> 01:10:34.660
and the other

01:10:34.660 --> 01:10:35.660
Ordinary clocks

01:10:35.660 --> 01:10:36.660
can synchronize

01:10:36.660 --> 01:10:37.660
with the Boundary clock,

01:10:37.660 --> 01:10:38.660
getting multiple

01:10:38.660 --> 01:10:39.660
PTP domains.

01:10:40.660 --> 01:10:41.660
And then,

01:10:42.660 --> 01:10:43.660
unlike transparent clocks

01:10:43.660 --> 01:10:44.660
that do not work

01:10:45.660 --> 01:10:46.660
when you have multiple

01:10:46.660 --> 01:10:47.660
VLANs on a device,

01:10:47.660 --> 01:10:48.660
only the native VLAN

01:10:48.660 --> 01:10:49.660
would get time,

01:10:50.660 --> 01:10:51.660
with Boundary clocks

01:10:52.660 --> 01:10:53.660
you can have

01:10:53.660 --> 01:10:54.660
time delivered

01:10:54.660 --> 01:10:55.660
to all the different

01:10:55.660 --> 01:10:56.660
VLANs.

01:10:56.660 --> 01:10:57.660
So, essentially,

01:10:57.660 --> 01:10:58.660
those distribution layer

01:10:58.660 --> 01:10:59.660
switches you have

01:10:59.660 --> 01:11:00.660
that have all those

01:11:00.660 --> 01:11:01.660
different SVIs on them,

01:11:01.660 --> 01:11:02.660
those multilayer switches

01:11:02.660 --> 01:11:03.660
with a multitude

01:11:03.660 --> 01:11:04.660
of VLANs,

01:11:05.660 --> 01:11:06.660
you make those

01:11:06.660 --> 01:11:07.660
Boundary clocks.

01:11:08.660 --> 01:11:09.660
Like I've done here.

01:11:10.660 --> 01:11:11.660
And so, now, in the end,

01:11:11.660 --> 01:11:12.660
Grandmaster clock,

01:11:12.660 --> 01:11:13.660
you get your transparency

01:11:13.660 --> 01:11:14.660
in between,

01:11:14.660 --> 01:11:15.660
going to the Boundary clocks,

01:11:15.660 --> 01:11:16.660
and now the Boundary clock

01:11:16.660 --> 01:11:17.660
can have hyper-accurate

01:11:17.660 --> 01:11:18.660
synchronization

01:11:18.660 --> 01:11:19.660
with the Grandmaster clock

01:11:19.660 --> 01:11:20.660
because it can do

01:11:20.660 --> 01:11:21.660
all the calculations.

01:11:22.660 --> 01:11:23.660
Boom.

01:11:23.660 --> 01:11:24.660
Hyper-accurate time.

01:11:24.660 --> 01:11:25.660
So, now the time here

01:11:25.660 --> 01:11:26.660
should be the exact

01:11:26.660 --> 01:11:27.660
time over here.

01:11:27.660 --> 01:11:28.660
Exact.

01:11:28.660 --> 01:11:29.660
And then, now,

01:11:30.660 --> 01:11:31.660
everybody down here

01:11:31.660 --> 01:11:32.660
will have the ability

01:11:32.660 --> 01:11:33.660
to synchronize

01:11:33.660 --> 01:11:34.660
to the Boundary clocks.

01:11:36.660 --> 01:11:37.660
Breaking up.

01:11:37.660 --> 01:11:38.660
Making it more efficient.

01:11:38.660 --> 01:11:39.660
Making it more effective.

01:11:40.660 --> 01:11:41.660
And, if for some reason,

01:11:41.660 --> 01:11:42.660
the Grandmaster clock

01:11:42.660 --> 01:11:43.660
goes down,

01:11:43.660 --> 01:11:44.660
or there's a disruption

01:11:44.660 --> 01:11:45.660
in communication here,

01:11:45.660 --> 01:11:46.660
that's fine

01:11:46.660 --> 01:11:47.660
because the Boundary clocks

01:11:47.660 --> 01:11:48.660
can still

01:11:48.660 --> 01:11:49.660
make themselves

01:11:49.660 --> 01:11:50.660
a Grandmaster clock

01:11:50.660 --> 01:11:51.660
at that moment in time.

01:11:51.660 --> 01:11:52.660
So, they can make themselves

01:11:52.660 --> 01:11:53.660
a Grandmaster clock,

01:11:53.660 --> 01:11:54.660
so now they are

01:11:54.660 --> 01:11:55.660
the trusted time source

01:11:55.660 --> 01:11:56.660
at that moment in time.

01:11:56.660 --> 01:11:57.660
And then,

01:11:57.660 --> 01:11:58.660
when the Grandmaster clock

01:11:58.660 --> 01:11:59.660
comes back on,

01:11:59.660 --> 01:12:00.660
it's going to have

01:12:00.660 --> 01:12:01.660
the higher priority

01:12:01.660 --> 01:12:02.660
and the more preferred,

01:12:02.660 --> 01:12:03.660
I should say,

01:12:03.660 --> 01:12:04.660
the more preferred

01:12:05.660 --> 01:12:06.660
Grandmaster clock

01:12:06.660 --> 01:12:08.660
algorithm information,

01:12:08.660 --> 01:12:09.660
which, in the end,

01:12:09.660 --> 01:12:10.660
means that the Grandmaster clock,

01:12:10.660 --> 01:12:11.660
this device,

01:12:11.660 --> 01:12:12.660
will go back to being

01:12:12.660 --> 01:12:13.660
the Grandmaster clock

01:12:13.660 --> 01:12:14.660
and our Boundary clocks

01:12:14.660 --> 01:12:15.660
will just end up what?

01:12:15.660 --> 01:12:16.660
Right?

01:12:16.660 --> 01:12:17.660
Going back to

01:12:17.660 --> 01:12:18.660
synchronizing with it.

01:12:19.660 --> 01:12:20.660
So, it's good in that case

01:12:20.660 --> 01:12:21.660
for us.

01:12:22.660 --> 01:12:23.660
So, in this case here,

01:12:23.660 --> 01:12:24.660
you can see

01:12:24.660 --> 01:12:25.660
that what we've done

01:12:26.660 --> 01:12:27.660
is there's that Boundary clock

01:12:27.660 --> 01:12:28.660
in the middle

01:12:29.660 --> 01:12:30.660
and that Boundary clock

01:12:30.660 --> 01:12:31.660
is in the middle,

01:12:31.660 --> 01:12:32.660
so the Grandmaster clock

01:12:32.660 --> 01:12:33.660
is in the middle

01:12:33.660 --> 01:12:34.660
and that Boundary clock

01:12:34.660 --> 01:12:35.660
is in the middle,

01:12:35.660 --> 01:12:36.660
so the Grandmaster clock

01:12:36.660 --> 01:12:37.660
is synchronizing

01:12:37.660 --> 01:12:38.660
with the Boundary clock.

01:12:38.660 --> 01:12:39.660
End-to-end type

01:12:39.660 --> 01:12:40.660
of synchronization

01:12:40.660 --> 01:12:41.660
through those

01:12:41.660 --> 01:12:42.660
transparent clocks.

01:12:42.660 --> 01:12:43.660
Now,

01:12:43.660 --> 01:12:44.660
if you want to get

01:12:44.660 --> 01:12:45.660
even more hyper-accurate,

01:12:45.660 --> 01:12:46.660
like we said,

01:12:46.660 --> 01:12:47.660
so these are transparent,

01:12:47.660 --> 01:12:48.660
transparent, transparent,

01:12:48.660 --> 01:12:49.660
transparent as an example.

01:12:49.660 --> 01:12:50.660
If you want to get

01:12:50.660 --> 01:12:51.660
more hyper-accurate,

01:12:51.660 --> 01:12:52.660
then you do transparent P2P

01:12:52.660 --> 01:12:53.660
and then you're like

01:12:53.660 --> 01:12:54.660
boom, boom, boom,

01:12:54.660 --> 01:12:55.660
boom, boom, boom,

01:12:55.660 --> 01:12:56.660
boom, boom, boom.

01:12:56.660 --> 01:12:57.660
Right?

01:12:57.660 --> 01:12:58.660
You could do that as well.

01:12:58.660 --> 01:12:59.660
It's up to you

01:12:59.660 --> 01:13:00.660
how accurate

01:13:00.660 --> 01:13:01.660
the time you need,

01:13:01.660 --> 01:13:02.660
but you have all

01:13:02.660 --> 01:13:03.660
the options.

01:13:03.660 --> 01:13:04.660
But the Boundary clock here,

01:13:04.660 --> 01:13:05.660
we are synchronizing,

01:13:05.660 --> 01:13:06.660
as you can see,

01:13:06.660 --> 01:13:07.660
with the Grandmaster clock

01:13:07.660 --> 01:13:08.660
and the ordinary clocks

01:13:08.660 --> 01:13:09.660
with the Boundary clocks.

01:13:09.660 --> 01:13:10.660
All right,

01:13:10.660 --> 01:13:11.660
so here are some

01:13:11.660 --> 01:13:12.660
configuration commands

01:13:12.660 --> 01:13:13.660
that may or may not

01:13:13.660 --> 01:13:14.660
show up on the

01:13:14.660 --> 01:13:15.660
certification exam,

01:13:15.660 --> 01:13:16.660
but what I want you

01:13:16.660 --> 01:13:17.660
to realize is that

01:13:17.660 --> 01:13:18.660
the commands may not

01:13:18.660 --> 01:13:19.660
be accurate

01:13:19.660 --> 01:13:20.660
for your devices.

01:13:20.660 --> 01:13:21.660
If you have a CAT 9300,

01:13:21.660 --> 01:13:22.660
these are your commands,

01:13:22.660 --> 01:13:23.660
but if you have

01:13:23.660 --> 01:13:24.660
another type of device

01:13:24.660 --> 01:13:25.660
that supports P2P,

01:13:25.660 --> 01:13:26.660
these more than likely

01:13:26.660 --> 01:13:27.660
would not be

01:13:27.660 --> 01:13:28.660
the commands

01:13:28.660 --> 01:13:29.660
that you need

01:13:29.660 --> 01:13:30.660
for your devices.

01:13:30.660 --> 01:13:31.660
So,

01:13:31.660 --> 01:13:32.660
more than likely

01:13:32.660 --> 01:13:33.660
would not be

01:13:33.660 --> 01:13:34.660
the commands

01:13:34.660 --> 01:13:35.660
that are on them

01:13:35.660 --> 01:13:36.660
because our commands

01:13:36.660 --> 01:13:37.660
are not consistent

01:13:37.660 --> 01:13:38.660
across Cisco products.

01:13:38.660 --> 01:13:39.660
So,

01:13:39.660 --> 01:13:40.660
P2P mode Boundary

01:13:40.660 --> 01:13:41.660
obviously sets it

01:13:41.660 --> 01:13:42.660
to Boundary mode,

01:13:42.660 --> 01:13:43.660
Boundary clock.

01:13:43.660 --> 01:13:44.660
P2P mode

01:13:44.660 --> 01:13:45.660
end-to-end transparent

01:13:45.660 --> 01:13:46.660
obviously sets it

01:13:46.660 --> 01:13:47.660
to end-to-end transparent.

01:13:47.660 --> 01:13:48.660
P2P mode

01:13:48.660 --> 01:13:49.660
P2P transparent

01:13:49.660 --> 01:13:50.660
obviously sets it

01:13:50.660 --> 01:13:51.660
to P2P transparent

01:13:51.660 --> 01:13:52.660
in global configuration mode.

01:13:52.660 --> 01:13:53.660
Right?

01:13:53.660 --> 01:13:54.660
And then some

01:13:54.660 --> 01:13:55.660
interface configurations.

01:13:55.660 --> 01:13:56.660
As soon as you turn

01:13:56.660 --> 01:13:57.660
this on,

01:13:57.660 --> 01:13:58.660
though,

01:13:58.660 --> 01:13:59.660
these features,

01:13:59.660 --> 01:14:00.660
P2P is automatically

01:14:00.660 --> 01:14:01.660
enabled.

01:14:01.660 --> 01:14:02.660
If you have

01:14:02.660 --> 01:14:03.660
P2P,

01:14:03.660 --> 01:14:04.660
then you've got

01:14:04.660 --> 01:14:05.660
to type in

01:14:05.660 --> 01:14:06.660
no P2P enable

01:14:06.660 --> 01:14:07.660
on the interface,

01:14:07.660 --> 01:14:08.660
but it would be

01:14:08.660 --> 01:14:09.660
automatically enabled.

01:14:09.660 --> 01:14:10.660
And if you need

01:14:10.660 --> 01:14:11.660
to do some VLAN

01:14:11.660 --> 01:14:12.660
enablement,

01:14:12.660 --> 01:14:13.660
then it's P2P VLAN

01:14:13.660 --> 01:14:14.660
and specify the

01:14:14.660 --> 01:14:15.660
VLAN ID for that

01:14:15.660 --> 01:14:16.660
or no P2P VLAN

01:14:16.660 --> 01:14:17.660
and the VLAN ID.

01:14:17.660 --> 01:14:18.660
And then for

01:14:18.660 --> 01:14:19.660
SVIs,

01:14:19.660 --> 01:14:20.660
Layer 3 interfaces

01:14:20.660 --> 01:14:21.660
and stuff like that,

01:14:21.660 --> 01:14:22.660
P2P transport,

01:14:22.660 --> 01:14:23.660
IPv4,

01:14:23.660 --> 01:14:24.660
UDP.

01:14:24.660 --> 01:14:25.660
So,

01:14:25.660 --> 01:14:26.660
these are just

01:14:26.660 --> 01:14:27.660
some commands

01:14:27.660 --> 01:14:28.660
to keep in mind.

01:14:28.660 --> 01:14:29.660
Like,

01:14:29.660 --> 01:14:30.660
up here,

01:14:30.660 --> 01:14:31.660
you have the opportunity

01:14:31.660 --> 01:14:32.660
to set it up

01:14:32.660 --> 01:14:33.660
as a whole

01:14:33.660 --> 01:14:34.660
on the actual device

01:14:34.660 --> 01:14:35.660
for the type of mode

01:14:35.660 --> 01:14:36.660
you want it to run in.

01:14:36.660 --> 01:14:37.660
So,

01:14:37.660 --> 01:14:38.660
that's the key here,

01:14:38.660 --> 01:14:39.660
right,

01:14:39.660 --> 01:14:40.660
when it comes to configuration.

01:14:40.660 --> 01:14:41.660
What mode,

01:14:41.660 --> 01:14:42.660
maybe,

01:14:42.660 --> 01:14:43.660
are they asking me

01:14:43.660 --> 01:14:44.660
to figure out?

01:14:44.660 --> 01:14:45.660
Well,

01:14:45.660 --> 01:14:46.660
based on the scenario.

01:14:46.660 --> 01:14:47.660
Do you need to

01:14:47.660 --> 01:14:48.660
support multiple VLANs?

01:14:48.660 --> 01:14:49.660
Then you're picking

01:14:49.660 --> 01:14:50.660
boundary as your answer.

01:14:50.660 --> 01:14:51.660
If you want to make sure

01:14:51.660 --> 01:14:52.660
that you have

01:14:52.660 --> 01:14:53.660
hyper-accurate time

01:14:53.660 --> 01:14:54.660
using transparent,

01:14:54.660 --> 01:14:55.660
then P2P is going to be

01:14:55.660 --> 01:14:56.660
the option that you

01:14:56.660 --> 01:14:57.660
choose in that case.

01:14:57.660 --> 01:14:58.660
So,

01:14:58.660 --> 01:14:59.660
Grand Master Clock,

01:14:59.660 --> 01:15:00.660
the definition of it,

01:15:00.660 --> 01:15:01.660
ordinary clock,

01:15:01.660 --> 01:15:02.660
Grand Master Clock algorithm,

01:15:02.660 --> 01:15:03.660
no transparent

01:15:03.660 --> 01:15:04.660
versus boundary,

01:15:04.660 --> 01:15:05.660
and you'll be set

01:15:05.660 --> 01:15:06.660
for the certification exam.

01:15:06.660 --> 01:15:07.660
All right, folks,

01:15:07.660 --> 01:15:08.660
so that's our coverage

01:15:08.660 --> 01:15:09.660
of PTP.

01:15:09.660 --> 01:15:10.660
That's our coverage

01:15:10.660 --> 01:15:11.660
of NTP.

01:15:11.660 --> 01:15:12.660
You shouldn't receive

01:15:12.660 --> 01:15:13.660
a lot of questions

01:15:13.660 --> 01:15:14.660
on the certification

01:15:14.660 --> 01:15:15.660
exam about these,

01:15:15.660 --> 01:15:16.660
but when you do,

01:15:16.660 --> 01:15:17.660
having the knowledge

01:15:17.660 --> 01:15:18.660
from this discussion

01:15:18.660 --> 01:15:19.660
we have

01:15:19.660 --> 01:15:20.660
is going to help you

01:15:20.660 --> 01:15:21.660
get all of them correct

01:15:21.660 --> 01:15:22.660
on the certification exam.

01:15:22.660 --> 01:15:23.660
Even though there is

01:15:23.660 --> 01:15:24.660
way more

01:15:24.660 --> 01:15:25.660
to both of these,

01:15:25.660 --> 01:15:26.660
for production

01:15:26.660 --> 01:15:27.660
and real-world environments,

01:15:27.660 --> 01:15:28.660
we've covered

01:15:28.660 --> 01:15:29.660
what you need to know

01:15:29.660 --> 01:15:30.660
to get ready for the exam.