Internet Draft SNMP CONFIGURATION March 9 2000 M. MacFaden Riverstone Networks, Inc J. Saperia JDS Consulting, Inc CONFIGURING NETWORKS AND DEVICES WITH SNMP draft-ietf-snmpconf-bcp-00.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 Configuration (provisioning) of network elements is hard in all but the most trivial of networks. This document describes first hand experience with provisioning of data networks over MacFaden&Saperia Expires September 10th 2000 [Page 1] Internet Draft SNMP CONFIGURATION March 9 2000 the past ten years. It then enumerates key tenets in configuration in in order to: 1) set expectations for users 2) guide implementors torward better 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 SNMP framework. Secton 5 describes relationship of Policy Management to SNMP framework and Section 6 reviews security issues related to the models described here. 1.1. 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 MacFaden&Saperia Expires September 10th 2000 [Page 2] Internet Draft SNMP CONFIGURATION March 9 2000 5. Watch for new unkown defaults 6. Watch for unknown side effects of changes 7. update configurations in revision control system Next, An analysis of the strengths and weaknesses of each method is offered here. 1.2. 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.2.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. MacFaden&Saperia Expires September 10th 2000 [Page 3] Internet Draft SNMP CONFIGURATION March 9 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 absolute given when configurations are made. While simulations can be made, keeping track of all state data is growing harder as features become more dynamic due to 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 tenent #1 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. Data communications technology continues to exhibit growing complexity and as networks grow in size and data communications functions collapse into fewer and fewer discrete systems. 4) others go here... 2. Terminology Here we enumerate terms we are defining and what exiting terms we redefine... 3. Agent Software Development This section describes how to implement a read-write MIB properly. It reviews some key SNMP requirements such as MacFaden&Saperia Expires September 10th 2000 [Page 4] Internet Draft SNMP CONFIGURATION March 9 2000 rollback of sets in a given PDU. 3.1. MIB Module Implementation and Design Discuss read-write operations here, RowStatus, timing out of non-active rows. 3.1.1. 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.2. 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 developer 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 or potentially redesign of the notification with the frequency in mind as found in RFC 2115 for DLCI traps per interface. There can be cases where it is not useful to send notifications such as defined in RFC 2115 when interfaces are taken down administratively, no frDLCIStatusChange must 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.3. 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. MacFaden&Saperia Expires September 10th 2000 [Page 5] Internet Draft SNMP CONFIGURATION March 9 2000 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. A vendor SHOULD also implement agent capability MIB modules to define any variations in implementation. 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. 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. 3.4.1. MIB Module TBD MacFaden&Saperia Expires September 10th 2000 [Page 6] Internet Draft SNMP CONFIGURATION March 9 2000 3.4.2. Agent TBD 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? 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 and the rule is that they all appear to be set at the same time. Discuss this rule and how to do partition pdus or do this logically with additional objects... MacFaden&Saperia Expires September 10th 2000 [Page 7] Internet Draft SNMP CONFIGURATION March 9 2000 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. 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 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. MacFaden&Saperia Expires September 10th 2000 [Page 8] Internet Draft SNMP CONFIGURATION March 9 2000 4.1. Protocol Operations TBD 4.2. Data Retrieval TBD This section details some important factors. 4.3. Topology/connectivity factors 4.3.1. In band 4.3.2. Out of band 4.3.3. Rules of thumb 4.4. 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.5. 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. Explain how these work here and how to use them. 4.6. 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. MacFaden&Saperia Expires September 10th 2000 [Page 9] Internet Draft SNMP CONFIGURATION March 9 2000 4.7. Handling Multiple Managers Devices are often modified by multiple management entities. Explain how to use the SNMP framework to provide boundaries and to audit changes made by any given manager. 4.8. Diagnostics and Configuation This section describes in detail the kinds of diagnostics needed to help support proper provisioning models. 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. Requirements TBD... 5.3. Capability Module TBD... 5.4. Integration with 'device specific' module TBD... MacFaden&Saperia Expires September 10th 2000 [Page 10] Internet Draft SNMP CONFIGURATION March 9 2000 6. 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 11] Internet Draft SNMP CONFIGURATION March 9 2000 7. 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 12] Internet Draft SNMP CONFIGURATION March 9 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. 8. 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 13] Internet Draft SNMP CONFIGURATION March 9 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. 9. 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 174 Chapman Street Watertown, MA 02472 email - spaeria@jdscons.com 10. 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 procedures for copyrights defined in the Internet Standards MacFaden&Saperia Expires September 10th 2000 [Page 14] Internet Draft SNMP CONFIGURATION March 9 2000 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 15] Internet Draft SNMP CONFIGURATION March 9 2000 Table of Contents 1 Introduction .......................................... 1 1.1 Background .......................................... 2 1.2 Requirements ........................................ 3 1.2.1 Fundamental Tenets of configuration ............... 3 2 Terminology ........................................... 4 3 Agent Software Development ............................ 4 3.1 MIB Module Implementation and Design ................ 5 3.1.1 Indexing Issues ................................... 5 3.1.2 Notifications ..................................... 5 3.1.3 RFC Module Compliance ............................. 5 3.2 Currency with RFC MIB Module Standards .............. 6 3.3 Implementing MIBs - Coverage ........................ 6 3.4 Lifecycle considerations ............................ 6 3.4.1 MIB Module ........................................ 6 3.4.2 Agent ............................................. 7 3.5 Vendor Extensions ................................... 7 3.6 Supporting More than one Management Interface ....... 7 3.6.1 Configuration State ............................... 7 3.6.2 Rollback .......................................... 7 3.6.3 Incremental Changes (sequencing issues) ........... 7 3.6.4 Supporting Large Changes .......................... 8 3.7 When should changes made become effective ........... 8 3.8 Devices that use SNMP as Primary Interface .......... 8 3.9 Devices that use SNMP as Secondary Interface ........ 8 4 Management Software Development ....................... 8 4.1 Protocol Operations ................................. 9 4.2 Data Retrieval ...................................... 9 4.3 Topology/connectivity factors ....................... 9 4.3.1 In band ........................................... 9 4.3.2 Out of band ....................................... 9 4.3.3 Rules of thumb .................................... 9 4.4 Device memory/Capability factors .................... 9 4.5 Persistence expectations ............................ 9 4.6 Rate and Volume of Changes to Device ................ 9 4.7 Handling Multiple Managers .......................... 10 4.8 Diagnostics and Configuation ........................ 10 5 Policy Based Management ............................... 10 5.1 Policy Modules ...................................... 10 5.2 Requirements ........................................ 10 5.3 Capability Module ................................... 10 5.4 Integration with 'device specific' module ........... 10 6 Security Considerations ............................... 11 MacFaden&Saperia Expires September 10th 2000 [Page 16] Internet Draft SNMP CONFIGURATION March 9 2000 7 References ............................................ 12 8 Intellectual Property ................................. 13 9 Editors' Addresses .................................... 14 10 Full Copyright Statement ............................. 14 MacFaden&Saperia Expires September 10th 2000 [Page 17]