Implementing SNMP Proxy

 

 

Overview

 

In original model of SNMP Management, it is a monolithic Agent that used to carry out all the management responsibilities on a given  network element (node). This solution was not flexible enough to provide an effective management of increasingly complex and distributed systems. In addition to the Agents typically provided by computer manufacturers for hardware and operating system information, Agents are also produced by other software vendors for SQL, Application servers, etc.

 

Also in distributed systems where different components of the product will be present in different network nodes (different IP address), each component needs its own management requirement for which each component will have an SNMP Agent. However, there should be a single gateway for managing the entire product (distributed components). This disadvantage of the original SNMP model, being unable to accommodate such complex and heterogeneous systems, is solved using Master - sub-agent concept where the Master Agent acts as a proxy for other SNMP Agents. WebNMS Agent Toolkit provides generic comprehensive Master sub-agent architecture for making Agents sub-agent to Master Agent on the fly. This dynamic behavior can be accomplished by the "Dynamic Registration concept in Master sub-agent Architecture".

 

j_snmp_proxy_commn.jpg

 

SNMP Master Agent

 

The Master Agent is an entity or process on a managed node that exchanges SNMP messages with the Management applications, such as WebNMS Framework, HP Openview, IBM Tivoli, etc. It acts as a primary interface between the Network Manager and sub-agents.

 

SNMP Sub-Agent

 

Sub-agents are processes that access the management information and provide manageability to various applications/components within a system. These sub-agents interact with the Master Agent using SNMP.

 

Creating Master Agent

 

All the SNMP Agents generated using Agent Compiler can act as both Master Agent and sub-agent. By default, the generated Agent acts as a standalone monolithic Agent. Follow the steps given below to make the standalone SNMP Agent, a Master Agent.

 

Define the Macro

 

To enable Proxy define the following MACRO in the config.h file present in

 

define PROXY_REMOTE_IFC

 

This implements Proxy.

 

Using Agent Compiler UI

 

The Macro also gets defined when the option for Proxy is enabled in the Agent Compiler UI settings.

  1. Create a Project and Load a MIB (MIB that you would like to make as a Master Agent).

  2. Select Settings -> Project Settings option from the menu bar of Agent Compiler UI.

  3. In the Settings tree, select Protocols -> SNMP -> Proxy -> General. The Proxy General dialog is displayed.

  4. Select the option Generate Agent with Proxy.

  5. After selecting these options, generate and compile the code.

  6. The Agent gets created as a Master Agent with Proxy support.

  7. By default you will have a sub-agent entry registered for every type of Proxy Table.

  8. To register more sub-agents, refer to the topic Registering sub-agents in the Master Agent.

note_nc.jpg

Note: Master Agent can be created with or without using a MIB.

 

Creating Sub-Agent

 

All the SNMP Agents generated using Agent Compiler can act as both Master Agent and sub-agent. By default, the generated Agent can directly act as a sub-agent. There is no specific option to make an Agent act as a sub-agent. Any SNMP Agent can act as a sub-agent. Sub-agent's particular host and port number are to be registered in the Master Agent. So, create a simple Agent using a MIB (from which you prefer to access the details) and make it act as a sub-agent.

 

UDP TCP dependency between Master Agent - Sub-Agent

 

In earlier release versions, the communication protocol used between the Master Agent and sub-agent was the same as that used by the Master Agent to communicate to the Manager. For example, if the Transport protocol configured for the Master Agent is TCP, the communication between the Master Agent and sub-agent must also be TCP. This dependency between the Master Agent and sub-agent is now removed.

 

The C Agent Toolkit provides a new option "sub-agent Transport Protocol" in the Agent Compiler, in addition to the "Transport Protocol" option. The option "sub-agent Transport Protocol" is enabled only if the agent is generated as a Proxy Agent to specify the communication between the Master agent and sub-agent. The option "Transport Protocol" is used to specify the communication between the Agent and Manager.

 

The Transport protocols supported are

 

TCP : If the "sub-agent Transport Protocol" is configured as TCP, the communication between the Master Agent and sub-agent will be TCP. The communication between the Master Agent and Manager may be either TCP or UDP, depending on the Transport Protocol chosen.

 

UDP: If the "sub-agent Transport Protocol" is configured as UDP, the communication between the Master Agent and sub-agent will be UDP. The communication between the Master Agent and Manager may be either TCP or UDP, depending on the Transport Protocol chosen.

 

Thus four combinations are possible :

 

Communication between Master Agent - Manager Communication between Master Agent - Sub-agent

TCP

UDP

UDP

TCP

