Definitions of Managed Objects for System and Interface Testing December 24, 1996 Maria Greene Ascom Nexion greene@nexen.com Keith McCloghrie Cisco Systems kzm@cisco.com Kaj Tesink Bell Communications Research kaj@cc.bellcore.com Status of this Memo This document is an Internet-Draft. 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 a "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). INTERNET-DRAFT System/Interface Test MIB December 1996 Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for testing systems and interfaces. This memo replaces the objects originally defined in the ifTestGroup of RFC1573, the IF-MIB [6], which have been deprecated. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. 1. The SNMP Network Management Framework The SNMP Network Management Framework presently consists of three major components. They are: o the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols. o the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to also refer to the object type. Expires June 1997 [Page 2] INTERNET-DRAFT System/Interface Test MIB December 1996 2. Experience with the Interfaces Test Group The ifTestGroup of objects defined in RFC1573 has not been used widely. Some cited problems were: o Few standard tests had been defined to date. o Some well known tests had already been written on a media- specific basis, e.g., DS1 loopback. o The ifTestGroup allowed for interface testing only. o A logging capability was missing. As a result, the ifTestGroup and associated ifTestTable have been deprecated. However, since renewed interest was expressed in a generic testing capability, specifically in the development of MIBs for managing Asynchronous Transfer Mode interfaces, a set of requirements have been defined that form the basis for the design of the generic Test MIB defined in this memo. 3. Requirements for a Generic Test MIB This section describes the requirements that have been identified for a generic test MIB. 3.1. Test Identification The system defined in RFC1573 to identify tests relies on OBJECT IDENTIFIERs. This system is flexible in that it allows additional tests to be defined over time and autonomously by vendors, removing the need to register test types in a single place. This mechanism for test identification has been retained. Expires June 1997 [Page 3] INTERNET-DRAFT System/Interface Test MIB December 1996 3.2. Test Targets With the advent of an increasing number of non-interface related MIB modules it is desirable to define a test capability that allows testing of interfaces and non-interface physical entities. The following possibilities were considered: a) Separate test capabilities for interface tests and other tests. b) The use of a single test capability where the test target would be defined within the test table. This memo uses the latter approach and uses an object with the syntax RowPointer to identify test targets. (Initially, the use of the Entity MIB was considered for identification of test targets, but this was abandoned because this would require support of the Entity MIB for testing purposes.) Tests are listed in the testTable. The entries in the testTable are distinguished through the value of a simple integer called testIndex. 3.3. Single Versus Multiple Simultaneous Tests The capability of allowing multiple simultaneous tests has sometimes been described as useful, though the requests for the feature have been sporadic. However, when allowing for non-interface related tests this need may become more apparent. Also, proxy situations may make the ability to run multiple simultaneous tests more desirable. A related question is: how long may a test run? This MIB module has taken a middle road approach where simultaneous tests on different physical entities are possible, while simultaneous tests on a single entity are excluded. This approach avoids the need for more complex read-create tables. A test in progress can be stopped by setting the testType to 'noTest'. Expires June 1997 [Page 4] INTERNET-DRAFT System/Interface Test MIB December 1996 3.4. Logging Results A logging capability of test results serves to store the test results for some period of time. Two mechanisms were considered: 1) Separate the test capability and the log. 2) Combine the test capability and the log in a single table. Note that searching criteria on the log relate to this choice as well. The log length is necessarily limited. The following choices were considered: 1) Age the entries. 2) Limit by the number of entries. 3) A system that allows either 1) or 2). This MIB module chooses a system where the test capability (testTable) has been separated from the log (testLogTable). The log length is limited by a read-write object (testLogMaxSize). This MIB module also defines a notification, testComplete, which contains the same information as the log entry. Therefore, an agent with limited resources can limit the maximum size of the log to a very few number of entries and rely on a management application to receive and log the testComplete notifications. 3.5. Log Searching Efficient searching in a log is a key to its effectiveness. The following possibilities were considered: a) Sort on age of the entries. b) Sort on test type. c) Sort on combinations of the above. Expires June 1997 [Page 5] INTERNET-DRAFT System/Interface Test MIB December 1996 This MIB module chooses for the index testId, which is an integer identifier for an invocation of a test. This addresses the requests that are expected to be most common: o What is the result of test testId? o What are the results of the last n tests? Since the testId has been defined as monotonically increasing, this approach will order log entries by time, oldest to newest. The possibility of testId wrapping is minimized by having it restart at 0 and the log flushed when the agent restarts. When a manager is interested in a specific test, a specific get-request may be issued. When a manager is interested in the latest n tests for the system, getnext/bulk starting from (testId-n) provides the approximate answer. Note that defining testId as a "TestAndDecr" would yield more precise results because the testLogTable would then be sorted with the most recent test first; however this was rejected because of the counter-intuitive behavior of the resulting index and the slight increase in complexity due to this new syntax. 3.6. Determining Agent Test Capabilities The testTable will only have entries for those entities represented by this agent that support tests. No capability has been defined to list the tests that an entity is capable of. However, if an entity is only capable of one test, then the testType columnar object for that entity may be initialized to that type, or, if it is capable of many tests, it may be initialized to one of the supported types. Expires June 1997 [Page 6] INTERNET-DRAFT System/Interface Test MIB December 1996 4. Definitions TEST-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, TimeTicks, Unsigned32, experimental, NOTIFICATION-TYPE, mib-2 FROM SNMPv2-SMI TestAndIncr, AutonomousType, RowPointer FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF OwnerString FROM IF-MIB ; testMIB MODULE-IDENTITY LAST-UPDATED "9611251200Z" -- November 25, 1996 ORGANIZATION "IETF IFMIB Working Group" CONTACT-INFO "Keith McCloghrie Postal: Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US Tel: +1 408 526 5260 E-mail: kzm@cisco.com Kaj Tesink Postal: Bell Communications Research 331 Newman Springs Road Red Bank, NJ 07701 US Tel: +1 908 758 5254 E-mail: kaj@cc.bellcore.com Maria Greene Postal: Ascom Nexion 289 Great Road Acton, MA 01720 US Tel: +1 508 266 4570 E-mail: greene@nexen.com" DESCRIPTION "This MIB module provides a generic test capability." -- ******** NOTE TO THE RFC EDITOR ************** Expires June 1997 [Page 7] INTERNET-DRAFT System/Interface Test MIB December 1996 -- In case this module is put on the standards track -- replace the following: -- "::= {experimental XX}" with -- "::= { mib-2 YY }" ::= { experimental XX } testMIBObjects OBJECT IDENTIFIER ::= { testMIB 1 } -- The Test Table testTable OBJECT-TYPE SYNTAX SEQUENCE OF TestEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains one entry per entity that supports testing. It defines objects which allow a network manager to instruct an agent to test an entity for various faults. Tests for an entity are defined in the specific MIB for that entity. After invoking a test, the object testResult can be read to determine the outcome. If an agent can not perform the test, testResult is set to so indicate. The testLogTable can be used to provide further test-specific or entity- specific (or even enterprise-specific) information concerning the outcome of the test. Only one test can be in progress on each entity at any one time. If one test is in progress when another test is invoked, the second test is rejected. Some agents may reject a test when a prior test is active on another entity. Before starting a test, a manager-station must first obtain 'ownership' of the entry in the testTable for the entity to be tested. This is accomplished with the testId and testStatus objects as follows: try_again: get (testId, testStatus) while (testStatus != notInUse) /* * Loop while a test is running or some other * manager is configuring a test. */ short delay get (testId, testStatus) } Expires June 1997 [Page 8] INTERNET-DRAFT System/Interface Test MIB December 1996 /* * Is not being used right now -- let's compete * to see who gets it. */ lock_value = testId if ( set (testId = lock_value, testStatus = inUse, testOwner = 'my-IP-address') == FAILURE) /* * Another manager got the testEntry -- go * try again */ goto try_again; /* * I have the lock */ set up any test parameters. /* * This starts the test */ set (testType = test_to_run); wait for test completion by polling testResult when test completes, agent sets testResult agent also sets testStatus = 'notInUse' retrieve test results from the testLog using lock_value as the index A manager station first retrieves the value of the appropriate testId and testStatus objects, periodically repeating the retrieval if necessary, until the value of testStatus is 'notInUse'. The manager station then tries to set the same testId object to the value it just retrieved, the same testStatus object to 'inUse', and the corresponding testOwner object to a value indicating itself. If the set operation succeeds then the manager has obtained ownership of the testEntry, and the value of the testId object is incremented by the agent (per the semantics of TestAndIncr). Failure of the set operation indicates that some other manager has obtained ownership of the testEntry. Once ownership is obtained, any test parameters can be Expires June 1997 [Page 9] INTERNET-DRAFT System/Interface Test MIB December 1996 setup, and then the test is initiated by setting testType. On completion of the test, the agent sets testStatus to 'notInUse'. Once this occurs, the manager can retrieve the results. In the (rare) event that the invocation of tests by two network managers were to overlap, then there would be a possibility that the first test's results might be overwritten by the second test's results prior to the first results being read. This unlikely circumstance can be detected by a network manager retrieving testId at the same time as retrieving the test results, and ensuring that the results are for the desired request. If testType is not set within an abnormally long period of time after ownership is obtained, the agent should time-out the manager, and reset the value of the testStatus object back to 'notInUse'. It is suggested that this time-out period be 5 minutes. In general, a management station must not retransmit a request to invoke a test for which it does not receive a response; instead, it properly inspects an agent's MIB to determine if the invocation was successful. Only if the invocation was unsuccessful, is the invocation request retransmitted. Some tests may require the entity to be taken off- line in order to execute them, or may even require the agent to reboot after completion of the test. In these circumstances, communication with the management station invoking the test may be lost until after completion of the test. An agent is not required to support such tests. However, if such tests are supported, then the agent should make every effort to transmit a response to the request which invoked the test prior to losing communication. When the agent is restored to normal service, the results of the test are properly made available in the appropriate objects. Note that this requires that the testIndex value assigned to an entity must be unchanged even if the test causes a reboot. An agent must reject any test for which it cannot, perhaps due to resource constraints, make available at least the minimum amount of information after that test completes." ::= { testMIBObjects 1 } testEntry OBJECT-TYPE Expires June 1997 [Page 10] INTERNET-DRAFT System/Interface Test MIB December 1996 SYNTAX TestEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing objects for invoking tests on an entity. There is one testEntry for every entity associated with the agent that supports testing." INDEX { testIndex } ::= { testTable 1 } TestEntry ::= SEQUENCE { testIndex Unsigned32, testTarget RowPointer, testId TestAndIncr, testStatus INTEGER, testType AutonomousType, testResult INTEGER, testOwner OwnerString } testIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of this table." ::= { testEntry 1 } testTarget OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-write STATUS current DESCRIPTION "The target of the test. An example of a test target is an instance of an interface, identified by the OID 'ifIndex.17'." ::= { testEntry 2 } testId OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "This object identifies the current invocation of any test, not just tests on the entity identified by the index of Expires June 1997 [Page 11] INTERNET-DRAFT System/Interface Test MIB December 1996 this entry. If the agent is restarted the value of this object shall be set to 0. If the value of testId ever reaches its maximum value of 2147483647, it will latch at that value and return the error 'inconsistentValue' (for SNMPv2) or 'badValue' (for SNMPv1) if the manager attempts to set it. Note that the value the manager sets this object to when setting the testStatus to 'inUse(2)' is the value that should be used for testLogIndex to retrieve the results of the test. After a successful SET, all instances of testId for all entries in this table will be incremented. The reason the testId and testStatus objects are not outside the table is that this would limit the manager to only running one test at a time." ::= { testEntry 3 } testStatus OBJECT-TYPE SYNTAX INTEGER { notInUse(1), inUse(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether or not some manager currently has the necessary 'ownership' required to invoke a test on this entity. A write to this object is only successful when it changes its value from 'notInUse(1)' to 'inUse(2)'. After completion of a test, the agent resets the value back to 'notInUse(1)'." ::= { testEntry 4 } testType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-write STATUS current DESCRIPTION "A control variable used to start and stop operator- initiated entity tests. Most OBJECT IDENTIFIER values assigned to tests are defined elsewhere, in association with specific types of entity. However, this memo defines the special meanings of the subject identifier: noTest OBJECT IDENTIFIER ::= { 0 0 } When the value 'noTest' is written to this object, no action is taken unless a test is in progress, in which case the test is aborted. Writing any other value to this object is Expires June 1997 [Page 12] INTERNET-DRAFT System/Interface Test MIB December 1996 only valid when no test is currently in progress, in which case the indicated test is initiated. When read, this object always returns the most recent value that testType was set to. If it has not been set since the last initialization of the network management subsystem on the agent, either a value of or a value of one of the valid test types that can be performed on this entity is returned." ::= { testEntry 5 } testResult OBJECT-TYPE SYNTAX INTEGER { none(1), -- no test yet requested success(2), inProgress(3), notSupported(4), unAbleToRun(5), -- due to state of system aborted(6), failed(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the result of the most recently requested test, or the value 'none(1)' if no tests have been requested since the last reset." ::= { testEntry 6 } testOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-write STATUS current DESCRIPTION "The manager which currently has the 'ownership' required to invoke a test on this entity." ::= { testEntry 7 } -- Log size testLogMaxSize OBJECT-TYPE SYNTAX Unsigned32 (10..4294967295) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number entries in the testLogTable. When the Expires June 1997 [Page 13] INTERNET-DRAFT System/Interface Test MIB December 1996 table reaches this size the oldest entries will be discarded when new entries are added. The table is flushed when the agent is reset." ::= { testMIBObjects 2 } -- Test Logging Table testLogTable OBJECT-TYPE SYNTAX SEQUENCE OF TestLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the most recent test results for tests which completed with the testResult of either 'success(2)' or 'failed(7)'." ::= { testMIBObjects 3 } testLogEntry OBJECT-TYPE SYNTAX TestLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry in this table represents a test result." INDEX { testLogIndex } ::= { testLogTable 1 } TestLogEntry ::= SEQUENCE { testLogIndex Unsigned32, testLogType AutonomousType, testLogCompletionTime TimeTicks, testLogSummary INTEGER, testLogCode OBJECT IDENTIFIER, testLogOwner OwnerString, testLogTestIndex Unsigned32 } testLogIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer index that uniquely identifies the entry in the log. This is the value of testId for the completed test." ::= { testLogEntry 1 } Expires June 1997 [Page 14] INTERNET-DRAFT System/Interface Test MIB December 1996 testLogType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of test that has completed." ::= { testLogEntry 2 } testLogCompletionTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the test completed." ::= { testLogEntry 3 } testLogSummary OBJECT-TYPE SYNTAX INTEGER { success(2), failed(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "The summary result of this test." ::= { testLogEntry 4 } testLogCode OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a code which contains more specific information on the test result, for example an error-code after a failed test or a result value such as round trip time for a 'ping' test. Error codes and other values this object may take are specific to the type of entity and/or test. The value may have the semantics of AutonomousType, InstancePointer, RowPointer or VariablePointer textual conventions as defined in RFC 1903. The identifier: testCodeNone OBJECT IDENTIFIER ::= { 0 0 } is defined for use if no additional result code is available." ::= { testLogEntry 5 } Expires June 1997 [Page 15] INTERNET-DRAFT System/Interface Test MIB December 1996 testLogOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the manager that owned the test." ::= { testLogEntry 6 } testLogTestIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of testIndex for this test." ::= { testLogEntry 7 } -- Notifications testMIBNotifications OBJECT IDENTIFIER ::= { testMIB 0 } testComplete NOTIFICATION-TYPE OBJECTS { testLogType, testLogSummary, testLogCode, testLogOwner, testLogTestIndex } STATUS current DESCRIPTION "A testComplete trap signifies that a test has completed for a particular entity. If the testLogCode has the semantics of a VariablePointer, the variable it points at will also be included in the objects list." ::= { testMIBNotifications 1 } -- Conformance Information testMIBConformance OBJECT IDENTIFIER ::= { testMIB 3 } testMIBGroups OBJECT IDENTIFIER ::= { testMIBConformance 1 } testMIBCompliances OBJECT IDENTIFIER ::= { testMIBConformance 2 } Expires June 1997 [Page 16] INTERNET-DRAFT System/Interface Test MIB December 1996 -- Compliance Statements testMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP agents which support generic testing capabilities." MODULE -- this module MANDATORY-GROUPS { testMIBGroup, testNotificationGroup } OBJECT testLogMaxSize MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { testMIBCompliances 1 } -- Units of Conformance testMIBGroup OBJECT-GROUP OBJECTS { testTarget, testId, testStatus, testType, testResult, testOwner, testLogType, testLogMaxSize, testLogCompletionTime, testLogSummary, testLogCode, testLogOwner, testLogTestIndex } STATUS current DESCRIPTION "A collection of objects providing a generic test capability." ::= { testMIBGroups 1 } testNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { Expires June 1997 [Page 17] INTERNET-DRAFT System/Interface Test MIB December 1996 testComplete } STATUS current DESCRIPTION "The notifications used to indicate test completion." ::= { testMIBGroups 2 } END Expires June 1997 [Page 18] INTERNET-DRAFT System/Interface Test MIB December 1996 5. Usage Examples The following sections show examples of interface testing and system testing. These examples assume the following physical configuration represented using the Entity MIB [5] and that, for convenience, the agent uses the value of entPhysicalIndex for testIndex. Note that this is just a convenience for an agent that supports both the Entity MIB and the Test MIB and is not a requirement. A router containing two slots. Each slot contains a 3 port router/bridge module. Each port is also represented in the ifTable. Physical entities -- entPhysicalTable: 1 chassis: entPhysicalDescr.1 == "Acme Chassis Model 100" entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 entPhysicalContainedIn.1 == 0 entPhysicalClass.1 == chassis(3) entPhysicalParentRelPos.1 == 0 2 slots within the chassis: entPhysicalDescr.2 == "Acme Router Chassis Slot 1" entPhysicalVendorType.2 == acmeProducts.slotTypes.1 entPhysicalContainedIn.2 == 1 entPhysicalClass.2 == container(5) entPhysicalParentRelPos.2 == 1 entPhysicalDescr.3 == "Acme Router Chassis Slot 2" entPhysicalVendorType.3 == acmeProducts.slotTypes.1 entPhysicalContainedIn.3 == 1 entPhysicalClass.3 == container(5) entPhysicalParentRelPos.3 == 2 2 Field-replaceable modules: Slot 1 contains a module with 3 ports: entPhysicalDescr.4 == "Acme Router Module Model 10" entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 entPhysicalContainedIn.4 == 2 entPhysicalClass.4 == module(9) entPhysicalParentRelPos.4 == 1 entPhysicalDescr.5 == "Acme Router Ethernet Port 1" entPhysicalVendorType.5 == acmeProducts.portTypes.2 entPhysicalContainedIn.5 == 4 entPhysicalClass.5 == port(10) entPhysicalParentRelPos.5 == 1 Expires June 1997 [Page 19] INTERNET-DRAFT System/Interface Test MIB December 1996 entPhysicalDescr.6 == "Acme Router Ethernet Port 2" entPhysicalVendorType.6 == acmeProducts.portTypes.2 entPhysicalContainedIn.6 == 4 entPhysicalClass.6 == port(10) entPhysicalParentRelPos.6 == 2 entPhysicalDescr.7 == "Acme Router Ethernet Port 3" entPhysicalVendorType.7 == acmeProducts.portTypes.3 entPhysicalContainedIn.7 == 4 entPhysicalClass.7 == port(10) entPhysicalParentRelPos.7 == 3 Slot 2 contains another 3-port module: entPhysicalDescr.8 == "Acme Router Module Model 11" entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 entPhysicalContainedIn.8 == 3 entPhysicalClass.8 == module(9) entPhysicalParentRelPos.8 == 1 entPhysicalDescr.9 == "Acme Router Fddi Port 1" entPhysicalVendorType.9 == acmeProducts.portTypes.3 entPhysicalContainedIn.9 == 8 entPhysicalClass.9 == port(10) entPhysicalParentRelPos.9 == 1 entPhysicalDescr.10 == "Acme Router Ethernet Port 2" entPhysicalVendorType.10 == acmeProducts.portTypes.2 entPhysicalContainedIn.10 == 8 entPhysicalClass.10 == port(10) entPhysicalParentRelPos.10 == 2 entPhysicalDescr.11 == "Acme Router Ethernet Port 3" entPhysicalVendorType.11 == acmeProducts.portTypes.2 entPhysicalContainedIn.11 == 8 entPhysicalClass.11 == port(10) entPhysicalParentRelPos.11 == 3 Entities Supporting Tests -- testTable: testTarget.4 == entPhysicalIndex.4 testTarget.5 == ifIndex.17 testTarget.6 == ifIndex.18 testTarget.7 == ifIndex.19 testTarget.8 == entPhysicalIndex.8 testTarget.9 == ifIndex.3 testTarget.10 == ifIndex.4 testTarget.11 == ifIndex.5 Expires June 1997 [Page 20] INTERNET-DRAFT System/Interface Test MIB December 1996 5.1. Interface Test In this example, the network manager wishes to run a loopback test on the third Ethernet port on the module in slot 1. The testIndex of the port is 7. The Ethernet-like Interfaces MIB [6], defines an OBJECT IDENTIFIER for the dot3TestLoopBack. Expires June 1997 [Page 21] INTERNET-DRAFT System/Interface Test MIB December 1996 The test would be invoked as follow: try_again: get (testId.7, testStatus.7) while (testStatus != notInUse) /* * Loop while a test is running or some other * manager is configuring a test. */ short delay get (testId.7, testStatus.7) } /* * Is not being used right now -- let's compete * to see who gets it. */ lock_value = testId if ( set (testId.7 = lock_value, testStatus.7 = inUse, testOwner.7 = 'my-IP-address') == FAILURE) /* * Another manager got the testEntry -- go * try again */ goto try_again; /* * I have the lock */ set up any test parameters. /* * This starts the test */ set (testType.7 = dot3TestLoopBack); wait for test completion by polling testResult.7 when test completes, agent sets testResult agent also sets testStatus = 'notInUse' retrieve any additional test results from testLogTable using lock_value as the index Expires June 1997 [Page 22] INTERNET-DRAFT System/Interface Test MIB December 1996 5.2. System Test A system test is the same as an interface test from the perspective of the test table. For example, the network administrator may wish to run a self test on the module in slot 2. Let's assume such a test is defined in one of the Acme vendor's enterprise MIBs as follows: acmeModuleSelfTest OBJECT-IDENTITY STATUS current DESCRIPTION "Run a diagnostic self-test on an Acme hardware module." ::= { acmeProductsTestTypes 1 } The procedure of invoking the test and retrieving the results is the same as that described in the Interface Test example. Note that value of entPhysicalIndex for the module in slot 2 is 8 based on the earlier example configuration so the test would be started using this operation: /* * This starts the test */ set(testType.8 = acmeModuleSelfTest); 6. Acknowledgments This document is a product of the IETF's Interfaces MIB Working Group. The original ifTestTable was the work of Keith McCloghrie (Cisco) and Frank Kastenholz (FTP Software) and has been used almost unchanged in this further evolution. The authors would like to acknowledge the following individuals for their input on requirements: James Watt (Newbridge) Dave Fowler (Newbridge) Steven Buchko (Newbridge) Milt Rosslinsky (ACC) Expires June 1997 [Page 23] INTERNET-DRAFT System/Interface Test MIB December 1996 7. References [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [2] 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. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [5] McCloghrie, K., and A. Bierman, Editors, "Entity MIB", RFC2037, Cisco Systems, January 1996. [6] Kastenholz, F., "Definitions of Managed Objects for the Ethernet- like Interface Types using SMIv2", RFC1650, FTP Software, Inc, August 1994. [6] McCloghrie, K., Kastenholz, F., "Evolution of the Interfaces Group of MIB-II", RFC1573, (should be updated to new IF-MIB RFC#) Cisco Systems, Inc., FTP Software, January 1994. [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. Expires June 1997 [Page 24] INTERNET-DRAFT System/Interface Test MIB December 1996 8. Security Considerations Security issues are not discussed in this memo. 9. Authors' Addresses Maria Greene Ascom Nexion 289 Great Road Acton, MA 01720-4739 Phone: (508) 266-4570 EMail: greene@nexen.com Keith McCloghrie Cisco Systems 170 West Tasman Drive San Jose, CA 95134 Phone: (408) 526-5260 E-mail: kzm@cisco.com Kaj Tesink Bell Communications Research Room 1A-427 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 Phone: (908) 758-5254 EMail: kaj@cc.bellcore.com Expires June 1997 [Page 25] INTERNET-DRAFT System/Interface Test MIB December 1996 Table of Contents 1 The SNMP Network Management Framework ........................ 2 1.1 Object Definitions ......................................... 2 2 Experience with the Interfaces Test Group .................... 3 3 Requirements for a Generic Test MIB .......................... 3 3.1 Test Identification ........................................ 3 3.2 Test Targets ............................................... 4 3.3 Single Versus Multiple Simultaneous Tests .................. 4 3.4 Logging Results ............................................ 5 3.5 Log Searching .............................................. 5 3.6 Determining Agent Test Capabilities ........................ 6 4 Definitions .................................................. 7 5 Usage Examples ............................................... 19 5.1 Interface Test ............................................. 21 5.2 System Test ................................................ 23 6 Acknowledgments .............................................. 23 7 References ................................................... 24 8 Security Considerations ...................................... 25 9 Authors' Addresses ........................................... 25 Expires June 1997 [Page 26]