|
|
Managed objects whose instances have to be read or written by the agent may be distributed between kernel and user space. Those in kernel space may be accessed by the agent by reading kernel memory. Objects in user space maintained by processes other than the agent may not be easily accessible without using some form of an interprocess communication (IPC) mechanism; the objects in question may not even be in the same physical environment as the agent. In such cases, the agent uses the SNMP Multiplexing Protocol (SMUX) to exchange management information with another process, termed SMUX peer, that maintains these managed objects.
The SMUX peer is said to be exporting a MIB module containing those objects and is responsible for SNMP operations on all objects within that MIB module. This also allows users to define their own private MIBs, usually called ``enterprise MIBs'', and export them via a SMUX peer process so that objects in that private MIB may be managed from any SNMP-compliant management station.
For example, the GateD routing daemon (see gated(ADMN)) maintains routing and configuration information for the EGP, BGP, RIP, and OSPF routing protocols. In the SCO OpenServer implementation, the SNMP agent and GateD are separate processes, therefore the SNMP agent cannot access information about the routing protocols directly. Therefore, if a network management station requests that the agent read/modify this information, the SNMP agent cannot do this directly. Instead, the agent forwards the SNMP requests to the GateD process that also acts as an SMUX peer. This peer exports MIB modules containing the objects which represent the information about the routing protocol mentioned above. In the role of an SMUX peer, the GateD process acts on the requests from the agent and sends responses to the agent. The agent then forwards these responses to the management station originating the request.
For an agent to be aware of an SMUX peer and to know what MIB modules the peer is exporting, an SMUX peer, when it starts running, must register with the local SNMP agent and export all the MIB modules it plans to support. The agent checks the registration requests from an SMUX peer against entries in the file /etc/snmpd.peers. If a valid entry does not exist for the peer requesting registration, the agent rejects the registration request.
The fields that comprise the entries in the /etc/snmpd.peers file are described in ``Configuring the SNMP ``peers'' group'' and snmpd.peers(SFF). One of the fields, however, requires more explanation. This is the priority field. Each peer registration has associated with it an integer priority value in the range of 0 to the maximum value of a 32-bit signed long integer, (2[31] - 1). A registration with a priority value of zero is given the highest possible priority and (2[31] - 1) the lowest. The highest allowed priority for each peer is specified in the agent's /etc/snmpd.peers file. If a peer attempts to register at a priority higher than allowed, the agent arbitrarily assigns that registration a priority at or below the priority specified in /etc/snmpd.peers. More than one peer can register the same MIB module, but the peer with the highest registration priority handles all management station requests for variables in that module. When a peer wishes to register a MIB module at a priority that has already been assigned to another SMUX peer, the agent continues to increment the priority value of the registration request until it finds an available priority value for that module. For example, if peer A has registered the module at priority 4, and peer B sends a registration request for the same module at priority 4, the agent will attempt to register the module to peer B at priority 5, and then 6, and so on until the agent finds an available priority for that module.
And what happens when a peer attempts to register a MIB module that encompasses a MIB module already registered by another SMUX peer? When peer B registers a MIB module that encompasses the module registered by peer A, peer B assumes responsibility for managing A's module as well.
A peer's registration request may have a special priority value of -1. When a peer uses this priority to register a MIB module, the agent will assign the highest available priority (that is, the lowest integer value available for that module) to that registration.
Details on the SMUX protocol and development of an SMUX peer may be found in RFC 1227 and the Network Programming Interfaces.
See also: