tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3512

Informational
Pages: 83
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: SNMPCONF

Configuring Networks and Devices with Simple Network Management Protocol (SNMP)

Part 1 of 4, p. 1 to 9
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                        M. MacFaden
Request for Comments: 3512                     Riverstone Networks, Inc.
Category: Informational                                       D. Partain
                                                                Ericsson
                                                              J. Saperia
                                                    JDS Consulting, Inc.
                                                            W. Tackabury
                                              Gold Wire Technology, Inc.
                                                              April 2003


                 Configuring Networks and Devices with
               Simple Network Management Protocol (SNMP)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document is written for readers interested in the Internet
   Standard Management Framework and its protocol, the Simple Network
   Management Protocol (SNMP).  In particular, it offers guidance in the
   effective use of SNMP for configuration management.  This information
   is relevant to vendors that build network elements, management
   application developers, and those that acquire and deploy this
   technology in their networks.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   3
      1.1. The Internet Standard Management Framework. . . . . . . .   3
      1.2. Configuration and the Internet Standard Management
           Frame-work. . . . . . . . . . . . . . . . . . . . . . . .   4
   2. Using SNMP as a Configuration Mechanism. . . . . . . . . . . .   5
      2.1. Transactions and SNMP . . . . . . . . . . . . . . . . . .   6
      2.2. Practical Requirements for Transactional Control. . . . .   6
      2.3. Practices in Configuration--Verification. . . . . . . . .   7
   3. Designing a MIB Module . . . . . . . . . . . . . . . . . . . .   9
      3.1. MIB Module Design - General Issues. . . . . . . . . . . .  10
      3.2. Naming MIB modules and Managed Objects. . . . . . . . . .  11
      3.3. Transaction Control And State Tracking. . . . . . . . . .  12

Top      ToC       Page 2 
           3.3.1. Conceptual Table Row Modification Practices. . . .  12
           3.3.2. Fate sharing with multiple tables. . . . . . . . .  13
           3.3.3. Transaction Control MIB Objects. . . . . . . . . .  14
           3.3.4. Creating And Activating New Table Rows . . . . . .  15
           3.3.5. Summary Objects and State Tracking . . . . . . . .  15
           3.3.6. Optimizing Configuration Data Transfer . . . . . .  18
      3.4. More Index Design Issues. . . . . . . . . . . . . . . . .  22
           3.4.1. Simple Integer Indexing. . . . . . . . . . . . . .  23
           3.4.2. Indexing with Network Addresses. . . . . . . . . .  23
      3.5. Conflicting Controls. . . . . . . . . . . . . . . . . . .  24
      3.6. Textual Convention Usage. . . . . . . . . . . . . . . . .  25
      3.7. Persistent Configuration. . . . . . . . . . . . . . . . .  26
      3.8. Configuration Sets and Activation . . . . . . . . . . . .  28
           3.8.1. Operational Activation Considerations. . . . . . .  28
           3.8.2. RowStatus and Deactivation . . . . . . . . . . . .  30
      3.9. SET Operation Latency . . . . . . . . . . . . . . . . . .  31
           3.9.1. Subsystem Latency, Persistence Latency,
                  and Activation Latency . . . . . . . . . . . . . .  33
      3.10. Notifications and Error Reporting. . . . . . . . . . . .  33
           3.10.1. Identifying Source of Configuration Changes . . .  34
           3.10.2. Limiting Unnecessary Transmission of
                   Notifications . . . . . . . . . . . . . . . . . .  34
           3.10.3. Control of Notification Subsystem . . . . . . . .  36
      3.11 Application Error Reporting . . . . . . . . . . . . . . .  36
      3.12 Designing MIB Modules for Multiple Managers . . . . . . .  37
      3.13 Other MIB Module Design Issues. . . . . . . . . . . . . .  39
           3.13.1 Octet String Aggregations  . . . . . . . . . . . .  39
           3.13.2 Supporting multiple instances of a MIB Module. . .  40
           3.13.3 Use of Special Optional Clauses. . . . . . . . . .  41
   4. Implementing SNMP Configuration Agents . . . . . . . . . . . .  41
      4.1. Operational Consistency . . . . . . . . . . . . . . . . .  41
      4.2. Handling Multiple Managers. . . . . . . . . . . . . . . .  43
      4.3. Specifying Row Modifiability. . . . . . . . . . . . . . .  44
      4.4. Implementing Write-only Access Objects. . . . . . . . . .  44
   5. Designing Configuration Management Software. . . . . . . . . .  44
      5.1. Configuration Application Interactions
           with Managed Systems. . . . . . . . . . . . . . . . . . .  45
           5.1.1. SET Operations . . . . . . . . . . . . . . . . . .  46
           5.1.2. Configuration Transactions . . . . . . . . . . . .  46
           5.1.3. Tracking Configuration Changes . . . . . . . . . .  47
           5.1.4. Scalability of Data Retrieval. . . . . . . . . . .  48
   6. Deployment and Security Issues . . . . . . . . . . . . . . . .  48
      6.1. Basic assumptions about Configuration . . . . . . . . . .  48
      6.2. Secure Agent Considerations . . . . . . . . . . . . . . .  49
      6.3. Authentication Notifications. . . . . . . . . . . . . . .  49
      6.4. Sensitive Information Handling. . . . . . . . . . . . . .  50
   7. Policy-based Management. . . . . . . . . . . . . . . . . . . .  51
      7.1. What Is the Meaning of 'Policy-based' . . . . . . . . . .  51

