[ Previous | Next | Contents | Glossary | Search ]
Performance Toolbox Version 1.2 and 2 for AIX: Guide and Reference

Chapter 13. SNMP Multiplex Interface

This chapter provides information about the SNMP Multiplex interface and applicable network management principles.

SNMP Multiplex Interface Overview

The SNMP (Simple Network Management Protocol) is a network protocol based upon the Internet protocol. As its name implies, its main purpose is to provide a protocol that allows management of networks of computers. Programs based upon SNMP are currently dominating the network management arena in non-SNA environments. One set of commonly used SNMP-based network management programs are the programs in IBM NetView.

Network Management Principles

Network management is primarily concerned with the availability of resources in a network. As implemented on top of SNMP, it uses a client/server model where one or a few hosts in the network run the client programs (known as SNMP Managers) and all network nodes (if possible) run the server code. On most host types the server code is implemented as a daemon, snmpd, normally referred to as the SNMP Agent.

Communication between the SNMP manager and the SNMP daemon uses two protocol models. The first model is entirely a request/response type protocol; the other is based upon traps, which are unsolicited packets sent from a server (agent) to the client (manager) to inform of some event.

The request/response protocol supports three request types:

Issued from the manager to an agent, requesting the current value of a particular variable. The agent will return the value if it's available.
Issued from the manager to an agent, requesting the change of a particular variable. By implication, the changing of a value will be interpreted by the agent as also meaning that the change of the value must be enforced. For example, if the number of memory buffers is changed, the agent is expected to implement this change on the system it runs on. A large number of system variables can not be set but are read-only variables.
Get next
Issued from the manager to the agent, requesting the agent to go one step further in the hierarchy of variables and return the value of the next variable.

As is implied by the "get next" request type, variables are arranged in a hierarchy much like the hierarchy used to maintain the statistics provided by the System Performance Measurement Interface (SPMI) and the xmservddaemon. Unlike the SPMI context hierarchy, however, even though an SNMP manager can traverse the hierarchy of variables to see what's available, it identifies those variables by a decimal coding system and is not able to convert these codes to textual descriptions by itself. To make the SNMP manager able to translate decimal coding into text, you must provide a file that describes the variables and the hierarchy. The file must describe the variables in a subset of the Abstract Syntax Notation (ASN.1) as defined by ISO. The subset used by SNMP is defined in RFC 1065. A file that describes a set or subset of variables and the hierarchy is referred to as a MIB file because it is said to describe a management information base (MIB).

Normally, an SNMP agent will know what variables it is supposed to provide and uses a fixed set. In other situations, the SNMP agent's set of variables may need to be expanded because special programs or special hardware is installed. This can be done through a programming interface called SMUX (SNMP Multiplex). The remainder of this topic describes how SMUX is used by the xmservd daemon to expand the set of variables available from the SNMP agent.

Note: The interface between xmservd and SMUX is only available on IBM RS/6000 Agents.

Interaction Between xmservd and SNMP

The objective of the xmperf program suite is very much different from that of the IBM NetView programs. The latter are concerned primarily with supervision and corrective action aiming at keeping the network resources available and accessible. Generally, resource availability is of more concern than resource utilization.

The xmperf program suite is primarily concerned with the continuous monitoring of resource utilization, aiming at:

Somewhere between the two products is a gray area that both are interested in. This means that certain of the variables (or statistics) must be available in both environments. It also means that if the two products do not share information, they both access the same information, inducing an overhead that could be eliminated if they had a common access mechanism.

Such a common access mechanism is available through the xmservd/SMUX interface. It allows the xmservd daemon to present all its statistics to the SNMP agent as read-only variables. The xmservd/SMUX interface is invoked by placing a single stanza in the configuration file/etc/perf/xmservd.res . (See "Files used by xmservd" for alternative locations for xmservd.res .) The stanza must begin in column one of a line of its own and must be:


Once the dosmux stanza is in effect, every statistic available to the xmservd daemon is automatically registered with the snmpd daemon on the local host. Dynamic data suppliers can add to or delete from the hierarchy of statistics. Any changes induced by dynamic data suppliers are communicated to the snmpd daemon. Every 15 seconds xmservd checks for such changes.

The xmservd daemon can produce an MIB file that describes all the variables currently exported to snmpd. This is done whenever you send a SIGINT (kill -2) to the xmservd process. The MIB file is created in ASN.1 notation and placed in /etc/perf/xmservd.mib . Any old copy of the file is overwritten. The generated MIB file can be moved to the host where NetView runs and imported by NetView.

