14.0 Configuring SNMPv3 Agents

 

14.1 Overview

14.2 Security Levels in SNMPv3

14.3 Default Users of SNMPv3 Agents

14.4 Developing a Sample V3 Agent

14.5 Testing the SNMPv3 Agent with Default Users

14.6 Adding More Users for v3 Agents (USM)

14.7 Storing Details of V3 Users in Your Own Model

14.8 Enabling Authorization in V3 Using VACM

14.9 Using USM Without VACM

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

14.11 Making the Agent Strictly SNMPv3

14.12 Sending Notifications

14.13 Making the SNMP Agent Compliant to SNMPv3

 

14.1 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.

 

WebNMS has implemented SNMPv3 as defined from RFC2570 to RFC2576.

 

14.2 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 SNMP-FRAMEWORK-MIB (RFC 2571) :

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.

 

14.2.1 Supported Privacy Packages

 

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

14.2.1.2 To make use of Cryptix classes

    security.provider.3=cryptix.provider.Cryptix

14.2.2 Export Restrictions

 

Encryption packages are bound by Export restrictions.

14.3 Default Users of SNMPv3 Agents

 

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

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

 

14.4 Developing a Sample V3 Agent

 

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

  1. Start the MIB Compiler application from <Agent Toolkit Home>/bin directory.

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

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

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

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

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

  7. On successful generation, compile the generated code.

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

14.5 Testing the SNMPv3 Agent With Default Users

 

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

 

14.5.1 Testing the V3 Agent for noAuth Users

 

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

To test the Agent for noAuthUser,

    1. Make sure the Agent is started from <Agent Toolkit Home>/snmpprojects/snmpproject01/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 :

    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

 

14.5.2 Testing the V3 Agent for authUsers

 

Default entry of authUser in USM Table

To test the Agent for authUser,

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

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

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

    4. Specify the Authentication password as authUser.

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

    6. Move on to the MIB Browser Main UI.

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

    8. 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.

14.5.3 Testing the Agent for Privacy Users

 

Default entry of privUser in USM Table

To test the Agent for privUser,

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

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

    3. Later, specify the User Name as privUser.

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

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

    6. Click OK.

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

    8. Move on to the MIB Browser Main UI.

    9. 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.

There is also an example available in <Agent Toolkit Home>/examples/snmp/snmpv3/simpleagent directory which will give you a clear idea of a Simple v3 Agent. Please refer readme.html for more information.

 

14.6 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, WebNMS 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.

 

14.6.1 Before Agent Startup

 

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

 

Using MIB Compiler UI

    1. Create a Project and load a MIB.

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

    3. Select usmUserTable in the 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 Mib Compiler UI get stored in the configuration file "UsmUserTable.xml" after code generation. They get stored under <Agent Toolkit Home>/snmpprojects/projectname/agent/bin/conf directory, provided the type of storage is chosen. To choose the Storage Type,

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

    2. Select usmUserTable from the 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"(14.6.2) . 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.

    usmUserTableListener.createAndAddUSMUserEntry("newUser", new Integer(0), "0.0", new Integer(com.adventnet.snmp.snmp2.usm.USMUserEntry.NO_AUTH), new Integer(com.adventnet.snmp.snmp2.usm.USMUserEntry.NO_PRIV), "userPublic", " ", " ", new Integer(3), new Integer(1));

14.6.2 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 -> SNMPv3 panel". Else, it is not possible to access the Table from remote.

    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

14.6.2.1 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:

The password can be changed in the following ways:

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

Here,

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

 

14.7 Storing Details of V3 Users in Your Own Model

 

SNMP V3 agent, by default, gets started reading the USM and VACM configurations in the snmpv3.ser file, a serialized file in an unreadable format. In case you want the USM and VACM details to be stored elsewhere, say for example in a database format, and if you expect the v3 agent to read the configurations from that database then you will have to implement certain interfaces provided by Agent Toolkit. These interfaces will implement your methods based on your application. On initializing these interfaces, the V3 details will be read from that method.

 

14.7.1 Interfaces Used

 

The two interfaces used for this feature are:

14.7.1.1 V3Initialiser Interface

 

An example class is provided here as a reference. The following line in the main file registers a V3InitialiserImpl to the SnmpAgent.

