|
0:00:13
|
Our next system management topic is the Simple Network
|
|
0:00:16
|
Management Protocol or SNMP
|
|
0:00:20
|
that is designed to provide information about variables
|
|
0:00:24
|
on the router or the switch
|
|
0:00:28
|
which is known as the management information base or the MIB.
|
|
0:00:33
|
Now SNMP runs over UDP ports 161 and 162
|
|
0:00:37
|
which means that it is not a reliable transport.
|
|
0:00:42
|
So we'll see that there are potential ways that you
|
|
0:00:44
|
can configure acknowledgments for SNMP, but normally for unsolicited
|
|
0:00:48
|
traps, they're not guaranteed delivery
|
|
0:00:52
|
which could potentially be a problem if you're trying to use
|
|
0:00:55
|
SNMP to send triggered events
|
|
0:01:00
|
based on something happening like your interface going down
|
|
0:01:02
|
or some sort of EEM script triggering
|
|
0:01:07
|
then normally, you would want to make sure that
|
|
0:01:08
|
that delivery is reliable, but by default since it's using
|
|
0:01:11
|
UDP, there is not going to be any acknowledgements for
|
|
0:01:14
|
the SNMP requests or traps.
|
|
0:01:21
|
Now the configuration of SNMP it's going to be two fold
|
|
0:01:24
|
we can configure SNMP polling
|
|
0:01:27
|
which is when the network management station is asking
|
|
0:01:30
|
the managed device where the managed device is going to be
|
|
0:01:34
|
either the router or switch, it's asking them what is the status
|
|
0:01:37
|
of a MIB, so you have your management application
|
|
0:01:42
|
like HPO from you that's asking the router what's
|
|
0:01:45
|
the size of your routing table or what's the number of errors
|
|
0:01:48
|
that's on your Fast Ethernet 0/0 interface.
|
|
0:01:52
|
So essentially every variable that we see on the router
|
|
0:01:55
|
when we're doing our show interfaces, show ip route
|
|
0:01:58
|
show version, essentially all of those individual
|
|
0:02:01
|
variables are going to have MIBS that are associated with them.
|
|
0:02:06
|
The problem with SNMP MIBs though is that they are platform
|
|
0:02:10
|
and version specific, so different platforms are going to
|
|
0:02:14
|
support different MIBs and there's really no way that
|
|
0:02:17
|
we can figure out the vast majority of what they are
|
|
0:02:20
|
without running what's known as an SNMP walk.
|
|
0:02:25
|
An SNMP walk is where the network management station
|
|
0:02:28
|
essentially polls every single possible variable to figure out
|
|
0:02:32
|
what does that platform support.
|
|
0:02:36
|
So once you ask the router what are all the MIBS that you
|
|
0:02:39
|
have, then you could sort through them and figure out
|
|
0:02:41
|
which ones do I actually want, but within the scope of the lab exam
|
|
0:02:46
|
there's generally not going to be a reference for what the MIBs are.
|
|
0:02:50
|
So if you are tested on this and they want you to
|
|
0:02:54
|
poll or trap a specific MIB value, generally they're going to have to
|
|
0:02:57
|
tell you what the value is.
|
|
0:03:01
|
We'll see that there are some minor ones that we can figure out locally
|
|
0:03:04
|
things like the MTU of the interface or the number of packets that are
|
|
0:03:10
|
going out the link, but most of them just based on their
|
|
0:03:13
|
names, we're not going to be able to figure out exactly
|
|
0:03:15
|
what they are referring to. The other option instead of the
|
|
0:03:19
|
network management station asking the device what's the
|
|
0:03:22
|
status of a MIB, we can have the managed device
|
|
0:03:25
|
sending an unsolicited event which is known as the SNMP trap
|
|
0:03:28
|
or the SNMP inform.
|
|
0:03:32
|
Now the difference between them, the SNMP trap is going to
|
|
0:03:34
|
be unreliable where the inform is acknowledged
|
|
0:03:39
|
so an inform is essentially a reliable trap.
|
|
0:03:43
|
SNMP supports three different versions
|
|
0:03:45
|
version 1, version 2c and version 3
|
|
0:03:50
|
where in general in a real design you should be running
|
|
0:03:53
|
SNMP version 3 because it supports both authentication
|
|
0:03:57
|
and encryption.
|
|
0:03:59
|
For version 1 and version 2, since the community strings
|
|
0:04:05
|
are in clear text, essentially anyone who sniffs the SNMP
|
|
0:04:09
|
packet could potentially change variables on the router
|
|
0:04:13
|
with the SNMP read/write communities.
|
|
0:04:19
|
So version 1 it supports only the community authentication
|
|
0:04:23
|
which again is just going to be a clear text string.
|
|
0:04:26
|
Version 2c supports the communities, but also the different views.
|
|
0:04:31
|
So we can control what different management stations can view
|
|
0:04:34
|
which particular MIBs.
|
|
0:04:38
|
Version 3 supports not only the encryption and authentication
|
|
0:04:41
|
but also different users and groups
|
|
0:04:44
|
where the idea behind this is that we can assign different
|
|
0:04:47
|
views to different groups
|
|
0:04:49
|
then apply the users to the groups
|
|
0:04:52
|
so depending on who is asking for the information
|
|
0:04:55
|
we can either permit or deny them from seeing or changing
|
|
0:05:00
|
a specific value of a MIB on the router. Now the
|
|
0:05:04
|
configuration for SNMP both for the polling and the trapping is
|
|
0:05:07
|
going to be fairly straightforward
|
|
0:05:09
|
where in the case of version 1 and version 2 polling
|
|
0:05:12
|
the only thing that we need to define is what is the community string.
|
|
0:05:17
|
We could have the same value for read-only and
|
|
0:05:20
|
read/write or we could have them as separate values.
|
|
0:05:24
|
Typically the defaults are going to be public and private
|
|
0:05:27
|
for read-only and read/write
|
|
0:05:28
|
so essentially you should never use those values.
|
|
0:05:34
|
Additionally you can control what network and management
|
|
0:05:36
|
stations can poll the device with the access
|
|
0:05:40
|
list, so in a real deployment you should always have the
|
|
0:05:44
|
ACL there that's listing what the network and management's address is.
|
|
0:05:48
|
This would prevent any other devices in the network from
|
|
0:05:51
|
polling information from the router or from the switch.
|
|
0:05:58
|
The two different types of community strings we have
|
|
0:06:00
|
read-only and read/write where read only is only
|
|
0:06:02
|
going to view the MIBs, read/write could change the
|
|
0:06:06
|
variables like doing configuration changes remotely, reloading the
|
|
0:06:12
|
router remotely, pretty much anything you can
|
|
0:06:16
|
change from the command line, you can also change through
|
|
0:06:18
|
SNMP with the read/write community string.
|
|
0:06:21
|
For SNMP trapping again these are going to be unsolicited events
|
|
0:06:26
|
that come from the managed device to the network and management
|
|
0:06:28
|
station for things like if the interface goes down or if the
|
|
0:06:34
|
number of errors exceed a certain threshold on the
|
|
0:06:36
|
interface or the CPU exceeds a certain threshold
|
|
0:06:40
|
we can configure the router to send a trap which is similar
|
|
0:06:44
|
to a syslog message except it's using the SNMP format
|
|
0:06:47
|
as opposed to the syslog messages.
|
|
0:06:51
|
Now in both cases whether we're doing traps or informs
|
|
0:06:54
|
they're both going to be using UDP port 162
|
|
0:06:58
|
again, the difference is that the informs are acknowledged
|
|
0:07:02
|
so they are reliable.
|
|
0:07:04
|
With the regular traps, they're unsolicited and the router does
|
|
0:07:07
|
not wait for an acknowledgement back in, so it's simply going to
|
|
0:07:11
|
send it once, if the packet is dropped, the managed device is
|
|
0:07:15
|
not going to know about that. For enabling this on version 1
|
|
0:07:19
|
and version 2, we simply say snmp-server enable traps
|
|
0:07:23
|
that's going to turn on everything
|
|
0:07:25
|
or we could say snmp-server enable traps and then the specific
|
|
0:07:30
|
ones that we want to enable.
|
|
0:07:32
|
So we always need to do this first globally either all of them
|
|
0:07:36
|
or specific traps.
|
|
0:07:40
|
Then we could specify who exactly are we going to send them to
|
|
0:07:43
|
so who is the network management station
|
|
0:07:45
|
this is the SNMP server host command.
|
|
0:07:49
|
Now if we specify just their address with the community string
|
|
0:07:53
|
we're going to send them all possible enabled traps.
|
|
0:07:57
|
If we say snmp-server host their address the community string
|
|
0:08:01
|
and then the specific type of trap, that is going to be a
|
|
0:08:05
|
subset of what is enabled.
|
|
0:08:10
|
Now the common mistake for this though is to specify
|
|
0:08:13
|
the subset of traps before actually enabling them
|
|
0:08:17
|
globally, so if I were to say the snmp-server host
|
|
0:08:23
|
is 1 2 3 4
|
|
0:08:26
|
and I want to send them traps with this as my community string
|
|
0:08:33
|
and I want to send them let's say bgp traps
|
|
0:08:43
|
right now, this is not actually going to do anything
|
|
0:08:45
|
because I did not enable bgp traps globally.
|
|
0:08:51
|
So what this command is saying is that I'm going to send the traps to
|
|
0:08:54
|
this particular server 1.2.3.4 but I'm going to filter what
|
|
0:08:59
|
I have enabled globally to include only the bgp traps.
|
|
0:09:04
|
This would then mean I need to do either one of two
|
|
0:09:07
|
things after this. Say snmp-server enable traps bgp
|
|
0:09:13
|
or just snmp-server enable traps
|
|
0:09:19
|
If we look at the result of this in the running config
|
|
0:09:22
|
show run include snmp
|
|
0:09:26
|
we can see it's going basically be every trap that this particular
|
|
0:09:31
|
platform supports.
|
|
0:09:33
|
So it's going to change depending on the particular
|
|
0:09:36
|
platform in the IOS version that you're working with.
|
|
0:09:41
|
Again, for the SNMP polling, the only thing we need to do is
|
|
0:09:45
|
specify the community string, so snmp-server community
|
|
0:09:51
|
we'll say this is read only
|
|
0:09:54
|
that's ro
|
|
0:09:57
|
we'll say the read/write is rw
|
|
0:10:00
|
but I want to limit this to whoever is matched in access list 10
|
|
0:10:04
|
Once the SNMP process is enabled, you can look at the
|
|
0:10:09
|
show snmp mib ifmib ifindex
|
|
0:10:15
|
which is going to show me for the local interfaces that I
|
|
0:10:18
|
currently have configured what are the index numbers
|
|
0:10:22
|
that are corresponding to them.
|
|
0:10:25
|
So for example, Fast Ethernet 0/0 is interface index number 1
|
|
0:10:31
|
so this means that when I look at a MIB that is related to
|
|
0:10:34
|
the interface and it ends with .1
|
|
0:10:38
|
it means it's corresponding specifically to Fast Ethernet 0/0
|
|
0:10:44
|
So if I wanted to figure out what is the MTU of Fast Ethernet 0/0
|
|
0:10:49
|
the MIB that I would be looking for would be ifMTU.1
|
|
0:10:57
|
Now the problem with this is that there's no possible way
|
|
0:11:00
|
you could memorize what are all the potential MIBs.
|
|
0:11:03
|
When you look at the format of them that are not
|
|
0:11:06
|
using these ascii strings, it's simply a long sequence of
|
|
0:11:09
|
numbers, decimal numbers that are separated by dots.
|
|
0:11:14
|
So the MIB tree has a hierarchy
|
|
0:11:17
|
where you're starting with the least specific number
|
|
0:11:19
|
that specifies the top level of the tree
|
|
0:11:22
|
and then you keep getting more and more detailed down
|
|
0:11:25
|
into the leaves as you go to the right of the number.
|
|
0:11:29
|
Now some of these you can see locally on the router if you
|
|
0:11:32
|
look at the show snmp mib
|
|
0:11:35
|
but a lot of these you won't be able to tell what they are
|
|
0:11:37
|
just based on their names.
|
|
0:11:40
|
So .11 station config entry
|
|
0:11:44
|
.11 authentication algorithms entry .2 and .3
|
|
0:11:48
|
so this is related something something to do with wireless
|
|
0:11:52
|
but we really don't know exactly what is that MIB, so
|
|
0:11:55
|
what's the difference between .22 and .23?
|
|
0:11:59
|
Really the only that you could figure this out is by using the
|
|
0:12:01
|
MIB browser on Cisco's website or doing the
|
|
0:12:04
|
SNMP walk.
|
|
0:12:07
|
So if I have wireless configured, then I tell the network management
|
|
0:12:12
|
station to get .11 station config entry .22
|
|
0:12:16
|
I can look at what's the actual result of that
|
|
0:12:19
|
and based on that kind of correlate exactly what this
|
|
0:12:21
|
is referring to.
|
|
0:12:25
|
Some of these though you will see based on their name it's fairly obvious
|
|
0:12:28
|
to what they're referring to. If we go down to the interface entries
|
|
0:12:37
|
ifdescription that would be the description command that
|
|
0:12:40
|
we have on the interface. ifphysical address
|
|
0:12:43
|
this would be like the Mac address of our Ethernet.
|
|
0:12:47
|
ifinoctects would be how many bytes have I received
|
|
0:12:51
|
on the interface.
|
|
0:12:53
|
ifinUcast packets would be the number of unicast packets
|
|
0:12:57
|
that I received inbound on the interface.
|
|
0:13:02
|
So some of these like the outbound octets or the
|
|
0:13:04
|
outbound unicast packets we can use these in order to
|
|
0:13:07
|
correlate what is the utilization of the link.
|
|
0:13:11
|
So these are the actual variables that we see
|
|
0:13:15
|
when we look at options like the show interface
|
|
0:13:18
|
Fast Ethernet 0/0
|
|
0:13:22
|
It says the total number of packets input is 13328
|
|
0:13:29
|
Again, since Fast Ethernet 0/0 was SNMP interface index 1
|
|
0:13:35
|
it means that the actual MIB value ifinucast packets .1
|
|
0:13:46
|
would relate to this specific variable
|
|
0:13:54
|
because the routers keep in track of the regular packets
|
|
0:13:56
|
versus the broadcasts separately.
|
|
0:14:02
|
Where this one here this would be ifinoctects
|
|
0:14:07
|
the number of bytes that we're receiving in on the interface.
|
|
0:14:13
|
Now knowing the value of these on their own it's not
|
|
0:14:17
|
really going to tell us anything because although I know that
|
|
0:14:20
|
1 million 467 thousand 130 bytes have been
|
|
0:14:24
|
received on the interface, I don't really know how
|
|
0:14:27
|
long it's taken me to receive those.
|
|
0:14:31
|
So it's possible that I received them within the past 30 seconds
|
|
0:14:34
|
or maybe I've received them within the past 30 hours.
|
|
0:14:38
|
so unless I really have some sort of time index to correlate this against
|
|
0:14:43
|
then I can't figure out what is the utilization of the interface.
|
|
0:14:49
|
So the network management station itself when it is polling
|
|
0:14:52
|
the variable, it's going to poll that at set specific times
|
|
0:14:57
|
like let's say it's going to poll that every 60 seconds
|
|
0:15:00
|
so then it would know based on the difference between the
|
|
0:15:03
|
two samplings if I can look at the change of how many
|
|
0:15:07
|
bytes were received at time index 2
|
|
0:15:09
|
versus where they were originally at time index 1
|
|
0:15:13
|
I could then correlate what was the change over time
|
|
0:15:17
|
and essentially what's the utilization of the link.
|
|
0:15:22
|
So looking at these counters locally on the router, it doesn't
|
|
0:15:24
|
necessarily tell you what the utilization is in packets
|
|
0:15:27
|
per second or in bits per second
|
|
0:15:30
|
but you can use these counters correlated over
|
|
0:15:32
|
time in order to derive what that value is.
|
|
0:15:39
|
Now the reason that I'm mentioning this is that
|
|
0:15:42
|
with the RMON feature and the embedded event manager
|
|
0:15:46
|
we could use these MIB values locally in order to
|
|
0:15:50
|
track the utilization or to track the errors or the number
|
|
0:15:54
|
of outbound packets and then generate log messages based on that.
|
|
0:16:01
|
So if you don't already have a full blown management suite
|
|
0:16:03
|
in your network like HP OpenView, then you could use
|
|
0:16:07
|
just the local polling of the router's MIBs with RMON
|
|
0:16:11
|
process or the EEM process in order to give you some visibility
|
|
0:16:14
|
as to what's going on on the router's legs.
|
|
0:16:18
|
So the SNMP version 1 and version 2 configs
|
|
0:16:21
|
those are pretty straightforward whether we're looking at the polling
|
|
0:16:24
|
or the trapping. The SNMP V3 config it's a little more involved
|
|
0:16:29
|
because we have users, groups and views that we need
|
|
0:16:32
|
to define where the user is going to be the user name
|
|
0:16:37
|
of whoever's trying to do the polling. The group is going to be the
|
|
0:16:40
|
access privileges that they are assigned
|
|
0:16:43
|
and the view is going to define what other particular MIBs
|
|
0:16:48
|
that are visible to them.
|
|
0:16:50
|
So I could say that they're only allowed to see the interface MIBs
|
|
0:16:53
|
or only allowed to see the system MIBs that would be things like
|
|
0:16:57
|
the CPU utilization, the amount of memory being used
|
|
0:17:00
|
the size of the routing table, the size of the cef table etc.
|
|
0:17:04
|
Specifically SNMP V3 supports three different access methods
|
|
0:17:09
|
where we can have no authentication and no encryption
|
|
0:17:13
|
which is called no NoAuthNoPriv
|
|
0:17:17
|
Authentication without encryption which is AuthNoPriv
|
|
0:17:22
|
then authentication and encryption which is AuthPriv
|
|
0:17:29
|
So ideally if your network management station supports it
|
|
0:17:31
|
you would want to be using the last one because not only
|
|
0:17:35
|
is the message going to be authenticated, the payload is
|
|
0:17:38
|
actually encrypted, so if someone is doing a man in the middle attack
|
|
0:17:42
|
or some sort of sniffing, they're not going to be able to figure out
|
|
0:17:44
|
exactly what that particular SNMP packet is about.
|
|
0:17:49
|
But with version 1 and version 2, all of the information
|
|
0:17:52
|
is clear text including the community string which is
|
|
0:17:57
|
essentially your password. Now SNMP V3 does support
|
|
0:18:01
|
both trapping and informs so it has the unreliable traps
|
|
0:18:05
|
and the reliable informs
|
|
0:18:07
|
but the authentication is going to be different.
|
|
0:18:11
|
So in order to send the trap, we need to figure out what's the
|
|
0:18:13
|
particular user that that's going to be associated with, then the
|
|
0:18:18
|
network management station is going to have to have that
|
|
0:18:20
|
user name and authentication credentials configured.
|
|
0:18:27
|
So essentially, the only reason that you would not use SNMP V3
|
|
0:18:30
|
is if your NMS doesn't support it to begin with.
|
|
0:18:33
|
So here we have a couple of different syntax examples for
|
|
0:18:37
|
SNMP V3 where the view is saying I'm going to include any
|
|
0:18:42
|
Cisco specific MIBs, so again with this you would have to know
|
|
0:18:46
|
the structure of the MIB naming format where most of
|
|
0:18:50
|
this you're not going to be able to figure it out from the command line itself.
|
|
0:18:56
|
The group here it says the group name is my group
|
|
0:18:58
|
it's running version 3 and it has a read view
|
|
0:19:03
|
of the view called my view
|
|
0:19:06
|
which essentially means that they're allowed to have the
|
|
0:19:09
|
Cisco MIBs.
|
|
0:19:12
|
Then the user is being placed into the group saying we're doing
|
|
0:19:15
|
authentication with md5
|
|
0:19:17
|
and then we're doing encryption with single des.
|
|
0:19:24
|
So the view, the group, the user that would be for the polling.
|
|
0:19:27
|
For the trapping, we're specifying the host, but then also the specific
|
|
0:19:33
|
user and then what we are trapping, in this case, it's saying
|
|
0:19:36
|
trap CPU messages and syslog messages.
|
|
0:19:40
|
So I wouldn't really expect them to get to too detailed with
|
|
0:19:43
|
the SNMP configurations. Again, just like these other IP services
|
|
0:19:48
|
and system management techniques, you need to make sure you know where
|
|
0:19:51
|
this is located on the documentation.
|
|
0:19:54
|
Specifically in 12.4 T under the configuration guides, this is
|
|
0:19:58
|
part of network management.
|
|
0:20:01
|
Then this will be under
|
|
0:20:08
|
SNMP support
|
|
0:20:13
|
and under RMON support.
|
|
0:20:17
|
Now, SNMP is going to be for the trapping and polling
|
|
0:20:21
|
the next one here RMON, the remote monitoring,
|
|
0:20:26
|
is used generate an event that is based on any random
|
|
0:20:30
|
MIB value that we want to use.
|
|
0:20:35
|
The reason that you would want to use RMON versus
|
|
0:20:38
|
regular SNMP trapping is that when we look in the router's
|
|
0:20:41
|
command line and look at the SNMP server enable traps
|
|
0:20:49
|
enable traps
|
|
0:20:51
|
in general, these traps are not specific as the individual
|
|
0:20:56
|
MIBs, so it's going to tell us generic information about
|
|
0:21:00
|
BGP or 802.11 authentication which would be for wireless
|
|
0:21:07
|
but we can't drill down to the individual MIB level
|
|
0:21:11
|
and say I want to know what's the utilization of my Fast Ethernet 0/0
|
|
0:21:14
|
outbound or what's the number of CRC errors that
|
|
0:21:18
|
happened on GIG 0/1
|
|
0:21:23
|
In that particular case where you want an event driven
|
|
0:21:26
|
alarm to occur or actually the other way around, it's an alarm
|
|
0:21:33
|
driven event, then this is what RMON is going to be used for.
|
|
0:21:39
|
So we're going to define two separate things.
|
|
0:21:41
|
The alarm is the condition that we are tracking, so
|
|
0:21:44
|
essentially it's going to be the particular MIB that
|
|
0:21:47
|
we want to sample and the event is what's triggered
|
|
0:21:51
|
once the alarm event happens.
|
|
0:21:55
|
Typically the event is going to be generating either a syslog
|
|
0:21:57
|
message or an SNMP trap. We could also use the
|
|
0:22:01
|
embedded event manager to look at the RMON event
|
|
0:22:05
|
and then do some other specific behavior like
|
|
0:22:08
|
send an e-mail message or run a TCL script that's going to
|
|
0:22:12
|
send us a text message, basically anything that you could program
|
|
0:22:16
|
in TCL, you'd be able to tie it in with RMON or SNMP
|
|
0:22:19
|
or a lot of these other management configurations.
|
|
0:22:24
|
Now the typical confusing point about RMON is the difference between
|
|
0:22:28
|
the delta sampling and the absolute sampling
|
|
0:22:32
|
of the MIB.
|
|
0:22:34
|
So the RMON alarm is going to figure out what is the particular
|
|
0:22:37
|
variable that we want to sample which again is called the
|
|
0:22:40
|
MIB and how do we want to sample this, do I want to look at
|
|
0:22:44
|
the change of the variable over time or do I want to
|
|
0:22:48
|
look at what the specific value of the MIB is right now.
|
|
0:22:53
|
With the delta sampling, that's going to be tracking what is the
|
|
0:22:57
|
MIB when I sample it at time index A and then again
|
|
0:23:01
|
when I sample it at time index B
|
|
0:23:03
|
where maybe A is right now and then B is going to be
|
|
0:23:06
|
60 seconds from now.
|
|
0:23:09
|
So if I were to look at what is the number of total packets that
|
|
0:23:13
|
were sent out the interface and I see right now it's been a
|
|
0:23:16
|
100 packets, then in 60 seconds it's a 160 packets
|
|
0:23:23
|
I know that the value has changed 60 packets over
|
|
0:23:26
|
that minute, so essentially the utilization would average
|
|
0:23:32
|
out to one packet per second. Now that would be a very simplistic
|
|
0:23:37
|
example because ideally you're not going to have one packet per
|
|
0:23:39
|
second utilization, but the idea is that with RMON you can define
|
|
0:23:43
|
whatever the MIB is, how often you're going to sample it
|
|
0:23:47
|
then based on the change of the value with the delta sampling
|
|
0:23:52
|
you can configure it to trigger the event like I want a log
|
|
0:23:56
|
message generated if my utilization goes over 75 percent.
|
|
0:24:03
|
Now the key with the delta sampling is that you're only going
|
|
0:24:06
|
to use this for the MIBs that values only increase and never
|
|
0:24:11
|
decrease, so if we were to look at the counter of the
|
|
0:24:16
|
number of packets that are coming in the interface
|
|
0:24:27
|
so we're looking at the number of packets that have been received
|
|
0:24:29
|
inbound over time.
|
|
0:24:32
|
Initially when the router boots or when the interface counters are
|
|
0:24:35
|
cleared, the packet counter is going to start at zero.
|
|
0:24:38
|
Over time, this is going to go up and up and up
|
|
0:24:41
|
but it's never going to go down
|
|
0:24:43
|
because the packet counter is accumulative for the total
|
|
0:24:48
|
number of packets that have come in the interface.
|
|
0:24:53
|
So this means that if I'm sampling this over time and
|
|
0:24:55
|
I'll say I'll check it at minute 1 then minute 2, 3, 4 etc.
|
|
0:25:01
|
when I look at these actual values, it's not going to help me
|
|
0:25:05
|
if I look at sample number 4 and it's says that there were
|
|
0:25:08
|
10 thousand packets that came in.
|
|
0:25:13
|
The reason why that doesn't help me is that I don't know
|
|
0:25:16
|
how long that has accumulated over.
|
|
0:25:19
|
Now at sample number 3 did that originally start at 2000 packets?
|
|
0:25:24
|
Or did it start at 9000 packets?
|
|
0:25:28
|
So depending on where the sampling was at before
|
|
0:25:30
|
that's going to change what was really the utilization over time.
|
|
0:25:35
|
So in the case of the delta sampling I'm going to look at the difference
|
|
0:25:39
|
between those two samples. I want to know exactly what was
|
|
0:25:42
|
the value at sampling A, what was the value at sampling B
|
|
0:25:47
|
look at the difference between them. Based on this, a change of
|
|
0:25:52
|
1000 over 60 seconds, I could then derive what's the average
|
|
0:25:58
|
utilization over time.
|
|
0:26:02
|
So again, for any value that is only increasing and not decreasing
|
|
0:26:08
|
that's what the delta sampling is going to be for.
|
|
0:26:13
|
For variables that go up and down over time like the CPU utilization
|
|
0:26:18
|
the amount of memory that's being used, the size of the routing
|
|
0:26:21
|
table, those would be MIBs that you want to sample
|
|
0:26:24
|
as absolute, so what's the exact value of the MIB
|
|
0:26:29
|
right now? Is my CPU at 90 percent or is it at 30 percent?
|
|
0:26:39
|
Now the problem with this the delta versus the absolute
|
|
0:26:42
|
there's no error checking in the parser. It -- going to tell you
|
|
0:26:46
|
it doesn't make sense to use this as a delta sampling or doesn't make
|
|
0:26:49
|
sense to use this as absolute.
|
|
0:26:52
|
So again, you always need to think about first is the MIB
|
|
0:26:55
|
going up and down? Or is it only going up?
|
|
0:26:58
|
If it's only going up, we want to sample it delta
|
|
0:27:02
|
if it goes up and down, we want to sample it as absolute.
|
|
0:27:05
|
So configuration wise for this again, the issue with RMON
|
|
0:27:09
|
is similar to a lot of the SNMP configs is that you would need to know
|
|
0:27:13
|
what is the MIB to begin with.
|
|
0:27:16
|
So unless I have the exact OID which is the value in that
|
|
0:27:20
|
dotted decimal format or essentially the ascii string
|
|
0:27:25
|
which is like ifinoctects, then it's not really going to help me
|
|
0:27:30
|
figure out what is the particular RMON config I need.
|
|
0:27:36
|
So let's on Router 5 I want to sample how many packets are going
|
|
0:27:40
|
out the interface on a 60 second average.
|
|
0:27:44
|
So I'm looking at the outbound packet per second utilization
|
|
0:27:48
|
over a one-minute average.
|
|
0:27:51
|
So again, if we look at the show SNMP MIB
|
|
0:27:58
|
and I'll say show snmp mib | b iF
|
|
0:28:05
|
or is if capital I? Let me try that in a different router.
|
|
0:28:10
|
Let's say on Router 4 Now to do this
|
|
0:28:13
|
to look at the show snmp mibs
|
|
0:28:15
|
you need to make sure that the SNMP process is
|
|
0:28:17
|
on first, so either you need to turn on trapping or polling
|
|
0:28:22
|
that's going to start the process.
|
|
0:28:26
|
So on Router 4 I'll say snmp-server enable traps bgp
|
|
0:28:33
|
Ok, it doesn't really matter what I say here as long as the process is on.
|
|
0:28:37
|
Now I can look at the show snmp mibs
|
|
0:28:43
|
From here I want to see what are the interface MIBs
|
|
0:28:49
|
and what I want is the outbound number of unicast packets
|
|
0:28:55
|
which is this one
|
|
0:28:58
|
ifoutucast packets
|
|
0:29:01
|
Now I need to correlate this against what is the interface's
|
|
0:29:04
|
index number.
|
|
0:29:06
|
So on Router 4, let's assume that I want to
|
|
0:29:09
|
track how many packets are going out this way.
|
|
0:29:15
|
So the link to BB1 or to BB3
|
|
0:29:17
|
which is Fast Ethernet 0/0
|
|
0:29:24
|
So now I know what is the particular MIB which is the ifoutucast packets
|
|
0:29:30
|
I need to know now what specific interface index is Fast Ethernet 0/0
|
|
0:29:38
|
If I show snmp mib ifmib ifindex
|
|
0:29:46
|
Fast Ethernet 0/0 is interface index 1
|
|
0:29:52
|
Now the potential problem with these interface index numbers
|
|
0:29:54
|
is that they will change over time as the router is adding or
|
|
0:29:59
|
deleting interfaces like loopbacks have index numbers, sub interfaces
|
|
0:30:04
|
have index numbers, null, zero, SSL, VPN, the Nat virtual interface
|
|
0:30:10
|
all of those links are going to have interface index numbers.
|
|
0:30:15
|
So if I want to make sure that the Ethernet is always staying
|
|
0:30:18
|
interface index 1 in global config, I would say snmp
|
|
0:30:28
|
snmp server ifindex persist
|
|
0:30:33
|
This says that if I reload or some new interface comes on
|
|
0:30:38
|
the interface index numbers are not going to change.
|
|
0:30:41
|
So I now know that Fast Ethernet 0/0 is always going to be index number 1
|
|
0:30:49
|
This now means that my previous MIB ifoutucast packets if I want this
|
|
0:30:55
|
to correspond to Fast Ethernet 0/0 it's going to be this .1
|
|
0:31:02
|
so this full string, this is the MIB value now.
|
|
0:31:10
|
Now I'm going to configure my RMON alarm. This is actually going to
|
|
0:31:14
|
track the MIB. I'll say rmon alarm
|
|
0:31:18
|
give it a number. I'll say this is alarm 1
|
|
0:31:21
|
that's the particular MIB.
|
|
0:31:25
|
I'm going to sample this every 60 seconds and I want to look at the
|
|
0:31:29
|
change over time
|
|
0:31:32
|
because again, this type of counter it's only going up.
|
|
0:31:35
|
If it was going up and down like the CPU utilization
|
|
0:31:39
|
the amount of memory being utilized, those would be absolute
|
|
0:31:43
|
samplings, but this is delta because it's only going up.
|
|
0:31:47
|
So I'm checking it every 60 seconds and looking at the difference
|
|
0:31:50
|
between my sample now versus 60 seconds ago.
|
|
0:31:59
|
Now I want to know what's the value that it needs to change
|
|
0:32:03
|
before I generate my event.
|
|
0:32:07
|
So let's 10 thousand packets per minute.
|
|
0:32:14
|
If I go over 10 thousand packets per minute, I'm going to
|
|
0:32:16
|
generate event number 2
|
|
0:32:20
|
I could also specify a falling threshold that if it then goes
|
|
0:32:25
|
below a value, let's say if it goes below one, so
|
|
0:32:29
|
it's almost no utilization, then I'll generate event number 3
|
|
0:32:37
|
So now I need to specify what are those particular events
|
|
0:32:39
|
number two and number three.
|
|
0:32:42
|
This is RMON event number 2
|
|
0:32:45
|
I want to generate a log
|
|
0:32:47
|
that specifically says interface fa0/0 is over 10000 packets per minute
|
|
0:33:08
|
then rmon event 3 says generate a log description int f0/0 no utilization
|
|
0:33:24
|
so this essentially means that they're generating syslog messages
|
|
0:33:30
|
where we should see after 60 seconds that one of these
|
|
0:33:35
|
events is going to be triggered.
|
|
0:33:39
|
So if I wanted to speed this up, I could lower what the sampling interval is
|
|
0:33:43
|
so I could change it from 60 seconds maybe to every
|
|
0:33:46
|
10 seconds
|
|
0:33:50
|
which is the alarm, so let's say the alarm is sampled every
|
|
0:33:55
|
10 seconds
|
|
0:33:59
|
But of course, the more often you're sampling, the more utilization
|
|
0:34:03
|
that the RMON and the SNMP process is going to take.
|
|
0:34:12
|
So right now, it's falling below value 1 because essentially
|
|
0:34:18
|
there's no utilization on the interface.
|
|
0:34:21
|
Now if I were to start to send packets out, let's say I'll ping
|
|
0:34:27
|
BB1's address 204.12.28.254
|
|
0:34:34
|
give it a high repeat count and say the timeout is zero.
|
|
0:34:40
|
Now I may not actually be able to hit 10 thousand packets
|
|
0:34:43
|
for a 10-second sample
|
|
0:34:47
|
because I'm generating these locally on the router, but if I
|
|
0:34:50
|
were to reach what the threshold is, then I should see
|
|
0:34:52
|
that it's going to generate that new syslog message.
|
|
0:35:05
|
So again, the big issue with this is to understand do I want to do
|
|
0:35:10
|
this sampling as a delta or do I want to do it as absolute
|
|
0:35:13
|
then we would have to know what is the exact MIB value.
|
|
0:35:18
|
So essentially, unless they're going to give you what the
|
|
0:35:21
|
value is, there's not many of these that you can figure out
|
|
0:35:24
|
what it should be referring to.
|
|
0:35:28
|
In reality to figure these out again you would have to do
|
|
0:35:30
|
either the snmp walk which is just to ask the router
|
|
0:35:34
|
what are all the possible values
|
|
0:35:36
|
or there is -- I believe it's called the SNMP MIB browser
|
|
0:35:46
|
let's say site cisco.com
|
|
0:35:50
|
the MIB object navigator.
|
|
0:36:00
|
Browse the object tree
|
|
0:36:06
|
so this is the hierarchy where iso is 1 so that would be 1.1
|
|
0:36:16
|
and you could go all the way through this, let's say
|
|
0:36:20
|
no, we could only say two
|
|
0:36:22
|
so you could either browse it manually like this to figure out
|
|
0:36:25
|
what exactly this object means or you could do the SNMP walk.
|
|
0:36:30
|
But the problem is, within the scope of the lab exam
|
|
0:36:32
|
you're not going to be able to get to this particular page.
|
