|
0:00:13
|
In our next class sessions we're going to talk about
|
|
0:00:15
|
these system management topics that are within the scope
|
|
0:00:18
|
of the routing and switching exam. Specifically these are going to include
|
|
0:00:22
|
NTP, SNMP and RMON for collecting different statistics about the router
|
|
0:00:28
|
things like CPU utilization, interface utilization, number of errors on the
|
|
0:00:34
|
links. Syslog is for sending our RMON traps or general
|
|
0:00:40
|
log messages to a collection station also how to enable SSH
|
|
0:00:47
|
on the router. We already talked about telnet a little bit within the
|
|
0:00:51
|
scope of security, how do we control access to the router
|
|
0:00:54
|
with things like the access class on the vty lines. We'll also look at
|
|
0:00:59
|
some other minor features like enabling system banners
|
|
0:01:01
|
and menus for when we login to the router to generate a banner
|
|
0:01:07
|
when the user logs in, we could give them a menu
|
|
0:01:09
|
for changing different configurations or running different show commands
|
|
0:01:15
|
and then last thing we'll talk a little bit about the embedded
|
|
0:01:17
|
event manager scripting or the EEM process
|
|
0:01:21
|
that can essentially tie in with any of these other system management
|
|
0:01:25
|
topics or with the enhanced object tracking in order to do different
|
|
0:01:30
|
types of alerts like sending messages to syslog or e-mailing information
|
|
0:01:35
|
or doing automation of the router based on different
|
|
0:01:39
|
types of triggered events that we can configure.
|
|
0:01:42
|
Now the first of these is going to be the network time protocol or NTP
|
|
0:01:47
|
which is designed to synchronize the clock between different devices
|
|
0:01:51
|
in the network.
|
|
0:01:53
|
Now the reason that we would want this in the first place is generally
|
|
0:01:56
|
to make sure that the log messages are going to be
|
|
0:01:59
|
the same between the different devices.
|
|
0:02:02
|
So if we're using a syslog server to keep track of what's going on
|
|
0:02:06
|
in the network or the embedded event manager that is doing
|
|
0:02:09
|
time based event management that we would need to make sure
|
|
0:02:13
|
that the clocks are accurate.
|
|
0:02:15
|
Additionally this would also be needed for any type of time
|
|
0:02:19
|
based authentication when we're doing key chain authentication
|
|
0:02:23
|
for EIGRP or our first hop redundancy protocols
|
|
0:02:26
|
where we're trying to do key rotation based on the time
|
|
0:02:29
|
we would need to make sure that the clocks are synchronized
|
|
0:02:32
|
to begin with. Now NTP uses a tree structure that is known as
|
|
0:02:37
|
the stratum to figure out who has the most accurate clock
|
|
0:02:41
|
in the network or a stratum 1 clock is either an atomic clock or
|
|
0:02:46
|
a GPS clock that is assumed to have the most accurate time
|
|
0:02:50
|
in the topology, so the stratum 1 this is known as the root of the tree.
|
|
0:02:56
|
Now the time itself is always going to be advertised in UTC
|
|
0:03:03
|
which is similar to GMT time but there's certain times of
|
|
0:03:07
|
the year when UTC and GMT don't match, so this means that
|
|
0:03:13
|
any time zone configuration on the devices is going to be only
|
|
0:03:18
|
locally significant to that device.
|
|
0:03:21
|
Now typically in most designs, you're better off just leaving
|
|
0:03:24
|
all the devices in the network in UTC time because if the network
|
|
0:03:29
|
starts to grow and the devices are in multiple time zones
|
|
0:03:32
|
it gets very difficult to try to correlate the log messages
|
|
0:03:36
|
between them if one of the devices is UTC+4 and another
|
|
0:03:41
|
one is UTC-6, so if all the devices are using the
|
|
0:03:46
|
UTC time, they're always using the same reference
|
|
0:03:51
|
then you can always coordinate that locally against what your
|
|
0:03:53
|
time zone is where you're trying to read the logs.
|
|
0:04:00
|
Now the configuration of NTP is going to be fairly straightforward
|
|
0:04:03
|
there's not that many commands that are related to this
|
|
0:04:06
|
we saw this previously in our EIGRP configuration
|
|
0:04:10
|
the big thing with NTP is that it's generally subject to
|
|
0:04:13
|
the order of operations of the commands.
|
|
0:04:17
|
So we'll look at some cases where it doesn't look like the
|
|
0:04:20
|
NTP configuration is right, but if you let the clock sit there
|
|
0:04:23
|
for a while, eventually it's going to skew closer and
|
|
0:04:26
|
closer towards the correct time.
|
|
0:04:29
|
Now the way it does this is based on three different
|
|
0:04:32
|
roles in the network where the NTP servers are going to be
|
|
0:04:35
|
giving out time, but not changing their local time.
|
|
0:04:40
|
The NTP client is going to be getting the time from the servers
|
|
0:04:43
|
and updating its local clock where NTP peers can give each other
|
|
0:04:48
|
time and also can synchronize to each other.
|
|
0:04:53
|
So NTP peering is used for a redundancy in the network
|
|
0:04:56
|
where maybe our network edge is getting time directly
|
|
0:04:59
|
from a GPS clock or an atomic clock which means that they
|
|
0:05:04
|
would stratum 2 because they're one hop away from
|
|
0:05:08
|
the original time source, then the stratum 2 devices who are
|
|
0:05:12
|
at the network edge we can configure them as peers of each other
|
|
0:05:17
|
to prevent against the case where if one of them loses their stratum 1
|
|
0:05:21
|
source, then they would be able to synchronize to the other device
|
|
0:05:26
|
that has the lower stratum, so out of the peers essentially
|
|
0:05:30
|
whoever has the lower stratum version or the stratum number
|
|
0:05:34
|
they are the version of the clock that is going to be more preferred
|
|
0:05:38
|
because again, the lower the stratum it means the closer you are
|
|
0:05:40
|
to the most accurate time source.
|
|
0:05:46
|
Additionally the NTP clock can be authenticated
|
|
0:05:50
|
specifically the messages that are coming from the server
|
|
0:05:52
|
down to the client where for this configuration we need to
|
|
0:05:57
|
make sure that the key number is matching because it is
|
|
0:06:01
|
exchanged in the NTP authentication
|
|
0:06:05
|
so not only does the password have to match which ultimately
|
|
0:06:08
|
that means that the MD5 signature is going to match
|
|
0:06:13
|
but the key number has to match as well.
|
|
0:06:15
|
So similar to the key chain authentication for EIGRP
|
|
0:06:19
|
or the OSPF MD5 authentication.
|
|
0:06:24
|
Now typically this is configured where the client is going to be
|
|
0:06:29
|
authenticating the server so it's the opposite of what our
|
|
0:06:34
|
normal authentication design is
|
|
0:06:37
|
because in the case of NTP, the server really doesn't
|
|
0:06:40
|
care who it is giving time out to, but the client wants to
|
|
0:06:44
|
make sure that it is getting time from the legitimate source.
|
|
0:06:48
|
So it's the client authenticating the server, not the server
|
|
0:06:52
|
authenticating the client. Now again, configuration
|
|
0:06:55
|
for this is going to be very straightforward where there's only
|
|
0:06:58
|
a couple commands for this
|
|
0:07:01
|
and they're all going to start with the NTP in a global configuration
|
|
0:07:08
|
where the NTP master command this is to configure us as the root
|
|
0:07:13
|
time source. Now typically the router itself should not be configured
|
|
0:07:17
|
as stratum 1 unless it has a GPS clock or an atomic clock
|
|
0:07:23
|
directly attached so in this case on Router 5 I'll say that the
|
|
0:07:27
|
that the NTP master stratum is 5
|
|
0:07:31
|
so I'm going to be the server for the rest of the network.
|
|
0:07:36
|
If we look at the show clock
|
|
0:07:38
|
on Router 5, it says it is 11:05 UTC Friday May 20th, 2001
|
|
0:07:46
|
Now for the other devices to synchronize to Router 5
|
|
0:07:50
|
there is an order of operations that we need to take into account here.
|
|
0:07:55
|
Based on the NTP specification, it says there's two possible
|
|
0:07:59
|
ways that you can update your clock.
|
|
0:08:01
|
Either you can take the time that the server has and
|
|
0:08:05
|
replace your local clock with that or you can slowly skew your
|
|
0:08:09
|
time closer and closer to the correct time.
|
|
0:08:15
|
So the issue then becomes it depends on how the
|
|
0:08:17
|
individual NTP client implements this. You can see cases where
|
|
0:08:24
|
the clock does not become synchronized because your
|
|
0:08:27
|
time is too far away from what the current server is
|
|
0:08:31
|
where eventually if you let the router sit there for a couple
|
|
0:08:34
|
hours, it will synchronize because it's moving closer
|
|
0:08:37
|
and closer and closer to the correct time
|
|
0:08:41
|
but if you want the router to synchronize fairly quickly
|
|
0:08:44
|
then the way that you should do it is to set the time first
|
|
0:08:49
|
then configure it as an NTP client or an NTP peer
|
|
0:08:52
|
of the server.
|
|
0:08:56
|
So if we were to look at Router 1 for example and look
|
|
0:08:58
|
at the show clock, since this particular device
|
|
0:09:02
|
doesn't have a hardware clock, when it reboots it's going to get the
|
|
0:09:06
|
default time which for this particular IOS
|
|
0:09:10
|
version in this particular platform is March 1st, 2002
|
|
0:09:16
|
Now if Router 5 is the server and it's saying that the time is
|
|
0:09:19
|
in 2011, then generally Router 1's time is going to be
|
|
0:09:23
|
too far off in order to synchronize immediately.
|
|
0:09:27
|
So it might take a couple hours in order for Router 1 to synchronize.
|
|
0:09:32
|
So to fix this, the first thing I'm going to do is just change the
|
|
0:09:34
|
clock. I'll say clock set and then something similar to what Router 5's is.
|
|
0:09:42
|
Now it doesn't have to be exact as long as I'm within
|
|
0:09:45
|
maybe five or ten minutes or so.
|
|
0:09:52
|
If we show clock, we should see that it's fairly close to what
|
|
0:09:55
|
Router 5 has. Router 5 says it's 11:07
|
|
0:09:59
|
Router 1 says it's 11:05
|
|
0:10:00
|
so it's only a couple minutes off.
|
|
0:10:04
|
Next if I specify that the NTP server is Router 5's
|
|
0:10:09
|
address, then look at the show ntp status
|
|
0:10:15
|
ideally I should see that this is going to change
|
|
0:10:18
|
to synchronized.
|
|
0:10:23
|
And it should happen almost immediately here
|
|
0:10:25
|
which it now has.
|
|
0:10:28
|
It said previously that the reference time was zero.
|
|
0:10:33
|
So it did not know about a server.
|
|
0:10:35
|
Now it says the reference time is 11:07:48 May 20th, 2011
|
|
0:10:41
|
which is Router 5's time.
|
|
0:10:45
|
If we look at the show ntp status versus the show clock
|
|
0:10:49
|
we should now see that they're pretty close in the synchronization
|
|
0:10:54
|
where the last time I got the reference time was 8:02
|
|
0:10:56
|
then my clock locally here is 8:11
|
|
0:11:01
|
We can see the actual packets come in if we look at the
|
|
0:11:06
|
debug ntp packets
|
|
0:11:12
|
So periodically we should see Router 1 receiving these
|
|
0:11:16
|
updates in from Router 5
|
|
0:11:20
|
where Router 5 is the reference clock.
|
|
0:11:22
|
Now for the other clients let's say on Router 2
|
|
0:11:25
|
that we want to use Router 5 as the server
|
|
0:11:28
|
but we want to authenticate this information.
|
|
0:11:32
|
So again, on Router 2 I'm going to look at the show clock
|
|
0:11:34
|
I want to make sure that my time if fairly close to Router 5's
|
|
0:11:39
|
so what Router 5 says the clock is right now
|
|
0:11:42
|
11:09:09 this is what I'm going to set it to be.
|
|
0:11:46
|
So on Router 2 I'll simply say clock set
|
|
0:11:51
|
and again, this is being exchanged in UTC
|
|
0:11:54
|
so if I change the time zone it's only going to be locally significant.
|
|
0:12:01
|
Next I'm going to configure Router 5 as the NTP server
|
|
0:12:05
|
but I want to authenticate them.
|
|
0:12:07
|
So I'll specify what is the NTP authentication key.
|
|
0:12:12
|
The key number I'll say this is key number 1
|
|
0:12:16
|
We're running md5, then this is the clear text password.
|
|
0:12:20
|
I'll say the password is cisco
|
|
0:12:25
|
Next I need to make sure that this key is actually active.
|
|
0:12:27
|
I'll say this is an ntp trusted key
|
|
0:12:31
|
and the NTP authentication process is on.
|
|
0:12:36
|
That's with the ntp authenticate
|
|
0:12:40
|
So now Router 2 is configured for authentication
|
|
0:12:42
|
but it doesn't know what the server is and what
|
|
0:12:45
|
key number to challenge them with.
|
|
0:12:48
|
So our final step would be to configure the NTP server
|
|
0:12:51
|
which is Router 5
|
|
0:12:54
|
but I need to specify that I'm going to authenticate them
|
|
0:12:57
|
with this particular key.
|
|
0:13:00
|
Now Router 5 who is the server it also needs to
|
|
0:13:03
|
know what the key is and that this key is active.
|
|
0:13:07
|
So it needs to say ntp authentication key
|
|
0:13:10
|
and this is an ntp trusted key.
|
|
0:13:15
|
Before we do this on Router 2, let's look at the debug ntp packets.
|
|
0:13:21
|
And the debug ntp authentication
|
|
0:13:27
|
Ideally what we should see is that when the server is
|
|
0:13:30
|
specified with that particular key, that the authentication
|
|
0:13:35
|
is correct and that synchronization happens fairly quickly.
|
|
0:14:12
|
So we can see in the time stamps here that the packets are
|
|
0:14:15
|
sent fairly quickly, this is Router 2 doing its initial
|
|
0:14:17
|
synchronization. It says, 'Received the packet in from Router 5'
|
|
0:14:24
|
It was using authentication key 1 The reference, this is the time that
|
|
0:14:28
|
Router 5 has configured. What we should see now if we look at
|
|
0:14:32
|
the show ntp status for one thing we want to make sure that
|
|
0:14:37
|
we're synchronized.
|
|
0:14:39
|
show ntp status it says that we are synchronized.
|
|
0:14:41
|
But if we look at the show ntp association detail
|
|
0:14:46
|
it needs to say that the neighbor has been authenticated
|
|
0:14:52
|
because you can have configurations where you
|
|
0:14:56
|
have synchronized with the peer, but they are not
|
|
0:14:58
|
authenticated, this would mean that the NTP client
|
|
0:15:02
|
does not have their authentication enabled.
|
|
0:15:07
|
So on Router 2, if I were to leave out the last option
|
|
0:15:12
|
in NTP which was the key that is challenging the server
|
|
0:15:16
|
so this portion right here
|
|
0:15:20
|
even though I have authentication enabled, I have the key defined and
|
|
0:15:24
|
it is active, it's a trusted key
|
|
0:15:26
|
unless I actually challenge the server with that key number
|
|
0:15:31
|
authentication is not going to occur.
|
|
0:15:35
|
Now notice additionally the server itself doesn't need to say ntp authenticate
|
|
0:15:40
|
because it is not initiating authentication, it is simply
|
|
0:15:44
|
responding to it.
|
|
0:15:46
|
Now the rest of the configuration on the server we could specify
|
|
0:15:49
|
an NTP access group
|
|
0:15:51
|
this would be used to control who I can give time to
|
|
0:15:56
|
where by default, the server is going to give
|
|
0:15:59
|
time to any client that requests it.
|
|
0:16:03
|
So if I say then I'm going to be a server I'll say ntp access group serve only
|
|
0:16:07
|
then for these particular devices where access list 1 would be
|
|
0:16:12
|
matching the source addresses where the requests are coming from.
|
|
0:16:17
|
So if I'm matching the loopback addresses of Router 1 and Router 2
|
|
0:16:21
|
on those device, I would want to say that the ntp
|
|
0:16:27
|
the ntp source
|
|
0:16:30
|
is my loopback.
|
|
0:16:32
|
So whatever address that Router 5 has in the access list
|
|
0:16:35
|
that should be the update source that the ntp client is using.
|
|
0:16:42
|
Another option for this on the server would be to
|
|
0:16:44
|
send the updates as multicasts.
|
|
0:16:51
|
where if we say ntp and this may be at the interface level.
|
|
0:16:59
|
Let's say ntp server
|
|
0:17:11
|
let's try in the link level ntp multicast
|
|
0:17:16
|
so here on this server we would specify what is the
|
|
0:17:18
|
destination address that we want to use
|
|
0:17:20
|
If I said 224.1.1.1
|
|
0:17:26
|
then I would want to say for the other devices the clients
|
|
0:17:30
|
ntp client or ntp multicast client
|
|
0:17:35
|
and the particular address that I'm looking for 224.1.1.1
|
|
0:17:40
|
This could be one way that you could test your multicast
|
|
0:17:42
|
configurations to make sure that you can actually get multicast
|
|
0:17:46
|
transit because if the server is using multicast updates
|
|
0:17:51
|
and the clients are actually receiving the time
|
|
0:17:53
|
then you could assume that the packets are working.
|
|
0:17:59
|
Additionally, if you look at the debug ip
|
|
0:18:02
|
debug ip packet detail
|
|
0:18:05
|
on either the NTP server or its clients
|
|
0:18:10
|
we should see the transport that's getting used here
|
|
0:18:13
|
which is
|
|
0:18:19
|
after I undebug here it should be UDP port
|
|
0:18:24
|
123
|
|
0:18:26
|
so both source and destination 123 is network time
|
|
0:18:32
|
we see this is coming from Router 5's loopback and it's
|
|
0:18:34
|
going to two's loopback because Router 2 set that
|
|
0:18:38
|
as its NTP source
|
|
0:18:41
|
where normally, just like BGP or telnet or ping or trace route
|
|
0:18:46
|
the router's going to use the IP address on the
|
|
0:18:49
|
outgoing interface towards the server as the address that
|
|
0:18:53
|
it is requesting from.
|
|
0:18:55
|
What if the server has an access list that is specifying
|
|
0:18:58
|
just this address 150.28.2.2
|
|
0:19:02
|
then the NTP client would have to specify where that
|
|
0:19:05
|
update is -- or where that request is coming from.
|
|
0:19:07
|
So the vast majority the configuration for this is
|
|
0:19:10
|
pretty straightforward. The issue is that the order of operations
|
|
0:19:13
|
can be a problem. If the clocks are not fairly close
|
|
0:19:16
|
to begin with, then it can take a very long time for the
|
|
0:19:20
|
client to get the time from the server.
|
|
0:19:24
|
The other issue with this is that in the 12.4 T documentation
|
|
0:19:29
|
the last time I checked for this there's some sort of web page
|
|
0:19:33
|
that's missing in one of the links where the NTP documentation
|
|
0:19:37
|
is not actually located under 12.4 T
|
|
0:19:41
|
so normally, this should be under performing basic system management
|
|
0:19:46
|
which is the network management configuration guide.
|
|
0:19:54
|
Then there would be a section here for NTP.
|
|
0:19:57
|
You can kind of work backwards again from this if you were to look
|
|
0:20:00
|
at the master index.
|
|
0:20:04
|
Let's go to the main documentation, products IOS
|
|
0:20:09
|
regular IOS, 12.4, 12.4 T
|
|
0:20:15
|
release and general information
|
|
0:20:17
|
master index
|
|
0:20:19
|
then master index for commands.
|
|
0:20:23
|
This is under NTP.
|
|
0:20:28
|
If you search for NTP, it says this is under NM which is Network Management.
|
|
0:20:38
|
So we see it's under IOS network management command reference.
|
|
0:20:41
|
Well, when we correlate this with the network management configuration guide
|
|
0:20:50
|
for some reason the document is not linked from here.
|
|
0:20:54
|
Now you may be able to find it in some of the older versions
|
|
0:20:59
|
because in a real design, the only thing you would need
|
|
0:21:03
|
to do is just say site www.cisco.com ntp
|
|
0:21:08
|
and then just search for it and you could get to the
|
|
0:21:10
|
particular page for the documentation.
|
|
0:21:14
|
But we know the problem is that within the scope of the lab exam
|
|
0:21:16
|
you're not going to be able to use the search engine.
|
|
0:21:20
|
So it's normally under this performing basic system management
|
|
0:21:24
|
but in the 12.4 T
|
|
0:21:27
|
this should be under
|
|
0:21:35
|
performing basic system management so this first document
|
|
0:21:38
|
and if you search for NTP
|
|
0:21:42
|
there's no matches for it
|
|
0:21:47
|
so the only it gives us is this day time service which
|
|
0:21:50
|
is one of the small TCP services that if you telnet to
|
|
0:21:55
|
the day time port, it should tell you what the time is.
|
|
0:22:02
|
So if you did need to reference this, you could go to the
|
|
0:22:05
|
earlier versions, in this case, this is 12.1 mainline
|
|
0:22:21
|
then from here you can see some of the configuration examples.
|
|
0:22:25
|
But again, the NTP configuration is really not that complicated
|
|
0:22:28
|
it's only a couple commands.
|
|
0:22:31
|
The only thing really that could be possibly complicated about
|
|
0:22:34
|
this is the NTP access restrictions.
|
|
0:22:39
|
The difference between the here, the client and then the
|
|
0:22:45
|
the serve only
|
|
0:22:48
|
which is peer, serve, serve only and query only
|
|
0:22:52
|
so you can see it says, 'The access groups options
|
|
0:22:56
|
are scanned in the following order from least to most restrictive.'
|
|
0:22:59
|
where NTP peer
|
|
0:23:04
|
says, 'Allows time request and control queries and allows the
|
|
0:23:07
|
system to synchronize itself to a system whose address
|
|
0:23:09
|
passes the access list criteria.'
|
|
0:23:14
|
Serve allows time requests and control queries
|
|
0:23:16
|
but does not allow the system to synchronize itself with those
|
|
0:23:19
|
who pass the access list.
|
|
0:23:24
|
Serve only allows time requests, query only allows control queries
|
|
0:23:29
|
from a system whose address passes the access list, so again
|
|
0:23:32
|
essentially this is controlling when you are the server
|
|
0:23:35
|
who are you going to give the time to.
|