Top      ToC       Page 3 
      7.2. Organization of Data in an SNMP-Based Policy System . . .  53
      7.3. Information Related to Policy-based Configuration . . . .  54
      7.4. Schedule and Time Issues. . . . . . . . . . . . . . . . .  56
      7.5. Conflict Detection, Resolution and Error Reporting. . . .  56
           7.5.1. Changes to Configuration Outside of the
                  Policy System. . . . . . . . . . . . . . . . . . .  57
      7.6. More about Notifications in a Policy System . . . . . . .  57
      7.7. Using Policy to Move Less Configuration Data. . . . . . .  57
   8. Example MIB Module With Template-based Data. . . . . . . . . .  58
      8.1. MIB Module Definition. . . . . . . .  . . . . . . . . . .  61
      8.2. Notes on MIB Module with Template-based Data. . . . . . .  73
      8.3. Examples of Usage of the MIB . . . . . . .. . . . . . . .  74
   9. Security Considerations . . . . . . . . . . .. . . . . . . . .  77
   10. Acknowledgments. . . . . . . . . . . . . . .  . . . . . . . .  78
   11. Normative References. . . . . . . . . . . . . . . . . . . . .  78
   12. Informative References. . . . . . . . . . . . . . . . . . . .  79
   13. Intellectual Property . . . . . . . . . . . . . . . . . . . .  81
   14. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . .  82
   15. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  83

1.  Introduction

1.1.  The Internet Standard Management Framework

   The Internet Standard Management Framework has many components.  The
   purpose of this document is to describe effective ways of applying
   those components to the problems of configuration management.

   For reference purposes, the Internet Standard Management Framework
   presently consists of five major components:

   o  An overall architecture, described in RFC 3411 [1].

   o  Mechanisms for describing and naming objects and events for the
      purpose of management.  The first version of this Structure of
      Management Information (SMI) is called SMIv1 and described in STD
      16, RFC 1155 [15], STD 16, RFC 1212 [16] and RFC 1215 [17].  The
      second version, called SMIv2, is described in STD 58, RFC 2578
      [2], STD 58, RFC 2579 [3] and STD 58, RFC 2580 [4].

   o  Message protocols for transferring management information.  The
      first version of the SNMP message protocol is called SNMPv1 and
      described in STD 15, RFC 1157 [18].  A second version of the SNMP
      message protocol, which is not an Internet standards track
      protocol, is called SNMPv2c and described in RFC 1901 [19].  The
      third version of the message protocol is called SNMPv3 and
      described in RFC 3417 [5], RFC 3412 [6] and RFC 3414 [7].

