How to Implement SNMP Proxy using SNMP Agent Toolkit C Edition

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, other software vendors for SQL, Application servers, etc, also produce Agents.

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

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

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.

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.

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
• Registration based on Context Names
• Registration based on Table Instance
  

  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 projects/ ProjectName/ 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.

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.

Sending Traps From Sub-Agent

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

• Sending Traps to the Manager directly.
• Sending Traps through the Master Agent after filtering it.

  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 manager’s 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 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 send 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.

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 and Solaris.