TCP

TCP

UDP

UDP

 

If the sub-agent communicates directly with the manager, the communication between the sub-agent and the Manager may be either TCP or UDP depending on the Transport Protocol chosen.

 

Registering Sub-Agents in the Master Agent

 

The Master Agent maintains the proxy table which is used to store sub-agents information. Each entry/row in this table refers to one sub-agent. Each row has one sub-agent's information, such as OID, context name, instance value, ipaddress, port number, community, version, timeout, retries, etc. Adding an entry to this table means we are registering one sub-agent in the master agent.

 

note_nc.jpg

Note: A row in the proxy table (sub-agent) is uniquely identified by the index columns of the Table : proxyOid, proxyContextName, and proxyEntryInstance.

 

The following table explains each column information in detail.

 

Table Column Name Usage

ProxyOid

The OID to be proxied, i.e. if the master agent receives a request whose OID value less than the registered OID value or starts with registered OID value then it will forward that request to the corresponding sub-agent.

Proxy ContextName

The context name provided to the sub-agent, i.e. if more than one sub-agent implements the same MIB or same subtree of a MIB, the proxy agent identifies the sub-agent based on this context name.

Proxy EntryInstance

The Instance value of the SNMP Table for which the sub-agent is registered, i.e. if more than one sub-agent implements different instance of the same SNMP Table, the proxy agent identifies the sub-agent based on the instance value provided for the sub-agent.

Proxy Host Type

Specifies whether the Sub-Agent's IpAddress is IPv4 or IPv6 Address. This field will be used only when the Master (Proxy) Agent is going to run in IPv6 Address

ProxyHost

The sub-agent host IP address or name

ProxyPortNumber

The port at which the sub-agent is running.

ProxyCommunity

The community string is used for the SNMPv1 and v2c communication.

SNMP version

SNMP version is used for the communication between the master agent and particular sub-agent.

ProxyTimeOut

The time out value to receive a response from the sub-agent.

ProxyRetries

The number of retries, if the request send to the sub-agent is timed out.

ProxyStatus

The status of the sub-agent, if it is active then only the master agent will send the request to the corresponding sub-agent. It is used for the SNMP remote configuration.

 

Default Entry Generated in the Proxy Table

 

Proxy OID

 Proxy Context Name proxy Entry Instance

Proxy Host Type

Proxy Agent IP Address

 Proxy Agent Port Number SNMP version community Timeout Retries Row Status

.1.3.6.1.2.1.1

default

.0.0

1

127.0.0.1

161

SNMP_VERSION_1

public

5(seconds)

0

ACTIVE

 

There are two ways to register sub-agents in the Master Agent. It can be done either : (1) Before Agent Startup or (2) During Run Time.

 

Before Agent Startup

 

By registering the sub-agent to the Master Agent before Agent startup, the sub-agent information is hard-coded in the C file. Here, sub-agent information is given during the development time. To register the sub-agent,

 

1. Using Agent Compiler UI

      1. Select Settings -> Project Settings menu from the Agent Compiler UI.

      2. In the Settings tree, select Protocols -> SNMP -> Proxy -> ProxyTable. The ProxyTable dialog is displayed.

      3. To add an entry to the table, click Add.

      4. Add sub-agent entries to the table and click OK.

 

2. Using Text Files

 

Once the entries are added through Agent Compiler UI, the configurations are saved in a text file, namely proxytable.txt (for OID Based Proxy) under <WebNMS>/C-Agent/projects/<Project-Name>/agent/conf/snmp directory provided the storage type MACRO is defined in the config.h file as given below :

    1. #define AGENT_FILE_TO_VECTOR

These files can be edited to add Manager entries. The proxytable.txt given below has been edited for adding a new sub-agent entry with OID ".1.3.6.1.2.1.1" ; sub-agent port : "9001".

    1. .1.3.6.1.2.1.1 default .0.0 1 127.0.0.1 9001 SNMP_VERSION_2c public 5 0 ACTIVE

Please note that the Agent has to be restarted for the changes to take effect

 

3. Using Functional Calls

 

An entry can be added to the proxy table by calling the function CreateAndAddNewProxyTableEntry().

 

This function is defined in

 

