SMUX peers

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 SCO's 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, (231 - 1). A registration with a priority value of zero is given the highest possible priority and (231 - 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:

• ``For more about SNMP''

Home Notes Home MCSE MCSE MCITP + Security CCNA MCITP 2008  Boot Camp Schedule Register Frequently Asked Questions Course Fees Contact US Boot Camp Location Compare us to our competitors Testimonials Sitemap

Testimonials

Join MCSE MCITP Boot Camp & CCNA Boot Camp Back to Back Certification Today. links  270  290    291  293    294  298  299   Security  640-801  routing 811  821   831  Resources MCSE MCITP + CCNA  Training  Card pay  Papal  MCSE MCITP Notes  CCNA Notes    index main   root   link  resources home    Ref1 Ref2

Vibrant offers MCSE certification training boot camp for $5400 all inclusive, instructor led at California and Baltimore.

Vibrant Bootcamp Participants come from All Around the World. Vibrant has trained students from more than 15 countries like USA, UK, (Scotland, Ireland, Wales), Switzerland, Germany, Australia, Canada, France, Holland, Japan, Belgium, Bahrain, New Zealand, Tanzania, Turkey, Kenya and more.