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 MacFaden, et al. Informational [Page 1] RFC 3512 Configuring Networks and Devices with SNMP April 2003 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 MacFaden, et al. Informational [Page 2] RFC 3512 Configuring Networks and Devices with SNMP April 2003 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]. MacFaden, et al. Informational [Page 3] RFC 3512 Configuring Networks and Devices with SNMP April 2003 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. MacFaden, et al. Informational [Page 4] RFC 3512 Configuring Networks and Devices with SNMP April 2003 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 MacFaden, et al. Informational [Page 5] RFC 3512 Configuring Networks and Devices with SNMP April 2003 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. 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 as in ACME-ATM-MIB. Object descriptors (the "human readable names" assigned to object identifiers [2]) defined in standard MIB modules should be unique across all MIB modules. Generally, a prefix is added to each managed object that can help reference the MIB module it was defined in. For example, the IF-MIB uses "if" prefix for descriptors of object types such as ifTable, ifStackTable and so forth. MIB module object type descriptors can include an abbreviation for the function they perform. For example the objects that control configuration in the example MIB module in Section 8 include "Cfg" as part of the object descriptor, as in bldgHVACCfgDesiredTemp. This is more fully realized when the object descriptors that include the fault, configuration, accounting, performance and security [33] abbreviations are combined with an organized OID assignment approach. For example, a vendor could create a configuration branch in their private enterprises area. In some cases this might be best done on a per product basis. Whatever the approach used, "Cfg" might be included in every object descriptor in the configuration branch. This has two operational benefits. First, for those that do look at instances of MIB objects, descriptors as seen through MIB browsers or other command line tools assist in conveying the meaning of the object type. Secondly, management applications can be pointed at specific subtrees for fault or configuration, causing a more efficient retrieval of data and a simpler management application with potentially better performance. MacFaden, et al. Informational [Page 11] RFC 3512 Configuring Networks and Devices with SNMP April 2003 3.3. Transaction Control And State Tracking Transactions and keeping track of their state is an important consideration when performing any type of configuration activity regardless of the protocol. Here are a few areas to consider when designing transaction support into an SNMP-based configuration system. 3.3.1. Conceptual Table Row Modification Practices Any discussion of transaction control as it pertains to MIB module design often begins with how the creation or modification of object instances in a conceptual row in the MIB module is controlled. RowStatus [3] is a standard textual convention for the management of conceptual rows in a table. Specifically, the RowStatus textual convention that is used for the SYNTAX value of a single column in a table controls the creation, deletion, activation, and deactivation of conceptual rows of the table. When a table has been defined with a RowStatus object as one of its columns, changing an instance of the object to 'active' causes the row in which that object instance appears to become 'committed'. In a multi-table scenario where the configuration data must be spread over many columnar objects, a RowStatus object in one table can be used to cause the entire set of data to be put in operation or stored based on the definition of the objects. In some cases, very large amounts of data may need to be 'committed' all at once. In these cases, another approach is to configure all of the rows in all the tables required and have an "activate" object that has a set method that commits all the modified rows. The RowStatus textual convention specifies that, when used in a conceptual row, a description must define what can be modified. While the description of the conceptual row and its columnar object types is the correct place to derive this information on instance modifiability, it is often wrongly assumed in some implementations that: 1) objects either must all be presently set or none need be set to make a conceptual RowStatus object transition to active(1) 2) objects in a conceptual row cannot be modified once a RowStatus object is active(1). Restricting instance modifiability like this, so that after a RowStatus object is set to active(1) is in fact a reasonable limitation, since such a set of RowStatus may have agent system side-effects which depend on committed columnar MacFaden, et al. Informational [Page 12] RFC 3512 Configuring Networks and Devices with SNMP April 2003 object instance values. However, where this restriction exists on an object, it should be made clear in a DESCRIPTION clause such as the following: protocolDirDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (1..64)) MAX-ACCESS read-create STATUS current DESCRIPTION "A textual description of the protocol encapsulation. A probe may choose to describe only a subset of the entire encapsulation (e.g., only the highest layer). This object is intended for human consumption only. This object may not be modified if the associated protocolDirStatus object is equal to active(1)." ::= { protocolDirEntry 4 } Any such restrictions on columnar object instance modification while a row's RowStatus object instance is set to active(1) should appear in the DESCRIPTION clause of the RowStatus columnar OBJECT-TYPE as well. 3.3.2. Fate sharing with multiple tables An important principle associated with transaction control is fate sharing of rows in different tables. Consider the case where a relationship has been specified between two conceptual tables of a MIB module (or tables in two different MIB modules). In this context, fate sharing means that when a row of a table is deleted, the corresponding row in the other table is also deleted. Fate sharing in a transaction control context can also be used with the activation of very large configuration changes. If we have two tables that hold a set of configuration information, a row in one table might have to be put in the 'ready' state before the second can be put in the 'ready' state. When that second table can be placed in the 'ready' state, then the entire transaction can be considered to have been 'committed'. Fate sharing of SNMP table data should be explicitly defined where possible using the SMI index qualifier AUGMENTS. If the relationship between tables cannot be defined using SMIv2 macros, then the DESCRIPTION clause of the object types which particularly effect the cross-table relationship should define what should happen when rows in related tables are added or deleted. MacFaden, et al. Informational [Page 13] RFC 3512 Configuring Networks and Devices with SNMP April 2003 Consider the relationship between the dot1dBasePortTable and the ifTable. These tables have a sparse relationship. If a given ifEntry supports 802.1D bridging then there is a dot1dBasePortEntry that has a pointer to it via dot1dBasePortIfIndex. Now, what should happen if an ifEntry that can bridge is deleted? Should the object dot1dBasePortIfIndex simply be set to 0 or should the dot1dBasePortEntry be deleted as well? A number of acceptable design and practice techniques can provide the answer to these questions, so it is important for the MIB module designer to provide the guidance to guarantee consistency and interoperability. To this end, when two tables are related in such a way, ambiguities such as this should be avoided by having the DESCRIPTION clauses of the pertinent row object types define the fate sharing of entries in the respective tables. 3.3.3. Transaction Control MIB Objects When a MIB module is defined that includes configuration object types, consider providing transaction control objects. These objects can be used to cause a large transaction to be committed. For example, we might have several tables that define the configuration of a portion of a system. In order to avoid churn in the operational state of the system we might create a single scalar object that, when set to a particular value, will cause the activation of the rows in all the necessary tables. Here are some examples of further usage for such object types: o Control objects that are the 'write' or 'commit' objects. Such objects can cause all pending transactions (change MIB object values as a result of SET operations) to be committed to a permanent repository or operational memory, as defined by the semantics of the MIB objects. o Control objects at different levels of configuration granularity. One of the decisions for a MIB module designer is what are the levels of granularity that make sense in practice. For example, in the routing area, would changes be allowed on a per protocol basis such as BGP? If allowed at the BGP level, are sub-levels permitted such as per autonomous system? The design of these control objects will be impacted by the underlying software design. RowStatus (see Section 3.3.1) also has important relevance as a general transaction control object. MacFaden, et al. Informational [Page 14] RFC 3512 Configuring Networks and Devices with SNMP April 2003 3.3.4. Creating And Activating New Table Rows When designing read-create objects in a table, a MIB module designer should first consider the default state of each object in the table when a row is created. Should an implementation of a standard MIB module vary in terms of the objects that need to be set in order to create an instance of a given row, an agent capabilities statement should be used to name the additional objects in that table using the CREATION-REQUIRES clause. It is useful when configuring new rows to use the notReady status to indicate row activation cannot proceed. When creating a row instance of a conceptual table, one should consider the state of instances of required columnar objects in the row. The DESCRIPTION clause of such a required columnar object should specify it as such. During the period of time when a management application is attempting to create a row, there may be a period of time when not all of these required (and non-defaultable) columnar object instances have been set. Throughout this time, an agent should return a noSuchInstance error for a GET of any object instance of the row until such time that all of these required instance values are set. The exception is the RowStatus object instance, for which a notReady(3) value should be returned during this period. One need only be concerned with the notReady value return for a RowStatus object when the row under creation does not yet have all of the required, non-defaultable instance values for the row. One approach to simplifying in-row configuration transactions when designing MIB modules is to construct table rows that have no more instance data for columnar objects than will fit inside a single SET PDU. In this case, the createAndWait() value for the RowStatus columnar object is not required. It is possible to use createAndGo() in the same SET PDU, thus simplifying transactional management. 3.3.5. Summary Objects and State Tracking Before beginning a new set of configuration transactions, a management application might want to checkpoint the state of the managed devices whose configuration it is about to change. There are a number of techniques that a MIB module designer can provide to assist in the (re-)synchronization of the managed systems. These objects can also be used to verify that the management application's notion of the managed system state is the same as that of the managed device. MacFaden, et al. Informational [Page 15] RFC 3512 Configuring Networks and Devices with SNMP April 2003 These techniques include: 1. Provide an object that reports the number of rows in a table 2. Provide an object that flags when data in the table was last modified. 3. Send a notification message (InformRequests are preferable) to deliver configuration change. By providing an object containing the number of rows in a table, management applications can decide how best to retrieve a given table's data and may choose different retrieval strategies depending on table size. Note that the availability of and application monitoring of such an object is not sufficient for determining the presence of table data change over a checkpointed duration since an equal number of row creates and deletes over that duration would reflect no change in the object instance value. Additionally, table data change which does not change the number of rows in the table would not be reflected through simple monitoring of such an object instance. Instead, the change in the value of any table object instance data can be tracked through an object that monitors table change state as a function of time. An example is found in RFC 2790, Host Resources MIB: hrSWInstalledLastUpdateTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the hrSWInstalledTable 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 descri