<WebNMS>/C-Agent/projects/<Project-Name>/agent/source/protocols/snmp/src/proxytable.c and is called from <WebNMS>/C-Agent/projects/<Project-Name>/agent/stubs/submain.c file. By calling the following function with specified parameters, a new entry will be added to the authentication table. You can call this function either before Agent startup or during run time.

    1. CHAR CreateAndAddNewProxyTableEntry(U_CHAR *proxyOid, U_CHAR *proxyContextName, INT32 proxyContextNameLen, CHAR *proxyEntryInstance, INT32 proxyHostType, CHAR *proxyHost, U_INT32 proxyPortNumber, U_INT32 proxySnmpVersion, CHAR *proxyCommunity, U_INT32 proxyTimeOut, U_INT32 proxyRetries, INT32 proxyStatus)

The example code given below would authenticate the requests sent from community "public", IP Address : "127.0.0.1" with Access status : Read_Write and Row Status : Active.

    1. CreateAndAddNewProxyTableEntry((U_CHAR *)".1.3.6.1.2.1", (U_CHAR *)"default", 7, ".0.0", 1, "127.0.0.1", 161, SNMP_VERSION_1, "public", 5, 0, SNMP_ROW_ACTIVE);

 

During Run Time: From the Manager

 

To add sub-agent entries to the Master Agent Proxy Table from the Manager, follow the steps given below:

    1. Load AGENT-SNMP-CONFIG-MIB in the MIB Browser application. 

    2. Select proxyTable (or whichever preferred sub-agent table) from the subAgentTables module of agentConfiguration group. 

    3. Selecting the respective table and clicking SNMP Table icon (View SNMP Table Data) in MIB Browser opens up a wizard wherein entries can be added to the corresponding proxyTable.

    4. Click Add in that SNMP Table wizard. The corresponding columns in the Table are listed.

    5. Include the sub-agent entries.

    6. The entries added from remote get updated in the text file provided the AGENT_FILE_TO_VECTOR is defined in the config.h file.

    7. Please note that it is possible to access the table from remote only if Remote Configuration of the Proxy Table is enabled in the Proxy General Panel of Settings -> Project Settings menu in Agent Compiler UI.

    8. You can also enable or disable the facility of "Remote Configuration" using the MACRO definition PROXY_REMOTE_IFCin the config.h file.

    1. note_nc.jpg

      Note : Similar to the steps mentioned in adding entries, the entries can be deleted/removed from the table.

Different Types of Master - Sub-Agent Relationship

 

Considering the design and the complexity of the distributed systems, it is very difficult to have just normal OID-based Master - sub-agent relationship. This made us evolve the Master - sub-agent relationship further and made us support different types of Master - Sub-agent relationship, such as Context-based registration  and  Instance-based registration.

 

The registration of a Sub-Agent in the Proxy Agent/Master Agent follows three different approaches. The user can follow any of these approaches or a combination of these to register the sub-agent with the Proxy Agent.

Registration Based on OID

 

This approach can be followed when each sub-agent implements a unique OID, In this case, the Master Agent identifies the sub-agent based on the OIDs they implement. The sub-agent information is stored in the Proxy Table.

 

Registration Based on Context Name

 

This approach is followed when more than one sub-agent implements the same MIB or same sub-tree of a MIB. In this case, the Master Agent identifies the sub-agent based on the context name provided for the SubAgent. The sub-agent information is stored in the Proxy Table.

 

The default entry generated by the agent in the Proxy Table has the context name as "default". The proxy agent will not consider the column "context name" if its value is "default". The user has to provide different context name for each sub-agent, so that the proxy agent can identify such sub-agent based on the context names.

 

If the master agent is SNMP v1/v2c, the context name is the community string of the SNMP request. The default community strings are "public" and "private". If the user wants to provide any other name other than public/private in the proxy table, those context names must also be registered as community in the <WebNMS>\C-Agent\projects\<Project-Name>\agent\bin\conf\snmp\authtable.txt.

 

If the master agent is SNMP v3, the context name is the Context Engine ID of the SNMP request.

 

Registration Based on SNMP Table Instance Value

 

This approach is followed when more than one sub-agent implements the same Snmp Table Entry OID with different instance of the Table. In this case, the Master Agent identifies the sub-agent based on the table instance value provided for the Sub-Agent. The sub-agent information is stored in the Proxy Table.

 

The default entry generated by the agent in the Proxy Table has the table instance value as ".0.0". The proxy agent will not consider the column "Instance value" if its value is "0.0". The user has to populate the proxy table with different instance values for each sub-agent, so that the proxy agent can identify such sub-agent based on the SNMP table instance value.

 

Automatic Registration of ProxyTable in Master Agent

 

When a sub-agent is started, the sub-agent entries can be automatically registered in the ProxyTable maintained by the Master Agent The corresponding row will be added successfully in the Master Agents proxy table.

 

