INTERNET-DRAFT SNMP CONFIGURATION July 2000 M. MacFaden Riverstone Networks, Inc J. Saperia JDS Consulting, Inc CONFIGURING NETWORKS AND DEVICES WITH SNMP draft-ietf-snmpconf-bcp-02.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. Abstract This document is intended for vendors building equipment using the Internet Standard Management Framework as well as for users of such equipment. General guidelines for configuration are presented from MacFaden/Saperia January 2000 [Page 1] INTERNET-DRAFT SNMP CONFIGURATION July 2000 which specific current best practices using the Internet Standard Management Framework are derived. NOTE: this work is very much a draft in progress. Reviewer comments, questions and criticisms welcome on the snmpconf mailing list. Table of Contents Copyright Notice .................................................... 1 Abstract ........................................................... 1 1. Introduction ..................................................... 3 2. Document Organization ............................................ 4 3. Background - Practicing Configuration ............................ 4 4. Requirements ..................................................... 5 4.1 Fundamental Tenets of configuration ............................. 5 4.2 Requirements of configuration .................................. 6 4.3 Agent Software Development .................................... 7 4.3.1 Define read-write objects at the "right" level of abstraction.. 7 4.3.2 Separate out configuration sets from activation of configuration sets ................................................................ 9 4.3.3 Employ summary objects so managers can track overall state of configuration easily and efficiently ................................ 9 4.3.4 Handle activation latency early in the design of read-write objects ............................................................ 9 4.3.5 Do not rely on the SNMP to report application layer errors for SET operations ......................................................12 4.3.6 Do not create read-write objects that overlap in capability or activate potentially the same instance...............................12 4.3.7 Use common Textual Conventions whenever possible, especially when defining enumerations ..........................................13 4.3.8 Distinguishing which enumeration's an agent can support should be done in an Agent Capability MIB or by designing the MIB to indicate required basic capabilities ........................................ 14 4.3.9 RowStatus objects should return notReady(3) value if one or more mandatory objects in a given row have not been set ..................14 4.3.10 For objects contained in a table, specify semantics of changing a value when the row is in active(1) stat e ........................ 15 4.3.11 Extending IETF standard notifications is considered permissible. 15 4.3.13 Octet strings should not be used to aggregate multiple objects. 16 4.3.14 Design in an upper limit on the number of notifications (or traps) that can be sent in response to a given event ............... 16 4.3.15 Currency with RFC MIB Module Standards 17 MacFaden/Saperia January 2000 [Page 2] INTERNET-DRAFT SNMP CONFIGURATION July 2000 4.3.16 Do not ship a device with a community string "public" or "private" .......................................................... 17 4.3.17 The default state of RFC 1215 Authentication traps should be off ................................................................ 17 4.3.18 Persistence expectations of sets should be well defined ..... 18 4.3.19 If a MIB object contains sensitive information, then specify so in DESCRIPTION clause the need for encryption ...................... 18 4.3.20 Using OwnerString to represent row ownership can be a useful diagnostic tool .................................................... 19 4.3.21 Using a TimeStamp in read-create tables to show when it was activated is a useful diagnostic tool .............................. 19 5.0 Management Software Development ............................... 19 5.1 Protocol Operations ........................................... 20 5.2 SET Operations ................................................ 20 5.3 Configuration Transactions .................................... 21 5.4 Notifications ................................................. 21 5.5 Scale of the Management Software .............................. 22 5.6 Rate and Volume of Changes to Device .......................... 22 5.7 Handling Multiple Managers .................................... 22 5.8 Diagnostics and Configuration ................................. 23 6.0 Policy Based Management ........................................ 23 6.1 Introduction and Definition of Terms ........................... 23 6.2 Information Related to Policy Configuration .................... 25 6.3 Policy, Mechanism/Implementation and Instance Specific Modules 26 6.4 Schedule and Time Issues ....................................... 26 6.5 Conflict Detection, Resolution and Error Reporting ............. 27 6.6 Policy Precedence and Grouping ................................. 28 6.7 Changes to configuration outside of the policy system .......... 28 6.6 Use of Contexts ................................................ 28 6.8 Policy distribution applications ............................... 28 6.9 Notifications in a Policy System ............................... 28 7.0 Glossary ....................................................... 29 8.0 Example MIB .................................................... 29 9.0 References ..................................................... 37 10.0 Editors' Addresses ............................................ 39 11.0 Full Copyright Statement ...................................... 40 1. Introduction Data networks have grown greatly in size and complexity over the past decade. Configuration, also called provisioning of network elements, has grown correspondingly more complex in a number of aspects: Scale - data networks consist of more devices than ever before. Functionality - network devices increasingly perform more functions. MacFaden/Saperia January 2000 [Page 3] INTERNET-DRAFT SNMP CONFIGURATION July 2000 Convergence - more protocols and network layers are involved than ever before. The SNMP framework continues to be used successfully to develop configuration management systems for a broad range of devices. This document describes Best Current Practices that should be used when designing an effective SNMP-based element management system. In addition to element management, the SNMP can be used to configure groups of devices on a more abstract layer. Recently a great deal of attention has been placed on policy based configuration management. This document also includes recommendations for policy based configuration. This document defines "Policy based configuration management" as a set of configuration operations distributed to potentially many network elements with the goal of achieving consistent network behavior throughout a given autonomous system [21]. This document draws on experience provisioning public and private 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. 2. Document Organization The background section describes how experienced operations staff generally practices configuration of TCP/IP networks. The first through fourht section on requirements enumerates the goals and fundamental assumptions of configuration. Section 2 and 3 describe agent and management best current practices using the Internet standard SNMP framework. Section 6 describes relationship of Policy Management to SNMP framework. Section 8 presents a sample MIB from which many examples are based. 3. Background - Practicing Configuration The purpose of this section is to provide a sample configuration sequence for evaluating many of the requirements in further sections of this BCP. Data network devices are configured using many mechanisms, however two methods remain the most common: SNMP and Command Line Interface (CLI). MacFaden/Saperia January 2000 [Page 4] INTERNET-DRAFT SNMP CONFIGURATION July 2000 Layered on top of these mechanisms are operational methods for deploying changes to networks in a cautious and incremental manner. Experienced Network Operations staff makes changes to network configurations and firmware with careful planning and well documented procedures. Here is one model in detail: A. Pass one: LAB tryout to verify reliability and interoperability with prior versions of system code. 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. C. Apply change first via CLI to memory and watch device/network carefully over some time period D. After some time, write changes to persistent storage E. Expand changes to a few more like devices F. Keep mixed versions to prevent total loss of network G. Watch for new unknown defaults H. Watch for unknown side effects of changes I. Update configurations in revision control system Often, a diagnostic mode is present to deal with specific implementation issues above and beyond the standard set of instrumentation. 4. Requirements This section describes basic realities affecting a configuration management system from which specific requirements will be derived. 4.1 Fundamental Tenets of configuration A "mere mortal" trained in the operation of a given technology SHOULD be able to understand a device's state or some logical view of that state. The configuration mechanism must not be more complex than what is generally being configured so as to obscure what is being configured. Operators MUST have the ability to validate proper operation of a device before and after configuration changes regardless of latency. Put another way, the operator should have an integrated view of configuration, status, and diagnostic information. Ideally there are a series of tests the operator runs before and after a change is MacFaden/Saperia January 2000 [Page 5] INTERNET-DRAFT SNMP CONFIGURATION July 2000 made to an operational network to ensure service remains intact. A configuration subsystem should provide tools to facilitate such tests. For example, when configuring a DNS system, the tool nslookup is often used with a script to verify key database entries are present and return the expected values. Configuration can affect network stability and network stability can affect configuration procedures. Achieving convergence (stability) in an autonomous system is not an absolute given when configuration changes are made. For example, if changes are made to ospfIfHelloInterval and ospfIfRtrDeadInterval [22] 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: lose adjacency, form adjacency and so on never reach a converged (stable) state. Systems under configuration should be able to cope with unexpected loss of control due to lost communications. Any modern configuration protocol or process should be able to cope with a connectivity loss between manager and managed device. Network elements must take appropriate measures to leave the configuration in a consistent/recognizable state by either rolling back to a previously valid state or changing to a default state. Here then are requirements for a modern configuration protocol. 4.2 Requirements of configuration Diagnostic routines should be provided to verify proper operation of complex protocols. Debugging is an integral part of the configuration process. Subsystems should provide self-tests that verify internal state as well as tests to verify external states. Inclusion of debug/diagnostic tests that are exposed through a MIB interface improve the chance configuration errors can be identified and localized. The sequence test, set, test then becomes a normal method if change control in a production environment. Impact on convergence of an existing network should be specified in the configuration MIB interface. For example, any configuration change that causes loss of convergence should be noted in a description clause. Should an implementation fail to meet the convergence properties for a given object, notes can be made in an agent-capabilities MIB variations clause. A similar requirement is stated in "Requirements for IP Version 4 Routers" [20], section 1.3.4: A vendor needs to provide adequate documentation on all configuration parameters, their limits and effects. MacFaden/Saperia January 2000 [Page 6] INTERNET-DRAFT SNMP CONFIGURATION July 2000 Any modern configuration protocol or process must be mindful of connectivity loss between manager and managed device and take appropriate measures to leave the network device or devices in a consistent/recognizable state. 4.3. Agent Software Development This chapter will enumerate a number of best current practices by drawing upon a fictional MIB called ACME-HOUSECTRL-MIB. This MIB can control familiar facilities found in a modern home and is defined in Section 8.0 along with a sample agent capabilities definition. Along the way, the BCP also reviews key capabilities in the SNMP such as transactions, security, and error handling in the context of configuration. 4.3.1 Define read-write objects at the "right" level of abstraction. Metrics that can be employed during MIB design include number of objects needed to configure a given system, the relations among objects in the system, and the frequency at which they change state. If a MIB used for configuration contains "too many" objects to provision a given facility, then it is likely an abstraction problem. If there are overlapping objects with similar capabilities, then the abstraction may be to blame as well (See BCP6). For example, consider the configuration request to turn on all lights in a house. There may be tens of light circuits in a given single family home. The MIB Designer might be tempted to create a table with an instance for each lighting group controlled by one more switches and have an object to turn that light group on/off. Yet it considering the request, this would force the application developer to issue sets with tens of objects. The MIB Designer might solve this in at least two ways. First, specify an enumeration with specific operations: acmeGlobalHouseOperations OBJECT-TYPE SYNTAX INTEGER { turnOffAllLights (1), turnOnAllLights(2) dimAllLights(3) } ACCESS read-write STATUS mandatory DESCRIPTION MacFaden/Saperia January 2000 [Page 7] INTERNET-DRAFT SNMP CONFIGURATION July 2000 "Actions to apply to all Lights in a house." ::= { acmeLightGlobals 2 } The ease of adding such an object though has he drawback that the relations to other read-create tables for which individual lights suddenly become more complicated. What should happens to read-write objects when all lights are turned using the above object is not clearly spelled out. Exception cases then are created and an application would have to poll all objects correctly to obtain the current state of lights. The second approach is to make the general command more powerful. acmeLightGlobalHouseAction OBJECT-TYPE SYNTAX INTEGER { turnOn(1), turnOff(2), dim(3) } ACCESS read-write STATUS mandatory DESCRIPTION "Actions to apply to the lights enumerated in acmeLightGlobalHouseArgument." ::= { acmeLightEntry 2 } acmeLightGlobalHouseArgument OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-write STATUS mandatory DESCRIPTION "A bitwise encoding of indexes into the light Table for which a given Action will be applied to." ::= { acmeLightEntry 3 } This solution makes interpreting what the original request was much easier, but not what the current state of all the light-groups currently are. If a history is needed of what commands were sent, this table can record this aspect as well. DISCUSION NOTE: Retrieving a consistent configuration remains problematic from most SNMP agents that implement a wide range of MIBs. There is no generic way to retrieve a configuration with out a-priori knowing what objects to get. A solution that records every object using the powerful getnext operator does not scale. MacFaden/Saperia January 2000 [Page 8] INTERNET-DRAFT SNMP CONFIGURATION July 2000 4.3.2 Separate out configuration sets from activation of configuration sets. (ospfAdminStat, schedAdminStatus) Any complex configuration should have a master on/off switch as well as strategically placed on/off switches to control the employment of configuration data. These controls play a pivotal role during the configuration process as well as during diagnostics. Generally a series of set operations should not cause an agent to act on each object causing convergence/stability to be lost on each and every set. Ideally a series of Set PDUs would install the configuration and a final set series of PDUs would activate the changes. During diagnostic situations, certain on/off switches can be set to localize the perceived error instead of having to remove the configuration. DISCUSSION NOTE: ifAdminStatus effects on ifOperStatus, helps in one case where one doesn't poll ifAdminStatus along with ifOperStatus, but hurts in another as in trying to know if the link would be up operationally without actually setting ifAdminStatus to up(1). A master on/off switch for a given subsystem SHOULD be provided. Often, these switches are useful for diagnostics such as to help locate which subsystem is unstable as well as for a common configuration sequence where a feature is taken off-line, reconfigured then put back online. Lastly, one should not overload RowStatus objects to control activation/deactivation of a configuration. While RowStatus looks ideally suited for such a purpose since a management application can set a row to active(1), then set it to notInService(2) to disable it then make it active(1) again, there is no guarantee that the agent won't discard the row while it is in the notInService state. For an example see RFC 2591 schedAdminStatus. 4.3.3 Employ summary objects so managers can track overall state of configuration easily and efficiently. It is generally important to track changes to a device and to sync the changes with some specific configuration repository. Creating summary status objects "dummy lights" to provide simple and quick means to determine overall configuration-state of a subsystem. MacFaden/Saperia January 2000 [Page 9] INTERNET-DRAFT SNMP CONFIGURATION July 2000 For example, checksums or configuration version ids could also be computed over a configuration so that an application can reasonably identify an entire configuration instead of having to poll many "LastChange" objects or have to use TimeFilter style indexing to achieve highly efficient polling of large tables. The ACME-HOUSECTL-MIB contains the following definitions: AcmeCfgVersion ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value that starts at 0 and increases monotonically until the max value is reached at which point the value returns to 0." SYNTAX Gauge32 acmeSysActiveConfigId OBJECT-TYPE SYNTAX AcmeCfgVersion MAX-ACCESS read-write STATUS current DESCRIPTION "Current value of configuration information. This value remains persistent across reboots and increases when configuration changes are made to any object in this MIB." ::= { acmeHouseGlobals 3 } If configuration changes are very frequent in the order of seconds then the abstraction for configuration is probably wrong, see BCP1. If polling would not scale, consider using Notifications for reporting the old and new checksum objects. Notifications should most always report objects that are readily accessible to a manager station via polling. 4.3.4 Handle activation latency early in the design of read-write objects. (doscsIfDownChannelFrequency) Many MIBs both standard and enterprise often make the mistake of assuming an agent can activate a set operation as fast as it takes the agent to reply to the manager for a given set PDU. When there is anticipated latency in activating the results of a set operation a MIB designer SHOULD either: Define state machine to support the intermediate states Separate out read state of the object from read-write state of the object. MacFaden/Saperia January 2000 [Page 10] INTERNET-DRAFT SNMP CONFIGURATION July 2000 For example, if the ACME-HOUSE-MIB had implemented the garage door with a single object as follows: acmePortGarageDoor OBJECT-TYPE SYNTAX INTEGER { unknown(0), closed(1), open(2)} MAX-ACCESS read-write STATUS current DESCRIPTION "The current state of the garage door. Most garage doors open completely within 12 seconds." ::= { acmePortGarageEntry 2 } Manger Time 0 GetPDU acmePortGarageDoor.1.1 Agent Time 1 ResponsePDU error-index 0 error-code 0 acmePortGarageDoor.1.1 = open(2) Manger Time 2 SetPDU acmePortGarageDoor.1.1 = closed(1) Agent Time 3 ResponsePDU error-index 0 error-code 0 acmePortGarageDoor.1.1 = closed(1) Manger Time 4 GetPDU acmePortGarageDoor.1.1 Agent Time 5 ResponsePDU error-index 0 error-code 0 acmePortGarageDoor.1.1 = open(2) Manger Time 5+N (some seconds later...) GetPDU acmePortGarageDoor.1.1 Agent Time N+4 ResponsePDU error-index 0 error-code 0 acmePortGarageDoor.1.1 = closed(1) But the Manager expected the value of closed(1) since it had just set that value! Repeated polling of the object will eventually return the state value of closed(1) assuming nothing prevented the door from returning to the open state. Another variation on latency is the granularity of counter updates. Mangers 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 January 2000 [Page 11] INTERNET-DRAFT SNMP CONFIGURATION July 2000 4.3.5 Do not rely on the SNMP to report application layer errors for SET operations. MIB Design for configuration SHOULD use objects to track application level state. Management applications to date do not handle errors gracefully from the SNMP. When designing a MIB for configuration, do not rely on the SNMP error command set for application level state. Even if the SNMP will catch a "badValue" error, the application should report additional application level error-state that an application can obtain from an agent and decode. Failure to provide detailed diagnostic information leads to management applications that end up reporting insufficient error information. acmeSysDeviceLastErr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "A description of the last error that occurred in this MIB due to configuration errors or status error presentable to user interface." ::= { acmeHouseGlobals 7 } 4.3.6 Do not create read-write objects that overlap in capability or activate potentially the same instance. (dot1dStpPortEnable) One SHOULD NOT duplicate configuration objects across MIBs. While it may appear as a convenience, such as providing different indexing schemes, the side effects may not be easily discernible. For example, in the ACME-HOUSECTL-MIB, a designer might have designed the following two objects at different times: acmeWaterHeaterPilot OBJECT-TYPE SYNTAX INTEGER { off(1), on(2) } ACCESS read-write STATUS mandatory DESCRIPTION MacFaden/Saperia January 2000 [Page 12] INTERNET-DRAFT SNMP CONFIGURATION July 2000 "The current state of the pilot light." ::= { acmeWaterHeaderEntry 4 } in one table indexed by instances of water heaters in a house and then in another section of another MIB that adds a third state. -- The state of all gas pilots acmeGasPilotsStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), -- ready to pass gas disabled(2), primed(3) -- in some prime mode } MAX-ACCESS read-write STATUS current DESCRIPTION "Gas Pilots have three states, initial state is disabled, then primed which properly heats thermocouple and activates safety valves, then enabled." ::= { acmeGasPilotsEntry 7 } If a port is set to primed(3) via the acmeGasPilotsStatus what should be reported in reported in acmeWaterHeaterPilot for the same instance? 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. 4.3.7 Use common Textual Conventions whenever possible, especially when defining enumerations. Textual conventions that have even the slightest chance of being reused in other MIBs SHOULD also be defined in a separate MIB to facilitate sharing of such objects. For example, the state of an object can often be described using a TruthValue textual convention instead of inventing yet another Boolean condition. acmePatioLights OBJECT-TYPE SYNTAX INTEGER { on(1), off(2), } MAX-ACCESS read-write MacFaden/Saperia January 2000 [Page 13] INTERNET-DRAFT SNMP CONFIGURATION July 2000 STATUS current DESCRIPTION "Current status of outdoor lighting." ::= { acmeOutDoorElectricalEntry 3 } Would better expressed as follows: AcmePatioLightsEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Current status of outdoor lighting." ::= { acmeOutDoorElectricalEntry 3 } 4.3.8 Distinguishing which enumeration's an agent can support should be done in an Agent Capability MIB or by designing the MIB to indicate required basic capabilities. (dot1dDeviceCapabilities) In some cases, the use of capability bits can alleviate this as defined in RFC 2674 dot1dDeviceCapabilities can define some preset levels of capability. Example: can one subset a RowStatus implementation by just doing createAndGo instead of createAndWait and still call it RowStatus? 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. 4.3.9 RowStatus objects should return notReady(3) value if one or more mandatory objects in a given row have not been set. When designing read-create objects in a table containing a RowStatus object, first consider the default state of each object in the table when a row is created via one simple createAndWait(5) PDU. If no default state is applicable but the object must be set to some value, the DESCRIPTION clause should specify this object as mandatory. In addtion, an snmp get of such an object then should return noSuchName if the object has not yet been set. The RowStatus object should return notReady until all mandatory objects have been specified. MacFaden/Saperia January 2000 [Page 14] INTERNET-DRAFT SNMP CONFIGURATION July 2000 Should a given implementation require more objects to be set than what is specified in a MIB, an Agent capabilities MIB can be used to define the additional objects using the CREATION-REQUIRES clause. Not implementing the above may result in a manager being mislead that a transition to active(1) state will succeed without further action by only polling the rowStatus object and receiving the notInService(2) value from an agent. 4.3.10 For objects contained in a table, specify semantics of changing a value when the row is in active(1) state. It is an advantage for an agent developer to know when an object can and can not change value. Some operations may require an extended period of time to run with a given set of parameters. To change those parameters in mid step would necessitate the restarting of the whole operation. 4.3.11 Extending IETF standard notifications is considered permissible. Vendor extensions to existing standard notifications are not explicitly disallowed or allowed in SMIv2. For example, linkUp 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 } An implementation MAY add additional varbind objects to standard notifications. However, an implementation SHOULD make any extensions be not enabled by default and when enabled. An implementation SHOULD append to the varbind list any extensions. 4.3.12 Do not use OCTET STRINGS to transport data that differs by memory architecture or implementation. MacFaden/Saperia January 2000 [Page 15] INTERNET-DRAFT SNMP CONFIGURATION July 2000 (PortList) A MIB designer SHOULD NOT use octet strings to transport data that differs by memory architecture or implementation. Only a well- specified generic model should be used such as the above example. 4.3.13 Octet strings should not be used to aggregate multiple objects. Separate objects should be specified in separate MIB objects. Octet string is by definition limited to 256 bytes. If the object being modeled is larger than this size, one should abstract the information or reorganize the data to fit within this size boundary which helps keep configuration working in the face of abnormally behaving networks. 4.3.14 Design in an upper limit on the number of notifications (or traps) that can be sent in response to a given event. The more frequent the event which causes the notification to be sent, 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 in frDLCIStatusChange defined in RFC 2115. In this case when interfaces are taken down administratively, no frDLCIStatusChange will be sent. At other times, rate limiting notifications sent should be considered as in frTrapMaxRate. acmeHouseCtlDeviceLost NOTIFICATION-TYPE OBJECTS { acmeHouseInvenDevice, acmeHouseInvenKey, acmeHouseInvenAdminStatus, acmeHouseInvenOperStatus} STATUS current DESCRIPTION "This notification is generated whenever the invocation of a scheduled action fails. If there is a failure of many devices such that sending single notifications would be resource and time prohibitive, send the acmeHouseCtrlManyDevicesLost notification." MacFaden/Saperia January 2000 [Page 16] INTERNET-DRAFT SNMP CONFIGURATION July 2000 ::= { acmeHouseCtlGlobalErrs 1 } acmeHouseCtlManyDevicesLost NOTIFICATION-TYPE OBJECTS { acmeSysDevicesLastFailed, acmeSysDeviceErrors } STATUS current DESCRIPTION "This notification is generated whenever the invocation of a scheduled action fails. If there is a failure of many devices such that sending single notifications would be resource and time prohibitive, send acmeHouseCtrlManyDevicesLost notification." ::= { acmeHouseCtlGlobalErrs 2 } 4.3.15 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 management software SHOULD follow the current STATUS of MIB objects. 4.3.16 Do not ship a device with a community string "public" or "private." Agents should not define default community strings except where to bootstrap devices that do not have secondary management interfaces. These lead to security issues. A managed device SHOULD support read only as well as read-write community strings. 4.3.17 The default state of RFC 1215 Authentication traps should be off. In the "Notifications" section earlier, the issue of throttling traps was raised. For SNMPv1 agents, any unsolicited packet to a device that causes one ore more trap packets to be created and sent to management stations in response. If these traps flow on links that are shared, the community string from the trap may be used to gain access to the device. MacFaden/Saperia January 2000 [Page 17] INTERNET-DRAFT SNMP CONFIGURATION July 2000 4.3.18 Persistence expectations of sets should be well defined. Explicit persistence of set requests has generally 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 implementers can make visible the level of persistence 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. 4.3.19 If a MIB object contains sensitive information, then specify so in DESCRIPTION clause the need for encryption. (Bert) There are MIB objects that may contain keys, passwords and other such sensitive information and hence must be protected from unauthorized access. MacFaden/Saperia January 2000 [Page 18] INTERNET-DRAFT SNMP CONFIGURATION July 2000 A DESCRIPTION clause and for IETF MIB RFCS, the Security Considerations section should make it clear how and why these specific objects are sensitive and that a user should only make them accessible for encrypted SNMP access. If an implementation does not support DES, then the customer should not allow access to these objects, which is easy to specify in VACM. When writing standards track MIBs, one must operate on the basis of the "must implement" properties are of the various standards-track specifications. Confidentiality is not a must-implement portion of the SNMPv3 specification. 4.3.20 Using OwnerString to represent row ownership can be a useful diagnostic tool. Practice has shown that the use of the string "monitor" to identify configuration set by an agent/local management has been useful. 4.3.21 Using a TimeStamp in read-create tables to show when it was activated is a useful diagnostic tool. (ipCidrRouteAge, docsIfCmtsServiceCreateTime) When tracking down errors in configuration sequences, having a TimeStamp object in a row can help order sort out the order of configuration without having to revert to write trace and protocol decoders. 5.0 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. MacFaden/Saperia January 2000 [Page 19] INTERNET-DRAFT SNMP CONFIGURATION July 2000 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 5.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. 5.2 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 MacFaden/Saperia January 2000 [Page 20] INTERNET-DRAFT SNMP CONFIGURATION July 2000 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 other factors. 5.3 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. 5.4 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 atttempted 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. 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 MacFaden/Saperia January 2000 [Page 21] INTERNET-DRAFT SNMP CONFIGURATION July 2000 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. 5.5 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 as security issues. This section should include BCP for these if possible or dropped upon further discussion. 5.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. 5.7. Handling Multiple Managers Devices are often modified by multiple management entities. These management 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 management 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 MacFaden/Saperia January 2000 [Page 22] INTERNET-DRAFT SNMP CONFIGURATION July 2000 locally such as a default or locally specified configuration made through an alternate management 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 implementers 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 encompassing lock can be used such as RFC 1907 snmpSetSerialNo object. An application SHOULD use this object if there is no specific TestAndIncr object. 5.8 Diagnostics and Configuration This section describes in detail the kinds of diagnostics needed to help support proper provisioning models. 6.0 Policy Based Management Since policy based management with SNMP is a relatively new concept, this section does not document established practice with regard to policy-enabled SNMP management systems. It gives some background and defines terms that are relevant to this field and describes recommended deployment approaches. Issues that one should consider when deploying an SNMP-enabled policy management system are also discussed. 6.1 Introduction and Definition of Terms A primary goal of policy based management is to represent configuration information at higher levels of abstraction to make it easier for some operators to configure elements without knowing the details of each device. MacFaden/Saperia January 2000 [Page 23] INTERNET-DRAFT SNMP CONFIGURATION July 2000 Part of the function of the management station software and software the executes inside the network elements is to transform these different levels of abstractness into a form the equipment can use. The following are some terms that refer to the different levels of abstraction. Domain-Specific. A domain is a general area of technology such as service quality or security. Services, or service level agreements, may span several domains, each of them potentially including many policies. As a general rule, people will not discuss these domains in the abstract. They will most often be discussed with technology or application-specific examples. Examples of technical domains include, IPSec and Differentiated Services. When expressed in terms specific to a particular domain, a policy is said to be at the Domain Specific level of detail. Mechanism-Specific. Mechanisms are technologies used within a particular domain. For example, in the differentiated services domain, RED (Random Early Detection) or WRED (Weighted Random Early Detection) might be used as one of the mechanisms that devices employ to support differentiated services and the applications on which they rely. Policy descriptions that include the details associated with a particular mechanism, are said to be mechanism- specific. Implementation-Specific. Implementation-specific details are those parameters that a particular vendor might use in an implementation that augment a standard set of mechanism-specific parameters. Vendors often add special capabilities to basic mechanisms as a way of meeting special customer requirements or differentiating themselves from their competitors. These special capabilities are often a result of the implementation approach that a vendor has used for the product, thus the term, implementation-specific. For example, if a router vendor implemented a particular routing protocol, they would have the mechanism- specific parameters that control the behavior of that software. The vendor might have chosen to run several instances of that routing protocol, perhaps on different processors, for performance reasons. The parameters that are used to control the distribution of work on the different processors for that protocol would be implementation- specific. Instance-Specific. Network operators are most familiar and comfortable with information of this type. Instance-specific information refers to parameter values that have been associated with a specific instance in a managed element. For example, The Border Gateway Protocol is a routing protocol that has a number of parameters that describe information about a particular router1s view of other routers that it is sharing information with, peer MacFaden/Saperia January 2000 [Page 24] INTERNET-DRAFT SNMP CONFIGURATION July 2000 routers. One such parameter defined in the BGP MIB Module [BGP MIB] is the desired connection retry interval for a peer, bgpPeerConnectRetryInterval. An example value would be 120 (seconds). When expressed with this level of specificity, one would say that this is mechanism-specific data. If we were to see a value of bgpPeerConnectRetryInterval.10.0.0.1 = 120 we would be looking at the retry interval of the peer router found at IP address 10.0.0.1. The value for this instance is 120 seconds, instance-specific data. 6.2 Information Related to Policy Configuration In order for effective policy management to take place, a range of information about the network elements is needed to avoid making poor policy decisions. An effective policy management system will include the following information about each network element before sending policies for execution: The operational state of network elements that are to be configured. In particular, care should be taken to determine if the sub components to be configured are available for use. In some cases the elements may not be available. The policy configuration software should determine if this is a prerequisite to policy download or if the condition is acceptable. In those cases where policy is distributed when the sub component such as an interface or disk is not available, the managed system should send a notification to the designated management station when the policy is to become active if the resource is still not available. The capabilities of the devices in the network. A capability can be almost any unit of work a network element can perform. These include, routing protocols supported, Web Server and OS versions, queuing mechanisms supported on each interface that can be used to support different qualities of service, and many others. this information can be obtained from the capabilities table of the Policy MIB Module. The capacity of the devices to perform the desired work. Capability is an ability to perform the desired work while a capacity is a measure of how much of that capability the system has. The policy configuration application should wherever possible, evaluate the capacity of the network element to perform the work identified by the policy. In some systems it will not be possible to directly obtain the capacity of the managed elements to perform the desired work, even though it may be possible to monitor the amount of work the element performs. In these cases, the management application may MacFaden/Saperia January 2000 [Page 25] INTERNET-DRAFT SNMP CONFIGURATION July 2000 benefit from pre-configured information about the capacity of different network elements so that evaluations of the resources available can be made before distributing new policies. Utilization refers to how much capacity for a particular capability has been consumed. For devices that have been under policy configuration control for any period of time, a certain percentage of the available capacity of the managed elements will be used. Policies should not be distributed to systems that do not have the resources to carry out the policy for a reasonable period of time. 6.3 Policy, Mechanism/Implementation and Instance Specific Modules A conformant system could implement the policy module without any mechanism or implementation-specific modules though it is thought that will not be a likely scenario. For complicated configuration areas such as Differentiated Services, Web servers, routing protocols, etc., mechanism and frequently implementation-specific MIB Modules will be required. If a vendor implements a standard set of instance-specific MIB objects and an RFC has not yet been defined for a mechanism-specific set of objects to control the policy based configuration of these instance-specific objects, the vendor should create such a module allowing for the fact that an RFC might be issued later for the mechanism-specific module. To the extent a vendor creates instance- specific extensions to standard instance-specific MIB Modules, they should also create implementation-specific MIB Modules if they intent the box to be configured with policy-based management. Many vendors create proprietary functions and the instrumentation to manage them. To enable these features to be integrated into an SNMP- based policy management system, both instance and implementation- specific MIB objects should be created. 6.4 Schedule and Time Issues In large networks it may be necessary to coordinate the application of policies across time zones. Wherever possible, the network elements should support time information that includes local time zone information. Some deployed systems do not store complex notions of local time and thus may not be able to properly process policy MacFaden/Saperia January 2000 [Page 26] INTERNET-DRAFT SNMP CONFIGURATION July 2000 directives that contain time zone relevant data. For this reason, policy management applications should have the ability to ascertain the time keeping abilities of the managed system and make adjustments to the policy for those systems that are time-zone challenged. 6.5 Conflict Detection, Resolution and Error Reporting Sophisticated conflict detection and resolution is not realistically achievable in the short-term. Using a hierarchical approach to this problem can achieve significant benefits. Each 'layer' policy management system should be able to check for some errors and report them. The responsibilities for each layer are: Instance-specific. Conflict detection has been performed in a limited way for some time in software that realizes instance- specific MIB objects. This detection is independent of policy however. They types of 'conflicts' that are usually processed related are to resource availability and validity of the set operations. In a policy enabled system, there are not additional requirements for this software assuming that good error detection and reporting appropriate to this level had already been implemented. Mechanism and implementation-specific. For software that realizes mechanism and/or implementation-specific objects, failures should be reported such that the specific policy that has been impacted can be related with the specific element that failed. Beyond this basic reporting which is does not perform any policy conflict detection, there are not requirements. Mechanism and implementation-independent. The software that implements the mechanism and implementation-independent function will most often be a realization of the policy module. This software does assume some limited role in conflict detection. Specifically this software should verify that no two policies with the same precedence are allowed on the system. The policy system should also report events where one policy overrides another or when an element under policy control has been modified outside the policy system as would be the case of CLI modifications to elements under policy control. MacFaden/Saperia January 2000 [Page 27] INTERNET-DRAFT SNMP CONFIGURATION July 2000 6.6 Policy Precedence and Grouping 6.7 Changes to configuration outside of the policy system A goal of SNMP-based policy management is to coexist with other forms what have historically been instance based management. The best example is command line interface. Here are some guidelines for handling these changes. A notification should be sent whenever an out of policy control change is made to an element that is under the control of policy. This notification should include the policy that was changed, the instance of the element that was changed and the object and value that it was changed to. More on contexts later. An element under the control of policy that has been changed remains a member of the policy group until the attributes in the Role table that caused it to match the policy in the first place are modified. An element that has been modified by a an out of policy mechanism, while remaining a member of the policy does not get overridden by a policy until its value is made the same as the extant policy with the highest precedence for this element, and by implication then returned to policy control. A notification should be sent when this action is taken. 6.7 Use of Contexts TBD 6.8 Policy distribution applications TBD 6.9 Notifications in a Policy System TBD. MacFaden/Saperia January 2000 [Page 28] INTERNET-DRAFT SNMP CONFIGURATION July 2000 7.0 Glossary Transaction A finite group of changes that taken as a whole can be applied or rolled back in one operation. For example, a single SNMP SET PDU represents a transaction for which the state before the set is returned should any individual element in the variable-bindings list fail to be applied thus returning the device to exactly the same state before the SET was executed. Device-Local Configuration Device-local configuration data is specific to a particular network device. This is the finest level of granularity for configuring network devices. Network-Wide Configuration Network-wide configuration data 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. 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. Denial of Service (DOS) Any situation where access to resources by authorized consumers is diminished by overt or inadvertent abuse of network layer mechanisms 8.0 Example MIB ACME-HOUSECTL-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, Counter32, Gauge32, OBJECT-TYPE, TimeTicks, Integer32, NOTIFICATION-TYPE MacFaden/Saperia January 2000 [Page 29] INTERNET-DRAFT SNMP CONFIGURATION July 2000 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF TruthValue, TEXTUAL-CONVENTION, TimeStamp FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB; acmeHouseCtlMIB MODULE-IDENTITY LAST-UPDATED "200007090000Z" ORGANIZATION "Acme, Inc" CONTACT-INFO "Acme, Inc 1 Main Street Anytown, Anywhere" DESCRIPTION "This mib module defines a sample mib module that contains status, configuration and diagnostic management objects for items in a single family home." REVISION "200007090000Z" DESCRIPTION "Initial version of ACME-HOUSECTRL-MIB." ::= { XXX 1 } -- -- Textual Conventions -- AcmeCfgVersion ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A value that starts at 0 and increases monotonically until the Max value is reached at which point the value returns to 0." SYNTAX Gauge32 AcmeDeviceAdminStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The operational state of a device. Setting a device to testing invokes diagnostic routines which may or may not bring a device out of service." SYNTAX INTEGER { up(1), down(2), testing(3) } MacFaden/Saperia January 2000 [Page 30] INTERNET-DRAFT SNMP CONFIGURATION July 2000 AcmeDeviceOperStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The current general state of the device. A failed state indicates the device is not responding to management control" SYNTAX INTEGER { up(1), down(2), testing(3), failed(4) } -- -- Top level delegations -- acmeHouseInventory OBJECT-IDENTITY STATUS current DESCRIPTION "Inventory of the controls in the home over which operations can be made." ::= { acmeHouseCtlMIB 1 } acmeHouseGlobals OBJECT-IDENTITY STATUS current DESCRIPTION "Objects of global scope over a given home." ::= { acmeHouseCtlMIB 2 } acmeHouseConfig OBJECT-IDENTITY STATUS current DESCRIPTION "Configuration of devices managed by this MIB or subsidiary MIBs." ::= { acmeHouseCtlMIB 3 } acmeHouseCtlExceptions OBJECT-IDENTITY STATUS current DESCRIPTION "Exceptions of global scope to this mib defined here." ::= { acmeHouseCtlMIB 9 } acmeHouseCtlConformance OBJECT-IDENTITY STATUS current DESCRIPTION "Conformance details kept here for this MIB." MacFaden/Saperia January 2000 [Page 31] INTERNET-DRAFT SNMP CONFIGURATION July 2000 ::= { acmeHouseCtlMIB 10 } -- -- Inventory Group -- acmeHouseInvenLastUpdated OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "Timestamp when inventory report was last updated. A value of zero indicates never." ::= { acmeHouseInventory 1 } acmeHouseInvenNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of rows in acmeHouseInvenTable." ::= { acmeHouseInventory 2 } acmeHouseInvenTable OBJECT-TYPE SYNTAX SEQUENCE OF AcmeHouseInvenEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table presents a list of devices found in a given home. Rows are added and deleted by the agent. " ::= { acmeHouseInventory 3 } acmeHouseInvenEntry OBJECT-TYPE SYNTAX AcmeHouseInvenEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each row represents a particular device managed by this agent." INDEX { acmeHouseInvenId } ::= { acmeHouseInvenTable 1 } AcmeHouseInvenEntry ::= SEQUENCE { acmeHouseInvenId SnmpAdminString, acmeHouseInvenDevice OBJECT IDENTIFIER, acmeHouseInvenKey Integer32, acmeHouseInvenAdminStatus AcmeDeviceAdminStatus, acmeHouseInvenOperStatus AcmeDeviceOperStatus, acmeHouseInvenLastContact TimeStamp MacFaden/Saperia January 2000 [Page 32] INTERNET-DRAFT SNMP CONFIGURATION July 2000 } acmeHouseInvenId OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS not-accessible STATUS current DESCRIPTION "A persistent identifier that identifies a device uniquely within a single domain." ::= { acmeHouseInvenEntry 1 } acmeHouseInvenDevice OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The object identifier that uniquely identifies the type of device. A registration mib maintains the mappings to text." ::= { acmeHouseInvenEntry 2 } acmeHouseInvenKey OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A unique value within a given set of device with the same acmeHouseInvenDevice object identifier. Can be used for a short-hand indexing to other tables and notifications." ::= { acmeHouseInvenEntry 3 } acmeHouseInvenAdminStatus OBJECT-TYPE SYNTAX AcmeDeviceAdminStatus MAX-ACCESS read-write STATUS current DESCRIPTION "The desired administrative status of this device. Setting the value to down(2) has the effect of changing acmeHouseInvenOperStatus to down(2) as well." ::= { acmeHouseInvenEntry 4 } acmeHouseInvenOperStatus OBJECT-TYPE SYNTAX AcmeDeviceOperStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The curent operational state of the device." MacFaden/Saperia January 2000 [Page 33] INTERNET-DRAFT SNMP CONFIGURATION July 2000 ::= { acmeHouseInvenEntry 5 } acmeHouseInvenLastContact OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the device last responded to any management request or last poll." ::= { acmeHouseInvenEntry 6 } -- -- Configuration Globals Group -- acmeHouseGlobalSysActive OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "State of house control system. A value of true(1) represents the system is actively monitoring state and will accept valid configuration requests. A value of false(2) indicates this the master system is not maintaining state of systems found in the inventory component." ::= { acmeHouseGlobals 1 } acmeSysActiveLastChanged OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-write STATUS current DESCRIPTION "sysUpTime when acmeHouseGlobalSysActive last changed state." ::= { acmeHouseGlobals 2 } acmeSysActiveConfigId OBJECT-TYPE SYNTAX AcmeCfgVersion MAX-ACCESS read-write STATUS current DESCRIPTION "Current value of configuration information. This value remains persistent across reboots and increases when configuration changes are made to any object in this MIB." ::= { acmeHouseGlobals 3 } acmeSysDevicesActive OBJECT-TYPE SYNTAX Gauge32 MacFaden/Saperia January 2000 [Page 34] INTERNET-DRAFT SNMP CONFIGURATION July 2000 MAX-ACCESS read-write STATUS current DESCRIPTION "Number of active devices in the system according to last poll." ::= { acmeHouseGlobals 4 } acmeSysDevicesLastFailed OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-write STATUS current DESCRIPTION "sysUpTime when last device failed poll or admin request." ::= { acmeHouseGlobals 5 } acmeSysDeviceErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-write STATUS current DESCRIPTION "Number of devices that this manager lost contact, timed out with." ::= { acmeHouseGlobals 6 } acmeSysDeviceLastErr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "A description of the last error that occured in this mib due to configuration errors or status error presentable to user interface." ::= { acmeHouseGlobals 7 } -- -- Notification Section -- acmeHouseCtlGlobalErrs OBJECT IDENTIFIER ::= { acmeHouseCtlExceptions 0} acmeHouseCtlDeviceLost NOTIFICATION-TYPE OBJECTS { acmeHouseInvenDevice, acmeHouseInvenKey, acmeHouseInvenAdminStatus, acmeHouseInvenOperStatus} STATUS current DESCRIPTION "This notification is generated whenever the invocation of a scheduled action fails. If there is a failure of many devices such that sending single notifications would be resource and time prohibitive, send the MacFaden/Saperia January 2000 [Page 35] INTERNET-DRAFT SNMP CONFIGURATION July 2000 acmeHouseCtrlManyDevicesLost notification." ::= { acmeHouseCtlGlobalErrs 1 } acmeHouseCtlManyDevicesLost NOTIFICATION-TYPE OBJECTS { acmeSysDevicesLastFailed, acmeSysDeviceErrors } STATUS current DESCRIPTION "This notification is generated whenever the invocation of a scheduled action fails. If there is a failure of many devices such that sending single notifications would be resource and time prohibitive, send the acmeHouseCtrlManyDevicesLost notification." ::= { acmeHouseCtlGlobalErrs 2 } -- -- Compliance Section -- acmeHouseCtlGroups OBJECT IDENTIFIER ::= { acmeHouseCtlConformance 1 } acmeHouseCtlCompliances OBJECT IDENTIFIER ::= { acmeHouseCtlConformance 2 } acmeHouseInventoryGroup OBJECT-GROUP OBJECTS { acmeHouseInvenLastUpdated, acmeHouseInvenNumber, acmeHouseInvenDevice, acmeHouseInvenKey, acmeHouseInvenAdminStatus, acmeHouseInvenOperStatus, acmeHouseInvenLastContact } STATUS current DESCRIPTION "A collection of objects providing inventory and general status of all home objects controlled by this MIB." ::= { acmeHouseCtlGroups 1 } acmeHouseGlobalsGroup OBJECT-GROUP OBJECTS { acmeHouseGlobalSysActive, acmeSysActiveLastChanged, acmeSysActiveConfigId, acmeSysDevicesActive, acmeSysDevicesLastFailed, acmeSysDeviceErrors, MacFaden/Saperia January 2000 [Page 36] INTERNET-DRAFT SNMP CONFIGURATION July 2000 acmeSysDeviceLastErr } STATUS current DESCRIPTION "A collection of objects providing overall feature configuration state status." ::= { acmeHouseCtlGroups 2 } acmeHouseCtlNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { acmeHouseCtlDeviceLost, acmeHouseCtlManyDevicesLost } STATUS current DESCRIPTION "The notifications used by this MIB to denote exceptional conditions." ::= { acmeHouseCtlGroups 3 } acmeHouseCtrlMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The set of groups that make up the mandatory and optional groups required for MIB implementation." MODULE MANDATORY-GROUPS { acmeHouseInventoryGroup, acmeHouseGlobalsGroup } ::= { acmeHouseCtlCompliances 1 } END 9.0 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. MacFaden/Saperia January 2000 [Page 37] INTERNET-DRAFT SNMP CONFIGURATION July 2000 [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. [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 MacFaden/Saperia January 2000 [Page 38] INTERNET-DRAFT SNMP CONFIGURATION July 2000 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. [20] Baker, F, "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [21] Hawkinson, J, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996. [22] Baker, F, "OSPF Version 2 Management Information Base", RFC 1850, November 1995. 10.0 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 MacFaden/Saperia January 2000 [Page 39] INTERNET-DRAFT SNMP CONFIGURATION July 2000 11.0 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 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 January 2000 [Page 40]