rfc3512.txt

开发snmp的开发包有两个开放的SNMP开发库

   such as an individual object instance or in very large aggregations
   that could include many object instances located in many tables on a
   managed device.  For this reason, reliance on transactional integrity
   only at the SNMP protocol level is insufficient.

2.2.  Practical Requirements for Transactional Control

   A well-designed and deployed configuration system should have the
   following features with regard to transactions and transactional
   integrity.

   1) Provide for flexible transaction control at many different levels
      of granularity.  At one extreme, an entire configuration may be
      delivered and installed on an element, or alternately one small
      attribute may be changed.

   2) The transaction control component should work at and understand a
      notion of the kind of multi-level "defaulting" as described in
      Section 7.1.  The key point here is that it may make most sense to
      configure systems at an abstract level rather than on an
      individual instance by instance basis as has been commonly
      practiced.  In some cases it is more effective to send a
      configuration command to a system that contains a set of
      'defaults' to be applied to instances that meet certain criteria.

   3) An effective configuration management system must allow
      flexibility in the definition of a successful transaction.  This
      cannot be done at the protocol level alone, but rather must be
      provided for throughout the application and the information that
      is being managed.  In the case of SNMP, the information would be
      in properly defined MIB modules.

   4) A configuration management system should provide time-indexed
      transaction control.  For effective rollback control, the
      configuration transactions and their successful or unsuccessful
      completion status must be reported by the managed elements and
      stored in a repository that supports such time indexing and can
      record the user that made the change, even if the change was not
      carried out by the system recording the change.





MacFaden, et al.             Informational                      [Page 6]

RFC 3512       Configuring Networks and Devices with SNMP     April 2003


   5) The managed system must support transactional security.  This
      means that depending on who is making the configuration request
      and where it is being made, it may be accepted or denied based on
      security policy that is in effect in the managed element.

   Effective transactional control is a responsibility shared between
   design, implementation, and operational practice.  Transaction
   control techniques for MIB module design are discussed in Section
   3.3.  Transaction control considerations for the agent implementation
   are discussed in Section 5.2.2.

2.3.  Practices in Configuration--Verification

   Verification of expected behavior subsequent to the commitment of
   change is an integral part of the configuration process.  To reduce
   the chance of making simple errors in configuration, many
   organizations employ the following change management procedure:

   pre-test - verify that the system is presently working properly

   change   - make configuration changes and wait for convergence
              (system or network stability)

   re-test  - verify once again that the system is working properly

   This procedure is commonly used to verify configuration changes to
   critical systems such as the domain name system (DNS).  DNS software
   kits provide diagnostic tools that allow automatic test
   procedures/scripts to be conducted.

   A planned configuration sequence can be aborted if the pre-
   configuration test result shows the state of the system as unstable.
   Debugging the unintended effects of two sets of changes in large
   systems is often more challenging than an analysis of the effects of
   a single set after test termination.

   Networks and devices under SNMP configuration readily support this
   change management procedure since the SNMP provides integrated
   monitoring, configuration and diagnostic capabilities.  The key is
   the sequencing of SNMP protocol operations to effect an integrated
   change procedure like the one described above.  This is usually a
   well-bounded affair for changes within a single network element or
   node.  However, there are times when configuration of a given element
   can impact other elements in a network.  Configuring network
   protocols such as IEEE 802.1D Spanning Tree or OSPF is especially
   challenging since the impact of a configuration change can directly
   affect stability (convergence) of the network the device is connected
   to.



MacFaden, et al.             Informational                      [Page 7]

RFC 3512       Configuring Networks and Devices with SNMP     April 2003


   An integrated view of configuration and monitoring provides an ideal
   platform from which to evaluate such changes.  For example, the MIB
   module governing IEEE 802.1D Spanning Tree (RFC 1493 [24]) provides
   the following object to monitor stability per logical bridge.

      dot1dStpTopChanges OBJECT-TYPE
          SYNTAX  Counter
          ACCESS  read-only
          STATUS  mandatory
          DESCRIPTION
             "The total number of topology changes detected by
             this bridge since the management entity was last
             reset or initialized."
          REFERENCE
             "IEEE 802.1D-1990: Section 6.8.1.1.3"
          ::= { dot1dStp 4 }

   Likewise, the OSPF MIB module provides a similar metric for stability
   per OSPF area.

      ospfSpfRuns OBJECT-TYPE
          SYNTAX   Counter32
          MAX-ACCESS   read-only
          STATUS   current
          DESCRIPTION
             "The number of times that the intra-area route
             table has been calculated using this area's
             link-state database.  This is typically done
             using Dijkstra's algorithm."
         ::= { ospfAreaEntry 4 }

   The above object types are good examples of a means of facilitating
   the principles described in Section 2.3.  That is, one needs to
   understand the behavior of a subsystem before configuration change,
   then be able to use the same means to retest and verify proper
   operation subsequent to configuration change.

   The operational effects of a given implementation often differ from
   one to another for any given standard configuration object.  The
   impact of a change to stability of systems such as OSPF should be
   documented in an agent-capabilities statement which is consistent
   with "Requirements for IP Version 4 Routers" [22], Section 1.3.4:

      A vendor needs to provide adequate documentation on all
      configuration parameters, their limits and effects.






