Sophie

Sophie

distrib > Fedora > 17 > x86_64 > by-pkgid > 675c8c8167236dfcf8d66da674f931e8 > files > 1294

erlang-doc-R15B-03.3.fc17.noarch.rpm

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html xmlns:fn="http://www.w3.org/2005/02/xpath-functions">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="stylesheet" href="../../../../doc/otp_doc.css" type="text/css">
<title>Erlang -- Agent Functional Description</title>
</head>
<body bgcolor="white" text="#000000" link="#0000ff" vlink="#ff00ff" alink="#ff0000"><div id="container">
<script id="js" type="text/javascript" language="JavaScript" src="../../../../doc/js/flipmenu/flipmenu.js"></script><script id="js2" type="text/javascript" src="../../../../doc/js/erlresolvelinks.js"></script><script language="JavaScript" type="text/javascript">
            <!--
              function getWinHeight() {
                var myHeight = 0;
                if( typeof( window.innerHeight ) == 'number' ) {
                  //Non-IE
                  myHeight = window.innerHeight;
                } else if( document.documentElement && ( document.documentElement.clientWidth ||
                                                         document.documentElement.clientHeight ) ) {
                  //IE 6+ in 'standards compliant mode'
                  myHeight = document.documentElement.clientHeight;
                } else if( document.body && ( document.body.clientWidth || document.body.clientHeight ) ) {
                  //IE 4 compatible
                  myHeight = document.body.clientHeight;
                }
                return myHeight;
              }

              function setscrollpos() {
                var objf=document.getElementById('loadscrollpos');
                 document.getElementById("leftnav").scrollTop = objf.offsetTop - getWinHeight()/2;
              }

              function addEvent(obj, evType, fn){
                if (obj.addEventListener){
                obj.addEventListener(evType, fn, true);
                return true;
              } else if (obj.attachEvent){
                var r = obj.attachEvent("on"+evType, fn);
                return r;
              } else {
                return false;
              }
             }

             addEvent(window, 'load', setscrollpos);

             //--></script><div id="leftnav"><div class="innertube">
<img alt="Erlang logo" src="../../../../doc/erlang-logo.png"><br><small><a href="users_guide.html">User's Guide</a><br><a href="index.html">Reference Manual</a><br><a href="release_notes.html">Release Notes</a><br><a href="../pdf/snmp-4.22.1.pdf">PDF</a><br><a href="../../../../doc/index.html">Top</a></small><p><strong>Simple Network Management Protocol (SNMP)</strong><br><strong>User's Guide</strong><br><small>Version 4.22.1</small></p>
<br><a href="javascript:openAllFlips()">Expand All</a><br><a href="javascript:closeAllFlips()">Contract All</a><p><small><strong>Chapters</strong></small></p>
<ul class="flipMenu" imagepath="../../../../doc/js/flipmenu">
<li id="no" title="SNMP Introduction" expanded="false">SNMP Introduction<ul>
<li><a href="snmp_intro.html">
              Top of chapter
            </a></li>
<li title="Scope and Purpose"><a href="snmp_intro.html#id73205">Scope and Purpose</a></li>
<li title="Prerequisites"><a href="snmp_intro.html#id63280">Prerequisites</a></li>
<li title="Definitions"><a href="snmp_intro.html#id61217">Definitions</a></li>
<li title="About This Manual"><a href="snmp_intro.html#id66265">About This Manual</a></li>
<li title="Where to Find More Information"><a href="snmp_intro.html#id65242">Where to Find More Information</a></li>
</ul>
</li>
<li id="loadscrollpos" title="Agent Functional Description" expanded="true">Agent Functional Description<ul>
<li><a href="snmp_agent_funct_descr.html">
              Top of chapter
            </a></li>
<li title="Features"><a href="snmp_agent_funct_descr.html#id70043">Features</a></li>
<li title="SNMPv1, SNMPv2 and SNMPv3"><a href="snmp_agent_funct_descr.html#id69677">SNMPv1, SNMPv2 and SNMPv3</a></li>
<li title="Operation"><a href="snmp_agent_funct_descr.html#id71220">Operation</a></li>
<li title="Sub-agents and MIB Loading"><a href="snmp_agent_funct_descr.html#id75292">Sub-agents and MIB Loading</a></li>
<li title="Contexts and Communities"><a href="snmp_agent_funct_descr.html#id74241">Contexts and Communities</a></li>
<li title="Management of the Agent"><a href="snmp_agent_funct_descr.html#id74376">Management of the Agent</a></li>
<li title="Notifications"><a href="snmp_agent_funct_descr.html#id73838">Notifications</a></li>
<li title="Discovery"><a href="snmp_agent_funct_descr.html#id75718">Discovery</a></li>
</ul>
</li>
<li id="no" title="Manager Functional Description" expanded="false">Manager Functional Description<ul>
<li><a href="snmp_manager_funct_descr.html">
              Top of chapter
            </a></li>
<li title="Features"><a href="snmp_manager_funct_descr.html#id75862">Features</a></li>
<li title="Operation"><a href="snmp_manager_funct_descr.html#id76012">Operation</a></li>
<li title="MIB loading"><a href="snmp_manager_funct_descr.html#id76080">MIB loading</a></li>
</ul>
</li>
<li id="no" title="The MIB Compiler" expanded="false">The MIB Compiler<ul>
<li><a href="snmp_mib_compiler.html">
              Top of chapter
            </a></li>
<li title="Operation"><a href="snmp_mib_compiler.html#id76200">Operation</a></li>
<li title="Importing MIBs"><a href="snmp_mib_compiler.html#id76263">Importing MIBs</a></li>
<li title="MIB Consistency Checking"><a href="snmp_mib_compiler.html#id76334">MIB Consistency Checking</a></li>
<li title=".hrl File Generation"><a href="snmp_mib_compiler.html#id76371">.hrl File Generation</a></li>
<li title="Emacs Integration"><a href="snmp_mib_compiler.html#id76421">Emacs Integration</a></li>
<li title="Compiling from a Shell or a Makefile"><a href="snmp_mib_compiler.html#id76467">Compiling from a Shell or a Makefile</a></li>
<li title="Deviations from the Standard"><a href="snmp_mib_compiler.html#id76521">Deviations from the Standard</a></li>
</ul>
</li>
<li id="no" title="Running the application" expanded="false">Running the application<ul>
<li><a href="snmp_config.html">
              Top of chapter
            </a></li>
<li title="Configuring the application"><a href="snmp_config.html#id76778">Configuring the application</a></li>
<li title="Modifying the Configuration Files"><a href="snmp_config.html#id79236">Modifying the Configuration Files</a></li>
<li title="Starting the application"><a href="snmp_config.html#id79327">Starting the application</a></li>
<li title="Debugging the application"><a href="snmp_config.html#id79377">Debugging the application</a></li>
</ul>
</li>
<li id="no" title="Definition of Agent Configuration Files" expanded="false">Definition of Agent Configuration Files<ul>
<li><a href="snmp_agent_config_files.html">
              Top of chapter
            </a></li>
