This chapter provides information about the SNMP Multiplex interface and applicable network management principles.
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 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:
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.
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:
dosmux
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 /etc/mib.defs.org: 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 > > /etc/mib.defs rm /tmp/mib.defs
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.
/etc/snmpd.conf: smux 1.3.6.1.4.1.2.3.1.2.1.3 xmservd_pw # xmservd /etc/snmpd.peers: "xmservd" 1.3.6.1.4.1.2.3.1.2.1.3 "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.
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.
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 (percent) /nchris/Disk/hdisk0/xfer Transfers to/from disk /nchris/Disk/hdisk0/rblk 512 byte blocks read from disk /nchris/Disk/hdisk0/wblk 512 byte blocks written to disk /nchris/Disk/hdisk1/ Statistics for disk hdisk1 /nchris/Disk/hdisk1/busy Time disk is busy (percent) /nchris/Disk/hdisk1/xfer Transfers to/from disk /nchris/Disk/hdisk1/rblk 512 byte blocks read from disk /nchris/Disk/hdisk1/wblk 512 byte blocks written to disk /nchris/Disk/hdisk2/ Statistics for disk hdisk2 /nchris/Disk/hdisk2/busy Time disk is busy (percent) /nchris/Disk/hdisk2/xfer Transfers to/from disk /nchris/Disk/hdisk2/rblk 512 byte blocks read from disk /nchris/Disk/hdisk2/wblk 512 byte blocks written to disk
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" .
In SPMI, a context can be defined as having an instantiation type of:
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.
xmdDisk OBJECT-TYPE
SYNTAX SEQUENCE OF XmdDisk
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Disk and CD ROM statistics"
::= {xmd 4 }
xmdDiskEntry OBJECT-TYPE
SYNTAX XmdDiskEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Element of above table"
::= {xmdDisk 1 }
XmdDiskEntry ::=
SEQUENCE
{
xmdDiskIndex INTEGER,
xmdDiskInstName DisplayString,
xmdDiskBusy Counter,
xmdDiskXfer Counter,
xmdDiskRblk Counter,
xmdDiskWblk Counter
}
xmdDiskIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Index Number"
::= {xmdDiskEntry 1 }
xmdDiskInstName OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Instance Name"
::= {xmdDiskEntry 2 }
xmdDiskBusy OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Time disk is busy (percent)"
::= {xmdDiskEntry 3 }
.
.
.
xmdDiskWblk OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"512 byte blocks written to disk"
::= {xmdDiskEntry 6 }