WTCS.ORG |
What is SNMP?
Executive Summary Brief Discussion Paper Standards (RFC) Page
Official SNMP FAQ (Frequently Asked Questions)
OID List Object Identifiers Registry Other Links
SNMP lets TCP/IP-based network management clients use a TCP/IP-based internetwork to exchange information about the configuration and status of nodes. The information available is defined by a set of managed objects referred to as the SNMP Management Information Base (MIB). The subset of managed objects that make up the TCP/IP portion of the MIB is maintained by each TCP/IP node. SNMP can also generates trap messages used to report significant TCP/IP events asynchronously to interested clients.
SNMP applications run in a network management station (NMS) and issue queries to gather information about the status, configuration, and performance of external network devices (called network elements in SNMP terminology). For example, HP Openview software is an example of a network management station, and a Cisco 4500 Router with its SNMP agent enabled could be considered an example of a network element. Shown below is a (very) basic diagram illustrating this concept.
SNMP agents run in network elements (for example, in the Cisco 4500 router) and respond to NMS queries (GETs) (for example, from HP Openview, or MRTG). In addition, agents send unsolicited reports (called traps) back to the NMS when certain network activity occurs. These traps can spawn events such as email alerts, automatic pages or network server parameter modifications.
For security reasons, the SNMP agent validates each request from an SNMP manager before responding to the request, by verifying that the manager belongs to an SNMP community with access privileges to the agent.
An SNMP community is a logical relationship between an SNMP agent and one or more SNMP managers. The community has a name, and all members of a community have the same access privileges: either read-only (members can view configuration and performance information) or read-write (members can view configuration and performance information, and also change the configuration).
All SNMP message exchanges consist of a community name and a data field, which contains the SNMP operation and its associated operands. It is embedded within a UDP Datagram, inside an IP Packet within an Ethernet frame (see below).
You can configure the SNMP agent to receive requests and send responses only from managers that are members of a known community. If the agent knows the community name in the SNMP message and knows that the manager generating the request is a member of that community, it considers the message to be authentic and gives it the access allowed for members of that community. Thus, the SNMP community prevents unauthorized managers from viewing or changing the configuration of a router or other SNMP managable device.
In summary, the SNMP Management program performs the following operations:
Simple Network Management Protocol (SNMP) is an
application protocol offering network management services in the Internet Protocol
suite. SNMP is defined in several RFCs published beginning in 1990. During the last
few years SNMP has been adopted by numerous vendors of network equipment as a main
or secondary management interface.
SNMP defines a client/server relationship. The client program (called the network
manager) makes virtual connections to a server program (called the SNMP agent) executing
on a remote network device. The data base controlled by the SNMP agent is referred to as
the SNMP Management Information Base (MIB), and is a standard set of statistical and
control values. SNMP additionally allows the extension of these standard values with
values specific to a particular agent through the use of private MIBs.
Directives, issued by the network manager client to an SNMP agent, consist of the
identifiers of SNMP variables (referred to as MIB object identifiers (OID) or MIB
variables) along with instructions to either get the value for the identifier, or set the
identifier to a new value.
Through the use of private MIB variables (OIDs), SNMP agents can be tailored for a myriad
of specific devices, such as network bridges, gateways, and routers. The definitions of
MIB variables supported by a particular agent are incorporated in descriptor files,
written in Abstract Syntax Notation (ASN.1) format, made available to network management
client programs so that they can become aware of these MIB variables and their usage.
The OID naming scheme is governed by the Internet Engineering Task Force (IETF). The IETF grants authority for parts of the name space to individual organizations such as Microsoft, Novell or CIsco. For example, Microsoft has the authority to assign the OIDs that can be derived by branching downward from the node in the MIB name tree that starts with 1.3.6.1.4.1.311. Novell's OIDs branch down from 1.3.6.1.4.1.23. and Cisco's OIDs branch down from 1.3.6.1.4.1.9. You can see this structure in the diagram below.
SNMP uses the OID to identify objects on each network element (i.e. router/computer) that can be managed using SNMP. For example, in order to get information about the free disk space on a Windows NT Server, the Network Management Station makes a request to the network element using the fully qualified OID that represents the variable containing the number representing the free disk space. In Microsoft's world, that would be .1.3.6.1.4.1.311.1.1.3.1.1.5.1.4.0. or something very similar, depending how the MIB for that object was created (i.e. perfm.bat). A Cisco 4500 router's CPU usage is accessed by targeting the OID .1.3.6.1.4.1.9.2.1.56.0. Note how bolded text matches the tree above!
For a list of Object Identifiers (OIDs), click here. A great Object Identifiers Registry Page is here. You can apply for your own Private Enterprise Number (at the Internet Assigned Numbers Authority-IANA) here.
SNMP has several strengths. Its biggest strength
is arguably its widespread popularity. SNMP agents are available for network devices
ranging from computers, to bridges, to modems, to printers. The fact that SNMP exists with
such support gives considerable credence to its reason for existence; SNMP has become
interoperable.
Additionally, SNMP is a flexible and extensible management protocol. Because SNMP agents
can be extended to cover device specific data, and because a clear mechanism exists for
upgrading network management client programs to interface with special agent capabilities
(through the use of ASN.1 files), SNMP can take on numerous jobs specific to device
classes such as printers, routers, and bridges, thereby providing a standard mechanism of
network control and monitoring.
Several weaknesses of SNMP can be identified. Despite its name, (i.e. "Simple"
Network Management Protocol), SNMP is a highly complicated protocol to implement. By the
admission of its designers, a more apt name might be "Moderate Network Management
Protocol", although even this seems generous in light of SNMP's highly complicated
encoding rules. Also, SNMP is not a particularly efficient protocol. Bandwidth is wasted
with needless information, such as the SNMP version (transmitted in every SNMP message)
and multiple length and data descriptors scattered throughout each message. The way that
SNMP variables are identified (as byte strings, where each byte corresponds to a
particular node in the MIB database) leads to needlessly large data handles that consume
substantial parts of each SNMP message.
The above complaints, while fair, cannot reasonably be used to detract from the
aforementioned strengths of SNMP. While complicated encoding rules frustrate programmers
who must deal with them, it is easily argued that end users of the protocol aren't
concerned with the complexity of the algorithms that decode their data. As for complaints
about SNMP efficiency, it has been shown to work well enough, given the nature of network
administration activities.
One criticism of SNMP cannot be dismissed so
easily: SNMP has generally lacked focus on why it is useful. Neither the governing RFC's
nor other explanatory references describe why SNMP is better than more traditional network
management tools such as "ping", "rsh", and "netstat".
Consider: the design of SNMP agents is difficult. Equally difficult is the administration
of these many agents and their managers, which typically entail individual configuration
and possible maintenance. Why is SNMP all that much better than, say, telnet protocol?
Does the elaborateness of SNMP justify its usefulness? Or can simple telnet driver
programs, which periodically log into network devices to gather statistics and apply
control, achieve the same end?
In part, this criticism has been aggravated by SNMP management program vendors, who create
systems where SNMP is merely an alternative to remote shells rather than a new way of
analyzing and managing networks. Many SNMP vendors seem to see network management
activities in terms of GUI's with point and click controls instead of automated systems
for configuring devices, gathering data, and conduct corrective procedures on large
networks.
Faced with the above criticism of SNMP, one tendency is to admit that there are alternatives to SNMP, but these alternatives are supplanted by the general popularity and interoperability of SNMP. This tendency should be rejected in favor of a much better argument for SNMP; a point made by the remainder of this paper is that there ARE NO current alternatives to SNMP, at least for certain types of network administrative functions.
Check out the Literature Page for more Web Pages, tutorials, white papers and presentations about SNMP, TCP/IP, UDP and Network Management in general.
While the protocol itself may be less than perfect, SNMP provides
the ONLY way to efficiently manage large networks.
To return the the main page, click
the 
logo!