MacFaden, et al.             Informational                      [Page 8]

RFC 3512       Configuring Networks and Devices with SNMP     April 2003


   Adherence to the above model is not fail-safe, especially when
   configuration errors are masked by long latencies or when
   configuration errors lead to oscillations in network stability.  For
   example, consider the situation of loading a new software version on
   a device, which leads to small, slow, cumulative memory leaks brought
   on by a certain traffic pattern that was not caught during vendor and
   customer test lab trials.

   In a network-based example, convergence in an autonomous system
   cannot be guaranteed when configuration changes are made since there
   are factors beyond the control of the operator, such as the state of
   other network elements.  Problems affecting this convergence may not
   be detected for a significant period of time after the configuration
   change.  Even for factors within the operator's control, there is
   often little verification done to prevent mis-configuration (as shown
   in the following example).

   Consider a change made to ospfIfHelloInterval and
   ospfIfRtrDeadInterval [24] timers in the OSPF routing protocol such
   that both are set to the same value.  Two routers may form an
   adjacency but then begin to cycle in and out of adjacency, and thus
   never reach a stable (converged) state.  Had the configuration
   process described at the beginning of this section been employed,
   this particular situation would have been discovered without
   impacting the production network.

   The important point to remember from this discussion is that
   configuration systems should be designed and implemented with
   verification tests in mind.

3.  Designing a MIB Module

   Carefully considered MIB module designs are crucial to practical
   configuration with SNMP.  As we have just seen, MIB objects designed
   for configuration can be very effective since they can be associated
   with integrated diagnostic, monitoring, and fault objects.  MIB
   modules for configuration also scale when they expose their notion of
   template object types.  Template objects can represent information at
   a higher level of abstraction than instance-level ones.  This has the
   benefit of reducing the amount of instance-level data to move from
   management application to the agent on the managed element, when that
   instance-level data is brought about by applying a template object on
   the agent.  Taken together, all of these objects can provide a robust
   configuration subsystem.

   The remainder of this section provides specific practices used in MIB
   module design with SMIv2 and SNMPv3.




MacFaden, et al.             Informational                      [Page 9]

RFC 3512       Configuring Networks and Devices with SNMP     April 2003


3.1.  MIB Module Design - General Issues

   One of the first tasks in defining a MIB module is the creation of a
   model that reflects the scope and organization of the management
   information an agent will expose.

   MIB modules can be thought of as logical models providing one or more
   aspects/views of a subsystem.  The objective for all MIB modules
   should be to serve one or more operational requirements such as
   accounting information collection, configuration of one or more parts
   of a system, or fault identification.  However, it is important to
   include only those aspects of a subsystem that are proven to be
   operationally useful.

   In 1993, one of most widely deployed MIB modules supporting
   configuration was published, RFC 1493, which contained the BRIDGE-
   MIB.  It defined the criteria used to develop the MIB module as
   follows:

      To be consistent with IAB directives and good engineering
      practice, an explicit attempt was made to keep this MIB as simple
      as possible.  This was accomplished by applying the following
      criteria to objects proposed for inclusion:

   (1)  Start with a small set of essential objects and add only as
        further objects are needed.

   (2)  Require objects be essential for either fault or configuration
        management.

   (3)  Consider evidence of current use and/or utility.

   (4)  Limit the total (sic) of objects.

   (5)  Exclude objects which are simply derivable from others in this
        or other MIBs.

   (6)  Avoid causing critical sections to be heavily instrumented.  The
        guideline that was followed is one counter per critical section
        per layer.

   Over the past eight years additional experience has shown a need to
   expand these criteria as follows:

   (7)  Before designing a MIB module, identify goals and objectives for
        the MIB module.  How much of the underlying system will be
        exposed depends on these goals.




MacFaden, et al.             Informational                     [Page 10]

RFC 3512       Configuring Networks and Devices with SNMP     April 2003


   (8)  Minimizing the total number of objects is not an explicit goal,
        but usability is.  Be sure to consider deployment and usability
        requirements.

   (9)  During configuration, consider supporting explicit error state,
        capability and capacity objects.

   (10) When evaluating rule (5) above, consider the impact on a
        management application.  If an object can help reduce a
        management application's complexity, consider defining objects
        that can be derived.

3.2.  Naming MIB modules and Managed Objects

   Naming of MIB modules and objects informally follows a set of best
   practices.  Originally, standards track MIB modules used RFC names.
   As the MIB modules evolved, the practice changed to using more
   descriptive names.  Presently, Standards Track MIB modules define a
   given area of technology such as ATM-MIB, and vendors then extend
   such MIB modules by prefixing the company name to a given MIB module