9.1.3.1 SNMPv3

• Overview

• Security Levels in SNMPv3

• Default Users of SNMPv3 Agents

• Developing a Sample V3 Agent

• Testing the SNMPv3 Agent with Default Users

• Adding More Users for v3 Agents (USM)

• Enabling Authorization in V3 Using VACM

• Authenticating Requests From v1/v2c Managers (Coexistence Support).

• Sending Notifications

Overview

The version 3 of Simple Network Management Protocol addresses some of the long pending issues related to the large scale deployment of SNMP. Due to lack of security in using SNMP, system and network administrators were using other means such as telnet, ascii, etc., for configuration, accounting, and fault management. The primary goal of SNMP version 3 (SNMPv3) is to define a secure version of the SNMP. SNMPv3 also facilitates remote configuration of the SNMP entities, which make remote administration

of SNMP entities a much simpler task.  

AdventNet has implemented SNMPv3 as defined from RFC2570 to RFC2576.

Security Levels in SNMPv3

As explained earlier, SNMP version 3 (SNMPv3) is used to provide a secured environment in managing the systems and networks. The SNMPv3 Agent supports the following set of security levels as defined in the USM MIB (RFC 2574) :

• noAuthNoPriv - Communication without authentication and privacy.

• authNoPriv - Communication with authentication and without privacy. The protocols used for Authentication are MD5 and SHA (Secure Hash Algorithm).

• authPriv - Communication with authentication and privacy. The protocols used for Authentication are MD5 and SHA and for Privacy, DES (Data Encryption Standard) protocol is used. For Privacy Support, you have to install some privacy packages. Please refer the topic "Supported Privacy Packages" for more details.

A framework for definition of different authentication and privacy protocols is available in V3. Currently, the MD5 and SHA authentication protocols and the CBC_DES privacy protocol are supported in USM.

Supported Privacy Packages

For privacy support, the Encryption packages that can be used are "Cryptix" and "JCE".

To make use of JCE classes  

• Download JCE classes 1.2 or 1.2.1 from the following URL:  http://java.sun.com/products/jce/

• In case JCE 1.2 classes are downloaded, you get the following jar : jce12-rc1-dom.jar

• In case JCE 1.2.1 classes are downloaded, you get the following four jars : jce1_2_1.jar; local_policy.jar; sunjce_provider.jar, and US_export_policy.jar

• Make sure the jars are placed under <Agent Toolkit Home> directory.

• Also make sure the jars are included in the setenv.bat file CLASSPATH (available in <Agent Toolkit Home>/bin directory)  in the beginning. Please note that the jars are required to be in the CLASSPATH settings of run.bat/sh file, that are used for running the Agent.

• Edit the java.security file present in the jre/lib/security folder under the JDK installed in your machine. And add the following piece of line below : security.provider.1=sun.
  
  security.provider.Sun security.provider.2=com.sun.crypto.provider.SunJCE
   

• Save the java.security file.

• The USMUtils.class required for encrypting v3 requests and responses is available in AdventNetSnmp.jar (<Agent Toolkit Home>/jars directory).

• Now, the v3Agent is ready for supporting Privacy.

Note : If JDK 1.4 is used, then JCE privacy jars are not required to be in the class path. 

To make use of Cryptix classes

• Download Cryptix classes 3.1 or 3.2  from the following URL:  http://www.cryptix.org/

• Make sure the jars are included in the setenv.bat file CLASSPATH (available in <Agent Toolkit Home>/bin directory)  in the beginning. Please note that the jars are required to be in the CLASSPATH settings of run.bat/sh file, that are used for running the Agent.

• The USMUtils.class required for encrypting v3 requests and responses is available in AdventNetSnmp.jar (<Agent Toolkit Home>/jars directory).

• Edit the java.security file present in the jre/lib/security folder under the JDK installed in your machine. And add the following piece of line below : security.provider.1=sun.security.provider.Sun
  
  security.provider.3=cryptix.provider.Cryptix
   

• Now, the v3 Agent is ready for supporting Privacy.

Export Restrictions

Encryption packages are bound by Export restrictions.

1. If JCE 1.2 or its implementations are used in developing application and applets, they cannot be used outside US and Canada.

2. JCE 1.2.1 does not have any export restrictions and it can be used in applications, which can be distributed throughout the world.

3. The latest JDK version ( JDK 1.4 beta ) comes integrated with the JCE 1.2.1.

4. Cryptix package does not have any such export restrictions.

Default Users of SNMPv3 Agents

By default, the SNMPv3 Agent provides support for three level of users, namely:

• noAuthUser - Users with security level noAuthNoPriv

• authUser - Users with security level authNoPriv

• privUser - Users with security level authPriv.#Security

The details about the users get stored in the XML or Serialized Files or Runtime Memory depending upon the type of storage option chosen. 

Developing a Sample V3 Agent

Please follow the steps given below to develop a Sample v3 Agent.

• Start the JMX Compiler application from <Agent Toolkit Home>/bin directory.

• Create a New Project with the name say : snmpproject01.

• Load any MIB from the MIBs directory say : AGENT-SAMPLE-MIB

• By default, the version of the Agent will be specified as V3 in the Project -> Settings menu.

• The Storage Type option chosen in the Project-> Settings menu -> Adaptors -> SNMP -> SNMPv3 Panel -> USM and VACM group will be XML. Keep the default settings.

• Generate code for the Agent. XML Files having the details of the v3 users will get generated under agent/bin/conf directory.

• On successful generation, compile the generated code.

• On successful compilation, a Sample V3 Agent is created.

Testing the SNMPv3 Agent With Default Users

Now that a Sample Agent is created, it has to be tested with the Default Users.

Testing the V3 Agent for noAuth Users

The default entry of noAuthUser in USM Table will be as follows. These details can

be viewed in the UsmUserTable.xml file or ser file generated under <Agent Toolkit Home>/jmxprojects/projectname/agent/bin/conf

directory.

To test the Agent for noAuthUser,

1. Make sure the Agent is started from <Agent Toolkit Home>/jmxprojects/projectname/agent/bin directory using run.bat or .sh file.

2. Start the MIB Browser application from <Agent Toolkit Home>/bin directory.

3. Load AGENT-SAMPLE-MIB.

4. Click MIB Browser Settings in the toolbar icon.

5. A wizard opens up wherein you have to choose the version of the Manager. Choose v3.

6. Click Add in this wizard. 

7. A Snmp Parameter Panel appears wherein the following details need to be filled : 

1. Target Host : localhost (by default)

2. Target Port : 8001.

3. User Name : noAuthUser

4. Security Level : noAuth,noPriv

5. Context Name : noAuth

8. Click OK.

9. The entry gets listed in v3 Settings.

10. Select the entry and click OK to close the MIB Browser Settings wizard.

11. Move on to the MIB Browser Main UI.

12. Now, test the SNMPv3 Agent by sending a query (say GET request) to the scalar variable agentDescr in the agentSystem group under the demo group. You will receive the response as
    Sent get request to localhost : 8001
    agentDescr.0:-->agentDescr not initialized

Testing the V3 Agent for authUsers

To test the Agent for authUser,

• Follow the steps given above (in Testing the Agent for noAuthUser) till setting the Target Port as 8001.

• Later, specify the User Name as authUser for this case.

• Select the Security Level as Auth,noPriv from the combo box.

• Specify the Authentication password as authUser.

• You can see the entry added in the Table. Select the entry and click OK to close the MIB Browser Settings wizard.

• Move on to the MIB Browser Main UI.

• Now, test the SNMPv3 Agent by sending a query (say GET request) to the agentDisk group under the demo group. 

• You will receive the response. If you try accessing the agentDescr of agentSystem group, you will not be able to access it as authUsers are not given View Access to that particular scalar variable. To know more on View-based Access, please refer to VACM.

Testing the Agent for Privacy Users

Default entry of privUser in USM Table :

To test the Agent for privUser,

• It is required to install all the jars necessary for Privacy support. Please follow the directions specified in Supported Privacy Packages.

• Then, follow the steps given in Testing the v3Agent for noAuthUsers till setting the Target Port as 8001.

• Later, specify the User Name as privUser.

• Select the Security Level as Auth,Priv from the combo box.

• Specify the Authentication password as authUser and Privacy password as privUser.

• Click OK.

• You can see the entry added in the Table. Select the entry and click OK to close the MIB Browser Settings wizard.

• Move on to the MIB Browser Main UI.

• Now, test the SNMPv3 Agent by sending a query to the agentDisk group under the demo group. You will receive the response without any problem.

Adding More Users for v3 Agents (USM)

User-based Security Model (USM) is a default security model defined by SNMPv3. It provides different types of security levels using various authentication and privacy protocols as explained earlier in this section. To add more users for accessing v3 Agents, AdventNet provides a table called the USMTable. User entries can be added to the Table either : (1) Before Agent Startup or (2) During Run Time.

Please note that though user entries are added these users will not be able to access the Agent unless View Access is given to them. Please refer to "Enabling Authorization in V3 using VACM" section for more details.

Before Agent Startup

Entries can be added to the USMTable before Agent Startup using any of the following options : (1)Using JMX Compiler UI or (2) Using XML/Ser Files/Runtime Memory or (3) Using API calls . 

Using JMX Compiler UI

1. Create a Project and load a MIB. 

2. Choose Project -> Settings menu from the menu bar of JMX Compiler UI. 

3. Select usmUserTable in the Adaptors -> SNMP -> SNMPv3 Panel.  

4. Click Add. 

5. A wizard pops up wherein you can specify the user entries.

6. Click OK. A new USM User entry gets added. 

Using XML/Ser File/Runtime Memory

The entries configured through JMX Compiler UI get stored in the configuration file "UsmUserTable.xml" after code generation. They get stored under <<Agent Toolkit Home>>/jmxprojects/projectname/agent/bin/conf directory, provided the type of storage is chosen.  To choose the Storage Type, 

1. Choose Project -> Settings menu of JMX Compiler UI. 

2. Select usmUserTable from the Adaptors -> SNMP -> SNMPv3 Panel -> USM Group. 

3. Choose XML or Serialization or Runtime Memory from the Storage Option. By default XML file is chosen.

This XML file can be edited to add new entries. Please note that the Agent has to be re-started for the changes to take effect.  The serialized formatted file cannot be edited to add new entries. They can be updated only by adding entries during runtime.  

Run time memory can be used to store the v3 users information in the Agent Memory itself. Using this option will not store the entries in ser files or xml files. After choosing the Runtime memory storage option,  follow the steps given in adding entries "From the Manager"  given under the heading "Adding Entries During Runtime". Please note that once the Agent is killed, the entries added are removed from the memory.

Using API Calls

Add the following piece of code in the Main file generated in the initializeV3Settings() method in case you want to add the entries using API calls. The following is a sample entry for adding a newUser entry.

snmpadaptor.getSnmpAgent().getUsmUserTableListener().createAndAddUSMUserEntry("newUser"

,new Integer(0) ,"0.0" ,new Integer(NO_AUTH) ,new Integer(NO_PRIV) ,"userPublic"

," " ," " ,new Integer(3) ,new Integer(1));

During Runtime

Entries can be added during run time from the Manager.  

From the Manager - Using a Command line Utility

To add entries from the Manager, it is important to enable the Remote Configuration option in "Project -> Settings menu -> Adaptors -> SNMP -> SNMPv3 panel". Else, it is not possible to access the Table from remote. 

• After enabling the Remote Configuration option (as said earlier),  make use of the command line tool "snmpUSMRemoteConfigure.java" available in <AdventNet/JavaAgent>/examples/snmp/low_level_udpapps directory.

• Go to run.bat or run.sh from the command prompt (available in the above specified directory)  and specify the following options. An user entry will be added to the USM Table using these options.

Usage : snmpUSMRemoteConfigure [-d dumps the messages] [-p agent port] [-r retries]

[-t timeout][-a auth_protocol] [-w auth_password] [-s priv_password] [-n contextName]

[-i contextID] [-y new_auth_password] [-z

new_priv_password] userName newUserName host

• For better understanding, please refer to the sample entry given below : 

<AdventNet\JavaAgent>\examples\snmp\low_level_udpapps>run snmpUSMRemoteConfigure

