Sun Microsystems
Products & Services
 
Support & Training
 
 

Previous Previous     Contents     Index     Next Next

20.2.3 SnmpUsmProxy

The SnmpUsmProxy object performs the same function as the SnmpProxy, except that it gets values from SNMP agents implementing the SNMPv3 protocol.

The SnmpUsmProxy object extends the SnmpUsmMibAgent abstract class, and as such can be registered in the SnmpV3AdaptorServer just like a local MIB generated by the mibgen tool. In a master agent application, one SnmpUsmProxy must be created per subagent. When creating the SnmpUsmProxy object, you must provide it with the following parameters to enable it to access the underlying subagent:

  • Subagent's IP address

  • Subagent's port number

  • Security parameters, namely context names, the user name and the security level, used for communicating with the subagent

  • Request context, namely the context engine ID and the context name

The SnmpUsmProxy receives requests in any version of SNMP, and always forwards them as SNMPv3 requests.

20.2.4 SnmpTrapForwarder

An SnmpTrapForwarder object makes it possible to listen to traps emitted by a subagent, convert them into the master agent's manager's protocol or protocols, and forward them to the manager or managers as if they originated from the master agent itself. One or more SnmpTrapForwarder objects must be instantiated, and the subagents must be configured to send their traps to these objects. This is the responsibility of the main application code. This is explained in detail in 20.5 Trap Forwarding.

20.3 Routing Overlapping MIBs

In a master agent application, routing is performed depending on the OIDs requested. SNMP MIB agents are registered for branches of the global OID tree, and varbinds are dispatched to subagents according to the requested OIDs. The SnmpV3AdaptorServer supports registration of overlapping MIBs. Overlapping MIBs are MIBs that are registered below the OID of a previously registered MIB. The actual value returned to the manager is the value implemented by the deepest MIB registered for that value. When a get or set request is received, for each varbind in the request, the SnmpV3AdaptorServer identifies the deepest MIB responsible for handling the OID contained in the varbind. All varbinds targeted to that MIB are grouped in an SnmpMibRequest, and that request is passed to the identified SnmpMibAgent.

20.3.1 Shadowing Overlapping MIBs

MIB overlapping enables you to shadow MIBs that are implemented in subagents. For instance, you might want to implement the system group and snmp from MIB-II locally in your master agent, and delegate all other requests concerning MIB-II to a legacy SNMP agent implementing MIB-II. You do this as described in To Shadow Overlapping MIBs.

ProcedureTo Shadow Overlapping MIBs

  1. Run the mibgen tool to generate an implementation of MIB-II

  2. Instrument the system group and snmp group as shown in the basic SNMP agent example in "Creating an SNMP Agent"

  3. Register your generated MIB with the OIDs of both the system group, 1.3.6.1.2.1, and snmp group, 1.3.6.1.2.1.1.1

  4. Create an SnmpProxy object proxying your legacy MIB-II agent, and register that proxy for the root OID of MIB-II

20.3.2 Delegation and Precedence of Overlapping MIBs

MIB overlapping also enables you to delegate all unhandled OIDs to a legacy master agent, such as the Solaris agent snmpdx. If you register an SnmpProxy at the root of the OID tree, then all varbinds for whose OIDs no SnmpMibAgent was registered are passed to that SnmpProxy.

In addition, MIB overlapping enables you to give precedence to a specific agent for a part of a MIB, by registering it deeper in the OID tree.


Note - For a get-next or get-bulk request, the incoming OID does not make it possible to identify directly the subagent that will contain the next OID. Indeed, the next OID might not be a sub-OID of the requested OID, but might be in a different part of the global OID tree. The get-next and get-bulk requests are thus forwarded to all subagents, and sorted a posteriori to identify the deepest matching subagent.


20.4 MIB Scoping in Master Agents

