Overview of the System Management Agent

The System Management Agent (SMA) is an SNMP agent that is based on an open source project, Net-SNMP at http://www.net-snmp.org. This base agent supports SNMPv1, v2c, and v3 protocols.

The Net-SNMP version used in SMA is 5.0.9.

The following diagram shows the structure of the Net-SNMP agent, and is followed by an explanation of the components.

Figure 1–1 Net-SNMP Architecture

The components of the Net-SNMP agent are:

• Transport domains

  The Net-SNMP agent currently supports the transports TCP, UDP, and UNIX Domain Sockets. The agent can receive and transmit SNMP messages through these transports. The agent's implementation of each transport implements functions to send and receive raw SNMP data. The raw messages received by the transport domains are passed to the message processor for further processing. The message processor also transfers raw SNMP messages to the transport domain for sending.

• Message processor

  The message processor decodes raw SNMP messages into internal PDU structures. The processor also encodes PDUs into raw SNMP messages. The SNMP messages are encoded by using Binary Encoding Rules, which are described in RFC 3416 and RFC 1157. The message processor also handles the security parameters in the SNMP messages. If the messages include User-based Security Model (USM) security parameters, the message processor passes the required parameters to the USM module. Additionally, trap messages from modules can be sent to the message processor for transmission.

• USM module

  The USM module handles all processing that is required by the User-based Security Model as defined in RFC 3414. The module also implements the SNMP-USER-BASED-SM-MIB as defined in the same RFC. The USM module, when initialized, registers with the agent infrastructure. The message processor invokes the USM module through this registration.

  The USM module decrypts incoming messages. The module then verifies authentication data and creates the PDUs. For outgoing messages, the USM module encrypts PDUs and generates authentication data. The module then passes the PDUs to the message processor, which then invokes the dispatcher.

  The USM module's implementation of the SNMP-USER-BASED-SM-MIB enables the SNMP manager to issue commands to manage users and security keys. The MIB also enables the agent to ensure that a requesting user exists and has the proper authentication information. When authentication is done, the request is carried out by the agent.

  The various keys that the USM module needs to perform encryption and authentication operations are stored persistently.

  See Chapter 4, Managing Security, in Solaris System Management Agent Administration Guide for more information about USM.

• Dispatcher

  The dispatcher is responsible for routing messages to appropriate destinations. After the USM module processes an incoming message into PDUs, the dispatcher performs an authorization check. This authorization check is done by the registered access control module, which is the VACM module. If the check succeeds, the dispatcher uses the agent registry to determine the module that has registered for the relevant object identifier. The dispatcher then invokes appropriate operations on the module. A particular request might cause the dispatcher to invoke several modules if the SNMP request contains multiple variables. The dispatcher keeps track of outstanding requests through session objects. Responses from the modules are then dispatched to the transports that are associated with the session objects. The message processor performs the appropriate message encoding.

• VACM module

  The View-based Access Control Model is described in RFC 3415. This RFC also defines the SNMP-VIEW-BASED-ACM-MIB. The MIB specifies objects that are needed to control access to all MIB data that is accessible through the SNMP agent. Upon initialization, the VACM module registers as the access control module with the agent infrastructure. The VACM module implements access control checks according to several parameters that are derived from the SNMP message. These parameters specify:

  • The security model being used, which can be USM, v1 communities, or v2 communities

  • The security name, which is user name in USM, and community string in v1 and v2

  • The context

  • The object being accessed

  • The operation being performed

  By implementing the SNMP-VIEW-BASED-ACM-MIB, the VACM module handles manipulation of various table entries that are mandated by VACM. These table entries are looked up in performing the VACM check and are maintained persistently in the agent configuration file.

  See Chapter 4, Managing Security, in Solaris System Management Agent Administration Guide for more information about VACM.

• Repository

  The agent configuration file, snmpd.conf, is the repository for the agent. Configuration tokens for various modules are stored in the repository. The modules have access to these configuration tokens when the modules are initialized. Modules can also register callback routines with the repository. The callbacks are invoked when the module state needs to be persisted, or written to disk to be retrieved later. Within the callbacks, each module is allowed to output its state. When the agent shuts down, the callbacks are used to save the modules' state. An SNMP SET command can also be used to cause a module's state to be persisted.

• OID registration handler

  The OID registration handler, or agent registry, handles the registration of object identifiers that are specified by modules.

• Proxy module

  The proxy module handles proxy forwarding of SNMP messages to and from other SNMP agents. The proxy module can also map between SNMPv1 and SNMPv2 protocols according to the rules specified in RFC 2576.

  The proxy module stores its configuration tokens in the agent configuration file. A particular configuration entry can associate OIDs within a context with another SNMP agent. The configuration file also specifies community strings and destination transport end points. By using these configuration tokens, the proxy module registers as the handler for the specific OIDs. When an incoming request for any of the proxy module's OIDs reaches the dispatcher, the dispatcher invokes the proxy module. The proxy module then issues appropriate SNMP requests to the target agents. Responses are returned back to the dispatcher.

  The System Management Agent uses the proxy module for interaction with the Solstice Enterprise Agents.

