|
0:00:13
|
So next, let's look at the
|
|
0:00:18
|
Again, the mian point of this...
|
|
0:00:21
|
is that we need to make sure that the routers
|
|
0:00:26
|
Otherwise, the key numbers will become
|
|
0:00:31
|
and then, the devices will not
|
|
0:00:34
|
So really, the first step before
|
|
0:00:38
|
would be to make sure that all of the
|
|
0:00:44
|
Now, there's two things that I
|
|
0:00:47
|
First, I'm going to define
|
|
0:00:51
|
So, everyone's clock is fairly
|
|
0:00:55
|
Then, I'm gonna configure NTP to make sure
|
|
0:01:01
|
The reason that I'm going to
|
|
0:01:05
|
is that if any of the two
|
|
0:01:09
|
have clock values that are too far apart,
|
|
0:01:13
|
so if we were to look at let's say...
|
|
0:01:17
|
router 1,
|
|
0:01:19
|
and we'll look at the Show Clock.
|
|
0:01:23
|
Router 1 says that the time is...
|
|
0:01:27
|
on Friday, March 1, 2002.
|
|
0:01:31
|
Where if we look on
|
|
0:01:35
|
Router 4 says that it's March 5th 2000.
|
|
0:01:40
|
So, depending on whether the devices
|
|
0:01:44
|
Okay, on switch 1, it says 1993.
|
|
0:01:47
|
So, they're kind of all over the
|
|
0:01:51
|
But the problem is now that if switch 1
|
|
0:01:53
|
tries to become an NTP client of
|
|
0:01:59
|
and says that it's April in 2011,
|
|
0:02:02
|
then, either they will no
|
|
0:02:07
|
or it's gonna take a very, very
|
|
0:02:11
|
Because when you look at the
|
|
0:02:15
|
it basically says you have two options.
|
|
0:02:17
|
Either your clock is within a
|
|
0:02:23
|
in which case, we can do
|
|
0:02:26
|
But if your clock is way far
|
|
0:02:29
|
then, we have to do a
|
|
0:02:33
|
So, typically, you'll see that the clock will adjust itself
|
|
0:02:39
|
but if I'm 10 years off, it may
|
|
0:02:44
|
So, what we can do instead is just make sure
|
|
0:02:49
|
then, configure NTP,
|
|
0:02:51
|
and we should see that everyone is
|
|
0:02:58
|
So then, first, let's set
|
|
0:03:01
|
Clock Set.
|
|
0:03:04
|
And we'll say just any
|
|
0:03:07
|
"Midnight on January 1st 2000".
|
|
0:03:16
|
So, I'm gonna take this value
|
|
0:03:20
|
So, from the access server,
|
|
0:03:22
|
I'll put everyone into exact mode
|
|
0:03:31
|
Now, we know that this is not gonna be
|
|
0:03:36
|
when I'm sending this command and
|
|
0:03:40
|
So, if we look at the Show
|
|
0:03:46
|
we may see that there are
|
|
0:03:49
|
but it's gonna be fairly close.
|
|
0:03:51
|
At least it's gonna be close enough
|
|
0:03:56
|
there's not gonna be any
|
|
0:03:58
|
So now, let's say that...
|
|
0:04:00
|
somewhere central in the
|
|
0:04:04
|
we'll have router 3 be the NTP server.
|
|
0:04:08
|
Then, all of the other routers in the network,
|
|
0:04:13
|
So, this then assumes that we have IP reachability
|
|
0:04:20
|
So, you could end up in kind
|
|
0:04:25
|
to get the correct time,
|
|
0:04:28
|
but to the route, you need the correct time
|
|
0:04:34
|
So, you do need to make sure that
|
|
0:04:38
|
Otherwise, they could fail the authentication
|
|
0:04:41
|
Now, there's a question here, "In the lab exam,
|
|
0:04:47
|
I would probably go ahead and do it.
|
|
0:04:49
|
I woud set it to whatever the local time is.
|
|
0:04:52
|
So then, if you're trying to sort through
|
|
0:04:56
|
you actually know when it happened.
|
|
0:04:59
|
So, just look at the clock that's on the desktop
|
|
0:05:04
|
and then set the clock close to that.
|
|
0:05:07
|
So, if there's no question in the exam
|
|
0:05:13
|
then, it's not gonna matter if you
|
|
0:05:16
|
So, you're not gonna loose
|
|
0:05:18
|
The only issue would be if there's an
|
|
0:05:22
|
and you don't configure it the same way,
|
|
0:05:25
|
then, obviously, you're not gonna
|
|
0:05:29
|
So, if they say, configure
|
|
0:05:33
|
and I configured this router 3, then,
|
|
0:05:38
|
But in our case here, we're just
|
|
0:05:40
|
doing the authentication
|
|
0:05:47
|
So now, let's go to router 3,
|
|
0:05:51
|
And we'll say, NTP Master 1.
|
|
0:05:54
|
Where 1 is its stratum number.
|
|
0:05:58
|
Now, on all the other routers, we should
|
|
0:06:03
|
Let's say to router 3's loopback,
|
|
0:06:06
|
which we do.
|
|
0:06:08
|
So, on all of the routers, I'm just gonna
|
|
0:06:14
|
We'll say, NTP Server...
|
|
0:06:16
|
150.10.3.3.
|
|
0:06:20
|
So, no special options. We're not doing
|
|
0:06:27
|
We're just specifying on everyone
|
|
0:06:31
|
Now, if this is working, we should be
|
|
0:06:37
|
and see that the clock is synchronized.
|
|
0:06:41
|
In this case, the clock is unsynchronized,
|
|
0:06:46
|
which means that we're still waiting...
|
|
0:06:48
|
to get the correct time from the server.
|
|
0:06:51
|
It says that our stratum is 16,
|
|
0:06:56
|
What I wanna see is what is the reference
|
|
0:07:00
|
The reference time is gonna be...
|
|
0:07:03
|
what the server is advertising to us.
|
|
0:07:05
|
So, if we now look at the
|
|
0:07:07
|
we should see ideally that this is
|
|
0:07:14
|
So, let's see, does router 5
|
|
0:07:18
|
Okay, it does.
|
|
0:07:19
|
So, if we keep looking at this, let's say,
|
|
0:07:23
|
sync.
|
|
0:07:28
|
We should see this
|
|
0:07:30
|
Okay, so let's look on everyone else.
|
|
0:07:34
|
Lets say on router, okay, 1 is synchronized.
|
|
0:07:40
|
2 is synchronized.
|
|
0:07:42
|
3 is gonna be synchronized, because its
|
|
0:07:49
|
4 is not synchronized.
|
|
0:07:53
|
5 is not.
|
|
0:07:56
|
6 is not.
|
|
0:07:59
|
Switch 1 is.
|
|
0:08:03
|
Switch 2, 3, and 4 are.
|
|
0:08:06
|
Okay so, the problems are
|
|
0:08:10
|
Now, I could just wait...
|
|
0:08:12
|
and see if the clocks are
|
|
0:08:17
|
But what I could do
|
|
0:08:19
|
would be to remove the NTP
|
|
0:08:26
|
150.10.3.3.
|
|
0:08:29
|
Then, put the command back.
|
|
0:08:32
|
This is essentially just gonna
|
|
0:08:36
|
So now, let's see... Do Show
|
|
0:08:49
|
And we should be getting the
|
|
0:08:52
|
Let's now look at the...
|
|
0:08:55
|
Let's check on router 5 one more time.
|
|
0:08:58
|
Let's look at the Debug NTP Packets.
|
|
0:09:02
|
And see at least, are we receiving...
|
|
0:09:08
|
the NTP updates from...
|
|
0:09:11
|
router 3?
|
|
0:09:15
|
Okay, there's a question here,
|
|
0:09:21
|
serial?" I believe that it's on on all the
|
|
0:09:29
|
So, we do have all the
|
|
0:09:34
|
Log...
|
|
0:09:36
|
I am logging, debugging to the console.
|
|
0:09:41
|
But I'm not receiving any
|
|
0:09:58
|
Okay, message sent from...
|
|
0:10:04
|
Message sent to router 3
|
|
0:10:07
|
Message received from them.
|
|
0:10:11
|
Let's say, Debug NTP...
|
|
0:10:15
|
Packet Detail.
|
|
0:10:19
|
We should see the specific clock
|
|
0:10:25
|
So, let's do this. Let's remove the server
|
|
0:10:36
|
And then, we'll put it back. So...
|
|
0:10:37
|
This is one one of the configurations
|
|
0:10:41
|
because the configuration is very straightforward.
|
|
0:10:46
|
But...
|
|
0:10:47
|
for whatever reason, sometimes,
|
|
0:10:51
|
Where we saw in some other platforms, it did.
|
|
0:10:55
|
Where either it's a platform issue
|
|
0:10:59
|
routers 4, 5, and 6, because they're
|
|
0:11:10
|
So, we received the message from 3.
|
|
0:11:14
|
This is the received time.
|
|
0:11:18
|
That's when 3 transmitted the time.
|
|
0:11:22
|
So, why are we not installing this then?
|
|
0:11:32
|
No, it's not allowing it.
|
|
0:11:57
|
So, 3 is the NTP master.
|
|
0:12:03
|
on 3, and let's set the
|
|
0:12:13
|
Then, on all the other routers,
|
|
0:12:17
|
So, we'll say, "No NTP Server is router 3.
|
|
0:12:24
|
NTP Server is 5."
|
|
0:12:41
|
So on router 5 now, let's look
|
|
0:12:48
|
It says we're still unsynchronized.
|
|
0:13:00
|
Which doesn't make any sense
|
|
0:13:04
|
Show NTP Status.
|
|
0:13:08
|
Okay, it says now we're synchronized.
|
|
0:13:10
|
Or stratum 1.
|
|
0:13:12
|
Let's see what routers 4 and 6 say.
|
|
0:13:19
|
They're still unsynchronized. I'm wondering
|
|
0:13:24
|
router 5 as a stratum 1 server,
|
|
0:13:26
|
because typically, stratum 1 is
|
|
0:13:30
|
either an atomic clock, or a GPS clock
|
|
0:13:34
|
that is highly, highly accurate. So, let's
|
|
0:13:40
|
that it's not stratum 1.
|
|
0:13:47
|
So No NTP Master.
|
|
0:13:50
|
NTP Master 5.
|
|
0:13:56
|
Then, on router 4, let's say, Show NTP Status.
|
|
0:14:00
|
Okay, let's try removing this.
|
|
0:14:04
|
No NTP Server.
|
|
0:14:09
|
And I'll go all the way back to exact
|
|
0:14:12
|
Then, NTP Server is router 5.
|
|
0:14:21
|
And Show NTP Status.
|
|
0:14:28
|
Still unsynchronized.
|
|
0:14:29
|
So, I think eventually,
|
|
0:14:33
|
this will work.
|
|
0:14:35
|
But sometimes, it just takes a
|
|
0:14:40
|
We can see on the other devices, if we
|
|
0:14:46
|
So, 1 is unsynchronized as well.
|
|
0:14:56
|
But somebody here should be.
|
|
0:14:58
|
Okay, 5 is because it's...
|
|
0:15:02
|
So let's see, Show Run in NTP.
|
|
0:16:14
|
I'm wondering if 5 knows
|
|
0:16:18
|
because it has a hardware clock.
|
|
0:16:21
|
So, it may be that I need to reboot...
|
|
0:16:25
|
in order to get the time working.
|
|
0:16:27
|
So, for now, we'll leave the NTP.
|
|
0:16:30
|
We're gonna come back when we get to
|
|
0:16:34
|
How to do the authentication, how to do
|
|
0:16:38
|
But really, as long as the clocks are...
|
|
0:16:45
|
as long as the clocks are fairly
|
|
0:16:48
|
So, let's look at Show
|
|
0:16:52
|
versus the Show Clock on switch 2.
|
|
0:16:58
|
They're only within a couple seconds
|
|
0:17:02
|
Okay, the key for this though is that
|
|
0:17:07
|
if we look at Show Run Section Key Chain.
|
|
0:17:12
|
And the Show Key Chain.
|
|
0:17:15
|
By default,
|
|
0:17:17
|
any of the keys have an infinite
|
|
0:17:22
|
Which means that we will
|
|
0:17:25
|
and we will accept the key number in
|
|
0:17:29
|
as long as the key number matches,
|
|
0:17:32
|
then, the authentication is good.
|
|
0:17:34
|
But the acceptance and lifetime, this is where
|
|
0:17:39
|
So, lets say now on router 5
|
|
0:17:44
|
for Key 10,
|
|
0:17:46
|
the send lifetime is from
|
|
0:17:55
|
through...
|
|
0:17:59
|
let's say, 23:59:59 on December 31st, 2000.
|
|
0:18:12
|
And the accept lifetime is gonna be the same.
|
|
0:18:19
|
Then, we'll say, for Key 20,
|
|
0:18:22
|
which will have a new key string...
|
|
0:18:25
|
we'll say, key string is 20.
|
|
0:18:28
|
We'll have a different send and accept
|
|
0:18:35
|
Both...
|
|
0:18:44
|
Both sending it and accepting it.
|
|
0:18:47
|
So now lets look at the Show Key Chain,
|
|
0:18:50
|
it says that the first key...
|
|
0:18:53
|
is valid now, because that's
|
|
0:18:56
|
The next key is not, because
|
|
0:19:00
|
It's not anywhere between January 1st
|
|
0:19:07
|
Now, where you can also run into
|
|
0:19:11
|
is that when the routers actually
|
|
0:19:14
|
it's gonna take some sort of finite time and actually
|
|
0:19:22
|
Whereas in this case, I'm not giving
|
|
0:19:27
|
for overlap between the keys.
|
|
0:19:31
|
So, there could be a potential
|
|
0:19:36
|
on January 1st 2001 that the
|
|
0:19:42
|
because one of them is sending key number 10,
|
|
0:19:48
|
Then, eventually, they would regain
|
|
0:19:54
|
but at that exact point, we
|
|
0:19:57
|
which means we're gonna
|
|
0:20:01
|
So, what we should do here ideally
|
|
0:20:04
|
is extend what the accept lifetime or
|
|
0:20:11
|
to overlap with the second one.
|
|
0:20:15
|
So, let's say that for key number 10,
|
|
0:20:18
|
we're going to continue
|
|
0:20:24
|
December 31st 2000.
|
|
0:20:28
|
Which means that if the other
|
|
0:20:34
|
it means that we are going
|
|
0:20:38
|
Okay, then likewise, with the
|
|
0:20:41
|
we probably wanna set this
|
|
0:20:45
|
January 1st 2001...
|
|
0:20:47
|
to make sure that they're not gonna
|
|
0:20:51
|
So, let's say Show Run...
|
|
0:20:54
|
Section Key Chain.
|
|
0:21:02
|
And let's make this change as No Path.
|
|
0:21:04
|
So, let's say here that "For the first key,
|
|
0:21:09
|
I'm gonna continue to accept it for...
|
|
0:21:14
|
let's say, 5 minutes after January 1st 2001."
|
|
0:21:21
|
So, this is giving me 5 minutes of
|
|
0:21:26
|
Then, the new key, I will accept this
|
|
0:21:30
|
for 5 minutes prior. So, 23:55:00
|
|
0:21:37
|
on December 31st 2000.
|
|
0:21:43
|
So now, we have a decent amount of
|
|
0:21:47
|
that if for some reason the clocks
|
|
0:21:51
|
then, the router should
|
|
0:21:56
|
So, let's apply this both on...
|
|
0:21:58
|
router 5 and...
|
|
0:22:03
|
switch 2.
|
|
0:22:04
|
So now, router 5, if we Show Key Chain,
|
|
0:22:08
|
we should see the new...
|
|
0:22:13
|
the new values here.
|
|
0:22:15
|
Okay, we can see the
|
|
0:22:18
|
We're accepting this for an
|
|
0:22:23
|
the old one is stopped being sent.
|
|
0:22:26
|
Then, the new one, we're accepting it 5
|
|
0:22:32
|
Again, just a protection mechanism to make
|
|
0:22:38
|
Then, on switch 2, we'll do the same thing.
|
|
0:22:46
|
So now, if we Show...
|
|
0:22:48
|
Key Chain.
|
|
0:22:51
|
And Show Clock.
|
|
0:22:54
|
Since it's currently January 1st 2000,
|
|
0:23:00
|
Now, if we were to change this,
|
|
0:23:11
|
January 1st 2001.
|
|
0:23:16
|
When I change this on switch 2,
|
|
0:23:20
|
and then, there's a delay before
|
|
0:23:26
|
we can see that there was a
|
|
0:23:32
|
So, since they were'nt agreeing on
|
|
0:23:36
|
then, the authentication fails. So, even
|
|
0:23:41
|
but if your network is very high availability...
|
|
0:23:45
|
in the design, then,
|
|
0:23:49
|
So now, if we look at
|
|
0:23:53
|
the new one is valid,
|
|
0:23:56
|
but the old one is invalid.
|
|
0:24:00
|
So, that's why we lost the
|
|
0:24:02
|
So really, for this configuration,
|
|
0:24:07
|
and the send lifetime should be extended.
|
|
0:24:10
|
So that it's gonna add to that overlap.
|
|
0:24:13
|
So, I would wanna say basically
|
|
0:24:19
|
the send lifetime.
|
|
0:24:23
|
And then, the same thing down
|
|
0:24:31
|
So, as long as they're both sending
|
|
0:24:36
|
then, we shouldn't have that failure,
|
|
0:24:39
|
So now, let's try this one of both of them.
|
|
0:24:51
|
Then, we'll set the clock back to 2000.
|
|
0:25:03
|
Same thing on router 5. If we
|
|
0:25:08
|
we can see now, the first key is valid.
|
|
0:25:11
|
If we Show IP EIGRP Neighbors,
|
|
0:25:16
|
we see that we are adjacent with switch 2.
|
|
0:25:19
|
Okay, now again, if we change
|
|
0:25:26
|
and look at the Show Key
|
|
0:25:31
|
5 says that both of them are valid.
|
|
0:25:35
|
Then, when switch 2 eventually
|
|
0:25:40
|
and we Show Key Chain.
|
|
0:25:44
|
Now, switch 2 likewise agrees
|
|
0:25:49
|
But during that period, when they
|
|
0:25:53
|
we see that the adjacency
|