MIB scoping is a special case in which the SNMP proxy forwarder application can be emulated by a master agent application. If a subagent is dedicated completely to handling a specific MIB scope, you register a single SnmpProxy for that subagent at the root of the OID tree for that scope. Because there can be only one context per request, then all or none of the varbinds in the incoming request are passed to the SnmpProxy. In this case, the master agent application behaves similarly to a proxy forwarder application. The only difference is that it identifies the target agent with the context name contained in the request.

20.5 Trap Forwarding

Another function of an SNMP master agent is to listen to SNMP traps and notifications emitted by its subagents, and to forward them to its managers. The Java DMK 5.1 SNMP toolkit provides an SnmpTrapForwarder for that purpose.

How to configure the trap forwarding mechanism is entirely the responsibility of your main application code. The following are three possibilities for ways to configure your trap forwarding mechanism, but the list is by no means exhaustive.

  • Create a single SnmpTrapForwarder and make all subagents to send traps to that forwarder

  • Create one forwarder per subagent, each listening to a different port for each subagent

  • Create one SnmpTrapForwarder per manager, each one forwarding traps to a specific manager

The SnmpTrapForwarder handles protocol conversion. It is able to convert any of an SNMPv1 trap, or an SNMPv2 or SNMPv3 notification into any of an SNMPv1 trap or an SNMPv2 or SNMPv3 notification following the protocol conversion rules specified in RFC 2576.

20.5.1 Configuration of Trap Targets

You can pass specific manager addresses when forwarding for a specific protocol. By default the InetAddressAcl is also parsed. So the set of actual manager addresses is the trap blocks located in the acl file and the set of added targets. You can disable the InetAddressAcl parsing by calling the method setInetAddressAclUsed(false).

To enable trap forwarding you must start the trap forwarder.


Caution Caution - If you have manager addresses in your set of targets that are also present in InetAddressAcl, or you have no InetAddressAcl activated but are targeting the local host, your manager will receive the trap twice. To prevent this, configure the SnmpTrapForwarder carefully. You can, for example, disable the setInetAddressAcl parsing by calling isInetAddressAclUsed(false).


20.5.2 Proxy Forwarding and Notification Originators

By default a trap is sent as a notification originator. The difference between acting as a notification originator or acting as a proxy when forwarding the trap is detailed in RFC 2576 "Coexistence Between SNMP versions"

20.5.2.1 Proxy Forwarding

Proxy forwarding is activated by calling the forwardAsProxy() method.

When translating SNMPv1 traps into SNMPv2 traps, the varbind received is reused. Three additional varbinds are appended, if these three additional varbinds do not already exist in the SNMPv1 varbinds:

  • The name portion of the first additional varbind contains snmpTrapAddress.0, and the value contains the SNMPv1 agent-addr parameter.

  • The name portion of the second additional varbind contains snmpTrapCommunity.0, and the value contains the value of the community string field from the received SNMPv1 message which contained the SNMPv1 trap PDU.

  • The name portion of the third additional variable binding contains snmpTrapEnterprise.0, and the value is the SNMPv1 enterprise parameter.

The SNMPv1 agent-addr parameter is determined by the proxy extracting the original source of the notification from the varbinds, If the SNMPv2 varbinds contain a varbind whose name is snmpTrapAddress.0, the agent-addr parameter is set to the value of that varbind. Otherwise, the SNMPv1 agent-addr parameter is set to 0.0.0.0.

20.5.2.2 Notification Originators

Traps are forwarded as notification originators by calling the forwardAsNotificationOriginator() method.

When translating from SNMPv1 to SNMPv2, the SNMPv2 varbinds are the same as the SNMPv1 varbinds.

When translating from SNMPv2 to SNMPv1, the SNMPv1 agent-addr parameter is determined as follow:

  • If the notification is sent over IP, the SNMPv1 agent-addr parameter is set to the IP address of the SNMP entity in which the notification originator resides.

  • If the notification is sent over some other transport protocol, the SNMPv1 agent-addr parameter is set to 0.0.0.0.

Previous Previous     Contents     Index     Next Next