When you need to generate a MIB file by sending a SIGINT to the xmservd daemon, make sure you have all relevant dynamic data-supplier programs running and registered with the daemon. Also have at least one data consumer registered with the daemon. This makes sure the generated MIB file includes all possible statistics in your host.

To be able to test the xmservd/SMUX interface with the SNMP program snmpinfo it is convenient to have a makefile for easy updating of the MIB file used by snmpinfo. This file is /etc/mib.defs . You must be root to update it. Consequently, you must have root authority to run the makefile.

A sample makefile to update the snmpinfo MIB file is shown in the following example and is available in /usr/samples/perfagent/server/Make.mib :

all: /etc/mib.defs.org /etc/mib.defs
  cp /etc/mib.defs /etc/mib.defs.org
/etc/mib.defs: /etc/perf/xmservd.mib
  mosy -o /tmp/mib.defs /etc/perf/xmservd.mib
  cp /etc/mib.defs.org /etc/mib.defs
  cat /tmp/mib.defs >
  rm /tmp/mib.defs

SMUX Configuration Conflicts

During the installation, and provided the snmp option of the base system's bosnet or tcpip component is installed, two configuration files are updated to allow the xmservd daemon to connect to the SNMP agent. The two files are updated with default identification strings and passwords.

"Figure 2. Changes to SNMP Files" shows the two files that are updated and the default lines inserted in the two files.

smux xmservd_pw # xmservd
"xmservd" "xmservd_pw"

If the xmservd/SMUX interface does not work as intended, even after you inserted dosmux in the file /etc/perf/xmservd.res , there may be a conflict between the xmservd/SMUX strings and other strings in the configuration files. To resolve the problem, simply change the last digit in the identification string for xmservd to something unique, then restart the snmpd daemon.

Limitations Induced by SMUX

One of the advanced features of the SPMI context hierarchy is that it allows you to instantiate in multiple levels. One context may define disks and the actual number of disks varies from host to host. Through instantiation, subcontexts are added for each disk present in a particular host.

The SNMP data structures allow for a similar facility, namely the definition of tables. In the above case, the table would be "Disks" and it would contain as many elements as there were disk drives, each element containing all the fields defined for a disk.

With the SPMI interface, you can continue the instantiation at the next level in the context hierarchy. For example, each disk may have a variable number of logical volumes assigned to them, each with its identical set of statistics. Instantiation would then allow you to adjust the context hierarchy as logical volume assignment changes.

SNMP does not allow such a thing. A table is the only type of structure that can be instantiated and it must always be at the lowest level in the hierarchy. Because of this, we have adjusted the SPMI context hierarchy so it only in one case instantiates in multiple levels. Otherwise we would not be able to export the context hierarchy to the SNMP agent.

The one situation where the SPMI instantiates in multiple levels is the context FS. When this context is exported to snmpd, only the top level is exported. Statistics for individual file systems are not available through snmpd.

SMUX Instantiation

Because of the differences between SPMI and the MIB definitions when it comes to instantiation, it seems warranted to illustrate what instantiation looks like in the two cases. We have chosen to illustrate this by looking at the instantiation of disk drives.

The following example shows the list of disk statistics clipped from the output of the command xmpeek -l. Notice that each disk (there are three of them) has four statistics defined:

/nchris/Disk/              Disk and CD ROM statistics
/nchris/Disk/hdisk0/                Statistics for disk hdisk0
/nchris/Disk/hdisk0/busy                      Time disk is busy 
/nchris/Disk/hdisk0/xfer                      Transfers to/from 
/nchris/Disk/hdisk0/rblk                      512 byte blocks read from 
/nchris/Disk/hdisk0/wblk                      512 byte blocks written to 
/nchris/Disk/hdisk1/                Statistics for disk hdisk1
/nchris/Disk/hdisk1/busy                      Time disk is busy 
/nchris/Disk/hdisk1/xfer                      Transfers to/from 
/nchris/Disk/hdisk1/rblk                      512 byte blocks read from 
/nchris/Disk/hdisk1/wblk                      512 byte blocks written to 
/nchris/Disk/hdisk2/                Statistics for disk hdisk2
/nchris/Disk/hdisk2/busy                      Time disk is busy 
/nchris/Disk/hdisk2/xfer                      Transfers to/from 
/nchris/Disk/hdisk2/rblk                      512 byte blocks read from 
/nchris/Disk/hdisk2/wblk                      512 byte blocks written to 

