- [Narrator] One of the ways that we can be notified
about certain events or issues within our network
is through SNMP, Simple Network Management Protocol.
This allows us to monitor our managed devices
such as routers, switches, servers, and more.
Any device that is SNMP capable
can be configured so that we can collect information
and monitor those from a single centralized point.
SNMP allows us to do several things.
We can detect issues and faults early
through alerts and notifications.
We can monitor traffic through a device
both inbound and outbound
and we can even remotely configure
and control devices that are compatible.
A complete SNMP system includes
both an SNMP manager and an SNMP agent.
An SNMP manager is the piece
that will poll our network devices
in order to obtain information and alerts.
Most typically, the SNMP manager is a software application
that runs in a central location on our network.
Depending on the features of the SNMP manager,
some even have the ability to send email
or text message alerts to specified contacts.
Anytime there is a malfunction in the network,
more simplified SNMP managers will only poll devices
and compile that information
into a centralized logging database.
SNMP managers will send out SNMP polls
to devices in order to receive data
and this polling happens regularly
over UDP port 161 by default.
An SNMP agent is a process running on a monitored device.
The devices themselves will gather various types of data
and store those in their local database.
Agents can also send unsolicited messages called traps.
These would be sent out by the agent without being polled.
So this is a way to make sure
that the manager receives information in the circumstances
that there is a critical event.
If we have something disastrous happen on a monitor device,
we don't want to have to wait for the polling to happen
before that's reported.
So, traps are able to take care of that concern.
By default, agents send system and device information
to the manager using UDP port 162.
We mentioned the fact that network devices
will gather different types of data
about themselves and store that in a local database.
In a Cisco device, this database is called
the Management Information Base or the MIB.
The MIB is a hierarchical structure that forms a tree
and the MIB contains object identifiers or OIDs.
Each OID represents a variable that can be read
or set through SNMP.
So for example, there may be an OID in the MIB
related to the number of frames
that have transited a particular interface.
The MIB could reference this OID
and send that information via SNMP
over to the SNMP manager if it's requested.
In order to see the MIB data,
an SNMP manager would have to send a poll to the agent
and the poll would contain the OID
of the specific variable that's being requested
and that's going to help the MIB
know which information to respond with.
When the manager sends an SNMP poll,
there are a few main types of requests that can be made.
A get-request lets the device know
that a specific MIB variable is needed
for a single OID.
A get-next-request asks for additional information
after an initial get-request.
Specifically, it wants the subsequent value
following the request.
A get-bulk-request asks for an entire table of values
from the MIB in a bulk manner.
And a set-request can be used for configuration needs
in order to set a MIB variable to a particular value.
From the agent side,
there are responses to each of these requests
called get-responses.
These can be unsolicited responses
as we've mentioned so that we don't have to wait
for our next polling cycle to report issues
and those alerts can be set in a couple of ways.
They can be sent as a normal SNMP trap,
meaning that the data is sent to the manager
without requiring the manager
to acknowledge receipt of the message
or they can be sent as an inform-request
wherein the manager is required
to acknowledge receipt of the message
by echoing back the request to the agent.
At the time of this recording,
there are three generations of SNMP.
SNMP version one is defined in RFC 1157
and that uses a very simple request and trap message format.
There is no option for the inform-request,
in this original version so the manager can't provide proof
of message receipt.
The security measure used by SNMP version one
is called a community string
and this is just a simple text string password.
When a manager communicates with an agent,
the community string is sent in clear text
as a part of the request which creates a security problem
and the potential for the string to be compromised.
The final iteration of SNMP version two
is often referred to as SNMP version two c.
The main advance here is the addition
of the inform-command.
So rather than using only simple traps,
we have the option to use the inform.
Just as with version one,
version two c has no encryption capabilities
and use as a simple clear text community string
for authentication purposes.
The most recent and preferred version
is SNMP version three,
the primary enhancement being stronger security.
This introduces something called an engine ID.
This is used by SNMP version three entities
to uniquely identify themselves
and to generate a key four message authentication.
So engine IDs are unique
to each SNMP version three device in a network.
SNMP version three adds authentication
through a special key based on the engine ID
and that can be based on either the HMACMD five algorithm
or the HMACSHA algorithm.
Privacy is also added through encryption using
either DES, triple DES, or AES.
There are three security levels
that you can configure with SNMP version three.
You can have noaauthnopriv,
which means none of the security features
of version three are enabled.
You don't have cryptographic hashing or encryption.
So with this, you're essentially using
SNMP version one or two.
Authnopriv means that a cryptographic hash is used
to secure authentication credentials,
but the data is not encrypted for privacy.
And the final level is authprive,
which uses the full security suite
of available security features, both hashing and encryption.
In our upcoming videos,
we'll take a look at how we can configure
both SNMP version two and version three.