This class contains API calls to the various V3 tables supported by the Agent. When the Agent is started, the initializing methods in this V3Initialiser class recalled with the respective table given as the parameter. For example, the initialiseUsmUserTable() is called, passing down the instance of the USMTable used by the SnmpAgent.

 

It is your responsibility to fill this table with the proper values for which the Agent will authenticate the requests.

 

Say for example, the following code adds an USMUser with the NO_AUTH_NO_PRIV security level to the USMTable.

The above code adds an USM User with the following parameters.

Similarly, VACM Group table, VACM Access Table and VACM Family Table are populated. The other tables like TargetAddrExtTable, TargetParamsTable, NotifyTable, NotifyFilterTable, NotifyFilterProfileTable are also to be initialized when implementing V3 Initializer.

 

14.7.1.2 RemoteV3Client Interface

 

Similar to the V3Initialiser Interface, this interface is implemented and registered to the SNMP Agent through the method addRemoteV3Client. When any addition, deletion, or modification of entry needs to be made in the USM / VACM tables, the RemoteV3Client Interface is used. The methods to add, delete, or modify the entries can be implemented inside the interfaces based on your application.

 

For example, the following method gets called when there is any addition in the USM table.

In this example, the Agent is made to apply the modification in the serialized file itself. But in normal circumstances, you will be storing the details elsewhere.

 

14.7.2 Running the Example

 

To know more on v3 user storage model, make use of the example present in <Agent Toolkit Home>/examples/snmp/snmpv3/remotev3initialiser directory. Also, refer to the readme.html which helps in running the example.

 

14.8 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.

 

14.8.1 Details for VACM

 

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

14.8.2 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.

 

14.8.2.1 Default VACM Entries

 

VacmContextTable

 

Context Name - noAuth, auth, priv

 

Vacm Security to Group Table

    Model Security Name

    Group Name

    USM (3)

    noAuthUser

    noAuthGroup

    USM (3)

    authUser

    authGroup

    USM (3)

    privUser

    privGroup

    1

    noAuthUser

    noAuthGroup

    2

    noAuthUser

    noAuthGroup

Vacm Group Access Table

Vacm View Tree Family

    View Name

    Mask

    		 Type

    Sub Tree

    noAuthView

    ff

    included

    1.3.6

    authView

    ff

    included

    1.3.6

    privView

    ff

    included

    1.3.6

14.8.2.2 Adding Entries before Agent Startup

 

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

 

Using MIB Compiler UI

    1. Create a Project and load a MIB.

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

    3. Select vacmContextTable in the 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 MibCompiler 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>/snmpprojects/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 MIB Compiler UI.

    2. Select a table from the VACM group of 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

    vacmContextTableListener.createAndAddVacmContextEntry("newNoAuth");

Adding entries to the vacmSecurityToGroupTable

    vacmSecurityToGroupTableListener.createAndAddVacmGroupEntry(new Integer(3), "newNoAuthUser", "newNoAuthGrp", new Integer(3), new Integer(1));

Adding entries to the vacmAccessTable

    vacmAccessTableListener.createAndAddVacmAccessEntry("authGrp", "newNoAuth", new Integer(3), new Integer(0), new Integer(1), "newNoAuthView", "newNoAuthView", "newNoAuthView", new Integer(3), new Integer(1));

Adding entries to the vacmViewTreeFamilyTable

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

14.8.2.3 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:

14.9 Using USM Without VACM

 

To make use of USM without VACM, follow the steps given below :

 

You have to include the following statement in the generated Main file after the code for restarting the Agent. The statement actually turns off the VACM check, that is, the VACM check always returns true.

 

super.getSnmpVacm().setAcmUsed(false);

 

14.10 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 MIB Compiler UI or through API Calls.

 

Using MIB Compiler UI

Using API calls

 

On enabling the option in MibCompiler 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.

14.10.2 Default Users of Coexistence Support

 

The Tables of Community MIB and Target MIB used for Coexistence support include SnmpCommunityTable, SnmpTargetAddrTable, SnmpTargetParamsTable, and SnmpTargetAddrExtTable. The configurations present by default in these Community tables are as follows:

 

SnmpCommunityTable

SnmpTargetAddrTable

SnmpTarget AddrName SnmpTarget

14.10.3 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 MIB Compiler UI or using API calls or using the XML files/Serialized file/Runtime memory storage options.

 

