System Management Guide: Communications and Networks

Migrate from SNMPv1 to SNMPv3

This scenario shows a typical migration from SNMPv1 to SNMPv3.

In AIX 5.2, the default SNMP agent running at system boot time is the non-encrypted version of SNMPv3. SNMPv3 uses the /etc/snmpdv3.conf file as its configuration file. Any parameters that you had configured in the /etc/snmpd.conf file, which is used by SNMPv1 in AIX 5.1 and earlier, will need to be manually migrated to the /etc/snmpdv3.conf file.

In this scenario, the communities and traps that were configured in the /etc/snmpd.conf file will be migrated to the /etc/snmpdv3.conf file. By the end of the scenario, SNMPv3 will provide identical functionality that SNMPv1 offered. If you did not configure any of your own SNMPv1 communities or traps, there is no need for you to complete this procedure.

This file does not contain any information about features available in SNMPv3. For information about creating users using SNMPv3 features not available in SNMPv1, see Create Users in SNMPv3.

The following file is the example /etc/snmpd.conf file that is going to be migrated. The following communities are configured: daniel, vasu, and david. These communities must be migrated manually.

logging         file=/usr/tmp/snmpd.log         enabled
logging         size=0                          level=0

community       daniel       0.0.0.0     0.0.0.0         readWrite  1.17.35
community       vasu         9.3.149.49  255.255.255.255 readOnly   10.3.5
community       david        9.53.150.67 255.255.255.255 readWrite  1.17.35

view 1.17.35    udp  icmp  snmp 1.3.6.1.2.1.25
view 10.3.5     system interfaces tcp icmp

trap            daniel          9.3.149.49      1.17.35   fe
trap            vasu            9.3.149.49      10.3.5   fe
trap            david           9.53.150.67     1.17.35   fe

smux            1.3.6.1.4.1.2.3.1.2.3.1.1         sampled_password  # sampled

To complete the steps in this scenario, refer to your /etc/snmpd.conf file. Have a copy of that file ready when you start this procedure.

Step 1. Migrate the community information

The community names in the /etc/snmpd.conf file become part of the VACM_GROUP entries in the /etc/snmpdv3.conf file. Each community must be placed in a group. You will then give the groups the view and access permissions needed.

With root authority, open the /etc/snmpdv3.conf file with your favorite text editor. Locate the VACM_GROUP entries in the file.
Create a VACM_GROUP entry for each community that you want to migrate. If multiple communities are going to share the same view and access permissions, you need to create only one group for them. The community names in the /etc/snmpd.conf file become the securityName values for the VACM_GROUP entries. In this scenario, the following entries were added for vasu, daniel, and david:
```
#--------------------------------------------------------------------
# VACM_GROUP entries
#    Defines a security group (made up of users or communities)
#    for the View-based Access Control Model (VACM).
# Format is:
#  groupName securityModel securityName storageType
VACM_GROUP group2 SNMPv1  vasu -
VACM_GROUP group3 SNMPv1  daniel -
VACM_GROUP group3 SNMPv1  david -
#--------------------------------------------------------------------
```
- groupName can be any value you choose, except group1.
- securityModel remains SNMPv1 because we are migrating the SNMPv1 communities.
- In this scenario, daniel and david share the same view and access permissions in the /etc/snmpd.conf file. Therefore, they are both members of group3 in the /etc/snmpdv3.conf file. Community vasu is placed in a different group because its view and access permissions are different than those for david and daniel.

The communities are now placed in groups.

Step 2. Migrate the view information

The view information in the /etc/snmpd.conf file will become COMMUNITY, VACM_VIEW, and VACM_ACCESS entries in the /etc/snmpdv3.conf file. These entries will determine the view and access permissions for each group.

Create COMMUNITY entries for daniel, vasu, and david, maintaining the same IP addresses for netAddr and netMask as were specified in the /etc/snmpd.conf file.

#------------------------------------------------------------------------
# COMMUNITY
#    Defines a community for community-based security.
# Format is:
#  communityName securityName securityLevel netAddr netMask storageType
COMMUNITY public    public     noAuthNoPriv 0.0.0.0     0.0.0.0         -
COMMUNITY daniel    daniel     noAuthNoPriv 0.0.0.0     0.0.0.0         -
COMMUNITY vasu      vasu       noAuthNoPriv 9.3.149.49  255.255.255.255 -
COMMUNITY david     david      noAuthNoPriv 9.53.150.67 255.255.255.255 -
#------------------------------------------------------------------------

Create a VACM_VIEW entry for every MIB object or variable that each group has access to. According to the /etc/snmpd.conf file, daniel and david have access to udp, icmp, snmp, and 1.3.6.1.2.1.25 (host subtree as defined in RFC 1514), and vasu has access to system, interfaces, tcp, and icmp. These view entries are migrated to the /etc/snmpdv3.conf file as follows:

#--------------------------------------------------------------------
# VACM_VIEW entries
#    Defines a particular set of MIB data, called a view, for the
#    View-based Access Control Model.
# Format is:
#  viewName viewSubtree viewMask viewType storageType

VACM_VIEW group2View        system                      - included -
VACM_VIEW group2View        interfaces                  - included -
VACM_VIEW group2View        tcp                         - included -
VACM_VIEW group2View        icmp                        - included -