-d -p 8001 -a MD5 -w authUser -n auth -y xxxUser authUser xxxUser localhost 

• Here,

• -d :  dumps the SNMP message.

• -p 8001 : represents the Agent Port number.

• -a MD5 : represents the admin user's (template user) and new user's  authProtocol.

• -w adminUser : represents the admin user's authentication password.

• -n auth : represents the auth user's context name.

• -y xxxUser : represents the new user's authentication password.

• authUser : represents the existing template's user name.

• xxxUser: represents the new user's name.

• localhost : represents the host in which the Agent is running.

• If the user is added to the USMTable successfully "User S u c c e s s f u l l y cloned !!!" can be seen in the command prompt. Else an error will be displayed.

Changing the Password of an Existing User

The Manager can also change the password of an existing user, using the utility called "snmpUSMKeyChange.java" available in <Agent Toolkit Home>/examples/snmp/low_level_udpapps directory.

The usage of this utility is as follows:

Usage: snmpUSMKeyChange [-d] [-p port] [-r retries] [-t time-out] [-a

auth_protocol] [-w auth_password] [-s priv_password] [-n contextName] [-i contextID]

[-y new_auth_password] [-z new_priv_password] [ -ou user_name] [

-ow old_auth_password] [ -oz old_priv_password] userName  host

The password can be changed in the following ways:  

• Own AuthKey change.

• AuthKey Change on behalf of another user.

• Own PrivKey change.

• PrivKey Change on behalf of another user.

The following is an example for Own AuthKey change. Assuming that View access is given for the user, options are explained.

run snmpUSMKeyChange -d -p 8001 -a MD5 -w authUser -n auth -y authUserNew authUser

localhost

Here,  

• -d :  dumps the SNMPmessage.

•  -p 8001 : represents  Agent port number.

• -a MD5 : represents adminUser's authProtocol.

• -w authUser : represents  the adminUser's authentication password

• -n auth : represents authUser's context name.

• -z authUserNew : represents the new authentication password of the user authUser.

• authUser - represents the user whose authentication password will be changed.

• localhost - represents the host where the agent is running.

The above inputs will modify the authentication password of the user "authUser" from "authUser" to "authUserNew". The user's authentication protocol is "MD5".

Enabling Authorization in V3 Using VACM

View-based Access Control Model (VACM) is a default access control model defined by SNMPV3 frame work (RFC 2575). It is possible to restrict a particular group in accessing an OID in the MIB using VACM. SNMPv3 Agent has implemented the VACM MIB

as a default access control model.

Details for VACM

The details for View-based Access are to be specified in the four tables of VACM MIB namely:  

• vacmContextTable - This table will have a set of context names supported by the SNMPv3 Agent. The context name received will be checked with this table in the access validation phase. It is not configurable through SNMP.

• vacmSecurityToGroupTable - This table will have a set of security to group mappings. If the received context name is valid then the group name is obtained from this table by giving user (security) name and security model as an input. It is configurable through SNMP.

• vacmAccessTable - This table will have a set of access supported by the Agent. By giving group name, context name, security model, and security level, you can get a view name based on the received request type. It is configurable through SNMP.

• vacmViewTreeFamilyTable - This table will have a set of views supported by the Agent. By giving view name and received OID, you can specify whether the received request has valid view or not. It is configurable through SNMP.

Adding Entries to VACM Tables

An user can be given view access to a managed node by specifying their views in the VACM Tables. Entries can be added to the VACM Tables either : (1) Before Agent Startup or (2) During Run Time. Please note that only when all the vacm tables are configured

for an user will the user entry have view access. Lets have a look at the default entries in VACM Tables and move on to the steps involved in adding view access to users.

Default VACM Entries

VacmContextTable 

Context Name - noAuth, auth, priv

Vacm Security to Group Table

Vacm Group Access Table

Vacm View Tree Family Table

Adding Entries before Agent Startup

Entries can be added to the tables before Agent Startup using (1) JMX Compiler UI option or (2) Using XML/Ser files/Runtime Memory or (3) Using API calls.

Using JMX Compiler UI

1. Create a Project and load a MIB. 