<li title="Agent Information"><a href="snmp_agent_config_files.html#id79867">Agent Information</a></li>
<li title="Contexts"><a href="snmp_agent_config_files.html#id79944">Contexts</a></li>
<li title="System Information"><a href="snmp_agent_config_files.html#id79997">System Information</a></li>
<li title="Communities"><a href="snmp_agent_config_files.html#id80066">Communities</a></li>
<li title="MIB Views for VACM"><a href="snmp_agent_config_files.html#id80148">MIB Views for VACM</a></li>
<li title="Security data for USM"><a href="snmp_agent_config_files.html#id80387">Security data for USM</a></li>
<li title="Notify Definitions"><a href="snmp_agent_config_files.html#id80603">Notify Definitions</a></li>
<li title="Target Address Definitions"><a href="snmp_agent_config_files.html#id80684">Target Address Definitions</a></li>
<li title="Target Parameters Definitions"><a href="snmp_agent_config_files.html#id80890">Target Parameters Definitions</a></li>
</ul>
</li>
<li id="no" title="Definition of Manager Configuration Files" expanded="false">Definition of Manager Configuration Files<ul>
<li><a href="snmp_manager_config_files.html">
              Top of chapter
            </a></li>
<li title="Manager Information"><a href="snmp_manager_config_files.html#id81118">Manager Information</a></li>
<li title="Users"><a href="snmp_manager_config_files.html#id81260">Users</a></li>
<li title="Agents"><a href="snmp_manager_config_files.html#id81361">Agents</a></li>
<li title="Security data for USM"><a href="snmp_manager_config_files.html#id81544">Security data for USM</a></li>
</ul>
</li>
<li id="no" title="Agent Implementation Example" expanded="false">Agent Implementation Example<ul>
<li><a href="snmp_impl_example_agent.html">
              Top of chapter
            </a></li>
<li title="MIB"><a href="snmp_impl_example_agent.html#id81793">MIB</a></li>
<li title="Default Implementation"><a href="snmp_impl_example_agent.html#id81833">Default Implementation</a></li>
<li title="Manual Implementation"><a href="snmp_impl_example_agent.html#id81912">Manual Implementation</a></li>
</ul>
</li>
<li id="no" title="Manager Implementation Example" expanded="false">Manager Implementation Example<ul>
<li><a href="snmp_impl_example_manager.html">
              Top of chapter
            </a></li>
<li title="The example manager"><a href="snmp_impl_example_manager.html#id82242">The example manager</a></li>
<li title="A simple standard test"><a href="snmp_impl_example_manager.html#id82333">A simple standard test</a></li>
</ul>
</li>
<li id="no" title="Instrumentation Functions" expanded="false">Instrumentation Functions<ul>
<li><a href="snmp_instr_functions.html">
              Top of chapter
            </a></li>
<li title="Instrumentation Functions"><a href="snmp_instr_functions.html#id82473">Instrumentation Functions</a></li>
<li title="Using the ExtraArgument"><a href="snmp_instr_functions.html#id83088">Using the ExtraArgument</a></li>
<li title="Default Instrumentation"><a href="snmp_instr_functions.html#id83196">Default Instrumentation</a></li>
<li title="Atomic Set"><a href="snmp_instr_functions.html#id83301">Atomic Set</a></li>
</ul>
</li>
<li id="no" title="Definition of Instrumentation Functions" expanded="false">Definition of Instrumentation Functions<ul>
<li><a href="snmp_def_instr_functions.html">
              Top of chapter
            </a></li>
<li title="Variable Instrumentation"><a href="snmp_def_instr_functions.html#id83474">Variable Instrumentation</a></li>
<li title="Table Instrumentation"><a href="snmp_def_instr_functions.html#id83849">Table Instrumentation</a></li>
</ul>
</li>
<li id="no" title="Definition of Agent Net if" expanded="false">Definition of Agent Net if<ul>
<li><a href="snmp_agent_netif.html">
              Top of chapter
            </a></li>
<li title="Mandatory Functions"><a href="snmp_agent_netif.html#id84750">Mandatory Functions</a></li>
<li title="Messages"><a href="snmp_agent_netif.html#id84772">Messages</a></li>
</ul>
</li>
<li id="no" title="Definition of Manager Net if" expanded="false">Definition of Manager Net if<ul>
<li><a href="snmp_manager_netif.html">
              Top of chapter
            </a></li>
<li title="Mandatory Functions"><a href="snmp_manager_netif.html#id85574">Mandatory Functions</a></li>
<li title="Messages"><a href="snmp_manager_netif.html#id85591">Messages</a></li>
</ul>
</li>
<li id="no" title="Audit Trail Log" expanded="false">Audit Trail Log<ul>
<li><a href="snmp_audit_trail_log.html">
              Top of chapter
            </a></li>
<li title="Agent Logging"><a href="snmp_audit_trail_log.html#id85997">Agent Logging</a></li>
<li title="Manager Logging"><a href="snmp_audit_trail_log.html#id86040">Manager Logging</a></li>
</ul>
</li>
<li id="no" title="Advanced Agent Topics" expanded="false">Advanced Agent Topics<ul>
<li><a href="snmp_advanced_agent.html">
              Top of chapter
            </a></li>
<li title="When to use a Sub-agent"><a href="snmp_advanced_agent.html#id86186">When to use a Sub-agent</a></li>
<li title="Agent Semantics"><a href="snmp_advanced_agent.html#id86296">Agent Semantics</a></li>
<li title="Sub-agents and Dependencies "><a href="snmp_advanced_agent.html#id86360">Sub-agents and Dependencies </a></li>
<li title="Distributed Tables"><a href="snmp_advanced_agent.html#id86378">Distributed Tables</a></li>
<li title="Fault Tolerance"><a href="snmp_advanced_agent.html#id86434">Fault Tolerance</a></li>
<li title="Using Mnesia Tables as SNMP Tables"><a href="snmp_advanced_agent.html#id86508">Using Mnesia Tables as SNMP Tables</a></li>
<li title="Deviations from the Standard"><a href="snmp_advanced_agent.html#id86786">Deviations from the Standard</a></li>
</ul>
</li>
<li id="no" title="SNMP Appendix A" expanded="false">SNMP Appendix A<ul>
<li><a href="snmp_app_a.html">
              Top of chapter
            </a></li>
<li title="Appendix A"><a href="snmp_app_a.html#id86932">Appendix A</a></li>
</ul>
</li>
<li id="no" title="SNMP Appendix B" expanded="false">SNMP Appendix B<ul>
<li><a href="snmp_app_b.html">
              Top of chapter
            </a></li>
