Chapter 3. Using Multiple SNMP Agents

The Agent Integrator enables you to:

Agent Integrator Roles

You can use the Agent Integrator to listen on UDP port 161, and handle all communications with the SNMP manager. SNMP requests received by the Integrator are fanned out to the appropriate "peer" SNMP agent (or SMUX subagent), and responses from the agents or subagents are passed on to the manager by the Agent Integrator. Thus, multiple SNMP agents (as well as SMUX subagents and other master agent/subagent architectures that use SNMP to communicate to a manager) can coexist on a single managed node. The various agents all appear to the manager as a single SNMP agent. Master agents that communicate with subagents using SMUX, DPI or other master agent/subagent architectures appear to the Agent Integrator as just another peer SNMP agent.

Figure 3-1 Agent Integrator with Multiple SNMP Agents

Handling manager/agent communications through the Agent Integrator has the advantage that you can offload polling of managed objects supported by the "peer" SNMP agents to the Agent Integrator, which reduces network polling traffic and management station load. The local polling capability of the Agent Integrator is described in Chapter 4, "Using Agent Integrator for Polling."

Configuring Agent Integrator

Each SNMP agent that is to run on the managed node with the Agent Integrator must have one or more NON_SMUX_PEER entry in the BEA Manager configuration file (beamgr.conf). The syntax of NON_SMUX_PEER entries is described in Chapter 7, "Configuration Files."

Each NON_SMUX_PEER entry lists the port that the Agent Integrator is to use in communicating with the SNMP "peer" agent. When the agent is started, it must be configured to listen on the port assigned to it in the NON_SMUX_PEER entries for that agent.

Note: If an SNMP agent can only listen on default port 161, and has no ability to be reconfigured to listen on other ports, then any NON_SMUX_PEER entry for that agent must list 161 as its assigned port. In this case, that agent must be started before the Agent Integrator is started.

Integrator Access to Managed Objects

Agent Integrator access to the managed objects that each agent is responsible for is defined through the NON_SMUX_PEER entries. Each NON_SMUX_PEER entry for an agent lists a branch of the OID tree that the SNMP agent is to be responsible for. If agent A is listed as responsible for a certain branch of the OID tree, then management requests for objects within that branch will be passed on to agent A by the Integrator.

For example: 

NON_SMUX_PEER 2001 snmp .1.3.6.1.2.1.1,ro
NON_SMUX_PEER 2002 squid .1.3.6.1.4.1.141 .1.3.6.1.4.1.145
NON_SMUX_PEER 161 * .1.3.6.1.4.1.140 .1.3.6.1.4.1.145

The first entry tells the Agent Integrator to look for an SNMP agent at port 2001. All the requests from BEA Agent Integrator to this SNMP agent will use snmp as the community. The agent supports the subtree .1.3.6.1.2.1.1, and is available for read-only commands.

The second entry tells the Agent Integrator to look for an SNMP agent at port 2002. All the requests from BEA Agent Integrator to this SNMP agent will use squid as the community. The agent supports the subtrees .1.3.6.1.4.1.141 and .1.3.6.1.4.1.145. Since no access option is specified, both subtrees default to read-write.

The third entry lists an agent at port 161. The asterisk means that the Agent Integrator will use the community string supplied by the management station. The agent supports two subtrees: .1.3.6.1.4.1.140 and .1.3.6.1.4.1.145. The subtree entries list no access information, so access defaults to read-write.

Note: The SMUX protocol provides that SMUX subagents automatically register the sections of the OID tree that they support with the master agent. Hence, it is not necessary to add specific configuration file entries to specify which sections of the OID tree are accessible from the SMUX subagents. However, this default behavior can be overridden using a configuration file OID_CLASS entry. For more information about the OID_CLASS entry, refer to Chapter 7, "Configuration Files."

Assigning Priority for Conflicting Agents

If two agents, A and B, conflict in the portions of the OID tree that they are responsible for, then the NON_SMUX_PEER entries that define these responsibilities must assign a distinct priority to the two agents. The Agent Integrator thus refers requests for objects in the overlapping area to the agent with the lowest priority number. (The lower the priority number, the higher the priority.) For example: 

NON_SMUX_PEER 2008 * .1.3.6.1.2.1.4,rw,8
NON_SMUX_PEER 2009 * .1.3.6.1.2.1.4,ro,5

In this example, the agents on port 2008 and port 2009 both supports the MIB-II ip group. Thus, both agents support the ipAddrTable (object .1.3.6.1.2.1.4.20). Since the agent at port 2009 has a higher priority (5 is a higher priority than 8), the Agent Integrator calls it for management requests for the ipAddrTable. Notice that this entry specifies read-only access. The other entry specifies read-write access, but since it has a lower priority, it is completely ignored for ipAddrTable requests.

The syntax of the NON_SMUX_PEER configuration file entry is described in detail, with examples, in Chapter 7, "Configuration Files."

SNMP Agents on Multiple Nodes

The Agent Integrator can be used as a proxy agent for the management station, conducting polling of SNMP agents on a number of machines, and sending an enterprise-specific trap when a user-defined condition is encountered. This is useful when resources of a single distributed system are spread over a number of machines.

From the perspective of the Agent Integrator, the resources managed by these multiple agents are viewed as if they were on a single machine. The polling capability of Agent Integrator is described in Chapter 4, "Using Agent Integrator for Polling." Polling of agents on multiple machines assumes that NON_SMUX_PEER entries have been defined for these SNMP agents in the BEA Manager configuration file (beamgr.conf). The following is an example where the Integrator is used as proxy agent for communication with SNMP agents in a single subnet: 

NON_SMUX_PEER 206.189.39.86.161 seahorse .1.3.6.1.2.1.4,rw,8
NON_SMUX_PEER 206.189.39.204.161 * \
.1.3.6.1.2.1.4.20,ro,5 .1.3.6.1.2.1.2

In this example, the SNMP agent on machine 206.189.39.86 communicates with the Integrator on port 161, uses a community string of seahorse, and is responsible for the MIB-II ip group. The SNMP agent on machine 206.189.39.204 also communicates with the Agent Integrator on port 161, using the community string passed from the SNMP manager.

The machine at IP address 206.189.39.204 is responsible for the SNMP interfaces group (.1.3.6.1.2.1.2) as well as the ipAddrTable (.1.3.6.1.2.1.4.20). The machine at IP address 206.189.39.86 is responsible for the MIB-II ip group which includes the ipAddrTable. Even though these agents are on physically distinct network nodes, there is still a conflict in the responsibilities of these two agents, as far as the Integrator is concerned, since the Integrator views the resources managed by the agents specified in its configuration file as if they were all on a single machine. Thus, the Integrator will only consult the machine at 206.189.39.204 for management requests for the ipAddrTable since the priority number for this entry is lower than the priority number for the machine at 206.189.39.86. All other ip group requests, and requests for the interfaces group, will be sent to 206.189.39.86, however.

This feature of the Agent Integrator is particularly useful when different functions of a distributed system are located on different machines, each with its own SNMP agent. The limitation to non-overlapping OID tree branches should not be a significant problem when different managed resources are located on the distinct nodes. If the same type of managed resource is located on multiple machines, then multiple Agent Integrators can be used to manage these resources.