2. Choose Project -> Settings menu from the menu bar of JMX Compiler UI. 

3. Select vacmContextTable in the Adaptors -> SNMP -> SNMPv3->VACM Panel. 

4. Now, Click Add. 

5. A wizard pops up wherein you can specify the user entries.

6. Click OK. 

Similarly other VACM Tables have to be populated.

Using XML/Ser File/Runtime Memory

The entries configured through JMX Compiler UI get stored in the configuration file, VacmContextTable.xml or VacmContextTable.ser (name of the table varies according to the table chosen) under <Agent Toolkit Home>/jmxprojects/projectname/agent/bin/conf

directory, provided the storage type is chosen. To choose the type of storage, 

1. Choose Project -> Settings menu from the menu bar of JMX Compiler UI. 

2. Select a table from the VACM group of Adaptors -> SNMP -> SNMPv3 Panel. 

3. Choose XML File or Serialization format or Runtime Memory from the Storage Type Options provided. By default XML File is chosen. 

4. Choosing this would generate files in xml or serialized for each table in the VACM group.

These XML files can be edited to add new entries.  Please note that the Agent has to be re-started for the changes to take effect. The serialized formatted file cannot be edited to add new entries. They can be updated only by adding entries during runtime.  

Run time memory can be used to store the v3 users information in the Agent Memory itself. Using this option will not store the entries in ser files or xml files. After choosing this storage option,  follow the steps given in adding entries "From the Manager"  given under the heading "Adding Entries During Runtime". Please note that once the Agent is killed, the entries added are removed from the memory.

Using API calls

These code snippets have to be added in the main file generated in the initializeV3Settings() method. Adding the piece of code will add new entries in the vacm tables.

Adding entries to the vacmContextTable

snmpadaptor.getSnmpAgent().getVacmContextTableListener().createAndAddVacmContextEntry("newNoAuth");

Adding entries to the vacmSecurityToGroupTable

snmpadaptor.getSnmpAgent().getVacmSecurityToGroupTableListener().createAndAddVacmGroupEntry(new

Integer(3), "newNoAuthUser", "newNoAuthGrp", new Integer(3), new Integer(1));

Adding entries to the vacmAccessTable

snmpadaptor.getSnmpAgent().getVacmAccessTableListener().createAndAddVacmAccessEntry("authGrp",

"newNoAuth", new Integer(3), new Integer(0), new Integer(1), new String("newNoAuthView"),

new String("newNoAuthView"), new String("newNoAuthView"), new Integer(3), new Integer(1));

Adding entries to the vacmViewTreeFamilyTable

snmpadaptor.getSnmpAgent().getVacmViewTreeFamilyTableListener().createAndAddVacmFamilyEntry("newNoAuthView",

".1.3.6", "ff", new Integer(1), new Integer(3), new Integer(1));

Adding entries during Run Time

You can also add entries to the tables during run time. 

From the Manager

To configure the Agent from the Manager, follow the steps given below:

• Start the MIB Browser application.

• Load SNMP-VIEW-BASED-VACM MIB from <Agent Toolkit Home>/mibs directory.

• This MIB contains four tables in which the View-based Access control has to be configured.

• Selecting the respective table and clicking SNMP Table icon in MIB Browser open up a wizard wherein entries can be added to the required Tables by sending SET requests.

• Please note that vacm context table is not configurable from the Manager (remotely).

Note : The User-based Security Model (USM) and View-based Access Control (VACM) Tables are implemented by default when the Agent is started as SNMP Version 3 Agent.

Authenticating Requests From v1/v2c Managers (Coexistence Support)

In a typical deployment scenario, the management applications and applets will be required to communicate with SNMP Agents of different versions. They will also be required to communicate with multilingual agents, i.e., SNMP Agents that support all the three SNMP versions (v1, v2c and v3 ).

The multilingual  SNMP Agents  support multiple SNMP message versions and coexist with entities which support only a single SNMP message version. So, management applications with SNMPv1 or v2c support  can also communicate with SNMPv3 agents.

