RFC 3512
Configuring Networks and Devices with Simple Network Management Protocol (SNMP)
Pages: 83
Informational
Informational
Part 1 of 4 – Pages 1 to 9
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
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
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].
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.
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
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.
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.
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.
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)