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.
To Shadow Overlapping MIBs
Run the mibgen tool to generate an implementation
of MIB-II
Instrument the system group and snmp
group as shown in the basic SNMP agent example in "Creating an SNMP Agent"
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
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 - 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.
|