Internet Draft SNMP CONFIGURATION May 3 2000 M. MacFaden Riverstone Networks, Inc J. Saperia JDS Consulting, Inc Configuring Networks and Devices with SNMP draft-ietf-snmpconf-bcp-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 1. Introduction Data networks have grown greatly in size and complexity over the past decade. Configuration (provisioning) of network elements has grown correspondingly more complex. Complexity in MacFaden/Saperia Expires September 10th 2000 [Page 1] Internet Draft SNMP CONFIGURATION May 3 2000 the context of this document means specifically: 1) Scale - data networks consist of more devices than ever 2) Functionality - network devices increasingly perform more functions 3) Convergence - more devices involved and different levels of the stack are affected during configuration changes causing lost connectivity for some period of time The SNMP framework can and has been used to develop configuration management systems. This document describes Best Current Practices that SHOULD be used when designing and effective SNMP-based management system that includes configuration functions, or is an SNMP-based system that has only configuration functions. Configuration is a broad subject and recently a great deal of attention has been placed on policy based configuration management. This document includes recommendations for that type of configuration. Policy based configuration management is a set of configuration operations to potentially many network elements with the goal of achieving some consistent network behavior over some autonomous system. Recommendations for the application of SNMP to what has commonly be thought of as device-specific configuration operations, such as assignment of an IP address to an interface or set up of routing protocols on a router are also included. This document draws on first-hand experience provisioning data networks over the past ten years. Over that same time-period, significant experience has been gained in the development and deployment of SNMP based management software, some of which also performs configuration functions. Some of this software is in the public domain and much has been developed in the private sector. 1.1. Document Organization This document presents the goals of configuration management, the needs of operators, and the needs of implementors. Realistic expectations must be set for users and rules of MacFaden/Saperia Expires September 10th 2000 [Page 2] Internet Draft SNMP CONFIGURATION May 3 2000 thumb must provide implementors with proper use of the SNMP framework for configuration of data networks. This document is organized as follows: The background section describes how configuration of TCP/IP networks is currently practiced by experienced network operations staff and the management interfaces used to perform these operations. The requirements section enumerates the goals and fundamental assumptions of configuration. Section 2 describes terminology as used in this document. Section 3 and 4 describe agent and management development using the Internet standard SNMP framework. Section 5 describes relationship of Policy Management to SNMP framework. Section 6 discusses agent and management system deployment issues and Section 7 reviews security issues related to the models described here. 1.2. Background Data network devices are configured using many methods, however two methods remain the most common: SNMP and Command Line Interface (CLI). Layered on top of these methods are operational methods for deploying changes to networks in a cautious and incremental manner. Experienced Network Operations staff make changes to network configurations and firmware with careful planning and well documented procedures such as: A. Pass one: LAB tryout to verify reliability and interoperability with prior versions. B. Pass two: select an edge of network during non-critical/off hours to effect the change and plan for fall back should changes fail. 1. Apply change first via cli to memory and watch device/network carefully over some time period 2. After some time, write changes to persistent storage 3. Expand changes to a few more like devices 4. Keep mixed versions to prevent total loss of network 5. Watch for new unkown defaults 6. Watch for unknown side effects of changes MacFaden/Saperia Expires September 10th 2000 [Page 3] Internet Draft SNMP CONFIGURATION May 3 2000 7. update configurations in revision control system A diagnostic mode is often present to deal with implementation issues of the above. Often this is done via syslog or output to some serial or telnet interface. 1.3. Requirements This section defines realistic requirements for what we want to accomplish with SNMP Configuration. What are the goals and assumptions needed achieve state of the art configuration on network elements. Show that SNMP can be used to achieve these goals and that the assumptions are practical. The following presents a set fundamental assumptions: 1.3.1. Fundamental Tenets of configuration 1) A loss of connectivity can occur at any point in time between the configurator and the device being configured. There is no conceivable protocol or sufficient voltage that can negate this assumption. 2) Device state and configuration SHOULD be understood by a "mere mortal" with the following assumptions: 1) trained in the fundamentals of data communication (bridging, routing) 2) understands the vendor implementation 3) Operators MUST have the ability to validate proper operation of a device before and after configuration changes. 4) The expected behavioral change exhibited by an individual device under configuration is not as readily apparent as it once was. Devices are more complex as they acquire more capabilities. Interactions between capabilities are not always well defined during configuration sequences up and down a protocol stack. This leads to the next tenent: MacFaden/Saperia Expires September 10th 2000 [Page 4] Internet Draft SNMP CONFIGURATION May 3 2000 5) Configuration affects network stability and network stability affects configuration. For example, noncritical changes to a facility such as BGP or spanning tree SHOULD NOT cause convergence to be lost. 6) Achieving convergence in an autonomous system is not an absolute given when configuration changes are made. While simulations can be made, keeping track of all state data is growing harder as basic networking features become more dynamic. Witness protocols like GVRP/GARP as well as time of day configuration capabilities found in RFC 2591. Here then are requirements for a modern configuration protocol: 1) Any modern configuration protocol or process MUST be mindful of connectivity loss between manager and manged device and take appropriate measures to leave the network device or devices in a consistent/recognizable state. 2) Support for testing configurations incrementally MUST be included. 3) Diagnostic routines SHOULD be provided to verify proper operation of complex protocols. Debugging is an integral part of the configuration process. 4) Impact on convergence SHOULD be specified. For example, any configuration change that causes loss of convergence should be noted in a description clause. 2. Terminology Transaction A finite group of changes that taken as a whole can be applied or rolled back in one operation. Device-Local Configuration Configuration data that is specific to a particular network device. This is the finest level of granularity for MacFaden/Saperia Expires September 10th 2000 [Page 5] Internet Draft SNMP CONFIGURATION May 3 2000 configuring network devices. Per draft-ops-mumble- conf_management Network-Wide Configuration Configuration data that is not specific to any particular network device and from which multiple device-local configurations can be derived. Network-wide configuration provides a level of abstraction above device-local configurations. Per draft-ops-mumble-conf_management Configuration Data Translator A function that transforms Configuration Management Data (high-level policies) or Network-wide configuration data (middle-level policies) into device local configurations (low-level policies) based on the generic capabilities of network devices. This function can be performed either by devices themselves or by some intermediate entity. Per draft-ops-mumble-conf_management Denial of Service Attack (DOS) Any situation where access to resources by authorized consumers is diminished by overt or inadvertant abuse of network layer mechanisms. 3. Agent Software Development 3.1. MIB Module Implementation and Design This section describes how to design and implement a read- write MIB properly. It reviews some key SNMP requirements such as rollback of sets in a given PDU. Most Agent software development focuses n Device-Local configuration aspects. There are however network wide aspects to agent development such as setting the Autonomous System in router. To begin with, let's consider a set pdu with one varbind using MacFaden/Saperia Expires September 10th 2000 [Page 6] Internet Draft SNMP CONFIGURATION May 3 2000 the managed object docsIfDownChannelFrequency from DOCS-IF- MIB, RFC 2670, and enumerate potential outcomes to see which are conformant with SNMP Framework: Here is the definition of this object: docsIfDownChannelFrequency OBJECT-TYPE SYNTAX Integer32 (0..1000000000) UNITS "hertz" MAX-ACCESS read-write STATUS current DESCRIPTION "The center of the downstream frequency associated with this channel. This object will return the current tuner frequency. If a CMTS provides IF output, this object will return 0, unless this CMTS is in control of the final downstream RF frequency. See the associated compliance object for a description of valid frequencies that may be written to this object." REFERENCE "DOCSIS Radio Frequency Interface Specification, Section 4.3.3." ::= { docsIfDownstreamChannelEntry 2 } Scenario 0: most common usage model value is 200000 at time 0. set to value 4400000 at time 1, read at time 2 returns 4400000 Scenario 1: read-write object is overloaded to return state + set state) value is 20000 at time 0, set to value 4400000 at time 1. read at time 2 returns 20000, and a subsequent read at time 3 returns 4400000 Scenario 2: value is 200000 at time 0, set to value 4400000 at time 1 and the snmp agent returns and error received by manager application Scenario 3: value is 200000 at time 0, set to value 4400000 at time 1 and the snmp agent returns and error which is not received by manager/network failure due to either set change, device crashes, or manager crashes. Another typical scenario is the granularity of counter updates, some devices can't update counters as fast as it may be polled. One SHOULD indicate in the agent capability MIB for the device what the minimum polling interval is. MacFaden/Saperia Expires September 10th 2000 [Page 7] Internet Draft SNMP CONFIGURATION May 3 2000 3.1.1. Reporting Errors for SET operations MIB Design for configuration SHOULD use objects to track application level state. Management applications that are unable to decode why "badValue" errors are received should be able to obtain error strings or enumerated values to help log problems from specific MIB objects. Failure to provide detailed diagnostic information leads to management applications that end up reporting insuficient error information. 3.1.2. Duplication of objects considered harmful One SHOULD NOT duplicate configuration objects across mibs. While it may appear as a convienience, such as providing different indexing schemes, the side effects may not be easily discernable. For example, RFC 1493 BRIDGE-MIB duplicates functionality found in RFC 1213 interfaces group and its successor RFC2233/IF-MIB as follows: The BRIDGE-MIB defines the managed object: dot1dStpPortEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The enabled/disabled status of the port." REFERENCE "IEEE 802.1D-1990: Section 4.5.5.2" ::= { dot1dStpPortEntry 4 } which is indexed by dot1dBasePortNumber, while the IF-MIB defines this managed object by ifIndex. ifAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets MacFaden/Saperia Expires September 10th 2000 [Page 8] Internet Draft SNMP CONFIGURATION May 3 2000 down(2), testing(3) -- in some test mode } MAX-ACCESS read-write STATUS current DESCRIPTION "The desired state of the interface. The testing(3) state indicates that no operational packets can be passed. When a managed system initializes, all interfaces start with ifAdminStatus in the down(2) state. As a result of either explicit management action or per configuration information retained by the managed system, ifAdminStatus is then changed to either the up(1) or testing(3) states (or remains in the down(2) state)." ::= { ifEntry 7 } If a port is set to testing in the IF-MIB, what should be reported in the BRIDGE-MIB? These kinds of issues should be avoided if at all possible and especially when mibs are as interrelated as the above. Fate sharing of the indexing should also be specified if possible using SMI constructs such as AUGMENTS. If the relationship between tables can not be defined using SMIv2 macros, then the DESCRIPTION clause should define what should happen. 3.1.3. Use Textual Conventions for enumerations Standard's track MIBS SHOULD define textual conventions such that later standard MIBs would be able to use them. Textual convetions that have even the slighest chance of being reused in other MIBS SHOULD also be defined in a separate MIB to facilitate sharing of such objects. Often in practice, dragging in an entire MIB definition in order to reuse one Textual convention may lead to computational excessiveness. For example, take the ifAdminStatus object: MacFaden/Saperia Expires September 10th 2000 [Page 9] Internet Draft SNMP CONFIGURATION May 3 2000 ifAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3) -- in some test mode } Had this used a Textual convention, other mibs could import the same semantic. Instead there there are now many more "admin" style objects in other mibs that use the same enumerations such as RFC 2668/MAU-MIB: ifMauAutoNegAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } Often a situation may arise where a Textual convention defines an enumeration of values. Should an implementation chose not to implement all the enumarations, then it SHOULD document this in an agent capabilities macro for the particular revision. In some cases, the use of capabilities bits can alievate this as defined in RFC 2674, dot1dDeviceCapabilities can define some preset level of capability. When implementing a mib object with the syntax of RowStatus, failure to implement the entire state machine MUST not be done. There is no VARIANT clause that allows one to implement only createAndGo and destroy and any such implementation is NOT compliant with the SMI. 3.1.4. Rules for implementing RowStatus Probably one of the most important areas of configuration with SNMP is the ability to add and delete conceptual rows from tables using the RowStatus textual convention. Proper implementation requires the following: First consider the default state of each object in the table MacFaden/Saperia Expires September 10th 2000 [Page 10] Internet Draft SNMP CONFIGURATION May 3 2000 when a row is created via one simple createAndWait(5). operation. If defval's are not appropriate, then return noSuchName for any object in that table not yet set by managment application. One SHOULD NOT return some implementation byproduct. Second, consider the state of a row following a simple PDU containing a createAndWait(5). Either notInService(2) or notReady(3) are the two states the row can exist in. In the latter case, one SHOULD define in the DESCRIPTION clause the mandatory objects required to change the row state from notReady(3) to notInService(2). A conforming table SHOULD set rowStatus to notReady if any mandatory object in the row has not yet been set be set by a manager or if there is potentially some other implementation constrictions such as being out of capacity to advance to active(1) state. Not doing this may lead a manager to assume falsely that a transition to active(1) state will succeed without futher action. Not overloading the semantics of notReady vs notInService can be done if mib defines error state objects an application can query to determine the state of configuration. Otherwise control rows in SNMP table may all activated but the intended effect is not achieved and there is no object an agent can provide to help diagnose the problem simply. This is typical with existing RMON2 implementatons where a typical example is configuring a host top N control row. Both the agent and the manager application must be needlessly *some would argue extremely* flexible in handling configuration of hostTopNControlTable. Control rows can be activated in the hostTopNControlTable regardless of whether the hostTopNHostIndex actually exists in the hostIndex of the hostTable. As such, the ability for an agent to communicate any diagnostic information is limited. Lastly, description clauses for any object in a table MacFaden/Saperia Expires September 10th 2000 [Page 11] Internet Draft SNMP CONFIGURATION May 3 2000 containing a RowStatus object SHOULD define the semantics of what changes are valid when a row is in active(1) state. As an example, RFC 1757 RMON-MIB used the following description: This object may not be modified if the associated alarmStatus object is equal to valid(1) is extremely useful and all new tables SHOULD follow this best current practice. 3.1.5. Ownership issues In many tables, ownership of a control row has been considered in context of multiple managers as well as for diagnostic information. As found in RMON-MIB -- OwnerString ::= DisplayString -- This data type is used to model an administratively -- assigned name of the owner of a resource. This -- information is taken from the NVT ASCII character -- set. It is suggested that this name contain one or -- more of the following: IP address, management station -- name, network manager's name, location, or phone -- number. -- In some cases the agent itself will be the owner of -- an entry. In these cases, this string shall be set -- to a string starting with 'monitor'. One MAY decide to make the agent responsible for tracking what it knows of a manager setting up a row. Often it is useful to the operator to know who is acessing the device and when as well as The IP Address is known in SNMPv1 and additional user info is known in SNMPv3. OwnerStrings are discussed further in the Multiple Manager section. 3.1.6. rowStatus and activation of configuration Often configuration changes are activated in a device as soon as a rowStatus is set to active(1). This is not always the best way and often the implementation complexity may be great if there are a set of interrelated tables. An alternate design MacFaden/Saperia Expires September 10th 2000 [Page 12] Internet Draft SNMP CONFIGURATION May 3 2000 to specify objects to activate all changes once all configuration changes are made. In this way master on/off changes can be effected in a two stage method. A two stage configuration method often works well when changes affect convergence. Many rows can be setup and when all rows are activated, some scalar object is touched to load the new changes. 3.1.7. Include a master on/off switch As mentioned above, a master on/off switch for a given subsystem SHOULD be provided. Often, these switches are useful for diagnostics such as to help locate unstable subsystems as well as for a common configuration sequence where a feature is taken offline, reconfigured then put back online. ospfAdminStat OBJECT-TYPE SYNTAX Status MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative status of OSPF in the router. The value 'enabled' denotes that the OSPF Process is active on at least one inter- face; 'disabled' disables it on all inter- faces." ::= { ospfGeneralGroup 2 } When these master switches are not provided such as in the BRIDGE-MIB which does not provide a to enable/disable Spanning tree on a device nor a way to turn off spanning tree on a per port basis requires managers to learn indirectly the state of the subsystem. 3.1.8. Summary Status objects help configuration Creating summary status objects "dummy lights" to provide a quick means to determine overall status of a subystem. Checksums could also be computed over a configuration so that an application can reasonably identify an entier configuration instead of having to poll many TableLastChange objects or have MacFaden/Saperia Expires September 10th 2000 [Page 13] Internet Draft SNMP CONFIGURATION May 3 2000 to use TimeFilter style indexing to achive highly efficient polling. ifOperStatus as it existed in RFC 1213, provids a template: up/down/testing and "fault" would provide simple means to know if changes have keep the overall subsystem up. 3.1.9. Indexing Issues This section describes uses for Associative indexing, multiple tables to support different indexing schemes, and other such issues as it affects configuration. 3.1.10. Notifications Proper use of notifications based on application development needs. It is hard for agent developer to know at first when agent should use notifications is being built and even harder if designer is not familiar with the feature being instrumented. Even so, there is one key rule of thumb: 1) The more frequent the event, the greater the need for internal aggregation or throttling in the agent. There can be cases where it is not useful to send notifications for a given notification such as frDLCIStatusChange defined in RFC 2115. In this case when interfaces are taken down administratively, no frDLCIStatusChange will be sent. Rate Limiting trap emission will be vital in the future world where hundreds of ports that do layer 1/2/3/4/n bridging and routing and load balancing exist in a given device. RFC 2115 includes the object frTrapMaxRate. 3.1.11. Extending Standard notifications permissible Vendor extensions to existing standard notifications are not explicitly disallowed or allowed in SMIv2. For example, linkUp MacFaden/Saperia Expires September 10th 2000 [Page 14] Internet Draft SNMP CONFIGURATION May 3 2000 and linkDown traps are defined as follows in IF-MIB, rfc 2233. linkDown NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } STATUS current DESCRIPTION "A linkDown trap signifies that the SNMPv2 entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links is about to enter the down state from some other state (but not from the notPresent state). This other state is indicated by the included value of ifOperStatus." ::= { snmpTraps 3 } A implementor MAY add additional varbind objects to standard notifications. However, an implementation SHOULD make any extensions be not enabled by default and when enabled. An implemetation SHOULD append to the varbind list any extensions. 3.1.12. Changed Configuration Alerts Any change to a managed device or application's configuration SHOULD be reported to an accounting authority. Notifications provide such an ability and MAY be also logged on the device. Any notification should include details on what management interface, user, sysuptime, and what was changed. 3.1.13. RFC Module Compliance There are a number of RFC MIB Modules today and new IETF standard MIB modules written MUST contain compliance macros per RFC 2579. A vendor MAY provide additions to the existing MIB Objects, they MAY also if necessary duplicate standard objects in their vendor name space. They MUST not use this duplication as an alternative to standard objects found in standards track RFCs. A vendor SHOULD write compliance macros for enterprise specific MIB modules as this helps document changes over time. MacFaden/Saperia Expires September 10th 2000 [Page 15] Internet Draft SNMP CONFIGURATION May 3 2000 A vendor SHOULD also implement agent capability MIB modules to define any variations in implementation. If an object in a mib is made optionally read write and the implementation does not implement the object to its fullest max access clause, the variations clause SHOULD still be made explicit. For example, RFC 2674 Q-BRIDGE-MIB defines OBJECT dot1qPortAcceptableFrameTypes MIN-ACCESS read-only DESCRIPTION "Write access is not required as this is an optional capability in IEEE 802.1Q." An agent that implements this object as read-only SHOULD include the following: SUPPORTS Q-BRIDGE-MIB INCLUDES { -- all Mandatory groups qBridgeBaseGroup, qBridgeVlanGroup, qBridgeVlanStaticGroup, qBridgePortGroup, qBridgeFdbUnicastGroup, qBridgeFdbMulticastGroup, qBridgeServiceRequirementsGroup } -- qBridgePortGroup: VARIATION dot1qPortAcceptableFrameTypes ACCESS read-only DEFVAL { disabled } DESCRIPTION "Firmware Version 3.1 does not support GVRP/GARP." 3.2. Currency with RFC MIB Module Standards Vendors SHOULD make every attempt to keep their implementations current with the standards versions of MIB Modules. In particular, agents and managemement software SHOULD follow the current STATUS of MIB objects. MacFaden/Saperia Expires September 10th 2000 [Page 16] Internet Draft SNMP CONFIGURATION May 3 2000 3.3. Implementing MIBs - Coverage The SNMP based instrumentation SHOULD provide complete coverage of the managed element to facility integrated management. Using module compliance macros to guide implementation, all mandatory conformance groups MUST be implemented. 3.4. Lifecycle considerations This section presents one proposed lifecycle of a MIB based on best current practices. 3.4.1. MIB Module TBD 3.4.2. Agent Agents, especially SNMPv1 agents require community strings to be defined. A managed device SHOULD support read only as as well as read-write community strings. Community strings should specify the min length of at least 8 characters and be less than 255 characters. Agents should not define default community strings except where to bootstrap devices that do not have secondary management interfaces. Practices include setting the read-write string to public or to one of the mac addresses on ethernet bridges often lead to security problems. 3.4.3. Default state of RFC 1215 Authentication traps In the "Notifications" section earlier, the issue of throttling traps was raised. For SNMPv1 agents, Any MacFaden/Saperia Expires September 10th 2000 [Page 17] Internet Draft SNMP CONFIGURATION May 3 2000 unsolicited packet to a device that causes another packet to be created and sent in response in a one for one sequence can be considered a denial of service attack. authTrap is one such object that should be carefully limited so as to create a denial of service attack or at least a diversion attack. 3.5. Vendor Extensions Describe here how to relate vendor MIBs to ietf MIBs. Fate sharing of MIB tables such as a MIB to create some layer that then shows up in ifTable... 3.6. Supporting More than one Management Interface Details how to relate data in one management interface to another and to make the data consistent. Only one data path to base information SHOULD exist in a device. There may exist multiple names for a given data object though. ifIndex defines some logical entity used by SNMP manager applications, yet ifName provides mapping to CLI. 3.6.1. Configuration State This will describe how to track current configuration state. At what level are changes reported as errors, per table or per object. Is there a need for specific objects to support changes other than RowStatus? To being with, it is important to track changes to a device and to sync the changes with some specific configuration respository. Tracking changes to configuration has been done well for command line interface via three reporting mechanisms: syslog, tacacs+, and radius. Tracking changes via SNMP has been done via enterprise traps and notifications. The notification may contain either direct or indirect references to what has changed or no varbinds. However, it should indicate when and who made a change. MacFaden/Saperia Expires September 10th 2000 [Page 18] Internet Draft SNMP CONFIGURATION May 3 2000 3.6.2. Rollback This section describes how SNMP can be used to maintain a consistent state in the event of errors. Some discussion of how this can work with large changes across tables. 3.6.3. Incremental Changes (sequencing issues) Varbinds can come in any order in a pdu. Per the spec, all sets must appear to occur at the same time. The flexibility of a set pdu is very great, yet this feature is infrequently used by management applications. Multiple tables can be configured in one set with varbinds intermixed. This puts a large implementation effort on the agent to sort out the proper order of varbinds in order to make a given set pdu succeed. While it may be the cast that being liberal in what you accept and conservative in what you send is the general case, it definitely case computantional consequences when it comes to handling set requests. MIB designers SHOULD be allowed to specify the order by which objects are created. 3.6.4. Supporting Large Changes Describe here how to implement support where changes are made with massive configuration files such as thousands of lines of access control lists. 3.7. When should changes made become effective When should changes be realized in the device? Simple devices like bridges performed simple set operations without consideration for storage type, etc. In addition, the need for near real time changes must be understood. MacFaden/Saperia Expires September 10th 2000 [Page 19] Internet Draft SNMP CONFIGURATION May 3 2000 While most MIB objects can be polled or set in as little as one second intervals, most agents may require more time for more complex operations. Agent implementations SHOULD provide some indication of time interval needed for set completion or retrieval of managed objects. 3.8. Devices that use SNMP as Primary Interface Describe this model of operation and interactions that should be followed to stop race conditions for changes from two interfaces. 3.9. Devices that use SNMP as Secondary Interface Describe this model of operation and interactions that should be followed to stop race conditions for changes from two interfaces. 4. Management Software Development This section focuses on general issues related to the development of SNMP based applications that configure one or more network elements. Special considerations for what has come to be known as policy-based management with SNMP are discussed in the following section. Effective software for the configuration of one or many network elements requires some up front design work before starting implementation. This is true regardless of the technology used to represent and transfer the configuration information. For SNMP-based configuration applications, here are some of the design parameters that should be investigated before starting implementation. 1. SNMP protocol operations 2. Scale of the Management Software 3. Security considerations 4. Network topologies 5. Synchronization of management software and device views 6. Data storage and coexistence with other management applications 7. Device capabilities and differences 8. Persistence of configuration information 9. Multiple management systems 10. Support for diagnostic activities MacFaden/Saperia Expires September 10th 2000 [Page 20] Internet Draft SNMP CONFIGURATION May 3 2000 4.1. Protocol Operations There are three basic areas to evaluate relevant to SNMP protocol operations and configuration: _ Set and configuration activation operations _ Notifications from the device _ Data retrieval and collection The design of the system should not assume that the objects in a device that represent configuration data will remain unchanged over time. As standard MIB modules evolve and vendors add private extensions, the specific configuration parameters for a given operation are likely to change over time. Even in the case of a configuration application that is designed for a single vendor, the designer SHOULD allow for variability in the MIB objects that will be used to configure the device for a particular purpose. The best method to accomplish this is by separating as much as possible the operational semantics of a configuration operation from the actual data. One way that some applications achieve this is by having the specific configuration objects that are associated with a particular device be table driven rather than hard coded. Management software SHOULD verify the support in the devices it is intended to manage and report any 'unexpected' deviations to the operator. This approach is particularly valuable when developing applications that are intended to support equipment or software from multiple vendors. 4.1.1. SET Operations Management software SHOULD adapt its SET operations to the type of device and specific MIB objects included in the SET PDU. Specifically, it SHOULD attempt to move the configuration information as efficiently to the managed device as possible. There are many ways to achieve efficiency and some are specific to devices. One general case example that all management software SHOULD employ is to reduce to the smallest reasonable number, the number of SET PDU exchanges between the managed device and the management software. One approach to this is to verify the largest number of variable bindings that can fit into a SET PDU for a managed device. In some cases, the number of variable bindings to be sent in a particular PDU will be influenced by the device, the specific MIB objects and MacFaden/Saperia Expires September 10th 2000 [Page 21] Internet Draft SNMP CONFIGURATION May 3 2000 other factors. 4.1.2. Configuration Transactions There are several types of configuration transactions that can be supported by SNMP-based configuration applications. They include transactions on a single table, transactions across several tables in a managed device and transactions across many devices. The managers ability to support these different transactions is partly dependent on the design of the MIB objects within the scope of the configuration operation. Management software that conforms with the BCP MUST be aware of the information in the MIB Modules that it is to configure so that it can effectively utilize row status objects for the control of transactions on one or more tables. Such software MUST also be aware of control tables that the device supports that are used to control the status of one or more other tables. To the greatest extent possible, the management application SHOULD provide the facility to support transactions across multiple devices. This means that if a configuration operation is desired across multiple devices, the manager can coordinate these configuration operations such that they become active as close to simultaneously as possible. 4.1.3. Notifications As described in the section on Agent Software Development, agents SHOULD provide the capability for notifications to be sent to their configured management systems whenever a configuration operation is attempted or completed. See that section for details on the control of such notifications. The management application MUST be prepared to accept these notifications so that it knows the current configured state of the devices it has been deployed to control. MacFaden/Saperia Expires September 10th 2000 [Page 22] Internet Draft SNMP CONFIGURATION May 3 2000 Some configuration management applications may consume data from the managed devices that reflects configuration, operational and utilization state information. The GetBulkRequest-PDU MUST be used whenever supported by the managed device. For the purposes of backward compatibility, the management station SHOULD also support the GetNextRequest-PDU. Management systems SHOULD also provide configuration options with defaults for users that tend to retrieve the smallest amount of data to achieve the particular goal of the application. 4.2. Scale of the Management Software Efficient data retrieval described above is only part of the dimension of scale that application developers should consider when developing configuration applications. Deploying configuration software requires proper thought on how configuration to a network will be done. There are basic connectivity issues as well a security issues. 4.3. Network Topology Topology plays a critical row when what is being configured are devices that implement network topology such as an internet backbone router. 4.4. Topology/connectivity factors 4.4.1. In band 4.4.2. Out of band 4.4.3. Rules of thumb MacFaden/Saperia Expires September 10th 2000 [Page 23] Internet Draft SNMP CONFIGURATION May 3 2000 4.5. Device memory/Capability factors This section describes how to design configuration models when device memory and capability are constrained and when these factors are not constrained. 4.6. Persistence expectations Explicit persistence of set requests has always been assumed in SNMP sets. New textual conventions such as StorageType allow for alternative configuration models. A mib designer SHOULD make explicit indications as to how an implementor can make visible the level of persistance any read write object can and should have. For example, RFC 2591 defines the object schedStorageType of syntax StorageType. New mibs SHOULD either define in DESCRIPTION macros how a table should exist or use this type to allow for varied persistence. For instance: RFC 2674 also defines explicitly the persistence as follows: dot1qVlanStaticTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot1qVlanStaticEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing static configuration information for each VLAN configured into the device by (local or network) management. All entries are permanent and will be restored after the device is reset." ::= { dot1qVlan 3 } Best current practice in network elements is a dual persistence model where: 1) a volatile memory configuration can be retrieved/updated and 2) persistent boot configuration. Single persistence systems suffer the ability to rollback changes that cause lost connectivity and hence are not often found in backbone wide area networks operated over remote connections. MacFaden/Saperia Expires September 10th 2000 [Page 24] Internet Draft SNMP CONFIGURATION May 3 2000 4.7. Rate and Volume of Changes to Device Describe different models from store and forward to real time changes and how this relates to the volume of changes needed to effect a feature change. 4.8. Handling Multiple Managers Devices are often modified by multiple management entities. These managment entities may be in the same organization or may be in different organizations interior or exterior to a given autonomous system. There are many aspects to view this model from. First is coordinating the changes between two or more mangagement applications issuing SET protocol operations. Race conditions should be easily detectable when two entities provision exactly the same object or within a transaction a group of objects. Second, A device SHOULD be able to report configuration as set by different entities as well as distinguish configuration defined locally such as a default or locally specified configuration made through an alternate managment interfaces like command line interface. The SMIv2 defines the Textual convention TestAndIncr often called a SpinLock to solve race conditions. As with most of the SNMP framework, much flexibility is left to the implementer to "do the right thing." Unless a MIB explicitly defines the use mandatory use of synchronization primitives, an agent MUST not enforce their use. An object of syntax TestAndIncr SHOULD be well defined as to what it is being covered. However the use of a general all encompasing lock can be used such as RFC 1907 snmpSetSerialNo object. An application SHOULD use this object if there is no specific TestAndIncr object. MacFaden/Saperia Expires September 10th 2000 [Page 25] Internet Draft SNMP CONFIGURATION May 3 2000 and RMON2-MIB, RFC 2021, Section 3.1 further that refined them. Practice has shown that the use of the string "monitor" to identify configuration set by an agent/local management has been useful. The flexibility of the OwnerString convention has been left to general application interpretation and as such has seen either good or bad implementation. As a whole, owner strings have shown the SHOULD be used to identify the owner of the configuration. In addtion, if needed, the use of objects to track when control rows are installed/activated are also recommneded. An example is the ipCidrRouteAge which tracks routing prefixes installed into a IP Forwarding table, RFC 2096. TimeStamps can who made a change to the system are useful example in addition to tracking which manager made the change. For example, in the DOCS-IF-MIB: docsIfCmtsServiceCreateTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this entry was created." ::= { docsIfCmtsServiceEntry 5 } The syntax of such objects SHOULD be consistent. One final thought of best current practice is to use authorization/accounting protcools such as RADIUS or TACACS+ to track changes to devices. Often these protocls can help identify conflicting changes that cause as well as what the changes were made from. From within the SNMPv3 framework much of what has traditionally been done with these protocols can now also be done through the use of informs backed by some level of persistence. 4.9. Diagnostics and Configuation This section describes in detail the kinds of diagnostics needed to help support proper provisioning models. MacFaden/Saperia Expires September 10th 2000 [Page 26] Internet Draft SNMP CONFIGURATION May 3 2000 5. Policy Based Management Provides an overview of configuration "in the large" and how to scale configuration to include many devices in a safe and sane manner. 5.1. Policy Modules TBD.. 5.2. Transaction Latency 5.3. Requirements TBD... 5.4. Capability Module TBD... 5.5. Integration with 'device specific' module TBD... 6. Deployment 6.1. Agent Deployment and Configuration Issues 6.2. Management System Deployment Considerations MacFaden/Saperia Expires September 10th 2000 [Page 27] Internet Draft SNMP CONFIGURATION May 3 2000 7. Security Considerations TBD... More specific Text about security goes here. Could add bits about snooping wire and sending. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. MacFaden/Saperia Expires September 10th 2000 [Page 28] Internet Draft SNMP CONFIGURATION May 3 2000 8. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. MacFaden/Saperia Expires September 10th 2000 [Page 29] Internet Draft SNMP CONFIGURATION May 3 2000 [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] McCloghrie, K. and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [17] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, Cisco Systems, FTP Software, November 1997. [18] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [19] Brown, C., and F. Baker, "Management Information Base for Frame Relay DTEs Using SMIv2", RFC 2115, September 1997. 9. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result MacFaden/Saperia Expires September 10th 2000 [Page 30] Internet Draft SNMP CONFIGURATION May 3 2000 of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10. Editors' Addresses Michael R. MacFaden Riverstone Networks, Inc 5200 Great America Parkway Santa Clara, CA 95054 phone - +1 408 878 6500 email - mrm@riverstonenet.com Jon Saperia JDS Consulting 174 Chapman Street Watertown, MA 02472 email - saperia@mediaone.net 11. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the MacFaden/Saperia Expires September 10th 2000 [Page 31] Internet Draft SNMP CONFIGURATION May 3 2000 procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MacFaden/Saperia Expires September 10th 2000 [Page 32] Internet Draft SNMP CONFIGURATION May 3 2000 Table of Contents 1 Introduction .......................................... 1 1.1 Document Organization ............................... 2 1.2 Background .......................................... 3 1.3 Requirements ........................................ 4 1.3.1 Fundamental Tenets of configuration ............... 4 2 Terminology ........................................... 5 3 Agent Software Development ............................ 6 3.1 MIB Module Implementation and Design ................ 6 3.1.1 Reporting Errors for SET operations ............... 8 3.1.2 Duplication of objects considered harmful ......... 8 3.1.3 Use Textual Conventions for enumerations .......... 9 3.1.4 Rules for implementing RowStatus .................. 10 3.1.5 Ownership issues .................................. 12 3.1.6 rowStatus and activation of configuration ......... 12 3.1.7 Include a master on/off switch .................... 13 3.1.8 Summary Status objects help configuration ......... 13 3.1.9 Indexing Issues ................................... 14 3.1.10 Notifications .................................... 14 3.1.11 Extending Standard notifications permissible ..... 14 3.1.12 Changed Configuration Alerts ..................... 15 3.1.13 RFC Module Compliance ............................ 15 3.2 Currency with RFC MIB Module Standards .............. 16 3.3 Implementing MIBs - Coverage ........................ 17 3.4 Lifecycle considerations ............................ 17 3.4.1 MIB Module ........................................ 17 3.4.2 Agent ............................................. 17 3.4.3 Default state of RFC 1215 Authentication traps .................................................... 17 3.5 Vendor Extensions ................................... 18 3.6 Supporting More than one Management Interface ....... 18 3.6.1 Configuration State ............................... 18 3.6.2 Rollback .......................................... 19 3.6.3 Incremental Changes (sequencing issues) ........... 19 3.6.4 Supporting Large Changes .......................... 19 3.7 When should changes made become effective ........... 19 3.8 Devices that use SNMP as Primary Interface .......... 20 3.9 Devices that use SNMP as Secondary Interface ........ 20 4 Management Software Development ....................... 20 4.1 Protocol Operations ................................. 21 4.1.1 SET Operations .................................... 21 4.1.2 Configuration Transactions ........................ 22 4.1.3 Notifications ..................................... 22 MacFaden/Saperia Expires September 10th 2000 [Page 33] Internet Draft SNMP CONFIGURATION May 3 2000 4.2 Scale of the Management Software .................... 23 4.3 Network Topology .................................... 23 4.4 Topology/connectivity factors ....................... 23 4.4.1 In band ........................................... 23 4.4.2 Out of band ....................................... 23 4.4.3 Rules of thumb .................................... 23 4.5 Device memory/Capability factors .................... 24 4.6 Persistence expectations ............................ 24 4.7 Rate and Volume of Changes to Device ................ 25 4.8 Handling Multiple Managers .......................... 25 4.9 Diagnostics and Configuation ........................ 26 5 Policy Based Management ............................... 27 5.1 Policy Modules ...................................... 27 5.2 Transaction Latency ................................. 27 5.3 Requirements ........................................ 27 5.4 Capability Module ................................... 27 5.5 Integration with 'device specific' module ........... 27 6 Deployment ............................................ 27 6.1 Agent Deployment and Configuration Issues ........... 27 6.2 Management System Deployment Considerations ......... 27 7 Security Considerations ............................... 28 8 References ............................................ 29 9 Intellectual Property ................................. 30 10 Editors' Addresses ................................... 31 11 Full Copyright Statement ............................. 31 MacFaden/Saperia Expires September 10th 2000 [Page 34]