To support this feature, two new methods have been defined in the following files present under WebNMS/C-Agent/agent/source/protocols/snmp/src and WebNMS/C-Agent/agent/source/protocols/snmp/include directory.

Implementing Automatic Registration of Sub-Agents in the Master Agent

Procedure Involved in Registering the Sub-Agent

Example 1

 

Here is an example to call the Registersubagent() method. The prototype of the method is :

    1. RegisterSubagent(CHAR *oid, CHAR *contextName, INT32 contextnameLen, CHAR *entryInst, INT32 version, CHAR *community, INT32 timeout, INT32 ret, INT32 status, CHAR *remoteHost, INT32 remotePort)

Example Entry :

    1. RegisterSubagent(".1.3.6.1.4.1.2162", (U_CHAR *)"default", 7, ".0.0", SNMP_VERSION_1, "private", 30, 5, ACTIVE, "127.0.0.1", 9001);

Procedure Involved in Unregister the sub-agent

Example 2

 

Here is an example to un-register the sub-agent. The prototype of the method is,

    1. UnRegisterSubagent(CHAR *oid, CHAR *contextName, CHAR *contextNameLen, CHAR *entryInst, CHAR *community, CHAR *remoteHost, INT32 remotePort)

Example Entry :

    1. UnRegisterSubagent(".1.3.6.1.4.1.2162", (U_CHAR *)"default", 7, ".0.0", "private", "127.0.0.1", 9001);

The above two methods, RegisterSubagent( ) and UnRegisterSubagent() will return the following :

 

    1.    if (retVal == MEMORY_ALLOCATION_FAILURE)

      {

      ERRMSG1("Unable to allocate memory\n");

      return retVal;

      }

      else if (retVal == FAILURE || retVal == INVALID_TYPE_FAILURE || retVal == MASTER_AGENT_RESPONSE_FAILURE || retVal == SUBAGENT_REGISTERATION_FAILURE)

      {

      ERRMSG1("Unable to register (or unregister) sub-agent\n");

      return retVal;

      }

 

Automatic Registration of AclTable in Master Agent

 

When a sub-agent is started, the authentication entries, such as community, access provided, etc. can be automatically registered in the AclTable maintained by the Master Agent. The corresponding row will be added successfully in the Master Agents AclTable.

 

To support this feature, two new methods have been defined in the following files present under WebNMS/C-Agent/agent/source/protocols/snmp/src and WebNMS/C-Agent/agent/source/protocols/snmp/include directory.

Implementing Automatic Registration of AclTable in the Master Agent

Procedure Involved in Registering the Acl Table Entries

Example 1

 

Here is an example to call the RegisterAcl() method. The Prototype of the method is :

    1. RegisterAcl(CHAR *community, INT32 access, CHAR *managers, INT32 status, CHAR *remoteHost, INT32 remotePort)

Example Entry

    1. RegisterAcl("public", RWRITE, "192.168.117.111", SNMP_ROW_ACTIVE,"127.0.0.1", 9001)

Procedure Involved in Unregistering the Acl Table entry

      • To un-register the Acl Table entry, the UnRegisterAcl( ) method is called which sends an SNMP SET request to the Master Agent to delete the row from the Acl Table.

      • On calling this method, the row is deleted from the Acl table. In case any problem occurs while deleting the row, the UnRegisterAcl() method returns FAILURE.

      • This function will unregister the Acl entry dynamically. It will delete the row registered in the Acl table by specifying the Acl community as argument to identify which row has to be deleted in the Acl table. Also, the host name and port number arguments have to be specified to identify in which port the master agent is running.

      • The values to be passed inside this function are ,

        • Acl community

        • Master ent host name

        • Master agent port number

Example 2

 

Here is an example to un-register the sub-agent. The Prototype of the method is :

    1. UnRegisterAcl(CHAR *community, CHAR *remoteHost, INT32 remotePort)

Example Entry

    1. UnRegisterAcl( "public", "127.0.0.1", 9001)

The above two methods, RegisterAcl( ) and UnregisterAcl() will return the following :

    1.    if (retVal == FAILURE || retVal == MEMORY_ALLOCATION_FAILURE)

      {

      DEBUGMSG1("Unable to register Acl entry\n");

      return retVal;

      }

      DEBUGMSG1("Acl entry registered successfully\n");

      return retVal;

       

      if (retVal == FAILURE || retVal == MEMORY_ALLOCATION_FAILURE)

      {

      DEBUGMSG1("Unable to un-register Acl entry\n");

      return retVal;

      }

      DEBUGMSG1("Acl entry un-registered successfully\n");

      return retVal;

 