The SNMP perception of this context structure is somewhat different. As the structure is exported from xmservd through the SMUX interface it is converted to an MIB table. Use the following command to print the output shown in the following example:

snmpinfo -md -v xmdDisk
xmdDiskIndex.0 = 1
xmdDiskIndex.1 = 2
xmdDiskIndex.2 = 3
xmdDiskInstName.0 = "hdisk0"
xmdDiskInstName.1 = "hdisk1"
xmdDiskInstName.2 = "hdisk2"
xmdDiskBusy.0 = 20943
xmdDiskBusy.1 = 679
xmdDiskBusy.2 = 386
xmdDiskXfer.0 = 11832
xmdDiskXfer.1 = 444
xmdDiskXfer.2 = 89
xmdDiskRblk.0 = 73201
xmdDiskRblk.1 = 2967
xmdDiskRblk.2 = 6595
xmdDiskWblk.0 = 137449
xmdDiskWblk.1 = 1585
xmdDiskWblk.2 = 105

As you can see, the retrieval sequence is inverted. Where the SPMI retrieves all statistics for one disk before proceeding to the next disk, SMUX traverses the structure by reading one statistic for all disks before proceeding to the next statistic.

You'll see that for each disk instance, an artificial statistic is created to provide the index of each value (with the name xmdDiskIndex).

Also notice how the name of the instance (in this case the name of the disk drive) appears as another artificial type of statistic, which always has the name InstName meaning "instance name."

The MIB definition for disk statistics is shown in the example below "MIB Description for Disk Instantiation" .

Instantiation Rules

In SPMI, a context can be defined as having an instantiation type of:

Context is never instantiated, not even if requested.
Context is instantiated when xmservd is started. Further attempts to instantiate are done only when explicitly requested. Most data-consumer programs will not attempt to instantiate contexts with this context type; xmperf does not. Examples of contexts with this instantiation type are disks and page spaces.
Context is instantiated when it is created and when instantiation is requested. Most data-consumer programs should attempt to instantiate contexts with this context type; xmperf does. The classical example of a context with this instantiation type is the context defining processes.

When exporting contexts through SMUX, contexts with instantiation type of SiCfgInst or SiContInst are converted to tables.

For dynamic data-supplier programs, a special restriction applies to the use of SiCfgInst and SiContInst. Neither can be used for contexts that are at the top of the hierarchy of non-volatile contexts defined by a DDS. Also, neither may be used for contexts that are added as volatile extensions.

In general, since a request for instantiation is not passed to a dynamic data-supplier program, you should avoid using anything but SiNoInst in your DDS programs. If you want to use SiContInst, all of the subcontexts of the context with SiContInst should be volatile contexts of the same type.

Example MIB Description for Disk Instantiation

          SYNTAX  SEQUENCE  OF  XmdDisk
          ACCESS  not-accessible
          STATUS  mandatory
              "Disk  and  CD  ROM  statistics"
          ::=  {xmd  4  }
xmdDiskEntry  OBJECT-TYPE
          SYNTAX XmdDiskEntry
          ACCESS  not-accessible
          STATUS  mandatory
              "Element  of  above  table"
          ::=  {xmdDisk  1  }
XmdDiskEntry  ::=
              xmdDiskIndex  INTEGER,
              xmdDiskInstName  DisplayString,
              xmdDiskBusy  Counter,
              xmdDiskXfer  Counter,
              xmdDiskRblk  Counter,
              xmdDiskWblk  Counter
xmdDiskIndex  OBJECT-TYPE
          ACCESS  read-only
          STATUS  mandatory
              "Index  Number"
          ::=  {xmdDiskEntry  1  }
xmdDiskInstName  OBJECT-TYPE
          SYNTAX  DisplayString
          ACCESS  read-only
          STATUS  mandatory
              "Instance  Name"
          ::=  {xmdDiskEntry  2  }
xmdDiskBusy  OBJECT-TYPE
          SYNTAX  Counter
          ACCESS  read-only
          STATUS  mandatory
              "Time  disk  is  busy  (percent)"
          ::=  {xmdDiskEntry  3  }
xmdDiskWblk  OBJECT-TYPE
          SYNTAX  Counter
          ACCESS  read-only
          STATUS  mandatory
              "512  byte  blocks  written  to  disk"
          ::=  {xmdDiskEntry  6  }

[ Previous | Next | Contents | Glossary | Search ]