<li title="Appendix B"><a href="snmp_app_b.html#id87320">Appendix B</a></li>
</ul>
</li>
</ul>
</div></div>
<div id="content">
<div class="innertube">
<h1>2 Agent Functional Description</h1>
  
  <p>The SNMP agent system consists of one Master Agent and
    optional Sub-agents.
    </p>
  <p>The tool makes it easy to dynamically extend an SNMP agent in
    run-time. MIBs can be loaded and unloaded at any time. It is also
    easy to change the implementation of an MIB in run-time, without
    having to recompile the MIB. The MIB implementation is clearly
    separated from the agent.
    </p>
  <p>To facilitate incremental MIB implementation, the tool can
    generate a prototype implementation for a whole MIB, or parts
    thereof. This allows different MIBs and management applications to
    be developed at the same time.
    </p>

  <h3><a name="id70043">2.1 
        Features</a></h3>
    
    <a name="features"></a>
    <p>To implement an agent, the programmer writes instrumentation
      functions for the variables and the tables in the MIBs that the
      agent is going to support. A running prototype which handles <span class="code">set</span>,
      <span class="code">get</span>, and <span class="code">get-next</span> can be created without any programming.
      </p>
    <p>The toolkit provides the following:
      </p>
    <ul>
      <li>multi-lingual multi-threaded extensible SNMP agent</li>
      <li>easy writing of instrumentation functions with a
       high-level programming language</li>
      <li>basic fault handling such as automatic type checking</li>
      <li>access control</li>
      <li>authentication</li>
      <li>privacy through encryption</li>
      <li>loading and unloading of MIBs in run-time</li>
      <li>the ability to change instrumentation functions without
       recompiling the MIB</li>
      <li>rapid prototyping environment where the MIB compiler can
       use generic instrumentation functions, which later can be
       refined by the programmer</li>
      <li>a simple and extensible model for transaction handling and
       consistency checking of set-requests</li>
      <li>support of the sub-agent concept via distributed Erlang</li>
      <li>a mechanism for sending notifications (traps and informs)</li>
      <li>support for implementing SNMP tables in the Mnesia DBMS.</li>
    </ul>
  

  <h3><a name="id69677">2.2 
        SNMPv1, SNMPv2 and SNMPv3</a></h3>
    
    <a name="versions"></a>
    <p>The SNMP development toolkit works with all three versions of
      Standard Internet Management Framework; SNMPv1, SNMPv2 and SNMPv3.
      They all share the same basic structure and components. And they 
      follow the same architecture.</p>
    <p>The versions are defined in following RFCs</p>
    <ul>
      <li>SNMPv1        RFC 1555, 1157 1212, 1213 and 1215</li>
      <li>SNMPv2        RFC 1902 - 1907</li>
      <li>SNMPv3        RFC  2570 - 2575</li>
    </ul>
    <p>Over time, as the Framework has evolved from SNMPv1 , through SNMPv2, 
      to SNMPv3 the definitions of each of these architectural components
      have become richer and more clearly defined, but the fundamental
      architecture has remained consistent.</p>
    <p>The main features of SNMPv2 compared to SNMPv1 are:
      </p>
    <ul>
      <li>The <span class="code">get-bulk</span> operation for transferring large
       amounts of data.
      </li>
      <li>Enhanced error codes.
      </li>
      <li>A more precise language for MIB specification</li>
    </ul>
    <p>The standard documents that define SNMPv2 are incomplete, in
      the sense that they do not specify how an SNMPv2 message looks
      like.  The message format and security issues are left to a
      special Administrative Framework. One such framework is the
      Community-based SNMPv2 Framework (SNMPv2c), which uses the same
      message format and framework as SNMPv1.   Other
      experimental frameworks as exist, e.g. SNMPv2u and SNMPv2*.
      </p>
    <p>The SNMPv3 specifications take a modular 
      approach to SNMP.  All modules are
      separated from each other, and can be extended or replaced
      individually.  Examples of modules are Message definition,
      Security and Access Control.  The main features of SNMPv3 are:
      </p>
    <ul>
      <li>Encryption and authentication is added.
      </li>
      <li>MIBs for agent configuration are defined.</li>
    </ul>
    <p>All these specifications are commonly referred to as "SNMPv3",
      but it is actually only the Message module, which defines a new
      message format, and Security module, which takes care of
      encryption and authentication, that cannot be used with SNMPv1 or
      SNMPv2c.  In this version of the agent toolkit, all the standard
      MIBs for agent configuration are used.  This includes MIBs for
      definition of management targets for notifications.  These MIBs
      are used regardless of which SNMP version the agent is configured
      to use.
      </p>
    <p>The extensible agent in this toolkit understands the SNMPv1,
      SNMPv2c and SNMPv3. Recall that SNMP consists of two separate
      parts, the MIB definition language (SMI), and the protocol.  On
      the protocol level, the agent can be configured to speak v1, v2c,
      v3 or any combination of them at the same time, i.e. a v1 request
      gets an v1 reply, a v2c request gets a v2c reply, and a v3 request
      gets a v3 reply.  On the MIB level, the MIB compiler can compile
      both SMIv1 and SMIv2 MIBs.  Once compiled, any of the formats can
      be loaded into the agent, regardless of which protocol version the
      agent is configured to use.  This means that the agent translates
      from v2 notifications to v1 traps, and vice versa.  For example,
      v2 MIBs can be loaded into an agent that speaks v1 only.  The
      procedures for the translation between the two protocols are
      described in RFC 1908 and RFC 2089.
      </p>
    <p>In order for an implementation to make full use of the enhanced
      SNMPv2 error codes, it is essential that the instrumentation
      functions always return SNMPv2 error codes, in case of error.
      These are translated into the corresponding SNMPv1 error codes by
      the agent, if necessary.</p>
    <div class="note">
<div class="label">Note</div>
<div class="content"><p>
      <p>The translation from an SMIv1 MIB to an SNMPv2c or SNMPv3 reply
        is always very straightforward, but the translation from a v2 MIB
        to a v1 reply is somewhat more complicated.  There is one data
        type in SMIv2, called <span class="code">Counter64</span>, that an SNMPv1 manager cannot
        decode correctly.  Therefore, an agent may never send a <span class="code">Counter64</span>
        object to an SNMPv1 manager.  The common practice in these
        situations is to simple ignore any <span class="code">Counter64</span> objects, when sending
        a reply or a trap to an SNMPv1 manager.  For example, if an SNMPv1
        manager tries to GET an object of type <span class="code">Counter64</span>, he will get a
        <span class="code">noSuchName</span> error, while an SNMPv2 manager would get a
        correct value.</p>
    </p></div>
