Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3512

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

Pages: 83
Informational
Part 1 of 4 – Pages 1 to 9
None   None   Next

Top   ToC   RFC3512 - 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   RFC3512 - 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   RFC3512 - 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   RFC3512 - 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   RFC3512 - 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   RFC3512 - 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   RFC3512 - 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   RFC3512 - 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   RFC3512 - 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 Section