The Automatic Registration of TrapForwardingTable and TrapReceiverTable are explained under the subsection "Sending Traps from sub-agents".

 

Knowing the Status of the sub-agent (Heart Beat Mechanism)

 

As the name implies, Heart Beat Mechanism is helpful to determine the existence of a connection between Master - sub-agent. This feature is implemented to constantly monitor the status of the sub-agent and make it available to the Master Agent.

 

By knowing the status, the Master Agent does not forward the request to sub-agents, which are not alive. Instead, the Master Agent throws a 'general failure' error directly to the Manager.

 

Enabling Heart Beat Mechanism

 

Heart Beat mechanism can be enabled from the Agent Compiler UI.

 

Using Agent Compiler UI

Enabling this option will define the MACRO SNMP_SUBAGENT_POLLING_PORT in the config.h file.

 

Handling SET Request between Master Agent and sub-agent

 

Atomic SET implementation in Master and sub-agent architecture

 

Phase I

 

When any Multi-varbind SET request reaches the Master Agent with the sub-agent OIDs, the Master agent groups the received varbinds based on each sub-agent and master agent OID registration, then it will send different SNMP GET request to each sub-agent and retrieves the value of the corresponding OIDs. The received value will be stored in the Master agent for Rollback support, that is, if the SET (commit) fails in the Phase II then the master agent will use these values for "Undo" the changes in the sub-agents.

 

Phase II

 

Once all GET responses are received from sub-agents, the Master Agent will enter this phase. Now the Master Agent will send the SET request to the sub-agents to which it had sent GET request in Phase I and wait for response. Since it is the SET request, each sub-agent internally will do atomic SET process and return either success of failure. If all sub-agents return response with noError, then the master agent will create a response with noError and send it back to the manager. If any of SET request fails then the master agent will go to the Phase III. It is equivalent to "Commit" state in the Atomic SET.

 

Phase III

 

Since the "Commit" is failed in the Phase II, now the master agent should "Undo" the committed value in the sub-agents. The master agent will send another SET request to all the sub-agents with the value received in the Phase I. After end of this phase, all original values are reverted in the sub-agents. It is equivalent to "Undo" in the Atomic SET.

 

LinkUp and LinkDown Traps from Master Agent

 

sub-agent status is intimated to the Master Agent through Heart Beat support. This is done by updating the Row Status column of the proxyTable in the Master Agent frequently. When the sub-agent status (row status column) keeps shifting from NOT_IN_SERVICE to ACTIVE, the Master Agent is made aware of the status.

 

On becoming NOT_IN_SERVICE, a Link Down Trap is generated and forwarded to the Managers. Similarly, a Link Up Trap is generated when the status shifts to ACTIVE. These Trap details can be viewed in the AGENT-SNMP-CONFIG-MIB. The ID of the OID Based Proxy linkUp and linkDown Traps are .1.3.6.1.4.1.2162.10.3.1.4.1 and .1.3.6.1.4.1.2162.10.3.1.4.2 respectively. Managers are identified using the entries in Trap Forwarding Table of the Master Agent. By default Traps are sent to the "localhost" at port "8002" and the trap version will be the manager version specified in the TrapForwardingTable. The host, port and version of the trap can be modified in the config.h file, as per the implementation.

 

To know more about Sending Traps from the sub-agent, refer to the topic "Sending Traps from sub-agent"

 

Sending Traps From Sub-Agent

 

The sub-agent can send Traps to the Manager in two ways,

Sending Traps to the Manager Directly

 

Each sub-agent can send traps or notifications directly to the Manager. In this model, sub-agents can also send traps / notifications to different set of Managers. For this, each sub-agent should maintain a trap forwarding table that stores managers information. If a Manager is ready to listen to all the traps, then each sub-agent's trap forwarding table must be updated. To add an entry or register a manager information in trap forwarding table, please refer to the topic Adding entries to Trap Forwarding Table in Sending Trap, Notifications, and Informs section.

 

Sending Traps through the Master Agent after Filtering It

 

sub-agents generate Traps and sends them through the Master Agent. Even though Traps can be sent directly to the Manager from the sub-agent, normally the traps are forwarded to the Master Agent. The Master Agent forwards them to the interested Managers. Details of Managers to whom the Master Agent should send Traps can be availed from the Trap Forwarding Table.

 

Filtering Traps Received from sub-agent Using Trap Receiver Table

 