</div>
  

  <h3><a name="id71220">2.3 
        Operation</a></h3>
    
    <a name="operations"></a>
    <p>The following steps are needed to get a running agent:</p>
    <ul>
      <li>
        <p>Write your MIB in SMI in a text file.</p>
      </li>
      <li>
        <p>Write the instrumentation functions in Erlang and compile them.</p>
      </li>
      <li>
        <p>Put their names in the association file.</p>
      </li>
      <li>
        <p>Run the MIB together with the association file through the
          MIB compiler.</p>
      </li>
      <li>
        <p>Configure the application (agent).</p>
      </li>
      <li>
        <p>Start the application (agent).</p>
      </li>
      <li>
        <p>Load the compiled MIB into the agent.</p>
      </li>
    </ul>
    <p>The figures in this section illustrate the steps involved in
      the development of an SNMP agent.</p>
    <a name="image-1"></a>
    <img alt="IMAGE MISSING" src="snmp-um-1-image-1.gif"><br>
      <em>Figure
        2.1:
         
        MIB Compiler Principles</em>
    
    <p>The compiler parses the SMI file and associates each table or
      variable with an instrumentation function (see the figure <span class="bold_code"><a href="#image-1">MIB Compiler Principles</a></span>). The actual
      instrumentation functions are not needed at MIB compile time, only
      their names.
      </p>
    <p>The binary output file produced by the compiler is read by the
      agent at MIB load time (see the figure <span class="bold_code"><a href="#image-2">Starting the Agent</a></span>). The instrumentation is ordinary Erlang code which
      is loaded explicitly or automatically the first time it is called.</p>
    <a name="image-2"></a>
    <img alt="IMAGE MISSING" src="snmp-um-1-image-2.gif"><br>
      <em>Figure
        2.2:
         
        Starting the Agent</em>
    
    <p>The SNMP agent system consists of one Master Agent and optional
      sub-agents. The Master Agent can be seen as a special kind of
      sub-agent. It implements the core agent functionality, UDP packet
      processing, type checking, access control, trap distribution, and
      so on. From a user perspective, it is used as an ordinary
      sub-agent.
      </p>
    <p>Sub-agents are only needed if your application requires special
      support for distribution from the SNMP toolkit. A sub-agent can
      also be used if the application requires a more complex set
      transaction scheme than is found in the master agent.
      </p>
    <p>The following illustration shows how a system can look  in runtime.</p>
    <a name="snmp_ch2_fig3"></a>
    <img alt="IMAGE MISSING" src="snmp-um-1-image-3.gif"><br>
      <em>Figure
        2.3:
         
        Architecture</em>
    
    <p>A typical operation could include the following steps:</p>
    <ul>
      <li>The Manager sends a request to the Agent.</li>
      <li>The Master Agent  decodes the incoming UDP packet.</li>
      <li>The Master Agent determines which items in the request
       that should be processed here and which items should be
       forwarded to its subagent.</li>
      <li>Step 3 is repeated by all subagents.</li>
      <li>Each sub-agent calls the instrumentation for its loaded MIBs.</li>
      <li>The results of calling the instrumentation are propagated
       back to the Master Agent.</li>
      <li>The answer to the request is encoded to a UDP Protocol
       Data Unit (PDU).</li>
    </ul>
    <p>The sequence of steps shown is probably more complex than
      normal, but it illustrates the amount of functionality which is
      available. The following points should be noted:
      </p>
    <ul>
      <li>An agent can have many MIBs loaded at the same time.</li>
      <li>Sub-agents can also have sub-agents. Each sub-agent can have
       an arbitrary number of child sub-agents registered, forming a
       hierarchy.</li>
      <li>One MIB can communicate with many applications.</li>
      <li>Instrumentation can use Distributed Erlang to communicate
       with an application.</li>
    </ul>
    <p>Most applications only need the Master Agent because an agent
      can have multiple MIBs loaded at the same time.</p>
  

  <h3><a name="id75292">2.4 
        Sub-agents and MIB Loading</a></h3>
    
    <a name="sub_agent_mib_loading"></a>
    <p>Since applications tend to be transient (they are dynamically
      loaded and unloaded), the management of these applications must be
      dynamic as well. For example, if we have an equipment MIB for a
      rack and different MIBs for boards, which can be installed in the
      rack, the MIB for a card should be loaded when the card is
      inserted, and unloaded when the card is removed.
      </p>
    <p>In this agent system, there are two ways to dynamically install
      management information. The most common way is to load an MIB into
      an agent. The other way is to use a sub-agent, which is controlled
      by the application and is able to register and unregister itself. A
      sub-agent can register itself for managing a sub-tree (not to be mixed up
      with <span class="code">erlang:register</span>). The sub-tree is identified by an
      Object Identifier. When a sub-agent is registered, it receives all
      requests for this particular sub-tree and it is responsible for
      answering them. It should also be noted that a sub-agent can be
      started and stopped at any time.
      </p>
    <p>Compared to other SNMP agent packages, there is a significant
      difference in this way of using sub-agents. Other packages normally
      use sub-agents to load and unload MIBs in run-time. In Erlang, it is
      easy to load code in run-time and it is possible to load an MIB
      into an existing sub-agent. It is not necessary to create a new process
      for handling a new MIB.
      </p>
    <p>Sub-agents are used for the following reasons:
      </p>
    <ul>
      <li>to provide a more complex set-transaction scheme than
       master agent</li>
      <li>to avoid unnecessary process communication</li>
      <li>to provide a more lightweight mechanism for loading and
       unloading MIBs in run-time</li>
      <li>to provide interaction with other SNMP agent toolkits.</li>
    </ul>
    <p>Refer to the chapter 
      <span class="bold_code"><a href="snmp_advanced_agent.html">Advanced Agent Topics</a></span> 
      in this User's Guide for more information about these topics.
      </p>
    <p>The communication protocol between sub-agents is the normal
      message passing which is used in distributed Erlang systems. This
      implies that sub-agent communication is very efficient compared to
      SMUX, DPI, AgentX, and similar protocols.</p>
  

  <h3><a name="id74241">2.5 
        Contexts and Communities</a></h3>
    
    <a name="context_and_communities"></a>
    <p>A context is a collection of management information accessible
      by an SNMP entity. An instance of a management object may exist in
      more than one context. An SNMP entity potentially has access to
      many contexts.</p>
    <p>Each managed object can exist in many instances within a
      SNMP entity. To identify the instances, specified by an MIB module,
      a method to distinguish the actual instance by its 'scope' or 
      context is used. Often the context is a physical or a logical device. 
      It can include multiple devices, a subset of a single device or a 
      subset of multiple devices, but the context is always
      defined as a subset of a single SNMP entity. To be able to 
      identify a specific 
      item of management information within an SNMP entity, the context,
      the object type and its instance must be used.</p>
    <p>For example, the managed object type <span class="code">ifDescr</span> from RFC1573, is
      defined as the description of a network interface.  To identify
      the description of device-X's first network interface, four pieces
      of information are needed: the snmpEngineID of the SNMP entity
      which provides access to the management information at device-X,
      the <span class="code">contextName</span> (device-X), the managed object type 
      (<span class="code">ifDescr</span>), and the instance ("1").
      </p>
    <p>In SNMPv1 and SNMPv2c, the community string in the message was
      used for (at least) three different purposes:
      </p>
    <ul>
      <li>
        <p>to identify the context</p>
      </li>
      <li>
        <p>to provide authentication</p>
      </li>
      <li>
        <p>to identify a set of trap targets</p>
      </li>
    </ul>
    <p>In SNMPv3, each of these usage areas has its own unique
      mechanism.  A context is identified by the name of the SNMP
      entity, <span class="code">contextEngineID</span>, and the name of the context,
      <span class="code">contextName</span>.  Each SNMPv3 message contains values for these
      two parameters.
      </p>
    <p>There is a MIB, SNMP-COMMUNITY-MIB, which maps a community
      string to a <span class="code">contextEngineID</span> and <span class="code">contextName</span>. Thus, 
      each message, an SNMPv1, SNMPv2c or an SNMPv3 message, always 
      uniquely identifies a context.
      </p>
    <p>For an agent, the <span class="code">contextEngineID</span> identified by a received
      message, is always equal to the <span class="code">snmpEngineID</span> of the agent.
      Otherwise, the message was not intended for the agent.  If the
      agent is configured with more than one context, the
      instrumentation code must be able to figure out for which context
      the request was intended.  There is a function
      <span class="code">snmpa:current_context/0</span> provided for this purpose.
      </p>
    <p>By default, the agent has no knowledge of any other contexts
      than the default context, <span class="code">""</span>.  If it is to support more
      contexts, these must be explicitly added, by using an appropriate
      configuration file 
      <span class="bold_code"><a href="snmp_agent_config_files.html">Agent Configuration Files</a></span>.
      </p>
  

  <h3><a name="id74376">2.6 
        Management of the Agent</a></h3>
    
    <a name="management"></a>
    <p>There is a set of standard MIBs, which are used to control and
      configure an SNMP agent.  All of these MIBs, with the exception of
      the optional SNMP-PROXY-MIB (which is only used for proxy agents),
      are implemented in this agent.  Further, it is configurable which
      of these MIBs are actually loaded, and thus made visible to SNMP
      managers.  For example, in a non-secure environment, it might be a
      good idea to not make MIBs that define access control visible.
      Note, the data the MIBs define is used internally in the
      agent, even if the MIBs not are loaded.  This chapter describes
      these standard MIBs, and some aspects of their implementation.
      </p>
    <p>Any SNMP agent must implement the <span class="code">system</span> group and the
      <span class="code">snmp</span> group, defined in MIB-II.  The definitions of these
      groups have changed from SNMPv1 to SNMPv2.   MIBs and implementations
      for both of these versions are Provided in the
      distribution.  The MIB file for SNMPv1 is called STANDARD-MIB, and the
      corresponding for SNMPv2 is called SNMPv2-MIB.  If the agent is
      configured for SNMPv1 only, the STANDARD-MIB is loaded by default;
      otherwise, the SNMPv2-MIB is loaded by default.  It is possible to
      override this default behavior, by explicitly loading another
      version of this MIB, for example, you could choose to implement
      the union of all objects in these two MIBs.
      </p>
    <p>An SNMPv3 agent must implement the SNMP-FRAMEWORK-MIB and
      SNMP-MPD-MIB.  These MIBs are loaded by default, if the agent is
      configured for SNMPv3.  These MIBs can be loaded for other
      versions as well.
      </p>
    <p>There are five other standard MIBs, which also may be loaded
      into the agent.  These MIBs are:
      </p>
    <ul>
      <li>
        <p>SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB, which defines
          managed objects for configuration of management targets,
          i.e. receivers of notifications (traps and informs).  These
          MIBs can be used with any SNMP version.
          </p>
      </li>
      <li>
        <p>SNMP-VIEW-BASED-ACM-MIB, which defined managed objects
          for access control.  This MIB can be used with any SNMP
          version.
          </p>
      </li>
      <li>
        <p>SNMP-COMMUNITY-MIB, which defines managed objects for
          coexistence of SNMPv1 and SNMPv2c with SNMPv3.  This MIB is
          only useful if SNMPv1 or SNMPv2c is used, possibly in
          combination with SNMPv3.
          </p>
      </li>
      <li>
        <p>SNMP-USER-BASED-SM-MIB, which defines managed objects
          for authentication and privacy.  This MIB is only useful
          with SNMPv3.
          </p>
      </li>
    </ul>
    <p>All of these MIBs should be loaded into the Master Agent.  Once
      loaded, these MIBs are always available in all contexts.
      </p>
    <p>The ASN.1 code, the Erlang source code, and the generated
      <span class="code">.hrl</span> files for them are provided in the distribution and are 
      placed  in the directories <span class="code">mibs</span>, <span class="code">src</span>, and <span class="code">include</span>,
      respectively, in the <span class="code">snmp</span> application.
      </p>
    <p>The <span class="code">.hrl</span> files are generated with
      <span class="code">snmpc:mib_to_hrl/1</span>.  Include these files in your code as in
      the following example:
      </p>
    <div class="example"><pre>
