rfc3512.txt

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

           was last completely updated.  Because caching of this
           data will be a popular implementation strategy,
           retrieval of this object allows a management station
           to obtain a guarantee that no data in this table is
           older than the indicated time."
       ::= { hrSWInstalled 2 }

   A similar convention found in many standards track MIB modules is the
   "LastChange" type object.

   For example, the ENTITY-MIB, RFC 2737 [34], provides the following
   object:

   entLastChangeTime OBJECT-TYPE
     SYNTAX      TimeStamp



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


     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
             "The value of sysUpTime at the time a conceptual row is
             created, modified, or deleted in any of these tables:
                     - entPhysicalTable
                     - entLogicalTable
                     - entLPMappingTable
                     - entAliasMappingTable
                     - entPhysicalContainsTable"
     ::= { entityGeneral 1 }

   This convention is not formalized.  There tend to be small
   differences in what a table's LastChanged object reflects.  IF-MIB
   (RFC 2863 [20]) defines the following:

   ifTableLastChange  OBJECT-TYPE
       SYNTAX      TimeTicks
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "The value of sysUpTime at the time of the last
               creation or deletion of an entry in the ifTable.  If
               the number of entries has been unchanged since the
               last re-initialization of the local network management
               subsystem, then this object contains a zero value."
       ::= { ifMIBObjects 5 }

   So, if an agent modifies a row with an SNMP SET on ifAdminStatus, the
   value of ifTableLastChange will not be updated.  It is important to
   be specific about what can cause an object to update so that
   management applications will be able to detect and more properly act
   on these changes.

   The final way to keep distributed configuration data consistent is to
   use an event-driven model, where configuration changes are
   communicated as they occur.  When the frequency of change to
   configuration is relatively low or polling a cache object is not
   desired, consider defining a notification that can be used to report
   all configuration change details.

   When doing so, the option is available to an SNMPv3 (or SNMPv2c)
   agent to deliver the notification using either a trap or an inform.
   The decision as to which PDU to deliver to the recipient is generally
   a matter of local configuration.  Vendors should recommend the use of
   informs over traps for NOTIFICATION-TYPE data since the agent can use
   the presence or absence of a response to help know whether it needs




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


   to retransmit or not.  Overall, it is preferable to use an inform
   instead of a trap so that changes have a higher likelihood of
   confirmed end-to-end delivery.

   As a matter of MIB module design, when practical, the NOTIFICATION-
   TYPE should include in the PDU all of the modified columnar objects
   in a row of a table.  This makes it easier for the management
   application receiving the notification to keep track of what has
   changed in the row of a table and perform addition analysis on the
   state of the managed elements.

   However, the use of notifications to communicate the state of a
   rapidly changing object may not be ideal either.  This leads us back
   to the MIB module design question of what is the right level of
   granularity to expose.

   Finally, having to poll many "LastChange" objects does not scale
   well.  Consider providing a global LastChange type object to
   represent overall configuration in a given agent implementation.

3.3.6.  Optimizing Configuration Data Transfer

   Configuration management software should keep track of the current
   configuration of all devices under its control.  It should ensure
   that the result is a consistent view of the configuration of the
   network, which can help reduce inadvertent configuration errors.

   In devices that have very large amounts of configuration data, it can
   be costly to both the agent and the manager to have the manager
   periodically poll the entire contents of these configuration tables
   for synchronization purposes.  A benefit of good synchronization
   between the manager and the agent is that the manager can determine
   the smallest and most effective set of data to send to managed
   devices when configuration changes are required.  Depending on the
   table organization in the managed device and the agent
   implementation, this practice can reduce the burden on the managed
   device for activation of these configuration changes.

   In the previous section, we discussed the "LastChange" style of
   object.  When viewed against the requirements just described, the
   LastChange object is insufficient for large amounts of data.

   There are three design options that can be used to assist with the
   synchronization of the configuration data found in the managed device
   with the manager:






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


   1) Design multiple indices to partition the data in a table logically
      or break a table into a set of tables to partition the data based
      on what an application will use the table for

   2) Use a time-based indexing technique

   3) Define a control MIB module that manages a separate data delivery
      protocol