The Master Agent has one module called the trap receiver. The main functionality of this module is to listen for traps from sub-agents, filter them and forward them to all the Managers. It maintains a table called the Trap Receiver Table which has a set of sub-agents information which can send traps to the Managers through Master Agent. The sub-agent registrations in the Trap Receiver Table purely depend on your requirement. You can either include all the sub-agent details present in the Master Agent (proxyTable) or a particular set of sub-agents from which you prefer to receive Traps. Using this implementation the Master Agent restricts the access of the sub-agents to send Traps to the Master Agent. It is a sort of filtering.

 

Trap Receiver Table

 

The Trap Receiver Table contains the following columns defined in it:

        • agentHostType (Index Column) - Host Type of the sub-agent. If it runs on IPv4 address, then its value is 1 and if the agent runs on IPv6 address, then the value is 2

        • agentHost (Index Column) - Host of the sub-agent.

        • agentPortNumber (Index Column) - Port number from which the sub-agent sends Traps.

        • agentCommunity - Community with the sub-agent is to be contacted or proxied.

        • agentStatus - Row Status column facilitating addition and deletion of rows.

Enabling Trap Receiver Table

 

You can enable Trap Receiver Table from the Agent Compiler UI.

 

Using Agent Compiler UI

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

        • In the Settings Tree, select Protocols -> SNMP -> Proxy -> General and enable the option Generate Agent with Proxy. The Trap Receiver Table will then get enabled automatically.

Enabling this option will define the following macro defined in the config.h file present under <WebNMS/C-Agent>/projects/ProjectName/agent/source/system/include directory for Trap Receiver facility,

        1. #define TRAPRECEIVER_REMOTE_IFC

Adding sub-agent Entries to Trap Receiver Table

 

sub-agent entries can be added to the Table either : (1) Before Agent Startup or (2) During Run Time.

 

Before Agent Startup

 

To add Manager Entries at Agent Startup,

 

1. Using Agent Compiler UI

        1. Select Settings -> Project Settings option from the menu bar of the Agent Compiler UI.
        2. In the Settings Tree, select Protocols -> SNMP -> TrapReceiverTable
        3. Click Add to add the sub-agent entries already existing in the Proxy Tables.

 

2. Text File

 

The entries configured through Agent Compiler UI get stored in the configuration file, trapreceivertable.txt under <WebNMS>/C-Agent/projects/<ProjectName>/agent/conf/snmp directory, provided the storage type MACRO is defined in the config.h file as given below :

        1. #define AGENT_FILE_TO_VECTOR

This text file has to be edited for adding Manager Entries. Please note that the Agent has to be restarted for the changes to take effect.

 

3. Using Functional Calls

 

An entry can be added to the authentication table by calling the function CreateAndAddNewTrapReceiverTableEntry().

 

This function is defined in

<WebNMS>/C-Agent/projects/<ProjectName>/agent/source/protocols/snmp/src/trapreceivertable.c and is called from WebNMS>/C-Agent/projects/<Project-Name>/agent/stubs/submain.c file. By calling the following function with specified parameters, a new entry will be added to the Trap Receiver table. You can call this function either before Agent startup or during run time

        1. CreateAndAddNewTrapReceiverTableEntry(INT32 agentHostType,CHAR *agentHost, U_INT32 agentPortNumber, CHAR *agentCommunity, INT32 agentStatus)

The example code given below would authenticate the requests sent from community "public", IP Address : "127.0.0.1" with Access status : Read_Write and Row Status : Active

        1. CreateAndAddNewTrapReceiverTableEntry(1, "127.0.0.1", 8004,

          "agentCommunity", SNMP_ROW_ACTIVE);

During Run Time: From the Manager

 

To add sub-agent entries to the Master Agent Proxy Table from the Manager, follow the steps given below :

      1. Load AGENT-SNMP-CONFIG-MIB in the MIB Browser application. 

      2. Select trapReceiver Table from the subAgentTables module of agentConfiguration group, in the MIB.

      3. Selecting the respective table and clicking SNMP Table icon in MIB Browser opens up a wizard wherein entries can be added to the trapReceiver Table.

      4. The entries added from remote get updated in the text file.

      5. Please note that it is possible to access the table from remote only if "Remote Configuration" option is enabled in the aclTablein v1v2Authentication Panel of Project -> Settings menu in Agent Compiler UI. 

      6. You can also enable or disable the facility of "Remote Configuration" using the MACRO definition in the config.h, header file.

        1. note_nc.jpg

          Note: Similar to the steps mentioned in adding entries, the entries can be deleted/removed from the table.:

Validating Traps Received from Sub-Agent

 