-include_lib("snmp/include/SNMPv2-MIB.hrl").
    </pre></div>
    <p>The initial values for the managed objects defined in these
      tables, are read at start-up from a set of configuration files.
      These are described in <span class="bold_code"><a href="snmp_config.html">Configuration Files</a></span>.
      </p>

    <h4>STANDARD-MIB and SNMPv2-MIB</h4>
      
      <p>These MIBs contain the <span class="code">snmp-</span> and <span class="code">system</span> groups
        from MIB-II which is defined in RFC1213 (STANDARD-MIB) or
        RFC1907 (SNMPv2-MIB).  They are implemented in the
        <span class="code">snmp_standard_mib</span> module. The <span class="code">snmp</span> counters all
        reside in volatile memory and the <span class="code">system</span> and
        <span class="code">snmpEnableAuthenTraps</span> variables in persistent memory,
        using the SNMP built-in database (refer to the Reference Manual,
        section <span class="code">snmp</span>, module <span class="code">snmpa_local_db</span> for more
        details).</p>
      <p>If another implementation of any of these variables is needed,
        e.g. to store the persistent variables in a Mnesia database,
        an own implementation of the variables must be made. That MIB 
        will be compiled and loaded instead of the default MIB. 
        The new compiled MIB
        must have the same name as the original MIB (i.e. STANDARD-MIB
        or SNMPv2-MIB), and be located in the SNMP configuration
        directory (see <span class="bold_code"><a href="snmp_config.html">Configuration Files</a></span>.) 
        </p>
      <p>One of these MIBs is always loaded.  If only SNMPv1 is used,
        STANDARD-MIB is loaded, otherwise SNMPv2-MIB is loaded.
        </p>

      <h4>Data Types</h4>
        
        <p>There are some new data types in SNMPv2 that are useful in
          SNMPv1 as well.  In the STANDARD-MIB, three data types are
          defined, <span class="code">RowStatus</span>, <span class="code">TruthValue</span> and
          <span class="code">DateAndTime</span>.  These data types are originally defined
          as textual conventions in SNMPv2-TC (RFC1903).
          </p>
      
    

    <h4>SNMP-FRAMEWORK-MIB and SNMP-MPD-MIB</h4>
      
      <p>The SNMP-FRAMEWORK-MIB and SNMP-MPD-MIB define additional 
        read-only managed objects, which
        is used in the generic SNMP framework defined in RFC2271 and the
        generic message processing and dispatching module defined in
        RFC2272.  They are generic in the sense that they are not tied
        to any specific SNMP version.
        </p>
      <p>The objects in these MIBs are implemented in the modules
        <span class="code">snmp_framework_mib</span> and <span class="code">snmp_standard_mib</span>,
        respectively.  All objects reside in volatile memory, and the
        configuration files are always reread at start-up.
        </p>
      <p>If SNMPv3 is used, these MIBs are loaded by default.
        </p>
    

    <h4>SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB</h4>
      
      <p>The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB define managed 
        objects for configuration of notification receivers.  They 
        are described in detail in RFC2273.  Only a brief description 
        is given here.
        </p>
      <p>All tables in these MIBs have a column of type
        <span class="code">StorageType</span>.  The value of this column specifies how each
        row is stored, and what happens in case of a restart of the
        agent.  The implementation supports the values <span class="code">volatile</span>
        and <span class="code">nonVolatile</span>.  When the tables are initially filled
        with data from the configuration files, these rows will
        automatically have storage type <span class="code">nonVolatile</span>.  Should the
        agent restart, all <span class="code">nonVolatile</span> rows survive the restart,
        while the <span class="code">volatile</span> rows are lost.
        The configuration files are not read at restart, by default.
        </p>
      <p>These MIBs are not loaded by default.
        </p>

      <h4>snmpNotifyTable</h4>
        
        <p>An entry in the <span class="code">snmpNotifyTable</span> selects a set
          of management targets, which should receive notifications, 
          as well as the type (trap or inform) of notification that 
          should be sent to each selected management target.
          When an application sends a notification using
          the function <span class="code">send_notification/5</span> or the function
          <span class="code">send_trap</span> the parameter <span class="code">NotifyName</span>, specified in
          the call, is used as an index in the table.  The notification
          is sent to the management targets selected by that entry.
          </p>
      

      <h4>snmpTargetAddrTable</h4>
        
        <p>An entry in the <span class="code">snmpTargetAddrTable</span> defines
          transport parameters (such as
          IP address and UDP port) for each management target.  Each row
          in the <span class="code">snmpNotifyTable</span> refers to potentially many rows
          in the <span class="code">snmpTargetAddrTable</span>.  Each row in the
          <span class="code">snmpTargetAddrTable</span>
          refers to an entry in the <span class="code">snmpTargetParamsTable</span>.
          </p>
      

      <h4>snmpTargetParamsTable</h4>
        
        <p>An entry in the <span class="code">snmpTargetParamsTable</span> defines 
          which SNMP version to use, and which security parameters to use.
          </p>
        <p>Which SNMP version to use is implicitly defined by
          specifying the Message Processing Model.  This version of the
          agent handles the models <span class="code">v1</span>, <span class="code">v2c</span> and <span class="code">v3</span>.
          </p>
        <p>Each row specifies which security model to use, along with
          security level and security parameters.
          </p>
      
    

    <h4>SNMP-VIEW-BASED-ACM-MIB</h4>
      
      <p>The SNMP-VIEW-BASED-ACM-MIB defines managed objects to
        control access to the the managed objects for the managers.  
        The View Based Access Control Module (VACM) can be used with 
        any SNMP version. However, if it is used with SNMPv1 or SNMPv2c, 
        the SNMP-COMMUNITY-MIB defines additional objects to map 
        community strings to VACM parameters.
        </p>
      <p>All tables in this MIB have a column of type <span class="code">StorageType</span>.  
        The value of this column specifies how each
        row is stored, and what happens in case of a restart of the
        agent.  The implementation supports the values <span class="code">volatile</span>
        and <span class="code">nonVolatile</span>.  When the tables are initially filled
        with data from the configuration files, these rows will
        automatically have storage type <span class="code">nonVolatile</span>.  Should the
        agent restart, all <span class="code">nonVolatile</span> rows survive the restart,
        while the <span class="code">volatile</span> rows are lost.
        The configuration files are not read at restart by default.
        </p>
      <p>This MIB is not loaded by default.
        </p>
      <p>VACM is described in detail in RFC2275.  Here is only a brief
        description given.
        </p>
      <p>The basic concept is that of a <strong>MIB view</strong>.  An MIB view
        is a subset of all the objects implemented by an agent.  A
        manager has access to a certain MIB view, depending on which
        security parameters are used, in which context the request is
        made, and which type of request is made.
        </p>
      <p>The following picture gives an overview of the mechanism to
        select an MIB view:</p>
      <img alt="IMAGE MISSING" src="MIB_mechanism.gif"><br>
        <em>Figure
        2.4:
         
        Overview of the mechanism of MIB selection</em>
      

      <h4>vacmContextTable</h4>
        
        <p>The <span class="code">vacmContextTable</span> is a read-only table that lists all
          available contexts.
          </p>
      

      <h4>vacmSecurityToGroupTable</h4>
        
        <p>The <span class="code">vacmSecurityToGroupTable</span> maps a <span class="code">securityModel</span>
          and a
          <span class="code">securityName</span> to a <span class="code">groupName</span>.
          </p>
      

      <h4>vacmAccessTable</h4>
        
        <p>The <span class="code">vacmAccessTable</span> maps the <span class="code">groupName</span> (found in
          <span class="code">vacmSecurityToGroupTable</span>), <span class="code">contextName</span>,
          <span class="code">securityModel</span>, and <span class="code">securityLevel</span> to an MIB view
          for each type of operation (read, write, or notify).  The MIB
          view is represented as a <span class="code">viewName</span>.  The definition of
          the MIB view represented by the <span class="code">viewName</span> is found in
          the <span class="code">vacmViewTreeFamilyTable</span></p>
      

      <h4>vacmViewTreeFamilyTable</h4>
        
        <p>The <span class="code">vacmViewTreeFamilyTable</span> is indexed by the
          <span class="code">viewName</span>, and defines
          which objects are included in the MIB view.
          </p>
        <p>The MIB definition for the table looks as follows:</p>
        <div class="example"><pre>
