| Sun SNMP Management Agent for Sun Fire and Netra Systems |    
|
| Sun SNMP Management Agent for Sun Fire and Netra Systems |
|
| C H A P T E R 7 |
|
Introduction to SNMP |
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 Sun Fire and Netra systems.
The chapter contains the following sections:
SNMP is an open internet standard for managing networked devices (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 website (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:
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 timestamp indicating the time at which the agent was started.
The MIB is a definition for a virtual data store accessible via SNMP. The content is accessible from the manager using get and set operations as follows:
To enable an NMS to manage a device via 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 mightbe 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 OIDs. For example, a table of fan characteristics could consist of a number of rows, one per fan, with each row containing columns corresponding to the current speed, the expected speed, and the minimum acceptable speed.
The addressing of the rows within the table can be as follows:
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 9). |
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 will permit 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:
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 the agent should respond to, 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, refer to Chapter 3.
| Sun SNMP Management Agent for Sun Fire and Netra Systems | 817-2559-16 |
|
Copyright © 2006, Sun Microsystems, Inc. All Rights Reserved.