Table of Contents Previous Next PDF


Using Multiple SNMP Agents

Using Multiple SNMP Agents
The following sections describe how to use the Oracle SNMP Agent Integrator component with other SNMP agents:
Configuring the Oracle SNMP Agent Integrator for Use with Multiple SNMP Agents
An Oracle SNMP agent started as an SNMP agent—started with the -s option—and running under the Oracle SNMP Agent Integrator is known as a non-SMUX peer agent. A non-SMUX peer agent must be started before starting the Oracle SNMP Agent Integrator.
Each non-SMUX peer agent running on the managed node must have one or more NON_SMUX_PEER entries in the Oracle SNMP Agent beamgr.conf configuration file. The syntax of NON_SMUX_PEER entries is described in “Configuration Files” on page 9‑1.
Note:
Each NON_SMUX_PEER entry lists the port that the Oracle SNMP Agent Integrator is to use in communicating with the non-SMUX peer agent. When the agent is started, it must be configured to listen on the port assigned to it in the NON_SMUX_PEER entry (or entries) in the beamgr.conf file.
Integrator Access to Managed Objects
Each NON_SMUX_PEER entry for a non-SMUX peer agent lists a branch of the OID tree for which the agent is responsible. 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 Oracle SNMP Agent Integrator.
Example
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 Oracle SNMP Agent Integrator to look for an SNMP agent at port 2001. All the requests from the Oracle SNMP 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 Oracle SNMP Agent Integrator to look for an SNMP agent at UDP port 2002. All the requests from the Oracle SNMP 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. Because no access option is specified, both subtrees default to read-write.
The third entry lists an agent at UDP port 161. The asterisk means that the Oracle SNMP Agent Integrator uses 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:
Assigning Priority for Conflicting Agents
If two agents, A and B, conflict in the portions of the OID tree for which they are responsible, then the NON_SMUX_PEER entries that define these responsibilities must assign a distinct priority to the two agents. The Oracle SNMP 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 UDP port 2008 and UDP port 2009 both support the MIB-II ip group. Thus, both agents support the ipAddrTable (object .1.3.6.1.2.1.4.20). Because the agent at port 2009 has a higher priority (5 is a higher priority than 8), the Oracle SNMP 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 because it has a lower priority, it is completely ignored for ipAddrTable requests.
The syntax of the NON_SMUX_PEER entry in the configuration file is described in detail, with examples, in “Configuration Files” on page 9‑1.
SNMP Agents on Multiple Nodes
The Oracle SNMP 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 Oracle SNMP Agent Integrator, the resources managed by these multiple agents are viewed as though they were on a single machine. The polling capability of Oracle SNMP Agent Integrator is described in “Using the Oracle SNMP Agent Integrator for Polling” on page 7‑1. Polling of agents on multiple machines assumes that NON_SMUX_PEER entries have been defined for these SNMP agents in the Oracle SNMP Agent beamgr.conf configuration file. The following is an example where the Oracle SNMP Agent Integrator is used as a 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 Oracle SNMP Agent 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 Oracle SNMP 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 that 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, because the integrator views the resources managed by the agents specified in its configuration file as though they were all on a single machine. Thus, the Oracle SNMP Agent Integrator only consults the machine at 206.189.39.204 for management requests for the ipAddrTable because the priority number for this entry is lower than the priority number for the machine at 206.189.39.86. However, all other ip group requests and requests for the interfaces group are sent to 206.189.39.86.
This feature of the Oracle SNMP 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 Oracle SNMP Agent Integrators can be used to manage those resources.
 

Copyright © 1994, 2017, Oracle and/or its affiliates. All rights reserved.