VacmViewTreeFamilyEntry ::= SEQUENCE
    {
        vacmViewTreeFamilyViewName     SnmpAdminString,
        vacmViewTreeFamilySubtree      OBJECT IDENTIFIER,
        vacmViewTreeFamilyMask         OCTET STRING,
        vacmViewTreeFamilyType         INTEGER,
        vacmViewTreeFamilyStorageType  StorageType,
        vacmViewTreeFamilyStatus       RowStatus
    }

INDEX { vacmViewTreeFamilyViewName,
        vacmViewTreeFamilySubtree
      }
        </pre></div>
        <p>Each <span class="code">vacmViewTreeFamilyViewName</span> refers to a
          collection of sub-trees.
          </p>

        <h4>MIB View Semantics</h4>
          
          <p>An MIB view is a collection of included and excluded
            sub-trees. A sub-tree is identified by an OBJECT IDENTIFIER. A
            mask is associated with each sub-tree.
            </p>
          <p>For each possible MIB object instance, the instance
            belongs to a sub-tree if:
            </p>
          <ul>
            <li>the OBJECT IDENTIFIER name of that MIB object
             instance comprises at least as many sub-identifiers as
             does the sub-tree, and
            </li>
            <li>each sub-identifier in the name of that MIB object
             instance matches the corresponding sub-identifier of the
             sub-tree whenever the corresponding bit of the associated
             mask is 1 (0 is a wild card that matches anything).</li>
          </ul>
          <p>Membership of an object instance in an MIB view is
            determined by the following algorithm:
            </p>
          <ul>
            <li>If an MIB object instance does not belong to any of
             the relevant sub-trees, then the instance is not in the
             MIB view.
            </li>
            <li>If an MIB object instance belongs to exactly one
             sub-tree, then the instance is included in, or excluded
             from, the relevant MIB view according to the type of
             that entry.
            </li>
            <li>If an MIB object instance belongs to more than one
             sub-tree, then the sub-tree which comprises the greatest
             number of sub-identifiers, and is the lexicographically
             greatest, is used.
            </li>
          </ul>
          <div class="note">