VACM_VIEW group3View        udp                         - included -
VACM_VIEW group3View        icmp                        - included -
VACM_VIEW group3View        snmp                        - included -
VACM_VIEW group3View        1.3.6.1.2.1.25              - included -
#---------------------------------------------------------------------

Define access permissions to the MIB variables defined in the VACM_VIEW entries by adding VACM_ACCESS entries. In the /etc/snmpd.conf file, daniel and david both have readWrite permission to their MIB variables, whereas vasu has readOnly.

Define these permissions by adding VACM_ACCESS entries. In this scenario, we gave group2 (vasu) the group2View for readView, but gave it - for writeView because vasu had readOnly in the /etc/snmpd.conf file. We gave group3 (daniel and david) the group3View for both readView and writeView because those groups had readWrite access in /etc/snmpd.conf. See the following example.

#-----------------------------------------------------------------------------------------------------------
# VACM_ACCESS entries
#    Identifies the access permitted to different security groups
#    for the View-based Access Control Model.
# Format is:
# groupName contextPrefix contextMatch securityLevel securityModel readView writeView notifyView storageType
VACM_ACCESS  group1 - - noAuthNoPriv SNMPv1  defaultView - defaultView -
VACM_ACCESS  group2 - - noAuthNoPriv SNMPv1  group2View - group2View -
VACM_ACCESS  group3 - - noAuthNoPriv SNMPv1  group3View group3View group3View -
#-----------------------------------------------------------------------------------------------------------

Step 3. Migrate the trap information

The trap entries in the /etc/snmpd.conf file will become the NOTIFY, TARGET_ADDRESS, and TARGET_PARAMETERS entries in the /etc/snmpdv3.conf file. However, only the TARGET_ADDRESS and TARGET_PARAMETERS will need to be migrated.

The IP addresses listed in the trap entries in the /etc/snmpd.conf file become part of the TARGET_ADDRESS entries in the /etc/snmpdv3.conf file. This line specifies the host where the trap will be sent. You can define the targetParams entries. In this scenario, we use trapparms1, trapparms2, trapparms3, and trapparms4, which will be defined in the TARGET_PARAMETERS entries.

#-------------------------------------------------------------------------------------
# TARGET_ADDRESS
#    Defines a management application's address and parameters
#    to be used in sending  notifications.
# Format is:
#  targetAddrName tDomain tAddress tagList targetParams timeout retryCount storageType
TARGET_ADDRESS Target1 UDP 127.0.0.1	   traptag trapparms1 - - - 
TARGET_ADDRESS Target2 UDP 9.3.149.49   traptag trapparms2 - - - 
TARGET_ADDRESS Target3 UDP 9.3.149.49   traptag trapparms3 - - - 
TARGET_ADDRESS Target4 UDP 9.53.150.67  traptag trapparms4 - - -
#-------------------------------------------------------------------------------------

The community names specified in the trap entries in the /etc/snmpd.conf file become part of the TARGET_PARAMETERS entries in the /etc/snmpdv3.conf file. The community names must be mapped to a specific TARGET_ADDRESS entry using the targetParams values. For example, community daniel is mapped with trapparms2, which, under the TARGET_ADDRESS entry, maps to IP address 9.3.149.49. Community daniel and IP address 9.3.149.49 were originally a trap entry in the /etc/snmpd.conf file. See the following example:

#--------------------------------------------------------------------------
# TARGET_PARAMETERS
#    Defines the message processing and security parameters
#    to be used in sending notifications to a particular management target.
# Format is:
#  paramsName mpModel securityModel securityName securityLevel storageType
TARGET_PARAMETERS trapparms1 SNMPv1  SNMPv1  public  noAuthNoPriv - 
TARGET_PARAMETERS trapparms2 SNMPv1  SNMPv1  daniel  noAuthNoPriv - 
TARGET_PARAMETERS trapparms3 SNMPv1  SNMPv1  vasu    noAuthNoPriv - 
TARGET_PARAMETERS trapparms4 SNMPv1  SNMPv1  david   noAuthNoPriv -
#--------------------------------------------------------------------------

The trapmask information in the /etc/snmpd.conf file does not migrate to the /etc/snmpdv3.conf file.

Step 4. Migrate the smux information

If you have smux information that you need to migrate, you can copy those lines directly into the new file. In this scenario, the sampled smux entry was configured in the /etc/snmpd.conf file. That line must be copied to the /etc/snmpdv3.conf file.

#--------------------------------------------------------------------------------------------
#       smux <client OIdentifier> <password> <address> <netmask>
smux            1.3.6.1.4.1.2.3.1.2.3.1.1         sampled_password  # sampled
#--------------------------------------------------------------------------------------------

Step 5. Stop and Start the snmpd daemon

After the migration of the /etc/snmpd.conf file to the /etc/snmpdv3.conf file is complete, stop and then start the snmpd daemon. You will need to stop and start the snmpd daemon each time you make changes to the /etc/snmpdv3.conf file.

Type the following command to stop the daemon:
```
stopsrc -s snmpd
```
Type the following command to restart the daemon:
```
startsrc -s snmpd
```

Note

Simply refreshing the SNMPv3 agent will not work as it did in SNMPv1. If you make changes to the /etc/snmpdv3.conf file, you must stop and start the daemon as instructed above. The dynamic configuration function supported in SNMPv3 will not allow you to refresh.