|
A System Administrator may want to allow the use of SNMPv1 or SNMPv2c management software to monitor and/or control legacy equipment. Once that decision has been made it is an obvious desirable to enable that software to have some management capabilities on SNMPv3 agents.
Such a mechanism is built into SNMPv3 through the SNMP-COMMUNITY-MIB mib. It provides for a mapping of the community string into the securityName/contextName. In the example that follows
row #1 takes v1 and v2c packets with the community string of "publicV2" and assigns the Security name of "publicV2MappedToUSM" to those packets. (Later in this tutorial we will discriminate against version 1 packets.)
It is now necessary to define the properties of the mapped Security Name. This is done in the Security/USM tab. Because the SNMPv1 and v2c management stations are not capable of providing the authentication or privacy protocols so both of those protocols "none" must be selected, as illustrated below.
The result of this defining of the mapped security name is just the first step in allowing access to V2 managers. At this stage we need to define a group that can be associated with our specific security name. This is done in the "VACM/Security To Group" tab as below.
In this case we only defined the case where V2 packets are involved. If we wanted to allow V1 managers to operate we would have to include a row for the security model "secModelSNMPv1(1)".
In order to define the group we have just named we need to first make sure there are MIB views defined which allow use to see the MIBs that we need to manage with our V2 manager. This is done in the "VACM/MIB Views" tab.
In the example we have produced here we have defined a new View named "restrictedV2Views" which includes all the branches off of the OID "(1)iso.(3)org.(6)dod.(1)internet" excluding those off of (1)iso.(3)org.(6)dod.(1)internet.(6)snmpV2.(3)snmpModules". This example has some significants in that because we can’t use any of the advanced security mechanisms of snmpV3 to protect the data in these tables, it’s just as well to restrict their access to only those management stations capable of employing the V3 mechanisms. Any addition branches which you want to exclude require additional rows such as row #5.
Now that we have defined the MIB views which we can apply to the different types of access we can go back to the "VACM/Access" tab to define the views which are available to the new group "grpReadOnlyForV2" which we just defined.
At this point our v3 agents can be queryied with SNMPv2c managers which use the community string "publicV2"
Configuring v3 agents for v1/v2c Requests