<div class="label">Note</div>
<div class="content"><p>
            <p>If the OBJECT IDENTIFIER is longer than an OBJECT
              IDENTIFIER of an object type in the MIB, it refers to
              object instances. Because of this, it is possible to
              control whether or not particular rows in a table shall be
              visible.</p>
          </p></div>
</div>
        
      
    

    <h4>SNMP-COMMUNITY-MIB</h4>
      
      <p>The SNMP-COMMUNITY-MIB defines managed objects that is used 
        for coexistence between SNMPv1 and SNMPv2c with SNMPv3.  
        Specifically, it contains objects for mapping between community 
        strings and version-independent SNMP message parameters.  In 
        addition, this MIB provides a mechanism for performing source address
        validation on incoming requests, and for selecting community
        strings based on target addresses for outgoing notifications.
        </p>
      <p>All tables in this MIB have a column of type
        <span class="code">StorageType</span>.  The value of this column specifies how each
        row is stored, and what happens in case of a restart of the
        agent.  The implementation supports the values <span class="code">volatile</span>
        and <span class="code">nonVolatile</span>.  When the tables are initially filled
        with data from the configuration files, these rows will
        automatically have storage type <span class="code">nonVolatile</span>.  Should the
        agent restart, all <span class="code">nonVolatile</span> rows survive the restart,
        while the <span class="code">volatile</span> rows are lost.
        The configuration files are not read at restart, by default.
        </p>
      <p>This MIB is not loaded by default.
        </p>
    

    <h4>SNMP-USER-BASED-SM-MIB</h4>
      
      <p>The SNMP-USER-BASED-SM-MIB defines managed objects that is
        used for the User-Based Security Model.
        </p>
      <p>All tables in this MIB have a column of type
        <span class="code">StorageType</span>.  The value of the column specifies how each
        row is stored, and what happens in case of a restart of the
        agent.  The implementation supports the values <span class="code">volatile</span>
        and <span class="code">nonVolatile</span>.  When the tables are initially filled
        with data from the configuration files, these rows will
        automatically have storage type <span class="code">nonVolatile</span>.  Should the
        agent restart, all <span class="code">nonVolatile</span> rows survive the restart,
        while the <span class="code">volatile</span> rows are lost.
        The configuration files are not read at restart, by default.
        </p>
      <p>This MIB is not loaded by default.
        </p>
    

    <h4>OTP-SNMPEA-MIB</h4>
      
      <p>The OTP-SNMPEA-MIB was used in earlier versions of the agent, before
        standard MIBs existed for access control, MIB views, and trap
        target specification.  All objects in this MIB are now obsolete.
        </p>
    
  

  <h3><a name="id73838">2.7 
        Notifications</a></h3>
    
    <a name="notifications"></a>
    <p>Notifications are defined in SMIv1 with the TRAP-TYPE macro in
      the definition of an MIB (see RFC1215).  The corresponding
      macro in SMIv2 is NOTIFICATION-TYPE.  When an application
      decides to send a notification, it calls one of the following
      functions:
      </p>
    <div class="example"><pre>
snmpa:send_notification(Agent, Notification, Receiver
                       [, NotifyName, ContextName, Varbinds])