This is called as coexistence in v3 as defined in RFC 2576. SNMPv3 Agent entities with coexistence support  implement the SNMP-COMMUNITY-MIB. This MIB contains objects for mapping between community strings and version-independent SNMP  message parameters. Apart from this , a complete implementation of Coexistence Support require the implementation of SNMP-TARGET-MIB. The implementation of this MIB facilitates the source address validation on the incoming requests.

In case the Agent is strictly v3, it will drop the requests sent from v1/v2c Managers. To know how to make an Agent strictly v3, please refer to Making the Agent Strictly V3" (14.11) topic.   

14.10.1 Enabling Co-existence Support

You can enable Coexistence Support either through JMX Compiler UI or through API Calls.

Using JMX Compiler UI  

• Create a Project and Load a MIB.

• Select Project -> Settings menu from the menu bar of JMX Compiler UI.

• From the Adaptors -> SNMP -> General Panel, check Target, Community and Notification MIB Support option.

• This will enable Coexistence Support and Notification Filtering Support  (Notification Support is explained under "Sending Notifications" topic in this section).

Using API calls

On enabling the option in JMX Compiler UI, the following code gets generated in the Main file. Without enabling the option in UI, you can enable Coexistence by adding the following line of code before the code for restarting SNMP Agent.

super.getSnmpAPI().setCommunityAuthentication(true);

Once the community Authentication is set as true, the Agent is ready to authenticate requests from all Managers. Thus Co-Existence is enabled.

Note : To enable Coexistence Support and add a new entry to the Table, the following import statement has to be included in the Main file.  import com.adventnet.snmp.snmp2.agent.community.*;

Default Users of Coexistence Support

The Tables of Community MIB and Target MIB used for Coexistence support include SnmpCommunityTable,

SnmpTargetAddrTable, and SnmpTargetAddrExtTable. The configurations present by default

in these Community tables are as follows:

SnmpCommunityTable

SnmpTargetAddrTable

SnmpTargetAddrExt Table

Adding Managers for Supporting Coexistence

Manager entries can be added to the Community Tables either : (1) Before Agent Startup or (2) During Run time.

Before Agent Startup

Entries can be added to the Target and Community tables either using the option in JMX Compiler UI or using API calls or using the XML files/Serialized file/Runtime memory storage options.

Using JMX Compiler UI

1. Create a Project and load a MIB. 

2. Choose Project -> Settings menu from the menu bar of JMX Compiler UI. 

3. Select a table under the Community or Target group in SNMPv3 Panel. 

4. Now, Click Add. 

5. A wizard pops up wherein you can specify the user entries for each table.

6. Click OK.  The entries are added. 

7. Following the same steps add entries in all the Community and Target Tables.

Using XML/Ser File/Runtime Memory

The entries configured through JMX Compiler UI get stored in the configuration file, USMTable.xml under <Agent Toolkit Home>/jmxprojects/projectname/agent/bin/conf directory, provided the storage type is chosen. For this purpose, 

1. Choose Project -> Settings menu from the menu bar of JMX Compiler UI. 

2. Select Community Table/ Target Tables from the Adaptors -> SNMP -> SNMPv3 Panel. 

3. Choose XML or Serialized or Runtime Memory from the Storage Option. By default xml is chosen.

Please note that the Agent has to be re-started for the changes to take effect. 

Run time memory can be used to store the v3 users information in the Agent Memory itself. Using this option will not store the entries in ser files or xml files. After choosing the storage option,  follow the steps given in adding entries "From the Manager"  given under the heading "Adding Entries During Runtime" . Please note that once the Agent is killed, the entries added are removed from the memory.

Using API Calls

The code snippet required for configuring the tables for Coexistence support through API calls is provided below. Add these sample codes in the main file generated before the code for restarting the SNMP Agent.

SnmpCommunityTable

snmpadaptor.getSnmpAgent().getSnmpCommunityTableListener().createAndAddCommunityEntry("newpublic",

"newpublic", "newUser", "127.0.0.18003", "newNoAuth", "newTag", new Integer(3), new

Integer(1));

SnmpTargetAddressExtTable

snmpadaptor.getSnmpAgent().getSnmpTargetAddrExtTableListener().createAndAddSnmpTargetAddrExtEntry("localHost1",

new Integer(484), "ff");

SnmpTargetAddressTable

