Sun SNMP Management Agent
Administration Guide for Sun Supported Servers | 
   |
| C H A P T E R 5 |
This chapter provides a brief introduction to the essential features of the Simple Network Management Protocol (SNMP). This chapter addresses the issues that are of particular relevance to the supported platforms. Refer to “Supported Platforms” in the Sun SNMP Management Agent Release Notes for a listing of supported platforms for Sun SNMP Management Agent software.
SNMP is an open Internet standard for managing network systems. It is defined, in common with other Internet standards, by a number of Requests for Comments (RFCs) published by the Internet Engineering Task Force (IETF).
There are three versions of SNMP that define approved standards:
SNMPv1 was first defined in 1988. SNMPv2 was introduced in 1993 and attempted to address some of the shortcomings of SNMPv1 by adding further protocol operations and data types and providing security. Limitations in the security model led to what is now accepted as the SNMPv2c standard, which dropped the new security-based features. Experimental versions, known as SNMPv2usec and SNMPv2*, also appeared at this time, but these have not been widely adopted and remain experimental.
SNMPv3, introduced in 1999, defines the SNMP management framework supporting pluggable components, including security.
For further information about these standards, refer to the following RFCs at the IETF web site (http://www.ietf.org/rfc.html):
SNMP is a network protocol that allows devices to be managed remotely by a network management station (NMS), also commonly called a manager.
To be managed, a device must have an SNMP agent associated with it. The purpose of the agent is to:
Receive requests for data representing the state of the device from the manager, and provide an appropriate response.
Accept data from the manager to enable control of the device state.
Generate SNMP traps, which are unsolicited messages sent to one or more selected mangers to signal significant events relating to the device.
To manage and monitor a device, its characteristics must be represented using a format known to both the agent and the manager. These characteristics can represent physical properties such as fan speeds, or services such as routing tables. The data structure defining these characteristics is known as a management information base (MIB). This data model is typically organized into tables, but can also include simple values. An example of the former is a routing table, and an example of the latter is a time stamp indicating the time at which the agent was started.
The MIB is a definition for a virtual data store accessible through SNMP. The content is accessible from the manager using get and set operations as follows:
In response to a get operation, the agent provides data, either maintained locally or directly from the managed device.
In response to a set operation, the agent typically performs some action affecting the state of either itself or the managed device.
To enable an NMS to manage a device through its agent, the MIB corresponding to the data presented by the agent must be loaded into the manager. The mechanism for doing this varies depending on the implementation of the network management software. This gives the manager the information required to address and interpret correctly the data model presented by the agent.
Note - MIBs can reference definitions in other MIBs, so to use a given MIB, it might be necessary to load others. |
To address the content of this virtual data store, the MIB is defined in terms of object identifiers (OIDs). An OID consists of an hierarchically arranged sequence of integers that defines a unique name space. Each assigned integer has an associated text name. For example, the OID 1.3.6.1 corresponds to the OID name iso.org.dod.internet and 1.3.6.1.4 corresponds to the OID name iso.org.dod.internet.private.
The numeric form is used within SNMP protocol transactions, whereas the text form is used in user interfaces to aid readability. Objects represented by such OIDs are commonly referred to by the last component of their name as a shorthand form. To avoid confusion arising from this convention, it is normal to apply a MIB-specific prefix, such as sunPlat, to all object names defined therein, thereby making all such identifiers globally unique.
Much of the data content defined by MIBs is in tabular form, and organized as entries consisting of a sequence of objects, each with its own OID. For example, a table of power supply characteristics could consist of a number of rows, one per power supply, with each row containing columns corresponding to voltages, currents, and temperature, for example.
The addressing of the rows within the table can be as follows:
Simple, single-dimensional index (a row number within the table, for example 6)
More complex, multidimensional, instance specifier such as an IP address and port number (for instance, 127.0.0.1, 1234)
Each table definition within the MIB has an INDEX clause that defines which instance specifiers to use to select a given entry. In either case, the objects used to define the index to the required row must themselves be defined within the MIB. Thus, a table with a simple, single-dimensional index typically has an index column that is referenced by the table’s INDEX clause. A specific data item within a table is then addressed by specifying the OID giving its columnar prefix.For example, myFanTable.myFanEntry.myCurrentFanSpeed with a suffix instance specifier (for instance, 127.0.0.1.1234 from the previous example) gives myFanTable.myFanEntry.myCurrentFanSpeed.127.0.0.1.1234.
The SMI defining the MIB syntax provides an important capability for extending tables to add additional entries, effectively by adding extra columns to the table. This is achieved by defining a table with an INDEX clause that is a duplicate of the INDEX clause of the table being extended.
It is also possible to define MIB tables that are indexed not by objects contained within them, but by objects imported from other tables, potentially defined in other MIBs. This construct, effectively, enables columns to be added to an existing table.
Note - The SUN-PLATFORM-MIB makes extensive use of this mechanism to extend tables defined in the ENTITY-MIB (see Chapter 7). |
All addressable objects defined in the MIB have associated maximum access rights, for instance, read-only or read-write. These determine the maximum access the agent can support, and can be used by the manager to restrict the operations it permits the operator to attempt. The agent is able to apply lower access rights as required, that is, it is able to refuse writes to objects that are considered read-write. This refusal can be on the basis of:
How applicable the operation is to the object being addressed (for example, where an object defined by the MIB represents a state machine for which only certain transactions are legal).
Security restrictions that limit certain operations to restricted sets of managers.
All objects in ENTITY-MIB and SUN-PLATFORM-MIB are implemented by this agent as read-only.
The mechanism used to communicate security access rights in SMMPv1 is that of community strings. These are simply text strings, such as private and public, that are passed with each SNMP data request. As SNMPv1 and SNMPv2 requests are not encrypted, this should not be considered secure. The mechanism used to define which community strings to which the agent should respond, and from which manager, depends on the implementation of the agent, but is typically based on access control lists (ACLs), which are files describing applicable access permissions.
For a description of how to configure ACLs, see Chapter 2.
|
Sun SNMP Management Agent
Administration Guide for Sun Supported Servers | 821-0655-10 |
|
Copyright © 2009, Sun Microsystems, Inc. All rights reserved.