• AgentX module

  The AgentX module implements RFCs 2741 and 2742. The AgentX module registers as the handler for the AgentX-related registration tables defined in the AGENTX-MIB. The transports that are used for the AgentX protocol interactions are specified in the agent configuration file. In the Net-SNMP agent, the transports are typically UNIX domain sockets. When the AgentX module is initialized, the module creates sessions on these transports and registers as the handler for these sessions. In the System Management Agent, the only allowable AgentX transport is UNIX domain sockets, so only sessions on UNIX domain sockets are created.

  When an AgentX subagent starts, the subagent sends its registration requests with messages that use the AgentX protocol to the master agent. The requests are received by the sessions that have been created by the AgentX module. The message processor decodes the message, then invokes the AgentX module. The AgentX module, rather than the dispatcher module, is the handler for these sessions.

  The AgentX module then registers as the handler for OIDs that are specified in the subagent registration message. When requests for these OIDs are received by the dispatcher, the requests are directed to the AgentX module, which in turn connects to the required subagent. Requests to unregister OIDs are handled similarly.

• Extension modules

  Extension modules, which are depicted at the bottom of Figure 1–1, are the means by which MIBs are implemented in the agent. An extension module registers with the agent all the object identifiers that the module manages. The module also implements functionality to perform SNMP operations on the module's objects. As shown in Figure 1–1, helper routines or handlers in the API can be inserted between a module and the agent infrastructure. These handlers can have various functions, such as handling details of table iterations or providing debug output.

Extending the Agent

The Net-SNMP agent can be extended in the following ways:

• The agent can be recompiled to include a static module, which becomes part of the agent infrastructure. Static modules are initialized on agent start up. Examples of static modules include the VACM and USM modules. The System Management Agent was developed by compiling several static modules for MIBs that are not included in the Net-SNMP agent. See Features Added in System Management Agent for a list of the MIBs included in SMA.

  You cannot deploy your own modules as static modules with SMA because you cannot recompile the SMA code.

• Modules can be loaded into the master agent's process image. A shared object is dynamically loaded into the agent when the agent is running. The shared object registers the OIDs for the MIB that is supported by the shared object. The location of the shared object libraries for the module can be specified through SNMP requests or in the agent configuration file.

• Modules can be loaded into secondary SNMP subagents. Subagents are separate executable programs that can dynamically register themselves with the agent that is running on the designated SNMP port. The monitoring agent processes any SNMP request that comes to the SNMP port, and can send a request to a subagent, if needed. In this scenario, the agent on the designated port is called the master agent. The AgentX RFCs 2741 and 2742 define the protocols between the subagent and master agent as well as the MIBs that contain details of the registrations. For more information on master agents and subagents, see Chapter 6, Deploying Modules.

• A module can be delivered as an SNMP agent. The master agent can interact with such agents through a proxy mechanism.

The System Management Agent supports module deployment in the form of dynamically loaded modules or subagents. The agent also provides a proxy mechanism. You cannot recompile the System Management Agent.

See Chapter 6, Deploying Modules for information about how to deploy modules as dynamic modules and in subagents.

Features Added in System Management Agent

The SMA product includes the Net-SNMP agent, Net-SNMP developer tools, and Net-SNMP API libraries that enable the agent to be extended through modules. You can use the tools and APIs to create a module to support the custom features of a managed device. A management program can then be used for monitoring and managing the device.

The SMA extends the Net-SNMP agent to support the following MIBs:

• MIB II, described in http://www.ietf.org/rfc/rfc1213.txt, defines the structure of management information and the network management protocol for TCP/IP-based networks. The SMA implements all the object groups of MIB II except the EGP group.

• Host Resources MIB, described in http://www.ietf.org/rfc/rfc2790.txt, defines the structure of management information for managing host systems. The SMA implements the same host resources MIB that is included in the base Net-SNMP agent.

• Sun MIB is the MIB II with Sun-specific object groups added. Sun MIB was originally provided in the Solstice Enterprise Agents product beginning with the Solaris 2.6 operating system. The SMA implements the following groups from the Sun MIB:

  • Sun System group

  • Sun Processes group

  • Sun Host Performance group

Support for these MIBs is provided as static modules that run in the SMA agent. The agent was created by recompiling the Net-SNMP agent to include these modules.

The SMA provides an additional MIB for hardware, the Entity MIB, in an external dynamically loaded module. The Entity MIB is described in RFC 2737 at http://www.ietf.org/rfc/rfc2737.txt. The Entity MIB is implemented as a skeleton MIB, so that module developers can populate the various tables of the MIB. The Entity MIB can be used by a single agent for managing multiple logical entities and physical entities. For more information about the Entity MIB, see Chapter 9, Entity MIB.