Using MIB Compiler UI

    1. Create a Project and load a MIB.

    2. Choose Project -> Settings menu from the menu bar of MIB 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 Mib Compiler UI get stored in the configuration file, USMTable.xml under <Agent Toolkit Home>/snmpprojects/projectname/agent/bin/conf directory, provided the storage type is chosen. For this purpose,

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

    2. Select Community Table/ Target Tables from the 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

    snmpCommunityTableListener.createAndAddCommunityEntry("newpublic", "newpublic", "newUser", "127.0.0.18003", "newNoAuth", "newTag", new Integer(3), new Integer(1));

SnmpTargetAddrExtTable

    snmpTargetAddrExtTableListener.createAndAddSnmpTargetAddrExtEntry ("localHost1", new Integer(484), "ff");

SnmpTargetAddrTable

    snmpTargetAddrTableListener.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,

14.11 Making the Agent Strictly SNMPv3

 

Please follow the steps given below to make an SNMPv3 Agent strictly V3 :

 

After generating the Agent as V3, override the callback method of SNMP Agent by adding the following code in the Main File.

 

/* User code starts here */

/**

* Overriding the callback of the SnmpAgent.

* This method will be called by the SnmpSession class . We check

* for the Pdu's version and if it is not V3, drop the PDU.

* else call the SnmpAgent's callback.

* @param sess - the SnmpSession which handles the request.

* @param pdu - the incoming request PDU

* @param reqid - the unique identifier for the request PDU maintained by

* the SnmpSession

* @return boolean indicating if the request is processed or not.

*/

public boolean callback(SnmpSession sess, SnmpPDU pdu,int reqid ){

if(pdu.getVersion() <SnmpAPI.SNMP_VERSION_3)

{

System.out.println("Lower Version received ...dropping the PDU");

return false;

}

else

return super.callback(sess,pdu,reqid);

}

/* User code ends here */

 

Adding this method drops the requests from v1 and v2c Managers. Save the file and compile it. Start the MIB Browser application and test the V3 agent by sending a v2c request. The request will be dropped.

 

14.12 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.

 

14.12.1 Notifications To v3 Managers

 

SNMPv3 frame work recommends SNMP-TARGET-MIB to identify the targets for sending Notifications, which is implementation specific . WebNMS 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.

 

14.12.2 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.

 

14.12.2.1 Enabling Notification Filtering Support

 

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

 

Using MIB Compiler UI

Using API Calls

 

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

    super.getSnmpAPI().setNotificationFiltering(true);

14.12.2.2 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

14.12.2.3 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 MIB Compiler UI

Using XML File/Ser File/Runtime Memory

 

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

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

    snmpTargetAddrTableListener.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

    snmpTargetParamsTableListener.createAndAddSnmpTargetParamsEntry("zohocorp1", new Integer(3), new Integer(3), "newUser", new Integer(0), new Integer(3), new Integer(1));

SnmpNotifyTable

    snmpNotifyTableListener.createAndAddSnmpNotifyEntry("localhost2", "public", new Integer(1), new Integer(3), new Integer(1));

SnmpNotifyFilterTable

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

SnmpNotifyFilterProfileTable

    snmpNotifyFilterProfileTableListener.createAndAddSnmpNotifyFilterProfileEntry("zohocorp1", "newProfile", new Integer(3), new Integer(1));

During Run Time - From the Manager

 

To configure the Agent from the Manager,

14.12.2.4 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:

14.13 Making the v3Agent Compliant to SNMPv3 Standards

 

The SNMPv3 Agent can be made compliant to SNMPv3 Standards. This topic deals with Snmpv3 Compliance support provided by WebNMS Agent Toolkit.

 

14.13.1 Enabling SNMPv3 Compliance

 

By default, v3Compliance is enabled in the Agent. If version v3 is disabled, v3 compliance also gets disabled. Version v3 can be enabled or disabled in

    Project -> Settings menu -> General Panel of MIB Compiler UI.

V3 compliance can also be enabled using API calls. The following piece of code gets generated in the Main file by default. By setting the value as true or false, v3 compliance is enabled or disabled respectively.

    super.setSnmpV3Compliance(true);

'super' here represents SNMPAgent.

 

14.13.2 Supported MIBs

 

SNMPv3 Compliance supports the following RFCs along with their implementations.

Please have a look at the standard RFC documents for more information.

 

Copyright © 2013, ZOHO Corp. All Rights Reserved.