The traps received from the sub-agent/sub-agents can be further validated, using the DoFilteringOnRcvdsub-agentTraps() method defined in submain.c file. This method will be called from traplist.c file, after receiving the trap from the sub-agent. Inside this method, user can write his code to do the necessary validation for sending the trap to the manager or to discard the received traps.

 

Steps Involved in Sending Traps by the Master Agent

 

The following steps are involved after receiving a trap by the Master Agent.

      1. The Master Agent matches the trap originator's (sub-agent) IP address and port number in the trap receiver table.

      2. If no entry is found then it will discard the received message.

      3. It will parse the received trap message headers (length, version, and community string).

      4. If the method GetProxyTrapVersion() returns SNMP_VERSION_3 then it will convert the received SNMPv1/v2c trap into SNMPv3.

      5. If the method GetProxyTrapVersion() returns SNMP_VERSION_1 then it will convert the received SNMPv2c trap into SNMPv1.

      6. It will go through each entry in the trap forwarding table and create a new trap message based on the GetProxyTrapVersion() result.

      7. The method DoFilteringOnRcvdsub-agentTraps() defined in submain.c file is called. Based on the conditions defined inside this method, the trap is sent or discarded.

      8. The Master Agent will send the created trap message to the managers registered in its Trap Forwarding Table.

Automatic Registration of TrapForwardingTable in Sub-Agent

 

Manager entries can be automatically registered in the TrapForwardingTable maintained by the sub-agent at Master Agent startup. The corresponding row will be added successfully in the sub-agents TrapForwardingTable.

 

To support this feature, two new methods have been defined in the following files present under WebNMS/C-Agent/agent/source/protocols/snmp/src and WebNMS/C-Agent/agent/source/protocols/snmp/include directory of the Master Agent.

Implementing Automatic Registration of Manager Entries in the Sub-Agent

Procedure Involved in Registering the TrapForwardingTable Entries

Prototype for SNMPv3 Agent

 

    1. CHAR RegisterManager(CHAR *host, U_INT32 port, INT32 version, CHAR *community, CHAR *userName, INT32 secModel, INT32 secLevel, CHAR *contextName, INT32 contextNameLen, U_INT32 timeout, U_INT32 ret, INT32 status, CHAR *remoteHost, INT32 remotePort)

Example

    1. RegisterManager("192.168.1.253", 8005, 2, "public", "noAuthUser", 3, 0, "noAuth", 6, 30, 5, 4, "192.168.121.234", 8001)

Prototype for SNMPv2c Agent

 

    1. CHAR RegisterManager(CHAR *host, U_INT32 port, INT32 version, CHAR *community, U_INT32 timeout, U_INT32 ret, INT32 status, CHAR *remoteHost, INT32 remotePort)

Example

    1. RegisterManager("192.168.1.120",8001,SNMP_VERSION_2c,public,15,2,4,"192.168.100",161)

Procedure Involved in Unregistering the TrapForwardingTable Entry

Example 2

 

Here is an example to un-register the sub-agent. The Prototype of the method is :

    1. UnRegisterManager(CHAR *host, U_INT32 port, CHAR *remoteHost, INT32 remotePort)

Example Entry

    1. UnRegisterManager("192.168.117.100",8001,"192.168.117.111",8001)

The above two methods, RegisterManager( ) and UnRegisterManager() will return the following :

    1. if (retVal == FAILURE || retVal == MEMORY_ALLOCATION_FAILURE)

      {

      DEBUGMSG1("Unable to register manager entry\n");

      return retVal;

      }

      DEBUGMSG1("Manager entry registered successfully\n");

      return retVal;

       

       

      if (retVal == FAILURE || retVal == MEMORY_ALLOCATION_FAILURE)

      {

      DEBUGMSG1("Unable to un-register manager entry\n");

      return retVal;

      }

      DEBUGMSG1("Manager entry un-registered successfully\n");

      return retVal;

 

Automatic Registration of TrapReceiverTable in Master Agent

 

sub-agent entries can be automatically registered in the TrapReceiverTable maintained by the Master Agent at sub-agent startup. The corresponding row will be added successfully in the Master Agent's TrapReceiverTable.

 

To support this feature, two new methods have been added in the following files present under WebNMS/C-Agent/agent/source/protocols/snmp/src and WebNMS/C-Agent/agent/source/protocols/snmp/include directory.

Implementing Automatic Registration of Manager Entries in the Sub-Agent

Procedure Involved in Registering the TrapReceiverTable Entries

      • Manager host

      • Manager port

      • Manager community

      • Status of the table

      • Sub-agent host name

      • Sub-agent port Num

Example 1

 