Top      ToC       Page 4 
   o  Protocol operations for accessing management information.  The
      first set of protocol operations and associated PDU formats is
      described in STD 15, RFC 1157 [18].  A second set of protocol
      operations and associated PDU formats is described in RFC 3416
      [8].

   o  A set of fundamental applications described in RFC 3413 [9] and
      the view-based access control mechanism described in RFC 3415
      [10].

   A more detailed introduction to the current SNMP Management Framework
   can be found in RFC 3410 [12].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

1.2.  Configuration and the Internet Standard Management Framework

   Data networks have grown significantly over the past decade.  This
   growth can be seen in terms of:

   Scale - Networks have more network elements, and the network
      elements are larger and place more demands on the systems managing
      them.  For example, consider a typical number and speed of
      interfaces in a modern core network element.  A managed
      metropolitan area network switch can have a port density much
      greater than the port density built into the expectations of the
      management systems that predated it.  There are also many more
      interrelationships within and between devices and device
      functions.

   Functionality - network devices perform more functions.
      More protocols and network layers are required for the successful
      deployment of network services which depend on them.

   Rate of Change - the nature of modern network services
      causes updates, additions, and deletions of device configuration
      information more often than in the past.  No longer can it be
      assumed that a configuration will be specified once and then be
      updated rarely.  On the contrary, the trend has been towards much
      more frequent changes of configuration information.

   Correct configuration of network elements that make up data networks
   is a prerequisite to the successful deployment of the services on
   them.  The growth in size and complexity of modern networks increases
   the need for a standard configuration mechanism that is tightly
   integrated with performance and fault management systems.

Top      ToC       Page 5 
   The Internet Standard Management Framework has been used successfully
   to develop configuration management systems for a broad range of
   devices and networks.  A standard configuration mechanism that
   tightly integrates with performance and fault systems is needed not
   only to help reduce the complexity of management, but also to enable
   verification of configuration activities that create revenue-
   producing services.

   This document describes Current Practices that have been used when
   designing effective configuration management systems using the
   Internet Standard Management Framework (colloquially known as SNMP).
   It covers many basic practices as well as more complex agent and
   manager design issues that are raised by configuration management.
   We are not endeavoring to present a comprehensive how-to document for
   generalized SNMP agent, MIB module, or management application design
   and development.  We will, however, cover points of generalized SNMP
   software design and implementation practice, where the practice has
   been seen to benefit configuration management software.  So, for
   example, the requirement for management applications to be aware of
   agent limitations is discussed in the context of configuration
   operations, but many issues that a management application developer
   should consider with regard to manager-agent interactions are left
   for other documents and resources.

   Significant experience has been gained over the past ten years in
   configuring public and private data networks with SNMP.  During this
   time, networks have grown significantly as described above.  A
   response to this explosive growth has been the development of
   policy-based configuration management.  Policy-Based Configuration
   Management is a methodology wherein configuration information is
   derived from rules and network-wide objectives, and is distributed to
   potentially many network elements with the goal of achieving
   consistent network behavior throughout an administrative domain.

   This document presents lessons learned from these experiences and
   applies them to both conventional and policy-based configuration
   systems based on SNMP.

2.  Using SNMP as a Configuration Mechanism

   Configuration activity causes one or more state changes in an
   element.  While it often takes an arbitrary number of commands and
   amount of data to make up configuration change, it is critical that
   the configuration system treat the overall change operation
   atomically so that the number of states into which an element
   transitions is minimized.  The goal is for a change request either to
   be completely executed or not at all.  This is called transactional
   integrity.  Transactional integrity makes it possible to develop

Top      ToC       Page 6 
   reliable configuration systems that can invoke transactions and keep
   track of an element's overall state and work in the presence of error
   states.

2.1.  Transactions and SNMP

   Transactions can logically take place at very fine-grained levels
   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.

Top      ToC       Page 7 
   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.

Top      ToC       Page 8 
   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.

Top      ToC       Page 9 
   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.



(page 9 continued on part 2)

Next RFC Part