snmpadaptor.getSnmpAgent().getSnmpTargetAddrTableListener().createAndAddSnmpTargetAddrEntry("localHost1",

".1.3.6.1.6.1.1", "127.0.0.1#8003", new Integer(5), new Integer(1), "newTag","addressParamsName",

new Integer(3), new Integer(1));

During Run Time - From the Manager

To Configure the Agent from the Manager,

• Start the MIB Browser application.

• Load SNMP-COMMUNITY-MIB from <Agent Toolkit Home>/mibs directory.

• This MIB contains the SnmpCommunityTable, SnmpTargetAddrTable, and SnmpTargetAddrExtTable in which v3 user entries can be added for Community Authentication.

• Selecting the respective table and clicking SNMP Table icon in MIB Browser will open up a wizard wherein entries can be added to the required Tables by sending SET requests.

Note : By default Co-Existence and Notification Filtering is not available for a v3 Agent. The option for enabling this is available in the Project - > Settings menu -> Adaptor -> SNMP -> General Panel of JMX Compiler UI.

Sending Notifications

SNMPv3 Notification PDU though similar to SNMPv2 Notification PDU, differs in the message format. It contains SNMPv3 message headers such as message ID,  version, security level, maximum supported size, security model, etc., and security parameters depending upon the security model and scoped PDU parameters such as context name, context engine ID, varbinds, etc.

Notifications can be sent to both v3 Managers (using the Manager information in v3Trap ForwardingTable) and v1/v2c Managers (using Notification Filtering Mechanism). Please go through the following topics for more details.

Notifications To v3 Managers

SNMPv3 frame work recommends SNMP-TARGET-MIB to identify the targets for sending Notifications, which is implementation specific . AdventNet Toolkit has a proprietary table called the V3 Trap Forwarding Table that contains all the information of the

target. For more information about this table, please refer to Traps section. This section explains how Traps can be sent from v3 Agents to v3 Managers using v3 Trap Forwarding Table.

Notifications to v1/v2c Managers

The Trap Forwarding Table mentioned above is by default bilingual in nature. Hence can forward Notifications from a v3 Agent to v1/v2c Managers also. If the proprietary implementation is not required, then you can go for the Notification Filtering Mechanism

support which is implemented as per RFC 2573.  

Enabling Notification Filtering Support

Notification Filtering support can be enabled using JMX Compiler UI or using API calls.

Using JMX Compiler UI

• Create a Project and Load a MIB.

• Select Project -> Settings menu from the menu bar of JMX Compiler UI.

• From the Adaptors -> SNMP ->General Panel, check Target, Community and Notification Support option.

• This will enable Coexistence Support and Notification Filtering Support. (Coexistence is explained under "Authenticating v1/v2c Requests" topic in this V3 section).

Using API Calls

Notification Filtering support can also be availed in AdventNet SnmpV3 Agent by adding the following piece of code in the main file before the code for restarting the Agent.

super.getSnmpAPI().setNotificationFiltering(true);

Note : While enabling Notification Filtering Support through API calls and adding a new entry to the Tables, the following import statement has to be included in the Main file (in the beginning).  

import com.adventnet.snmp.snmp2.agent.notification.*;

Coexistence support should also be enabled to support Notification Filtering Mechanism. Hence, include the API calls and the imports for the same.

Default Users for Notification Filtering Support

The Tables of Notification MIB and Target MIB used for Filtering Mechanism support include SnmpTargetAddrTable, SnmpTargetParamsTable, SnmpNotifyTable, SnmpNotifyFilterProfileTable, and SnmpNotifyFilterTable. The default configurations present in these Notification Filtering Tables are as follows:

SnmpTargetParamsTable

SnmpNotifyTable

SnmpNotify FilterProfileTable

SnmpNotify FilterTable

Adding Managers to the Notification Tables

After enabling Notification Filtering Support, it is required to specify the v1/v2c Managers to whom these Notifications should be sent. Manager Entries can be added to the Notification tables either : (1) Before Agent Startup or (2) During Run Time.

Before Agent Startup - 

Using JMX Compiler UI

1. Create a Project and load a MIB. 