Here is an example to call the RegisterTrapReceiver() method. The Prototype of the method is :

      1. RegisterTrapReceiver(CHAR *host, U_INT32 port, CHAR *community, INT32 status, CHAR *remoteHost, INT32 remotePort)

Example Entry

      1. RegisterTrapReceiver("192.168.117.111",8007,"public",4,"127.0.0.1",9001)

 

Procedure Involved in Un-registering the TrapReceiverTable entry

Example 2

 

Here is an example to un-register the sub-agent. The Prototype of the method is :

      1. UnRegisterTrapReceiver(CHAR *host, U_INT32 port, CHAR *remoteHost, INT32 remotePort)

Example Entry

      1. UnRegisterTrapReceiver("192.168.117.111",8007,"127.0.01",9001)

The above two methods, RegisterTrapReceiver( ) and UnRegisterTrapReceiver( ) will return the following :

    1. if (retVal == FAILURE || retVal == MEMORY_ALLOCATION_FAILURE)

      {

      DEBUGMSG1("Unable to register trap receiver entry\n");

      return retVal;

      }

      DEBUGMSG1("Trap receiver entry registered successfully\n");

      return retVal;

            

      if (retVal == FAILURE || retVal == MEMORY_ALLOCATION_FAILURE)

      {

      DEBUGMSG1("Unable to un-register trap receiver entry\n");

      return retVal;

      }

      DEBUGMSG1("Trap receiver entry un-registered successfully\n");

      return retVal;

       

Sending Traps through Master Agent without Filtering It Using Trap Filtering Table

 

The Traps received by the Master Agent can be sent without validating it using the Trap Receiver Table. The macro used for this purpose is given below:

 

#ifndef DROP_PROXY_TRAP_FILTERING

 

By default, this macro is not defined and the user can define this macro for filtration. The below piece of code, when added to the traplist.c file will achieve this functionality.

      1. /* The following block is in #if 0 in order to comment

        * the filtering functionality of the master agent.

        */

        #ifndef DROP_PROXY_TRAP_FILTERING

        retVal = CheckSubAgentAccessForRcvdTrap(ipAddress, portNumber);

        if(retVal == FAILURE)

        {

        ERRMSG1("Access denied\n");

        return FAILURE;

        }

        #endif /* #ifndef DROP_PROXY_TRAP_FILTERING */

Configuring SNMP V3 in Proxy

 

WebNMS SNMP Agent also supports Proxy Concept in SNMPV3. Mostly, the Master and sub-agents run in a private network and only the communication between a Manager and the Master Agent takes place in a public network. Hence,  the Agents running in a private network may not require SNMP V3 as they would be well secured.

 

Having this in mind, WebNMS's implementation provides only v1/v2c support to sub-agents. Even if the Manager sends a request of V3 type, the Master Agent being a V3 Agent would convert the V3 request to a V1/V2c Request and forward the PDU to the sub-agents. The V1/V2c Response would be further converted to a V3 response and sent back to the Manager.

 

Configuring WebNMS Agents as sub-agents to Third-Party Agents (including OS Native agents )

 

Because the Master - sub-agent communication uses SNMP PDU, any Agent that understands SNMP can be made as sub-agent to WebNMS Master Agent. Even the Native Agents can be made as sub-agent to WebNMS Master Agent. WebNMS Agents can also be made as sub-agents to Third-Party Agents / Native Agents. This helps to derive the data of the OS you prefer. The supported OS by WebNMS are Windows, Linux and Solaris.

 

Configuring WebNMS Agent as Sub-Agent to Solaris Native Agent

 

To make WebNMS Agent as sub-agent to Solaris Agent,

note_nc.jpg

Note: Please remember that, to perform the functions specified from the point "Go To solaris directory" you must be a super user.

 

Configuring WebNMS Agent as sub-agent to Windows native Agent Using apadll

 

To make WebNMS Agent as sub-agent to Windows Agent,

Procedure for Registration

Testing

This is the most widely used approach. On using apadll.dll the WebNMS Agent can act as both Standalone Agents, listening for requests at a port 8001 and also as sub-agent to Windows.

 

Configuring WebNMS Agent as Sub-Agent to Linux Native (Net-SNMP) Agent

 

To make WebNMS Agent as sub-agent to Linux Native Agent, please perform the following steps:

 Testing

Sending Traps through Windows Master Agent

 

Trap generation support is also provided when the WebNMS Agent is made to act as Windows sub-agent. To avail Trap generation support:

Setting the Properties of the SNMP Service

Stopping and Restarting the SNMP Service

 


Copyright © 2012, ZOHO Corp. All Rights Reserved.