3.3.6.1.  Index Design

   Index design has a major impact on the amount of data that must be
   transferred between SNMP entities and can help to mitigate scaling
   issues with large tables.

   Many tables in standard MIB modules follow one of two indexing
   models:

   - Indexing based upon increasing Integer32 or Unsigned32 values of
      the kind one might find in an array.

   - Associative indexing, which refers to the technique of using
      potentially sparse indices based upon a "key" of the sort one
      would use for a hash table.

   When tables grow to a very large number of rows, using an associative
   indexing scheme offers the useful ability to efficiently retrieve
   only the rows of interest.

   For example, if an SNMP entity exposes a copy of the default-free
   Internet routing table as defined in the ipCidrRouteTable, it will
   presently contain around 100,000 rows.

   Associative indexing is used in the ipCidrRouteTable and allows one
   to retrieve, for example, all routes for a given IPv4 destination
   192.0.2/24.

   Yet, if the goal is to extract a copy of the table, the associative
   indexing reduces the throughput and potentially the performance of
   retrieval.  This is because each of the index objects are appended to
   the object identifiers for every object instance returned.

   ipCidrRouteEntry OBJECT-TYPE
      SYNTAX   IpCidrRouteEntry
      MAX-ACCESS not-accessible
      STATUS   current
      DESCRIPTION
       "A particular route to a particular destination,



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


       under a particular policy."
      INDEX {
        ipCidrRouteDest,
        ipCidrRouteMask,
        ipCidrRouteTos,
        ipCidrRouteNextHop
        }

   A simple array-like index works efficiently since it minimizes the
   index size and complexity while increasing the number of rows that
   can be sent in a PDU.  If the indexing is not sparse, concurrency can
   be gained by sending multiple asynchronous non-overlapping collection
   requests as is explained in RFC 2819 [32], Page 41 (in the section
   pertaining to Host Group indexing).

      Should requirements dictate new methods of access, multiple
      indices can be defined such that both associative and simple
      indexing can coexist to access a single logical table.

   Two examples follow.

   First, consider the ifStackTable found in RFC 2863 [20] and the
   ifInvStackTable RFC 2864 [33].  They are logical equivalents with the
   order of the auxiliary (index) objects simply reversed.

   ifStackEntry  OBJECT-TYPE
        SYNTAX        IfStackEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
                "Information on a particular relationship between
                two sub-layers, specifying that one sub-layer runs
                on 'top' of the other sub-layer.  Each sub-layer
                corresponds to a conceptual row in the ifTable."
                INDEX { ifStackHigherLayer, ifStackLowerLayer }
        ::= { ifStackTable 1 }

   ifInvStackEntry  OBJECT-TYPE
      SYNTAX        IfInvStackEntry
      MAX-ACCESS    not-accessible
      STATUS        current
      DESCRIPTION
          "Information on a particular relationship between two
          sub-layers, specifying that one sub-layer runs underneath
          the other sub-layer.  Each sub-layer corresponds to a
          conceptual row in the ifTable."
          INDEX { ifStackLowerLayer, ifStackHigherLayer }
      ::= { ifInvStackTable 1 }



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


   Second, table designs that can factor data into multiple tables with
   well-defined relationships can help reduce overall data transfer
   requirements.  The RMON-MIB, RFC 2819 [32], demonstrates a very
   useful technique of organizing tables into control and data
   components.  Control tables contain those objects that are configured
   and change infrequently, and the data tables contain information to
   be collected that can be large and may change quite frequently.

   As an example, the RMON hostControlTable provides a way to specify
   how to collect MAC addresses learned as a source or destination from
   a given port that provides transparent bridging of Ethernet packets.

   Configuration is accomplished using the hostControlTable.  It is
   indexed by a simple integer.  While this may seem to be array-like,
   it is common practice for command generators to encode the ifIndex
   into this simple integer to provide associative lookup capability.

   The RMON hostTable and hostTimeTable represent dependent tables that
   contain the results indexed by the hostControlTable entry.

   The hostTable is further indexed by the MAC address which provides
   the ability to reasonably search for a collection, such as the
   Organizationally Unique Identifier (OUI), the first three octets of
   the MAC address.

   The hostTimeTable is designed explicitly for fast transfer of bulk
   RMON data.  It demonstrates how to handle collecting large number of
   rows in the face of deletions and insertions by providing
   hostControlLastDeleteTime.

   hostControlLastDeleteTime OBJECT-TYPE
   SYNTAX     TimeTicks
   MAX-ACCESS read-only
   STATUS     current
   DESCRIPTION
       "The value of sysUpTime when the last entry
       was deleted from the portion of the hostTable
       associated with this hostControlEntry.  If no
       deletions have occurred, this value shall be zero."
   ::= { hostControlEntry 4 }

3.3.6.2.  Time Based Indexing

   The TimeFilter as defined in RFC 2021 [44] and used in RMON2-MIB and
   Q-BRIDGE-MIB (RFC 2674 [26]) provides a way to obtain only those rows
   that have changed on or after some specified period of time has