All right, folks.
Now we get to jump into our discussion on management protocols and services to get us
ready for the Encore certification exam.
So we're going to focus on topics like NTP, PTP, SPAN, RSPAN, ERSPAN, Flexible NetFlow,
IPSLA, SNMP, Syslog.
We'll even look at debugging pings and traceroutes, well not debugging pings and traceroutes, we'll
look at debugging pings and even we'll look at traceroutes.
So we're not going to be focused on debugging pings and traceroutes, we'll look at ping
and traceroutes though.
And then also quality of service in this particular section.
So a lot of different topics, again, these topics are going to be rather large in the
real world, but our focus is to get you ready for the exam.
So we're going to cover the exam relevant information in regards to all of these.
So let's begin here with network time protocol and precision time protocol with our focus
on NTP first and then PTP second.
So this is all about synchronizing time.
Why is it important for us to synchronize time, right?
Because there is so many services that exist that our users consume every single day that
require time to be accurate.
In addition to that, digital certificates for security are based on time.
We have the need for event correlation and tracking, which is based on time.
We have the need to authenticate and authorize users, which again is going to require a component
of time.
For example, something like Kerberos, if time is not synchronized properly, then authentication
will not happen in that case.
So it's important that we have synchronized time.
So NTP and PTP allow us to synchronize our time.
But before we get to those, let's talk about how we can manually synchronize our time on
all of our Cisco iOS devices.
We can do that by manually setting our clock, and the command we use to do that is the clock
set command.
And then you specify your time, and then you specify your date.
What you need to be aware of here is that this command is looking for UTC time.
Now it doesn't know whether you typed in UTC time or not.
It doesn't know that.
But it is your responsibility to put in UTC time when you're setting your clock.
That's what it is expecting.
That is what it is trusting you to do.
If you don't do that, it doesn't know.
So you would set UTC time.
So you'd have to look it up, do a Google search for UTC time, current UTC time, and you'll
know what time it is, and you can use a clock set command to manually set that.
Notice it's in privileged exact mode.
That is not a typo.
Right now, when you look here, you're going to see that we have our clock time zone command.
So what is the clock time zone command?
The clock time zone command is used to adjust your local clock to your current time zone.
But wait a second.
That's kind of misleading.
I said current time zone.
For those of you who spring forward and fall back, what it's looking for is the winter
time, not the summer time.
So what is it during your darkest hours?
Your time.
So for those of you who spring forward and fall back, this is really looking for what
we call standard time.
That's what it's looking for.
What is your standard time when compared to UTC time?
That's the value you must put in there.
So it's the offset.
So in my case, Atlantic standard time, which is less than Eastern time.
So Eastern time would be minus five compared to UTC time.
Atlantic time is minus four compared to UTC time.
You have central time, which would be minus six compared to UTC time.
So that's what it's looking for.
But it's looking for it in the winter time, not the summer time.
In the winter time.
If you need to adjust your clock based on daylight savings time, you can have your device
do it automatically for you by using the clock summer time command and then specifying what
it is.
So Atlantic daylight time for me or Eastern daylight time, whatever you call it.
This value here is just for your own reference.
The device doesn't know what that means, just like the device doesn't know what that means
right there.
And that's for you as an administrator.
And then recurring the second Sunday of March at 2 a.m. and the first Sunday of November
at 2 a.m. and then it can go ahead and adjust automatically for me.
So I'm going to go ahead and do this on one of our devices here in our live environment.
I'm just going to go to ISP1, I'll type in enable, we're going to type in clock and then
set and then we're going to set the time to UTC time right now.
So I got to look that up.
So I'm just going to type in current UTC time in my browser and the current UTC time is
4.26 p.m. while I'm recording this.
So that would be 16, 16 colon 26, we'll do 27 because by the time I officially enter
this 00 and then what is the date?
The date is going to be October 18th, 2023.
All right, so now if we type in show clock, we have our clock set right now to UTC time
14.27 UTC time on Wednesday, October 18th, 2023.
And that is on our ISP router in this example.
So if we wanted to now have that displayed in our local time, then we could type in clock
time zone.
So if I type in, for example, clock time zone and we said Atlantic Standard Time, we are
minus four.
When compared to UTC time, you're going to see now that when we type in do show clock,
it's now in the adjusted time.
But right now I am in summertime.
So that is not actually the correct time.
It's actually 1.27 here.
So 13.27, not 12.27.
So we need to adjust that for summertime.
So clock, summertime, Atlantic Daylight Time recurring the second Sunday of March, 02 colon
00 on the first Sunday of November, 02 colon 00.
Now that's going to adjust and we should see when we type in do show clock that our time
is now accurate.
It's a lot of hoops to jump through just to manually set our clocks.
But most of us have a tendency to leave our clocks in UTC time and we just have all of
our devices in UTC time.
So that way there, there's a consistency amongst time amongst all of our different devices
just by following UTC time around the world.
But if you need to adjust it at all with summertime or to your time zone, you can go ahead and
use those commands to do that.
All right, so there's an example of those two commands right there.
Now if you're using NTP as an example, these commands still work.
So if your device is getting time and the time it's receiving is UTC time and you want
it displayed instead of in UTC time, then you use these.
So all you're doing with these commands is changing the way it's displayed on your device.
That's essentially what you're doing.
So if you're receiving UTC time from an NTP server, then you could still use these commands
and it would change the clock the way it's displayed on your local device as well.
All right, so now let's talk about NTP, Network Time Protocol.
We want to use something like NTP because our devices don't have the ability to keep
hyper-accurate time all on their own.
So their internal clocks are going to have a significant amount of drift over time.
So for example, today we just set the clock on that device, but in a month from now it
could be off by 15 minutes.
It could be.
I'm not saying it would be, but it could be.
As a result of that, we don't want to rely on our device's local clock to keep hyper-accurate
time.
So using a protocol like NTP, we have the ability to synchronize our device's time with
some authoritative time piece that exists out there.
So our device will always be checking its time and making sure it is accurate in comparison
to this authoritative time piece.
NTP uses UDP port 123.
It is a client-server model based on what we call stratum levels.
So for example, you have a clock, so 1, 2, 3.
This is my authoritative time piece.
My authoritative time piece, that would essentially have a stratum level of zero.
A stratum level of zero.
It is the trusted time piece.
It is the time piece that is providing time.
So for example, a global NTP server, a GPS or atomic clock, some sort of master clock
that is out there that you have that is getting its time.
We have this authoritative time piece.
It is the most trustworthy time piece that exists.
So with that in mind, you're going to need some sort of server.
So I have a server now that is connected up to that authoritative time piece.
So you might have purchased what is called a master clock, and that master clock is connected
to maybe a GPS, maybe an atomic clock, right?
So the GPS, the atomic clock is the actual authoritative time piece in that case, and
then that server, that master clock is getting its time from that.
So now we have what?
We have a stratum level of one in this particular case, a stratum level of one.
Why?
Because we are one time synchronization away from that actual time piece.
That's what stratum levels are all about.
So what does that mean?
It means that, well, let's say this is NIST, National Institute of Standards and Technology,
and we're getting their time from them, and that is something you absolutely can do.
Well, how do you connect up to them typically?
It's going to be over the internet.
So here's, let's say, a router you have, and you are connected to the internet.
The internet's eventually connected to NIST, and you are synchronizing.
You're synchronizing with that server.
Well now you have a stratum level of two.
It doesn't matter how many routers are in between you.
It doesn't matter how many devices are in between you and that server.
It's who you're synchronizing with.
So now we're at a stratum level of two.
So now if we have another router in our environment, and that router's connected up to that router,
and our synchronization is here to here, that's our synchronization.
Now we've got a stratum level of three.
So let's put another router here, another device, doesn't have to be a router.
And let's say we synchronize over to here.
What stratum level is this now?
Well, this is going to be a stratum level of four.
No, no, no.
It's going to be three as well.
Why is it three?
Because we're synchronizing with two.
We're synchronizing with two.
It's who you synchronize with.
It doesn't matter on the physical connectivity you have.
It's based on who you synchronize with.
So does that mean if we had another device here, and we synchronized all the way back
to here, that this would be a stratum level of two?
Yes, that's exactly what I'm saying.
So as you can see, stratum levels are based on the level, the hierarchy of synchronization,
not the physical hierarchy.
16 means unsynchronized, means unreachable, it means too far away.
So if you have 15 stratum levels, if you have a device that is stratum level 15, and you
have another device that synchronizes to it, it won't synchronize because it's too
far away.
15 is the max synchronization number you can have.
16 is unreachable beyond that, not synchronized, and so on and so forth.
But again, remember, it doesn't matter on physicality.
That device could be 100 routers away from the authoritative timepiece, but still be
a stratum level of what?
Seven, eight, nine, ten, right?
The stratum levels are based on who you're synchronizing with, not the physical environment.
So make sure you understand what stratum levels are.
Make sure you know 16 is unreachable.
Make sure you know that the actual clock itself would be zero.
So the first device connected to the clock, so the device that's actually getting its
time from the clock, it's going to be a stratum level of one.
So how do we make this happen with our Cisco devices?
So let's say we have an NTP server here.
How do I make this a client of this server?
It's very easy.
I use the NTP server command on my router, and I put in the IP address of that device.
So the NTP server command is what makes my device a client of the NTP server, right?
The NTP server command makes you a client of that server.
And so how would I make this device now a client and this device a server?
That's very easy.
All I have to do is go to this device, type in NTP server, and put in the IP address of
the device, which would be this dot one.
So NTP server 10.10.127.1, and now this becomes a client of this server.
I'm serious.
You don't even need that NTP master command.
Why does this work?
It works because if this is synchronized using NTP with another server, so if we're synchronized
using NTP, then if somebody wants to synchronize with me, then I can automatically become their
server.
So if I'm a client of another server, then I can become the server of a client behind
me.
But if I am not synchronized with a server, then I can't be a server to somebody else.
So if I'm not a client to a server, then I can't be a server to a client.
That's how it works.
So it's really simple to set up.
You just go to your devices and point them to who you want to point them to, and as everybody
starts synchronizing, synchronizing, synchronizing, then eventually everybody gets synchronized.
So you might be asking now, well, what in the world is the NTP master command for?
So the NTP master command is available on our Cisco devices to make us the authoritative
timepiece, meaning that we trust our own clocks.
Our clock, the internal clock, is the master clock.
It is the authoritative timepiece.
All right.
As is, the way I explained it, that's not a good thing, right?
We don't want our routers or our switches to use their own clocks as the authoritative
clock.
Why?
Because it's not all that accurate.
So because it's not all that accurate, we'd have clock drift over time, and therefore
we don't really know what time it is then.
But if you ever need to have your device be the authoritative timepiece, like maybe
in a lab environment where you don't have an NTP server set up, you can make your router
an NTP server, your Cisco IOS device, an NTP server, an authoritative timepiece.
So if we go to ISPA right now, we're going to do that because I don't have a clock connected
to this lab environment.
But if we type in configure terminal, and we type in NTP master, let's give it a stratum
level of five as an example.
This has just made me the authoritative timepiece, and my clock is the authoritative clock.
So if I type in, for example, show NTP associations, you'll see right now that I am synchronized
with some device called 127.127.1.1.
That is me.
I am synchronized with me.
And my local clock is the time source, the timepiece that we trust.
Five means my stratum level is five, therefore this is a stratum level of four.
So you can set the stratum level you want.
Now production environment, not a great idea, right, because we really want to have some
sort of more accurate timepiece be the authoritative timepiece.
But in a lab environment, not a problem, especially when you're playing around with it.
You may want to do this in the real world, in your production environments, as a fallback
scenario, meaning if all of a sudden your router, your device, stops getting time from
the NTP server, let's say out on the internet.
Why?
Because the internet connection is down.
Well, then the router, if it can't get time from the internet, then it can't give time
to whoever's client's behind it, as an example, because remember, if I am not synchronized,
I cannot give time.
So with that in mind, if I get my time, get my time from that NTP server, and then we
also at the same time configure NTP master, we do both.
So NTP server is someone out on the internet, and then I say NTP master instead of stratum
level, then what's that going to make sure?
It's going to make sure that I synchronize my time, and then I trust my local clock that
has been synchronized.
And then if all of a sudden I lose connectivity to the internet, and I can't synchronize my
time anymore, will I trust my local clock anyways, because my local clock was updated.
So as long as the internet connection comes back up, and I can synchronize within a matter
of what?
Well, before we start getting drift on our local clock, then we're going to be okay.
It's kind of a fallback kind of situation in that particular case.
So let's go ahead and do some demonstrations in this environment right here.
So our NTP server is out there, we just set it up, ISPA as an example, we're pretending
it has an NTP server.
So we're going to set up R2 here to get its time from that server.
So if we go over to R2, let's find out what time it is.
It's too accurate from the last time I did this demonstration.
So let's go ahead and say clock set, and we're going to set it to 00 colon 00 colon 01, January
1, 1999.
All right, so that's what it's set to now.
So what we're going to do now is we are going to show you if we type in clock, or configure
term, I should say, NTP, and then what is the server's IP address?
Server's IP address is 123, 123, 123, 123.
So now if we type in do show NTP associations, you'll see here that it says we are synchronizing
with 123, 123, 123, 123, and 123, 123, 123, 123 gets its time from 127, 127, 11.
And 127, or 123, 123, 123, 123 is a stratum level of five, which means I should be a stratum
level of six.
The tilde, the tilde, that's a tilde if you didn't know that, it means configure.
So that is what we have configured based on this command.
And then the star in front, system peer, means we've actually synchronized with them.
So if we type in show NTP status, you're going to see that I am synchronized, and I am a
stratum level of six, because they're a stratum level of five, and their clock is a stratum
level of four.
And they are 123, 123, 123, 123.
Right?
So my clock is now synchronized.
So do show clock, and there we go.
That's the time we're getting from that ISP device.
Now to show you how the stratum levels work, let's go ahead and do R1 in this case.
So if we go over to R1, and we type in enable, configure terminal, we say NTP server, and
let's put in the IP address of R2, it's 10.40.23.5.
So that's this interface right here.
And we should see here, if we type in do show NTP associations, that we are configured,
we're just not synchronized yet, because the star is not in front of it, and now we're
synchronized.
So do show NTP status, we are synchronized, we're a stratum level of seven.
As we said, the clock is four, the router's five, this one's six, that one's seven.
Notice there's not even a physical connection between them.
So we are synchronizing through the network.
We are sending our UDP message out to that IP address, that device is responding back
to us with time.
So the UDP message gets sent, they process it, they send back the answer with time.
So do show clock, and there we go.
Now, one of the things to keep in mind when you are working with any type of management
protocols and services, and since this is our very first management protocol and service
discussion, I'm going to bring this up now.
You need to consider the fact that it's this device generating the actual message.
So in this case, the NTP message is being generated by this device, and then it has
to send it to this device here.
So the question now is, which interface is it going to be leaving?
It could leave this interface, or it could leave this interface.
Now, don't forget, every single packet we ship out of any single device in the network
needs to have a source and destination IP address.
So what is the source IP going to be in this example?
What is the destination IP going to be in this example?
Well, the destination IP in this example would be anything we set in the NTP server command.
So the NTP server command was what?
10.40.23.5 we set.
And what's the source IP?
The source IP is going to be the IP of exit interface.
And who determines the exit interface?
It's the routing table.
So in this case, R1 would look up, how do I get to 10.40.23.5?
Oh, right now, I can either go this way or this way for load balancing, and in this particular
case, right now, my load balancing algorithm is telling me we're going to go this way.
So that means the source IP in this case is going to be this interface right here.
But next time, it could be this one here.
And the time after, it could be this one here.
And the time after, it could be this one here, and then here, and then here, and then here.
That makes it really, really hard for us to set proper access control measures when it
comes to our management protocols and services.
What we want to have for our management protocols and services is a single IP address for the
entire device.
And how can we accomplish that?
With loopback interfaces and loopback IP address.
So if I create a loopback interface, like let's say loopback 192, and we give it the
IP address of 192.168.255.1.32, and then we do the same thing down here, and we say, hey,
loopback 192, and you are 192.168.255.2.32, and we inject that into OSPF, then these devices
are going to be able to reach each other and talk to each other.
So now the source IP, what I can do is I can set the source IP to this IP address here,
and I can set the destination IP to always be this IP address right here.
I'm just going to make sure that we're always sending those NTP messages from the same source,
always going to the exact same destination.
So let me show you how we can go ahead and do that.
So let's create our loopback interface here.
If you already have a loopback interface, then you can use it.
And let's go to R2 and do the same thing.
So this is a recommended best practice.
It's not mandatory, but it is a recommended best practice.
And then we're going to type in IP OSPF 1, area 0, do ping 192.168.255.1.
Great, I can ping successfully.
So we have connectivity between the two.
Let's go back now to R1 instead and do show run pipe to section NTP.
Let's go ahead and say no, NTP server, yada, yada, yada, yada.
And now let's go ahead and type in NTP server 192.168.255.2.
So reference that IP address instead.
Also, NTP server, no, NTP source interface, no, NTP source.
It will just be loopback 192.
There you go.
So in this case, this command sets the destination IP address.
This command sets what?
The source IP address of the packets.
And so they're always going to be those same IPs.
The destination is always going to be the same IP, whatever you specify there.
But now it doesn't matter which way it goes.
The packet could come this way.
The packet could go this way.
It doesn't matter which interface it comes in.
Jeez, it could go all the way out here, spend some time out here, have a party, come in this way.
And it would still get to 192.168.255.2 as an example.
That's a little extreme, but I'm trying to tell you that we're always referencing that same IP address,
no matter whether physical interfaces are up, down.
It doesn't matter.
As long as there's one physical interface up on that device, we can get to that loopback address.
Likewise, this way.
It doesn't matter whether I go this way or this way.
It doesn't matter.
The source IP is always going to be 192.168.255.1 based on that command.
So now let's type in do show NTP status, make sure we're synchronized.
And we are with 192.168.255.2.
So now that we've done this, let's talk a little bit about security in this case.
So when we talk about security, now that we are controlling the source and destination IP addresses,
on R2 as an example, we can set up an ACL.
And we can apply that ACL to NTP.
And what we can do is we can say, hey, only hand out time to the following devices.
Only hand out time to the following devices.
So if we are controlling the source IP, then it's really easy for us now to control who we hand out time to.
So this is a way to make sure that our device is not handing out time to rogue NTP requests.
We're only allowing it to hand out time to legitimate NTP requests.
That's the point here.
So if we go over to R2 as an example, and we type in access list, and we'll just go access list 5.
We're going to say permit 192.168.255.1, 0.0.0.0.
And let's say we had all of our management IP addresses were actually .2 and then .3, .4, .5.
Let's say that entire range.
So actually, we could do maybe something like this instead.
192.168.255.0, 0.0.0.25.
Now, any IP address in that management IP addressing space.
And so now we're going to make sure that we only hand out time to devices that have an IP address as such.
And how do we do that?
You type in NTP access group serve only those listed in access control list number 5.
So only hand out time to those devices with a source IP address in that range.
So this is one way that we can provide security when it comes to NTP, controlling who we hand out time to.
Now, we also have the ability to do authentication.
Now, authentication is about protecting the client, not the server, the client.
So what does that mean?
We are going to, for example, set up authentication between R1 and R2.
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.
So it's not the server authenticating the client, it's the client who's authenticating the server in this particular case.
So what we're going to do is we're going to set up.
We're going to go ahead and set up here on R2 or R1 first.
I'm going to do R2 first.
I'm going to say NTP trusted key.
So what we need is we need a key that can be used.
In order to do the authentication.
So I'm going to create a key and you'll see where this key comes into play here shortly.
I'm going to call it key seven.
Now what I'm going to do is I am going to.
Type in NTP authentication key.
And I'm going to say we're going to use that trusted key of seven.
So we built the trusted key of seven with this command and now we're using it down here.
And we only have the ability to use the MD5 hashing algorithm.
So authentication is using a hashing algorithm with NTP and the hashing algorithm is MD5.
And then I also need a passphrase to go along with this.
So I'm just going to create one.
Give me time is my passphrase.
So now what's going to happen here is for every single NTP message.
We have to use the key of seven.
The passphrase of give me time and the MD5 hashing algorithm to create a hash.
We then take that hash and we attach it to the plain text UDP message and we send it on the network.
So there's no encryption here, right?
It's not encryption.
It's authentication with a hashing algorithm.
So it's still in plain text.
But the idea here is now when R1 receives the message, it can take the key of seven MD5.
Give me time.
Create the hash and double check.
Is this message from somebody that I can authenticate?
If so, then I'm going to accept the message.
If not, then I'm going to discard the message.
And so now I'm going to turn it on NTP authenticate.
So if I type in do show run pipe to section NTP now, I'm going to copy and paste.
Those pieces of information over to R1.
Why?
Because R1 needs that exact same information.
So we'll paste it in.
And so now all I have to do is reconfigure.
This parameter right here.
So I'm going to type in no.
And to be server and now we're going to type in NTP server and then we'll type in key of seven.
So this is what now triggers it.
So now any time we are receiving NTP messages from that NTP server.
Then we have to use the key of seven.
The key of seven says what?
The key of seven says we're using seven with MD5 with our hash.
You take all of that or that passphrase, I should say, which is our hash in the end.
So the key plus the hashing algorithm plus the passphrase combined together to generate our hash.
So now I can generate my hash and compare it to the hash that has arrived.
So I'm going to type in key of seven.
So now I can generate my hash and compare it to the hash that has arrived.
If they're the same, then I process the NTP message.
If they're not the same, I discard the NTP message.
That's how we authenticate.
So now if I type in do show NTP associations, you'll see right now I'm configured.
But I'm not synchronized because there's no star in front of it.
But if I type in show NTP status, what does it say?
It says I'm currently on synchronized stratum level of 16.
But let's take a look at associations detail right now.
And associations detail says that I'm actually authenticated right now.
So I'm configured to peer with them and we've authenticated, but I still haven't synchronized my time.
And that's okay.
This could take a little bit of time.
But then once that little bit of time passes, then we'll see that we're sane, we're valid,
we're synchronized with our certain stratum level.
And I've seen this take anywhere from 30 seconds during demonstrations
all the way up to my worst case scenario was 45 minutes, if I recall correctly, doing a demonstration.
So we'll just let that cook for a bit.
But I don't want to waste too much of your time as we sit here, wait, wait, wait, wait, wait.
So what are some of the key takeaways from this particular discussion you're preparing for the exam?
So number one is know why we use NTP, which we've covered.
Make sure you understand stratum levels and the purpose of stratum levels.
Also recognize how to or read an NTP configuration.
So why do we need NTP master versus NTP server?
The last thing you want to do is use NTP master when all you have to do is use NTP server
because they result in two different things.
So pay attention to what's going on.
So in our particular case, you know, NTP server on the devices,
we want to synchronize with some other device because NTP server points to the server's IP address.
That's what the command does.
Now, if you're synchronizing, when there's multiple paths available,
it's better to use a loopback interface as the source.
And as we saw here, a loopback interface is the destination because then it doesn't matter
what the physical interfaces are that are being utilized to forward the packets.
The source IP is always going to be the same.
The destination IP is always going to be the same.
And there's two different ways that we can perform security with NTP that we need to know for the exam.
One is the ACLs that are going to allow us to convey those access groups,
control which servers we can give time to or what devices we can give time to,
and an authentication to authenticate the client for the server.
So to make sure, pardon me, to authenticate the server for the client,
to make sure the client authenticates the server before it actually processes the messages
that it's receiving from that particular server.
All right.
So it's still not synchronized at this particular point in time.
I was hoping that little moment we had together would have given us the opportunity to synchronize,
but it hasn't, and that's okay.
All right.
Real world, folks, typically what's going to happen,
you're probably going to have a server in your environment that is going to be getting its time
from a trusted time source externally,
and then you're going to point all of your devices to that trusted time piece,
and you're probably going to have two time sources in your environment for redundancy sakes,
and they're getting their time from external.
So then all the other devices you have point to those two devices to get their time.
So you're not going to typically be configuring your routers and your switches to get their time externally,
because that opens up a vulnerability, right, a vulnerability that could be exploited.
That is, they are now getting out on the Internet,
and maybe you don't want your devices to be getting out on the Internet for any purpose.
I wouldn't.
I never get equipment.
So in that case, having some sort of trusted time piece inside the environment
or something that gets its time from a trusted time piece is what we would want to do.
So NTP currently, what we're running on Cisco devices is version 4, just to let you know.
So NTP version 4 supports both IPv4 and IPv6.
NTP version 3, 2, and 1 does not support IPv6.
So NTP 4 supports IPv4 and IPv6.
Still not synchronized.
All right.
I'll leave that alone.
So let's now have a discussion on PTP, Precision Time Protocol,
which is a new addition to this particular exam.
It wasn't covered in the old version of the exam,
but it has been added to the new version of the exam.
So PTP, Precision Time Protocol, is an IEEE standard 1588.
So if you see 1588 on the exam or IEEE 1588, they're talking about Precision Time Protocol.
Why would Cisco do that?
I don't know, but sometimes they do crazy things like that.
Instead of just typing in Precision Time Protocol, they type in, oh, IEEE 1588.
So know that that is Precision Time Protocol.
It's about precise clock synchronization.
You might be saying, wait, wait, wait, wait.
Isn't NTP precise clock synchronization?
Yes, but not as precise as PTP, Precision Time Protocol.
It's even more precise.
You see, PTP has been designed specifically for those environments that need super,
hyper-accurate time with no more than nanosecond differences in devices' time.
Whereas NTP is more like millisecond.
PTP is like nanosecond.
So we're dealing with industrial environments.
We are dealing with network measurement and control systems.
It is designed specifically to use minimal bandwidth and have very low processing overhead.
So when you need super, hyper-accurate time, any scenario that's talking about super, hyper-accurate time,
I would go with Precision Time Protocol because it is more precise than NTP.
And how is this going to happen?
Because with Precision Time Protocol, we can keep track of the delay.
Where?
The delay from the device providing time and the device getting time.
So when you think about your server providing time, so there's my time.
That's my time source.
And some device over here that's getting time.
Think about everything that's happening in between.
There's a ton of networking equipment in between those devices.
Some Layer 1 devices, some Layer 2 devices, some Layer 3 devices, whatever it happens to be, right?
There is delay there.
And that delay is going to be variable.
So how do we get our time more accurate?
More accurate than NTP can do?
That is where Precision Time Protocol excels
because we can keep track of that delay between the time providing or the device providing time and the device getting time.
And then adjustments can be made using that delay information.
So PTP, a network, can compensate for latency and delay problems by correctly adjusting the device's clocks
so that they stay synchronized with one another to a nanosecond.
Let me walk you through an example here using seconds, okay?
Seconds instead of microseconds or nanoseconds.
So that way our brains don't melt.
We're going to focus on synchronizing time from our master clock over here to our PC right there.
So let's say our time source has a current time of 1,000,000 as we see here.
That's the current time.
And for simplicity's sake, let's say our master clock, which is this device right here, the master clock,
has that time of 1,000,000.
Now, in reality, there would be like nanosecond difference between the two
because of the delay of the cable between the actual time piece and the master clock, right?
But let's just keep it equal here so that way, again, our brains don't melt.
So now what's going to happen with NTP?
With NTP, our packet is going to be sent.
And what is the time going to be listed in that particular packet?
It's going to be this time right here.
So let's say it takes one second.
Again, for simplicity's sake, we're using seconds.
Let's say it takes one second to go from here, the message, to here.
What time is it on this device?
On this device, well, it sees that it's this time right here.
It's what it sees because that's what the message says.
But what time is it really now if it took a second to get there?
The real time is now this, right?
This is real time.
So we have a one second, a one second difference, don't we?
We're one second off.
So let's now say that we go, it takes a second to go from here to here,
another second to go from here to here, another second to go from here to here.
So what time is it over here?
It's 1,00,00.
But over here, what would it be?
Three seconds off.
Three total seconds.
Now we're three seconds off.
So one second off, two seconds off, three seconds off.
Now, again, this is for simplicity's sake so you realize what's happening here.
So if we take this further, there's another second, there's another second.
Let's say there's another second.
So what time is it here?
This is the time because that's what the message says.
But in reality, this is the time.
We're six seconds off now.
Six total seconds off.
Now remember, in reality, this would be microseconds with NTP.
And many of you are thinking, okay, whoop-de-doo, big deal, don't care.
All right, well, here's the thing.
Most of us will be fine in our production environments like this.
But there are environments where you may be in in the future or you are in now
where hyper-accurate time down to nanosecond is really, really, really, really, really important.
And so where might that be?
Industrial control systems, financial scenarios, smart grid power automation applications,
power generators, outage monitoring and management.
We need precise time accuracy.
We need stability in our time.
We need to account for delay in those scenarios of the networking devices that are in between.
And so that's where PTP comes into play.
It improves our accuracy.
And therefore, all those other systems that rely on our devices being within our control system
within a nanosecond of each other, we can get that.
So PTP exists.
We get that hyper-accurate time.
So here's a table I put together.
I don't need you to memorize this for the certification exam,
but you'll see accuracy for PTP is submicrosecond.
It's nanosecond, whereas NTP is millisecond and submillisecond.
Highly precise synchronization under clock synchronization and moderate to good synchronization for NTP.
IEEE 1588 versus NTP4, which is an IETF standard.
So you don't have to know what you see here, but reading through it once might be a good idea.
But you're not going to have to memorize that for the certification exam.
So let's now talk about PTP devices.
Because there's some specific terminology you're going to have to know for the certification exam.
So first of all, we have the Grandmaster Clock, the GMC.
So the Grandmaster Clock is a highly accurate and stable time source.
So it is typically equipped with precise hardware, precision hardware,
and is considered the primary reference for time within your PTP network.
So you're going to have a Grandmaster Clock set up in your network.
And then a Grandmaster Clock is going to be synchronized to some very precise clock.
Some very precise time standard.
Some sort of authoritative time piece, GPS, atomic clock.
However, if you can't connect them to a GPS or atomic clock,
they do have the ability to keep relatively highly accurate time themselves.
And when you are relying on them to be the clock,
and not rely on the GPS or atomic clock that's out there,
we call that free-running them.
They are considered to free-run,
which means they are using their own internal clocking components for time.
So this is something you would have to purchase, something you would have to get.
I'm going to go to Google right now,
and I'm just going to type in Grandmaster Clock as an example.
Ooh, beautiful. All right, so we're going to go to this company here.
I'm not promoting any company at all,
but here's an example of a Grandmaster Clock going to their website.
See our network's heartbeat, as they say.
There you go.
A device that is designed for what?
Hyper-accurate time.
That's what it's designed for.
So you'd set this up, you'd put it in your environment,
and it has the ability to keep hyper-accurate time,
but you can also connect it to an external time piece as well, if you had to.
Like the GPS or atomic clock to get even better time when it's all said and done.
So you know that it's synchronizing to world time as opposed to just itself.
You can only have one per PTP domain.
So what is a precision time protocol domain?
A PTP domain is the grouping of devices that are synchronizing their time altogether.
And so you can only have one Grandmaster Clock per PTP domain,
but backups are recommended.
So when you have backups, that means you're going to have multiple devices
that could become your Grandmaster Clock.
For example, there's my Grandmaster Clock,
there's a backup Grandmaster Clock.
So we need an algorithm that's going to have the ability to ultimately determine
who is going to be the best time piece at that moment in time.
And that's where the Best Master Clock algorithm comes into play.
This Best Master Clock algorithm specifies how each clock on the network
determines the Best Master Clock in its domain of all the clocks it can see.
So all the clocks that can see each other,
all the devices that can see each other are part of the Best Master Clock.
They're part of that same PTP domain that you've set up using PTP.
And as a result of that, between them all,
even your switches, even your routers, if they're participating in PTP,
they have the opportunity to become a Grandmaster Clock.
Obviously, you don't want them to be, but they could.
So the Grandmaster Clock is going to be,
or all the devices are going to be running the Best Master Clock algorithm
on all their different ports participating in PTP
in order to figure out who in the world is going to be that Grandmaster Clock.
And so you can see here that we have our decision order,
a Priority 1, Class, Accuracy, Variance, Priority 2, as well as Identity.
Based on my experience, you don't really have to know these specifically,
but you never know, right?
You never know if all of a sudden you get a question on PTP on the exam,
you're like, oh, I wish I would have known this.
So I've included it here in case it comes up.
But when you're looking at the Best Master Clock algorithm
and you're looking at the output, for example, of Show PTP Clock,
you'll see Priority 1 is right there.
So Priority 1, what is that?
It's just a user-assigned priority.
And every single device defaults to a value of 128 for Priority 1.
It's a range from 0 to 255.
And lower is better.
So the lower Priority 1, the better.
And since they're all 128 by default, then we move on to Class.
So what is Class?
Class is about what the clock class is that the clock belongs to.
So depending on the type of clock you have,
the class is going to be different.
So for example, Class of 6, for example,
means that the primary reference clock is a GPS.
So if you saw 6 here, Class 6, we're dealing with GPS.
So if this GMC, Grandmaster Clock, was connected to GPS,
it would have a Class of 6.
Whereas if this one was not connected to a GPS,
then it would have something like 248,
which is a default value, meaning nothing else applies.
So there are different class categories for different clocks.
And I didn't provide all the different ones here to you
because it doesn't matter, right?
If it does in the future, then I'll add it.
But if you want to look it up, what are the PTP clock
or what are the PTP clock class categories?
And you can find a list out there.
And the list is not all that intuitive.
They'd have numbers of 6 and 7 and 13 and 14 and 52 and 248 and 255.
255 means never become the Master Clock.
That's what 255 would mean.
Never become the Master Clock.
But then there's other values underneath that.
Accuracy is next.
So the precision between the clock and UTC time in nanoseconds.
So if the priority is tied amongst two and then the class is tied,
the question now is, who is more accurate between the two?
So right now, accuracy is unknown in this particular example.
But if accuracy was known, it would be listed in nanoseconds.
For example, you might see something where one says it's 250 nanoseconds
and another one that maybe says 260 nanoseconds.
So the lower the nanoseconds, the better
because that means you are more accurate.
Because your accuracy is the variation with the UTC clock.
And then you've got variance, which is the variability of the clock,
which is basically the stability of the clock.
So how stable is it?
And then you've got priority 2, which is another user-assigned priority.
So it's just tied, tied, tied, tied.
You still have the ability to have another priority if you want to.
And you can see the priority 2 right there.
But again, default is 128.
Lower is better with a value from 0 to 255.
So if all of those other things are the same
and you want to leave them that way,
you can use priority 2 to break your tie in that case.
And then lastly, there's an identity for all of it.
And there's the identity right there.
What it is, it takes the base Ethernet MAC address of the device,
and it uses EUI-64 to come up with a 64-bit identifier.
And you can always identify anything that's EUI-64
by looking at the middle of it and seeing FFFE.
All right.
So let's say in this particular case,
this is going to be our Grand Master Clock, our GMC.
And this is going to be our backup Grand Master Clock
based on the Best Master Clock algorithm.
So what is next?
Well, let's talk about Ordinary Clock.
So what is an Ordinary Clock?
Well, Ordinary Clock, let's say,
Ordinary Clock right here, so this device.
An Ordinary Clock refers to any device
within that PTP network, within that PTP domain
that's going to be synchronizing its time
with the Grand Master Clock.
So in this case, I'm synchronizing with the Grand Master Clock.
That makes me an Ordinary Clock.
I am synchronizing with the Grand Master Clock.
That makes me an Ordinary Clock.
That's all that means.
So computers and servers, routers, switches, printers,
IP phones, industrial control systems,
test and measurement equipment like, what,
oscilloscopes, signal generators, spectrum analyzers,
IP-based surveillance cameras, network-attached storage devices,
Internet of Things devices, and the list goes on and on and on
and can be Ordinary Clocks.
So how does synchronization actually happen?
Well, this is our process we follow here for synchronization
between the Grand Master Clock and our Ordinary Clock.
So it doesn't matter where the Ordinary Clock is.
It doesn't matter where the Ordinary Clock is,
any one of those devices we just talked about.
This is what's happening.
So we have these messages.
Our first one here is that our Grand Master Clock
sends out what is called a sync message
to the Ordinary Clocks
and notes the time of T1 at which it was sent.
And then the Ordinary Clock receives that sync message
and notes the time of reception, T2.
The Master conveys to the Ordinary Clock the timestamp T1
by embedding that timestamp T1 in a follow-up message.
So the follow-up message is the GMC telling the Ordinary Clock,
hey, T1 was this, by the way.
So now what does that mean?
It means the Ordinary Clock has T1 and T2.
And also the Ordinary Clock can now send a delay request,
it's called, message to the Master
and note the time of T3 at which it was sent.
And then the Master receives the delay request message
and notes the reception timestamp of T4.
And then the Master conveys to the Ordinary Clock
the timestamp of T4 in that delay response message.
So now the Ordinary Clock has T1, T2, T3, T4.
It has those four pieces of information
that are necessary to actually do the calculation
that it needs to do.
So the Ordinary Clock processes all four timestamps.
And so now it can calculate the offset of the Ordinary Clock
relative to the Master
and then figure out what time it actually is.
However, that's not it.
There's more to it.
Because remember that PTP provides more accurate time
versus NTP.
How?
We said by keeping track of what?
Delay from the device providing time
and the device getting time.
We need the device that's getting time
to be able to use that delay
in order to modify its time
to get more accurate time.
See all these devices in between?
This is what we talked about.
The time it takes to go from here to here
to here to here to here to here to here to here.
Right?
Or the time it takes to go from here to here
to here to here to here to here to here to here to here.
That is what we're talking about.
That delay.
The time it takes to go there.
How does this get taken care of?
Well, what we need is we need devices
that understand IEEE 1588.
They have to be IEEE 1588 enabled devices.
And what does IEEE 1588 mean?
It means PTP, right?
That's what it means.
So we need PTP enabled devices.
That's what we need.
So the PTP enabled device
has the ability to
inform the ordinary clock
about that delay.
And we have two different types
of IEEE 1588
devices we can set up.
We can set up a transparent device
or we can set up a boundary device.
So let's talk about transparent.
So in this case here,
let's just take a peek at the transparence.
So I have a transparent here.
I have a transparent here.
We'd also want a transparent here.
Right? And transparent.
So essentially, we'd want all of our devices
to be transparent.
So the transparent device, that is our what?
That is our network device.
So the transparent clock
is our device
that handles PTP packets,
IEEE 1588 packets,
differently than a non-PTP device,
a non-IEEE 1588 device.
So when we set up this transparent clock feature,
the transparent clock can actually measure
the time that the packet is stored in the switch.
I'll repeat that.
It can measure the time the packet is stored
in the actual networking device.
And then,
that information can be added
to the PTP message
that is being forwarded on.
And therefore,
that information that's been added
can help the ordinary clock
account for the packet delay,
therefore getting more hyper-accurate time.
So when it comes to transparent clocks,
we've got two different modes.
We've got end-to-end transparent clocks,
and we've got PTP transparent clocks.
All right, so let's make these a little darker
so we can see them.
All right, so there we go.
So here's an example.
There we've got our transparent clock set up.
So what would be happening now
as we go from here to here to here
to here to here,
and so on and so forth?
What is happening?
Let's zoom into that right now.
So essentially,
what would be happening here
is that the Grandmaster clock,
when it's sending out that sync,
you see how the sync
is going to be going from end-to-end.
That's why it's called end-to-end.
That sync message is going from end-to-end.
But what you need to recognize here
is that along the way,
our network devices
are calculating the time it takes
to do things like processing.
And it creates a value called residency time.
And it adds the residency time
to that sync message.
So now when the sync message goes,
there's the residency time included with it.
And then this device calculates
its residency time, adds to it.
So now we've got the residency time
added to that as well,
and so on and so forth.
So along the way,
we've got residency time,
residency time, residency time.
And then eventually the ordinary clock gets it,
and what does it have?
It has the original time
provided by the Grandmaster clock
along with what?
Along with
all of the residency times,
how long that particular sync message
hung out on that device
while it was doing other things,
like processing other packets.
So we've got the device for,
well, if we go with seconds,
one second,
well, at least the residency time
would say one second.
Simplification,
we're talking microseconds here
as packets flow through our network,
but so our brains don't explode,
we're going to stick with seconds
as our discussion unfolds.
And then don't forget,
we also have that secondary forward message
that comes up to follow up, I should say.
So that follow up again
is the time and so on and so forth
that gets sent down the line.
So in the end,
the ordinary clock is still getting T1,
T2, T3, T4,
but it's also getting all the residency times as well.
And so then by taking
all those times
and then factoring in
the residency times,
it has the ability to figure out
what time it actually is
on that Grandmaster clock.
More hyper-accurate time.
So we've taken into account what?
The latency
of that device,
the delay that the device is causing.
But the problem with
end-to-end transparent, folks,
is that it doesn't take into consideration
link delay.
That's right.
It's only taking into consideration what?
The time it takes
for the device to do its processing.
We're still missing
another valuable part.
And that is the link delay
between the peers.
How long it takes the peers
to actually talk to each other.
So we could be even more hyper-accurate.
And how do we do that?
We've got to do what is called
P2P transparent.
So P2P transparent instead,
this is how the conversation would happen.
Notice how each
of the devices
are essentially
exchanging messages with each other.
And then exchanging messages
with each other.
And then exchanging messages
with each other.
Whereas before,
it was what?
End-to-end.
Message, message, message.
You see that?
Whereas with P2P,
every step along the way
is an exchange.
So,
exchange,
exchange.
That's P2P.
So now with P2P,
we can also calculate
not only the residency time,
but also the time it took
to talk to each other.
The time it took to communicate.
So now you're getting
everything
as part of this particular calculation.
So we have the thing called
the correction field.
The correction field
is going to be taken into consideration.
The time it took to talk
plus the residency time.
The time it took to talk
plus the residency.
And then in the end,
the full calculation can be done
by the ordinary clock.
You're not going to have to do
calculations on the exam, folks.
So don't worry about it.
But I'm just trying to show you here
how we get that
more hyper-accurate time now.
So,
on an exam,
if they're asking you to choose
which is more accurate,
peer-to-peer would be more accurate
than end-to-end.
But we still have a few issues here.
Regardless of whether you're using
end-to-end or peer-to-peer.
And that is what?
Well,
let's think about what's happening here.
With transparent mode,
transparent clocks,
we are really just dealing with
forwarding devices.
They don't generate any
P2P messages themselves, right?
What do they do?
They take the original P2P message
from the Grandmaster clock.
They add whatever information
is necessary for delay,
for processing,
things like that.
By adding the PD field,
the RT fields,
different things like that,
and they pass it on.
And that
can
become extremely overwhelming
for the network
and the Grandmaster clock
when it's all said and done.
We're going to get to that
here momentarily.
Another thing, too,
is that transparent clocks
can only basically work
when the clock is set.
Transparent clocks
can only basically work
in a single VLAN.
That's right.
So if you have, for example,
like a multilayer switch
servicing multiple VLANs,
only the native VLAN
would receive the P2P messages.
So any other device
in any other VLAN
would not get those messages.
So what we need
is another mode,
and that other mode
is called boundary mode.
So with boundary mode,
what do we get?
Well, a boundary mode
or boundary clock
is a device
that can handle P2P packets
differently
than those transparent switches.
Remember, a transparent switch
only modifies the P2P packet.
But see, a boundary clock,
what it does
is it gobbles up
and actually processes
that P2P packet.
Therefore, the boundary clock
is synchronizing
with the Grandmaster clock.
You see, the transparent clocks
don't synchronize
with the Grandmaster clock.
It's not part of the standard.
However,
your Cisco devices
might, even though they're
in transparent mode,
be synchronizing with
the Grandmaster clock
because that is what
Cisco chose to do.
But based on the IEEE standard,
they shouldn't be.
But if Cisco is doing it,
then fine.
So if all of a sudden
you have transparent clocks,
you're like,
well, it is synchronizing.
Yeah, because Cisco
made some modifications
to how they deploy
transparent clocks.
But based on the standard,
a boundary clock
will 100%
synchronize with
the Grandmaster clock
and gobble up
the PTP messages.
And then the boundary clock
becomes
the master
PTP clock
for anybody
after it,
for all downstream devices.
So it's going to generate
new PTP messages
and send them on.
Why?
Okay, well, consider this.
Let's say you have
10,000 ordinary clocks.
10,000 ordinary clocks
between
all the different
systems you have
that need hyper-accurate time.
You've got like 10,000.
They are all
ordinary clocks.
They need to synchronize
their time.
Well, if you have
10,000 devices
synchronizing all with
the Grandmaster clock,
that can be overwhelming
for the Grandmaster clock,
right?
Absolutely.
And in all those
transparent clocks
in between,
in end-to-end
transparent mode
are going to be
very, very, very,
very busy, aren't they?
Yes, they will be.
Why?
Because what are they doing?
They are synchronizing
every single PTP message.
So, let's break up
the environment
into multiple
PTP domains.
Let's have a PTP domain
between the Grandmaster clock
and a Boundary clock
and another PTP domain
between Boundary clocks
and the Ordinary clocks
in different VLANs.
Yes.
So, our Boundary clock
is synchronizing
with the Grandmaster clock
and the other
Ordinary clocks
can synchronize
with the Boundary clock,
getting multiple
PTP domains.
And then,
unlike transparent clocks
that do not work
when you have multiple
VLANs on a device,
only the native VLAN
would get time,
with Boundary clocks
you can have
time delivered
to all the different
VLANs.
So, essentially,
those distribution layer
switches you have
that have all those
different SVIs on them,
those multilayer switches
with a multitude
of VLANs,
you make those
Boundary clocks.
Like I've done here.
And so, now, in the end,
Grandmaster clock,
you get your transparency
in between,
going to the Boundary clocks,
and now the Boundary clock
can have hyper-accurate
synchronization
with the Grandmaster clock
because it can do
all the calculations.
Boom.
Hyper-accurate time.
So, now the time here
should be the exact
time over here.
Exact.
And then, now,
everybody down here
will have the ability
to synchronize
to the Boundary clocks.
Breaking up.
Making it more efficient.
Making it more effective.
And, if for some reason,
the Grandmaster clock
goes down,
or there's a disruption
in communication here,
that's fine
because the Boundary clocks
can still
make themselves
a Grandmaster clock
at that moment in time.
So, they can make themselves
a Grandmaster clock,
so now they are
the trusted time source
at that moment in time.
And then,
when the Grandmaster clock
comes back on,
it's going to have
the higher priority
and the more preferred,
I should say,
the more preferred
Grandmaster clock
algorithm information,
which, in the end,
means that the Grandmaster clock,
this device,
will go back to being
the Grandmaster clock
and our Boundary clocks
will just end up what?
Right?
Going back to
synchronizing with it.
So, it's good in that case
for us.
So, in this case here,
you can see
that what we've done
is there's that Boundary clock
in the middle
and that Boundary clock
is in the middle,
so the Grandmaster clock
is in the middle
and that Boundary clock
is in the middle,
so the Grandmaster clock
is synchronizing
with the Boundary clock.
End-to-end type
of synchronization
through those
transparent clocks.
Now,
if you want to get
even more hyper-accurate,
like we said,
so these are transparent,
transparent, transparent,
transparent as an example.
If you want to get
more hyper-accurate,
then you do transparent P2P
and then you're like
boom, boom, boom,
boom, boom, boom.
Right?
You could do that as well.
It's up to you
how accurate
the time you need,
but you have all
the options.
But the Boundary clock here,
we are synchronizing,
as you can see,
with the Grandmaster clock
and the ordinary clocks
with the Boundary clocks.
All right,
so here are some
configuration commands
that may or may not
show up on the
certification exam,
but what I want you
to realize is that
the commands may not
be accurate
for your devices.
If you have a CAT 9300,
these are your commands,
but if you have
another type of device
that supports P2P,
these more than likely
would not be
the commands
that you need
for your devices.
So,
more than likely
would not be
the commands
that are on them
because our commands
are not consistent
across Cisco products.
So,
P2P mode Boundary
obviously sets it
to Boundary mode,
Boundary clock.
P2P mode
end-to-end transparent
obviously sets it
to end-to-end transparent.
P2P mode
P2P transparent
obviously sets it
to P2P transparent
in global configuration mode.
Right?
And then some
interface configurations.
As soon as you turn
this on,
though,
these features,
P2P is automatically
enabled.
If you have
P2P,
then you've got
to type in
no P2P enable
on the interface,
but it would be
automatically enabled.
And if you need
to do some VLAN
enablement,
then it's P2P VLAN
and specify the
VLAN ID for that
or no P2P VLAN
and the VLAN ID.
And then for
SVIs,
Layer 3 interfaces
and stuff like that,
P2P transport,
IPv4,
UDP.
So,
these are just
some commands
to keep in mind.
Like,
up here,
you have the opportunity
to set it up
as a whole
on the actual device
for the type of mode
you want it to run in.
So,
that's the key here,
right,
when it comes to configuration.
What mode,
maybe,
are they asking me
to figure out?
Well,
based on the scenario.
Do you need to
support multiple VLANs?
Then you're picking
boundary as your answer.
If you want to make sure
that you have
hyper-accurate time
using transparent,
then P2P is going to be
the option that you
choose in that case.
So,
Grand Master Clock,
the definition of it,
ordinary clock,
Grand Master Clock algorithm,
no transparent
versus boundary,
and you'll be set
for the certification exam.
All right, folks,
so that's our coverage
of PTP.
That's our coverage
of NTP.
You shouldn't receive
a lot of questions
on the certification
exam about these,
but when you do,
having the knowledge
from this discussion
we have
is going to help you
get all of them correct
on the certification exam.
Even though there is
way more
to both of these,
for production
and real-world environments,
we've covered
what you need to know
to get ready for the exam.