snmpa:send_trap(Agent, Notification, Community [, Receiver, Varbinds])
    </pre></div>
    <p>providing the registered name or process identifier of the
      agent where the MIB, which defines the notification is loaded and
      the symbolic name of the notification.
      </p>
    <p>If the <span class="code">send_notification/3,4</span> function is used, all
      management targets are selected, as defined in RFC2273.  The
      <span class="code">Receiver</span> parameter defines where the agent should send
      information about the delivery of inform requests.
      </p>
    <p>If the <span class="code">send_notification/5</span> function is used, an
      <span class="code">NotifyName</span> must be provided.  This parameter is used as an
      index in the <span class="code">snmpNotifyTable</span>, and the management targets
      defined by that single entry is used.
      </p>
    <p>The <span class="code">send_notification/6</span> function is the most general
      version of the function.  A <span class="code">ContextName</span> must be specified,
      from which the notification will be sent.  If this parameter is
      not specified, the default context (<span class="code">""</span>) is used.
      </p>
    <p>The function <span class="code">send_trap</span> is kept for backwards
      compatibility and should not be used in new code.  Applications
      that use this function will
      continue to work.  The <span class="code">snmpNotifyName</span> is used as the
      community string by the agent when a notification is sent.
      </p>

    <h4>Notification Sending</h4>
      
      <p>The simplest way to send a notification is to call the function 
        <span class="code">snmpa:send_notification(Agent, Notification, no_receiver)</span>.
        In this case, the agent performs a get-operation to retrieve the
        object values that are defined in the notification
        specification (with the TRAP-TYPE or NOTIFICATION-TYPE macros).
        The notification is sent to all managers defined in the target
        and notify tables, either unacknowledged as traps, or
        acknowledged as inform requests.
        </p>
      <p>If the caller of the function wants to know whether or not
        acknowledgments are received for a certain notification
        (provided it is sent as an inform), the <span class="code">Receiver</span>
        parameter can be specified as <span class="code">{Tag, ProcessName}</span> (refer
        to the Reference Manual, section snmp, module <span class="code">snmp</span> for
        more details).  In this case, the agent send a message
        <span class="code">{snmp_notification, Tag, {got_response, ManagerAddr}}</span> or
        <span class="code">{snmp_notification, Tag, {no_response, ManagerAddr}}</span> for
        each management target.
        </p>
      <p>Sometimes it is not possible to retrieve the values for some
        of the objects in the notification specification with a
        get-operation.  However, they are known when the
        <span class="code">send_notification</span> function is called. This is the case if
        an object is an element in a table.  It is possible to give the
        values of some objects to the <span class="code">send_notification</span> function
        <span class="code">snmpa:send_notification(Agent, Notification, Receiver, Varbinds)</span>.  In this function, <span class="code">Varbinds</span> is a list of
        <span class="code">Varbind</span>, where each <span class="code">Varbind</span> is one of:
        </p>
      <ul>
        <li>
<span class="code">{Variable, Value}</span>, where <span class="code">Variable</span> is the
         symbolic name of a scalar variable referred to in the notification
         specification.
        </li>
        <li>
<span class="code">{Column, RowIndex, Value}</span>, where <span class="code">Column</span> is
         the symbolic name of a column variable.  <span class="code">RowIndex</span> is a
         list of indices for the specified element.  If this is the
         case, the OBJECT IDENTIFIER sent in the trap is the
        <span class="code">RowIndex</span> appended to the OBJECT IDENTIFIER for the
         table column. This is the OBJECT IDENTIFIER which specifies
         the element.
        </li>
        <li>
<span class="code">{OID, Value}</span>, where <span class="code">OID</span> is the OBJECT
         IDENTIFIER for an instance of an object, scalar variable or
         column variable.
        </li>
      </ul>
      <p>For example, to specify that <span class="code">sysLocation</span> should have the
        value <span class="code">"upstairs"</span> in the notification, we could use one of:
        </p>
      <ul>
        <li>
<span class="code">{sysLocation, "upstairs"}</span> or</li>
        <li><span class="code">{[1,3,6,1,2,1,1,6,0], "upstairs"}</span></li>
      </ul>
      <p>It is also possible to specify names and values for extra
        variables that should be sent in the notification, but were not
        defined in the notification specification.
        </p>
      <p>The notification is sent to all management targets found in
        the tables.  However, make sure that each manager has access to
        the variables in the notification. If a variable is outside a
        manager's MIB view, this manager will not receive the
        notification.
        </p>
      <div class="note">
<div class="label">Note</div>
<div class="content"><p>
        <p>By definition, it is not possible to send objects with
          ACCESS <span class="code">not-accessible</span> in notifications. However,
          historically this is often done and for this reason we allow
          it in notification sending. If a variable has ACCESS
          <span class="code">not-accessible</span>, the user must provide a value for the
          variable in the <span class="code">Varbinds</span> list. It is not possible for
          the agent to perform a get-operation to retrieve this value.
          </p>
      </p></div>
</div>
    

    <h4>Notification Filters</h4>
      
      <p>It is possible to add <strong>notification filters</strong> to an agent.
        These filters will be called when a notification is to be 
        sent. Their purpose is to allow modification, suppression or 
        other type of actions.</p>
      <p>A notification filter is a module implementing the 
        <span class="bold_code"><a href="snmpa_notification_filter.html">snmpa_notification_filter</a></span> behaviour. A filter is added/deleted using the functions:
        <span class="bold_code"><a href="snmpa.html#register_notification_filter">snmpa:register_notification_filter</a></span> and 
        <span class="bold_code"><a href="snmpa.html#unregister_notification_filter">snmpa:unregister_notification_filter</a></span>.</p>
      <p>Unless otherwise specified, the order of the registered filters
        will be the order in which they are registered.</p>
    

    <h4>Sub-agent Path</h4>
      
      <p>If a value for an object is not given to the
        <span class="code">send_notification</span> function, the sub-agent will perform a
        get-operation to retrieve it. If the object is not implemented
        in this sub-agent, its parent agent tries to perform a
        get-operation to retrieve it. If the object is not implemented
        in this agent either, it forwards the object to its parent, and
        so on. Eventually the Master Agent is reached and at this point
        all unknown object values must be resolved. If some object is
        unknown even to the Master Agent, this is regarded as an error
        and is reported with a call to <span class="code">user_err/2</span> of the 
        error report module. No notifications are sent in this case.
        </p>
      <p>For a given notification, the variables, which are referred to
        in the notification specification, must be implemented by the
        agent that has the MIB loaded, or by some parent to this
        agent. If not, the application must provide values for the
        unknown variables. The application must also provide values for
        all elements in tables.
        </p>
    
  

  <h3><a name="id75718">2.8 
        Discovery</a></h3>
    
    <a name="discovery"></a>
    <p>The <strong>sender</strong> is <strong>authoritative</strong> for messages containing
      payload which does <strong>not</strong> expect a response (for example 
      SNMPv2-Trap, Response or Report PDU). </p>
    <p>The <strong>receiver</strong> is <strong>authoritative</strong> for messages containing
      payload which expects a response (for example 
      Get, GetNext, Get-Bulk, Set or Inform PDU). </p>
    <p>The agent can both perform and respond to discovery.</p>
    <p>The agent responds to discovery autonomously, without interaction
      by the user. </p> 
    <p>Initiating discovery towards a manager is done by calling the 
      <span class="bold_code"><a href="snmpa.html#discovery">discovery</a></span> function. 
      The <span class="code">EngineId</span> field of the target (manager) entry in the 
      <span class="bold_code"><a href="snmp_agent_config_files.html#target_addr">target_addr.conf</a></span> file has to have the value <span class="code">discovery</span>. 
      Note that if the manager does not respond, the <span class="code">Timeout</span> and 
      <span class="code">RetryCount</span> 
      fields decide how long the function will hang before it returns. </p>
    <p>Discovery can only be performed towards one manager at a time.</p>
  

</div>
<div class="footer">
<hr>
<p>Copyright © 1997-2012 Ericsson AB. All Rights Reserved.</p>
</div>
</div>
</div></body>
</html>