Chapter 1 Introduction to the System Management Agent
The System Management Agent is a Simple Network Management Protocol (SNMP) agent.
This chapter contains the following topics:
Overview of SNMP Agents
SNMP uses the term manager for the client
application that accesses the data about a managed device or system. The manager
usually runs on a system that is different from the managed system. The term agent is used for the program that implements the protocol stack
for servicing the requests from the manager. The SNMP agent typically runs
on the managed device. The agent offers services on a designated TCP/IP port.
The default SNMP port is 161.
Information about the target device is contained in a Management
Information Base (MIB). MIBs are used by agents and managers so that both
programs have knowledge of the data available. The MIB tells the manager about
the device's functions and data. The MIB also tells the manager how to address
or access that information in the form of managed objects. To access this
management information, the manager issues requests to the agent. The requests
contain identifiers for the MIB's data objects that are of interest to the
manager. If the request can be successfully completed, the agent returns a
response that contains the values for the required data objects.
Most SNMP agents support the basic SNMP protocol stack, and some minimal
MIBs. However, to make management of a device more effective, additional MIBs
must be supported on the managed device. The additional MIBs are provided
by device vendors to provide management information about custom features
of the managed device.
A MIB that is added to an SNMP agent is commonly known as an extension because the MIB extends the capabilities of the agent.
An agent that can accept extensions is extensible. The System Management Agent (SMA),
described in this manual, is an extensible agent. The extensions to the System Management Agent are
called extension modules.
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.
Note –
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.
Note –
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:
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.
Contents of the SMA for Developers
SMA includes the following content for developers:
-
Developer tools, and Perl modules needed by the tools
-
API libraries for using Net-SNMP functions
-
API library for using the Entity MIB functions
-
Demo modules, for demonstrating how to implement some types
of data modeling
In addition, you can install the SUNWsmaS package,
which contains the source code for Net-SNMP. See the Solaris System Management Agent Administration Guide for installation instructions.
File Locations of Developer Files
The developer files are installed in the locations that are shown in
the following table.
Table 1–1 File Locations for Developer
Content
|
Directory
|
Developer Content
|
|
/usr/demo/sma_snmp
|
Sample modules for demonstration purposes. See Demonstration Modules for more information.
|
|
/usr/sfw/bin
|
Command line tools that are useful for developers. For more information
on these tools, see SMA Tools.
|
|
/usr/sfw/sbin
|
Executable files for the snmpd agent daemon and snmptrapd trap daemon, which provide the SNMP services.
|
|
/usr/sfw/lib
|
The 32-bit shared libraries that contain the API functions from Net-SNMP,
and the libentity.so library, which defines functions
for using the Entity MIB.
This directory is supplied on all Solaris platforms. See API Libraries for more information.
|
|
/usr/sfw/lib/sparcv9
|
The 64-bit shared libraries that contain the API functions from Net-SNMP,
and the libentity.so library, which defines functions
for using the Entity MIB.
This directory is supplied only on 64-bit Solaris on SPARC® platforms. See API Libraries for more information.
|
|
/usr/sfw/include
|
Header files needed by API libraries.
|
|
/usr/sfw/doc/sma_snmp/html
|
HTML documentation for Net-SNMP API functions.
|
|
/etc/sma/snmp
|
Configuration files that are used by the mib2c tool.
|
|
/etc/sma/snmp/mibs
|
The MIBs supported by the System Management Agent.
|
|
/usr/perl5/vendor_perl/5.8.3/sun4-solaris-64int
|
Perl modules needed by the mib2c tool.
|
|
/usr/share/sma_snmp
|
Source code for Net-SNMP. The code is provided in the SUNWsmaS package,
which is not installed by default during Solaris installation. The package
must be installed manually from the Solaris media. For instructions for installing
the SUNWsmaS package, see the Solaris System Management Agent Administration Guide.
|
SMA Tools
The SMA includes many command-line tools, which are described
in the sma_snmp(5) man
page.
Each tool has an associated man page. Links to all the man pages for
the product are included in Appendix A, SMA Resources. The tools are located in /usr/sfw/bin.
The snmp commands can be used to query the agent
to test your modules. Read the man pages for detailed usage information.
API Libraries
The following API libraries are included with the SMA product:
-
libnetsnmp
-
libnetsnmpagent
-
libnetsnmpmibs
-
libnetsnmphelpers
-
libentity
The libentity library is not part of Net-SNMP,
but is a customization for the SMA product.
On SPARC platforms, the 32–bit Net-SNMP libraries are contained
in the /usr/sfw/lib directory. The 64–bit
Net-SNMP libraries are contained in the /usr/sfw/lib/sparcv9 subdirectory.
On x86 platforms, only the 32–bit Net-SNMP libraries are available
in the /usr/sfw/lib directory.
The functions contained in the Net-SNMP libraries are used
in the MIB modules that you create, as well as in the agent. Documentation
from Net-SNMP for using the API functions is contained in /usr/sfw/doc/sma_snmp/html.
The SMA includes the same Net-SNMP API functions that are
available with the open source Net-SNMP agent. API Functions includes a list of functions that are certified to work
with the System Management Agent.
Demonstration Modules
The /usr/demo/sma_snmp directory contains several demonstration
modules. The demo modules illustrate methods for creating modules to solve
various kinds of information-gathering problems. Later chapters in this manual
discuss the demo modules in detail. The following table lists and describes
the demo modules. The table also provides cross-references to the sections
that discuss the demos.
Table 1–2 Descriptions of Demonstration
Modules
Technical Support for Developers
Technical support for developers of modules for the System Management Agent is
provided through the Net-SNMP open source community at http://www.net-snmp.org. You might find the developers
discussion mailing list net-snmp-coders@lists.sourceforge.net to
be helpful. An archive for the mailing list is located at http://sourceforge.net/mailarchive/forum.php?forum_id=7152.
Download this book in PDF (1013 KB)