categorized into eight different groups, totaling
114 managed objects. More groups were added to define MIB-II,
which now replaces MIB-I. All managed objects in the SNMP
environment are arranged in a hierarchical or tree structure.
The leaf objects of the tree, which are the elements that
appear at the bottom of the diagram, are the actual managed
objects. Each managed object represents some resource, activity
or related information that is to be managed. A unique object
identifier, which is a number in dot notation, identifies each
managed object. Each object identifier is described using
abstract syntax notation (ASN.1). SNMP uses these object
identifiers to identify the MIB variables to retrieve or
modify. Objects that are in the public domain are described in
MIBs introduced in Request for Comments (RFCs). They are
readily accessible at: http://www.ietf.org All vendors are
encouraged to make their MIB definitions known. Once an
assigned enterprise value has been given, the vendor is
responsible for creating and maintaining sub-trees.
Content 6.2 Network Management 6.2.6 SNMP
protocol The agent is a software function embedded in most
networked devices, such as routers, switches, managed hubs,
printers, and servers. It is responsible for processing SNMP
requests from the manager. It is also responsible for the
execution of routines that maintain variables as defined in the
various supported MIBs. Interaction between the manager and the
agent is facilitated by the Simple Network Management Protocol
(SNMP). The term simple comes from the restricted number of
message types that are part of the initial protocol
specification. The strategy was designed to make it easier for
developers to build management capabilities into network
devices. The initial protocol specification is referred to as
SNMPv1 (version 1). There are three types of SNMP messages
issued on behalf of an NMS. They are GetRequest, GetNextRequest
and SetRequest. All three messages are acknowledged by the
agent in the form of a GetResponse message. An agent may issue
a Trap message in response to an event that affects the MIB and
the underlying resources. The development of SNMPv2c addressed
limitations in SNMPv1. The most noticeable enhancements were
the introduction of the GetBulkRequest message type and the
addition of 64-bit counters to the MIB. Retrieving information
with GetRequest and GetNextRequest was an inefficient method of
collecting information. Only one variable at a time could be
solicited with SNMPv1. The GetBulkRequest addresses this
weakness by receiving more information with a single request.
Secondly, the 64-bit counters addressed the issue of counters
rolling over too quickly, especially with higher speed links
like Gigabit Ethernet. The management entity is also referred
to as the manager or network management station (NMS). It is
responsible for soliciting information from the agent. The
solicitations are based on very specific requests. The manager
processes the retrieved information in a number of ways. The
retrieved information can be logged for later analysis,
displayed using a graphing utility, or compared with
preconfigured values to test if a particular condition has been
met. Not all manager functions are based on data retrieval.
There is also the ability to issue changes of a value in the
managed device. This feature enables an administrator to
configure a managed device using SNMP. The interaction between
the manager and the managed device does introduce traffic to
the network. Caution should be taken when introducing managers
on to the network. Aggressive monitoring strategies can
negatively affect network performance. Bandwidth utilizations
will go up, which may be an issue for WAN environments. Also,
monitoring has a performance impact on the devices being
monitored, since they are required to process the manager
requests. This processing should not take precedence over
production services. A general rule is that a minimum amount of
information should be polled as infrequently as possible.
Determine which devices and links are most critical and what
type of data is required. SNMP uses UDP as a transport
protocol. Since UDP is connectionless and unreliable, it is
possible for SNMP to lose messages. SNMP itself has no
provision for guarantee of delivery, so it is up to the
application using SNMP to cope with lost messages. Each SNMP
message contains a cleartext string, called a community string.
The community string is used like a password to restrict access
to managed devices. SNMPv3 has addressed the security concerns
raised by tranmitting the community string in cleartext. An
example of what the SNMPv2c message looks like is illustrated
in Figure . A detailed presentation of the protocol can be
found in the Internet standard RFC1905. The fact that the
community string is cleartext is no surprise to anyone who has
studied the Internet Protocol (IP) protocol suite. All fields
specified in the protocol suite are cleartext, except for
security authentication and encryption specifications. The
community string was essentially a security placeholder until
the SNMPv2 working group could ratify security mechanisms. The
efforts were referred to the SNMPv3 working group. All
SNMP-based management applications need to be configured to use
the appropriate community strings. Some organizations
frequently change the community string values to reduce the
risk of malicious activity from the unauthorized use of the
SNMP service. In spite of the weakness associated with
community-based authentication, management strategies are still
based on SNMPv1. Cisco devices do support SNMPv3 message types
and the increased security capabilities, but most management
software applications do not support SNMPv3. SNMPv3 supports
the concurrent existence of multiple security models.
Content 6.2 Network Management 6.2.7 Configuring
SNMP In order to have the NMS communicate with networked
devices, the devices must have SNMP enabled and the SNMP
community strings configured. These devices are configured
using the command line syntax described in the following
paragraphs. More than one read-only string is supported. The
default on most systems for this community string is public. It
is not advisable to use the default value in an enterprise
network. To set the read-only community string used by the
agent, use the following command: Router(config)#snmp-server
community string ro - String –
Community string that acts like a password and permits access
to the SNMP protocol
- ro – (Optional) Specifies
read-only access. Authorized management stations are only able
to retrieve MIB objects.
More than one read-write
string is supported. All SNMP objects are available for write
access. The default on most systems for this community string
is private. It is not advisable to use this value in an
enterprise network. To set the read-write community string used
by the agent, use the following command:
Router(config)#snmp-server community string
rw - rw – (Optional) Specifies read-write
access. Authorized management stations are able to both
retrieve and modify MIB objects
There are several
strings that can be used to specify location of the managed
device and the main system contact for the device.
Router(config)#snmp-server location text
Router(config)#snmp-server contact text
- text – String that describes the system
location information
These values are stored in the
MIB objects sysLocation and sysContact. Web
Links Configuring SNMP http://www.cisco.com/en/US/products/hw/ switches/ps628