2. Choose Project -> Settings menu from the menu bar of JMX Compiler UI. 

3. Select a table from the Notification Group in Adaptors -> SNMP -> SNMPv3 Panel. 

4. Now, Click Add. 

5. A wizard pops up wherein you can specify the user entries.

6. Click OK. Thus the entries get added to the table selected.

7. Following the same steps add entries to all the tables in the Notification group.

Using XML File/Ser File/Runtime Memory

The entries configured through JMX Compiler UI get stored in the configuration file, NotificationTable.xml under <Agent Toolkit Home>/jmxprojects/projectname/agent/bin/conf directory, provided the storage type is chosen. For this purpose, 

1. Choose Project -> Settings menu from the menu bar of JMX Compiler UI. 

2. Select each table in the Adaptors -> SNMP -> SNMPv3 Panel -> Notification Group. 

3. Choose XML or Serialized or Runtime Memory from the Storage Option. By default xml is chosen. 

4. By choosing either of the option for each Notification related table, a file gets generated either in xml or serialized format. By default the storage type chosen is xml.

These XML files can be edited to add new entries.  Please note that the Agent has to be re-started for the changes to take effect. 

Run time memory can be used to store the v3 users information in the Agent Memory itself. Using this option will not store the entries in ser files or xml files. After choosing the storage option,  follow the steps given in adding entries "From the Manager"  given under the heading "Adding Entries During Runtime" . Please note that once the Agent is killed, the entries added are removed from the memory.

Using API calls

To add the entries, follow the links and include the code (given under respective links) in the generated main file.

SnmpTargetAddrTable

snmpadaptor.getSnmpAgent().getSnmpTargetAddrTableListener().createAndAddSnmpTargetAddrEntry("localHost1",

".1.3.6.1.6.1.1", "127.0.0.1#8003", new Integer(5), new Integer(1), "newTag","addressParamsName",

new Integer(3), new Integer(1));

SnmpTargetParamsTable

snmpadaptor.getSnmpAgent().getSnmpTargetParamsTableListener().createAndAddSnmpTargetParamsEntry("advent1",

new Integer(3), new Integer(3), "newUser", new Integer(0), new Integer(3), new Integer(1));

SnmpNotifyTable

snmpadaptor.getSnmpAgent().getSnmpNotifyTableListener().createAndAddSnmpNotifyEntry("localhost2",

"public", new Integer(1), new Integer(3), new Integer(1));

SnmpNotifyFilterTable

snmpadaptor.getSnmpAgent().getSnmpNotifyFilterTableListener().createAndAddSnmpNotifyFilterEntry("advent1",

".1.3.6", "ff", new Integer(1), new Integer(3), new Integer(1));

SnmpNotifyFilterProfileTable

snmpadaptor.getSnmpAgent().getSnmpNotifyFilterProfileTableListener().createAndAddSnmpNotifyFilterProfileEntry("advent1",

"newProfile", new Integer(3), new Integer(1));

During Run Time - From the Manager

To configure the Agent from the Manager,

• Start the MIB Browser Application.

• Load SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB from <Agent Toolkit Home>/mibs directory.

• These MIBs contain the SnmpTargetAddrTable, SnmpTargetParamsTable, SnmpNotifyTable,

• SnmpNotifyFilterTable, and SnmpNotifyFilterProfileTable in which Notification Filtering

• Support is to be configured.

• When you select the respective table and click SNMP Table icon (View SNMP Table Data

• icon), MIB browser opens up a wizard wherein entries can be added to the required

• Tables.

• Click OK and you can see the entries added to the Table.

• Check for the same by sending a GET request to the Table.

Testing Notification Filtering Support

Now that you have enabled this feature and added entries to the Notification Table, the next step is checking whether the Agent works with this support. To ensure the same, follow these steps:

• Start the MIB Browser application.

• Load the MIB with which v3 Agent is developed.

• Configure the MIB Browser settings. The Manager has to be of v1 or v2c type for testing purpose.

• Start the v3 Agent.

• Send a SET Request to a variable in the MIB for which Notification is defined.

• Values should be set and Notification should be generated.

• Notifications can be viewed in the Trap Viewer of MIB Browser application.