Cisco CMTS Troubleshooting and Network Management Features Configuration Guide, Release 12.2SC
GOLD Health Monitoring for the Cisco UBR10012 Universal Broadband Router
Download this chapter
GOLD Health Monitoring for the Cisco UBR10012 Universal Broadband RouterGOLD Health Monitoring for the Cisco UBR10012 Universal Broadband Router
Download the complete book
Cisco CMTS Router Troubleshooting and Network Management Features Configuration Guide, Release 12.2SCCisco CMTS Router Troubleshooting and Network Management Features Configuration Guide, Release 12.2SC (PDF - 1 MB)
 Feedback

Table Of Contents

GOLD Health Monitoring for the Cisco UBR10012 Universal Broadband Router

Finding Feature Information

Contents

Prerequisites for GOLD

Restrictions for GOLD feature

Information About GOLD

Limitations of Existing Logging Mechanism

Understanding the Importance of GOLD Functionality

Understanding the GOLD Feature

Configuring Online Diagnostics

Configuring the Bootup Diagnostics Level

Configuring On-Demand Diagnostics

Scheduling Diagnostics

Configuring Health-Monitoring Diagnostics

Displaying Online Diagnostic Tests and Test Results

Supported GOLD Tests on Cisco UBR10012 Router

Low Latency Queue (LLQ) Drop Test

Guardian Index Leak Test

Memory Leak Test

How to Manage Diagnostic Tests

Configuration Examples for GOLD Feature

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance

Feature Information for GOLD for the Cisco CMTS Routers


GOLD Health Monitoring for the Cisco UBR10012 Universal Broadband Router

First Published: November 16, 2009
Last Updated: November 29, 2010


Generic Online Diagnostic (GOLD) is a health monitoring feature implemented on the Cisco UBR10012 Universal Broadband Router in the Cisco IOS Release 12.2(33)SCC. The GOLD functionality is developed to provide online diagnostic capabilities that run at bootup, in the background on a periodic basis, or based on demand from the CLI.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for GOLD for the Cisco CMTS Routers" section.

Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.

Contents

•Prerequisites for GOLD

•Restrictions for GOLD feature

•Information About GOLD

•Configuring Online Diagnostics

•How to Manage Diagnostic Tests

•Configuration Examples for GOLD Feature

•Additional References

•Feature Information for GOLD for the Cisco CMTS Routers

Prerequisites for GOLD

Table 1 shows the hardware and software compatibility prerequisites for this feature.

Note The hardware components introduced in a given Cisco IOS Release will be supported in all subsequent releases unless otherwise specified.

Table 1 GOLD Support for the Cisco CMTS Routers Hardware and Software Compatibility Matrix

CMTS Platform
Processor Engine
Cable Interface Cards

Cisco uBR10012 Universal Broadband Router

Cisco IOS Release 12.2(33)SCA and later

•PRE2

Cisco IOS Release 12.2(33)SCB and later

•PRE4

Cisco IOS Release 12.2(33)SCB and later

•Cisco uBR10-MC5X20U/H

Cisco IOS Release 12.2(33)SCC and later

•Cisco UBR-MC20X20V

Cisco IOS Release 12.2(33)SCE and later

•Cisco uBR-MC3GX60V1

Cisco uBR7246VXR Universal Broadband Router

Cisco IOS Release 12.2(33)SCA and later

•NPE-G1

•NPE-G2

Cisco IOS Release 12.2(33)SCA and later

•Cisco uBR-MC28U/X

Cisco IOS Release 12.2(33)SCD and later

•Cisco uBR-MC88V2

Cisco uBR7225VXR Universal Broadband Router

Cisco IOS Release 12.2(33)SCA and later

•NPE-G1

Cisco IOS Release 12.2(33)SCB and later

•NPE-G2

Cisco IOS Release 12.2(33)SCA and later

•Cisco uBR-E-28U

•Cisco uBR-E-16U

•Cisco uBR-MC28U/X

Cisco IOS Release 12.2(33)SCD and later

•Cisco uBR-MC88V

1 Cisco uBR3GX60V cable interface line card is not compatible with PRE2. You must use PRE4 with the Cisco uBR3GX60V cable interface line card.

2 Cisco uBR-MC88V cable interface line card is not compatible with NPE-G1. You must use NPE-G2 with the Cisco uBR-MC88V cable interface line card.


Restrictions for GOLD feature

•GOLD test cases are designed on a per chip or per interface level and are not expected to monitor at a per modem or per service flow level.

•GOLD diagnostic test cases supported in the Cisco IOS Release 12.2(33)SCC are as follows:

–Low Latency Queue (LLQ) Drop Monitor Test: Implemented on 5x20 cable line card (CLC) (Test520LLQDrops), 20x20 CLC (Test2020LLQDrops), and Modena (TestModenaLLQDrops).

–Guardian Index Leak Test: Implemented only on 5x20 Guardian LC (TestBlazeIndexLeak).

–CLC Memory Leak Test: Implemented on 5x20 and 20x20 LC (TestMemLeaks).

Information About GOLD

The following sections provide details of the GOLD feature:

•Limitations of Existing Logging Mechanism

•Understanding the Importance of GOLD Functionality

•Understanding the GOLD Feature

Limitations of Existing Logging Mechanism

To provide high-availability for a router without any downtime it is imperative to analyze the stability of a system. The primary method of discovering the cause of system failure is system messages. However, there are certain system failures that do not send notifications. It is difficult to understand the cause of these system failures, as the existing logging mechanism fails to notify or maintain a log of these failures.

Understanding the Importance of GOLD Functionality

As there are certain system failures that do not send any notification or keep a log of failure, it is essential to address these limitations. The GOLD feature has been designed specifically to provide error detection by polling for errors for those system modules that do not have any notification mechanism. GOLD has been implemented on the Cisco UBR10012 router to actively poll for system errors. Online diagnostics is one of the requirements for high availability (HA). HA is a a set of quality standards that seeks to limit the impact of equipment failures on the network. A key part of HA is detecting system failures and taking corrective actions while the system is running in a live network.

Understanding the GOLD Feature

The GOLD feature is primarily used to poll for system errors targeted for those components, which do not send a notification upon failure. Although the infrastructure can be used to poll for both hardware and system errors, the main scope is to poll for status and error registers on physical hardware device. The Cisco UBR10012 Router uses a distributed GOLD implementation. In this model, the core Cisco IOS GOLD subsystem is linked on both the route processor (RP) and the cable line cards.

Diagnostic tests can be registered either as local tests which run on the RP or as proxy tests which run on the line cards. When a proxy test is requested on the RP, a command is sent using Inter-Process Communication (IPC) to the line card to instruct it to run the test locally. The results are then returned to the RP using IPC. Tests are specified by card type on a per slot/subslot basis. Diagnostic tests can be run either on bootup, periodically (triggered by a timer), or on demand from the CLI. GOLD feature is managed through a range of commands which are mainly used to provide on-demand diagnostic tests, schedule tests at particular intervals, monitor the system health on periodic basis and to view the diagnostic test results.

Configuring Online Diagnostics

The following sections describe how to configure various types of diagnostics and view test reports:

•Configuring the Bootup Diagnostics Level

•Configuring On-Demand Diagnostics

•Scheduling Diagnostics

•Configuring Health-Monitoring Diagnostics

•Displaying Online Diagnostic Tests and Test Results

Configuring the Bootup Diagnostics Level

You can configure the bootup diagnostics level as minimal or complete or you can bypass the bootup diagnostics entirely. Enter the complete keyword to run all bootup diagnostic tests and the minimal keyword to run minimal tests such as loopback. Enter the no form of the command to bypass all diagnostic tests. The default bootup diagnostics level is minimal.

Note None of the currently implemented tests on the Cisco UBR 10012 Router are bootup tests.

SUMMARY STEPS

1. enable

2. configure terminal

3. diagnostic bootup level {minimal | complete}

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode. Enter your password if prompted.

Step 2 

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3 

Router(config)# diagnostic bootup level {minimal | complete}

Example: 
Router(config)# diagnostic bootup level 
complete

Configures the bootup diagnostic level.

Configuring On-Demand Diagnostics

You can run the on-demand diagnostic tests from the CLI. You can set the execution action to either stop or continue the test when a failure is detected or to stop the test after a specific number of failures occur by using the failure count setting. You can configure a test to run multiple times using the iteration setting.

SUMMARY STEPS

1. enable

2. diagnostic ondemand {iteration iteration_count} | {action-on-error {continue | stop}[error_count]}

3. diagnostic start {bay slot/bay | slot slot-no} test {test-id | test-id-range | all | complete | minimal | non-disruptive}

4. diagnostic stop {bay slot/bay | slot slot-no | subslot slot/subslot}

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode. Enter your password if prompted.

Step 2 

diagnostic ondemand {iteration iteration_count} | {action-on-error {continue | stop}[error_count]}

Example: 
Router# diagnostic ondemand iteration 3

Configures on-demand diagnostic tests to run, how many times to run (iterations), and what action to take when errors are found.

Step 3 

diagnostic start {bay slot/bay | slot slot-no} test {test-id | test-id-range | all | complete | minimal | non-disruptive}

and

diagnostic start {subslot slot/sub-slot} test {test-id | test-id-range | all | complete | minimal | non-disruptive | per-port [port {num | port#-range | all}]}

Example: 
Router# diagnostic start bay 1/0 test 5

Starts the on-demand diagnostic test on the specified bay, slot, or subslot.

Step 4 

diagnostic stop {bay slot/bay | slot slot-no | subslot slot/sub-slot}

Example: 
Router# diagnostic stop bay 1/0

Stops the diagnostic test running on the specified bay, slot, or subslot.

Scheduling Diagnostics

You can schedule online diagnostics to run at a designated time of day or on a daily, weekly, or monthly basis. You can schedule tests to run only once or to repeat at an interval. Use the no form of this command to remove the scheduling.

To schedule online diagnostics, perform this task:

SUMMARY STEPS

1. enable

2. configure terminal

3. diagnostic schedule {bay slot/bay | slot slot-no} test {test-id | test-id-range | all | complete | minimal | non-disruptive} {daily hh:mm | on mm dd year hh:mm | weekly day-of-week hh:mm}

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode. Enter your password if prompted.

Step 2 

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3 

diagnostic schedule {bay slot/bay | slot slot-no} test {test-id | test-id-range | all | complete | minimal | non-disruptive} {daily hh:mm | on mm dd year hh:mm | weekly day-of-week hh:mm}

and

diagnostic schedule {subslot slot/sub-slot} test {test-id | test-id-range | all | complete | minimal | non-disruptive | per-port {daily hh:mm | on mm dd year hh:mm | weekly day-of-week hh:mm | port {{num | port#-range | all}{daily hh:mm | on mm dd year hh:mm | weekly day-of-week hh:mm}}}}

Example:

This example shows how to schedule the diagnostic testing on a specific date and time for a specific bay: 

Router(config)# diagnostic schedule bay 1/0 
test 1 on september 2 2009 12:00

This example shows how to schedule the diagnostic testing to occur daily at a certain time for a specific slot: 

Router(config)# diagnostic schedule slot 1 test 
complete daily 08:00

Schedules on-demand diagnostic tests for a specific date and time, how many times to run (iterations), and what action to take when errors are found.

Configuring Health-Monitoring Diagnostics

You can configure health-monitoring diagnostic testing while the system is connected to a live network. You can configure the execution interval for each health monitoring test, whether or not to generate a system message upon test failure, or to enable or disable an individual test. Use the no form of this command to disable testing.

Note Before enabling the diagnostic monitor test, you first need to set the interval to run the diagnostic test. An error message is displayed if the interval is not configured before enabling the monitoring.

SUMMARY STEPS

1. enable

2. configure terminal

3. diagnostic monitor interval {bay slot/bay | slot slot-no | subslot slot/sub-slot} test {test-id | test-id-range | all} {hh:mm:ss} {milliseconds} {number-of-days}

4. diagnostic monitor {bay slot/bay | slot slot-no | subslot slot/sub-slot} test {test-id | test-id-range | all}

5. diagnostic monitor syslog

6. diagnostic monitor threshold {bay slot/bay | slot slot-no | subslot slot/sub-slot} test {test-id | test-id-range | all} {failure count no-of-allowed-failures}

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode. Enter your password if prompted.

Step 2 

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3 

diagnostic monitor interval {bay slot/bay | slot slot-no | subslot slot/sub-slot} test {test-id | test-id-range | all} {hh:mm:ss} {milliseconds} {number-of-days}

Example:

The following example shows how to configure the periodic interval for running diagnostic tests on the Cisco UBR10012 Router before enabling monitoring: 

Router(config)# diagnostic monitor interval bay 
1/0 test 2 06:00:00 100 10

Configures the health-monitoring interval of the specified tests. The no form of this command will change the interval to the default interval, or zero.

Step 4 

diagnostic monitor {bay slot/bay | slot slot-no | subslot slot/sub-slot} test {test-id | test-id-range | all}

Example:

The following example shows a sample output of an error message displayed when monitoring is enabled before configuring the test interval: 

Router(config)# diagnostic monitor bay 1/0 test 
2

Aug 12 18:04:56.280: 
%DIAG-3-MONITOR_INTERVAL_ZERO: Bay 1/0: 
Monitoring interval

is 0. Cannot enable monitoring for Test #2

Enables or disables health-monitoring diagnostic tests.

Step 5 

diagnostic monitor syslog

Example: 
Router(config)# diagnostic monitor syslog

Enables the generation of a system logging messages when a health-monitoring test fails.

Step 6 

diagnostic monitor threshold {bay slot/bay | slot slot-no | subslot slot/sub-slot} test {test-id | test-id-range | all} {failure count no-of-allowed-failures}

Example: 
Router(config)# diagnostic monitor threshold 
bay 1/0 test 2 failure count 10

Configures the failure threshold value for the bay, slot, or subslot.

Displaying Online Diagnostic Tests and Test Results

You can display the online diagnostic tests that are configured and check the results of the tests using the show commands.

SUMMARY STEPS

1. enable

2. show diagnostic content [all | bay slot/bay | slot slot-no | subslot slot/subslot]

3. show diagnostic result [[bay slot/bay | slot slot-no | subslot slot/subslot] {detail | test {test-id | test-id-range | all}} | all]

4. show diagnostic schedule [all | bay slot/bay | slot slot-no | subslot slot/subslot]

5. show diagnostic events [bay slot/bay | slot slot-no | subslot slot/sub-slot | event-type {error | info | warning}]

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode. Enter your password if prompted.

Step 2 

show diagnostic content [all | bay slot/bay | slot slot-no | subslot slot/subslot]

Example: 
Router# show diagnostic content bay 1/0

Displays the online diagnostics tests and test attributes that are configured.

Step 3 

show diagnostic result [[bay slot/bay | slot slot-no | subslot slot/subslot] {detail | test {test-id | test-id-range | all}} | all]

Example: 
Router# show diagnostic result all

Displays the diagnostic test results (pass, fail, or untested) for a bay, slot, or subslot.

Step 4 

show diagnostic schedule [all | bay slot/bay | slot slot-no | subslot slot/subslot]

Example: 
Router# show diagnostic schedule slot 1

Displays the current scheduled diagnostic tasks.

Step 5 

show diagnostic events [bay slot/bay | slot slot-no | subslot slot/sub-slot | event-type {error | info | warning}]

Example: 
Router# show diagnostic events subslot 5/0

Displays the diagnostic event log details for the specified bay, slot, or subslot.

Supported GOLD Tests on Cisco UBR10012 Router

This section discusses the GOLD test cases that have been implemented on Cisco UBR10012 Router in the Cisco IOS Release 12.2(33)SCC. This section contains the following topics:

•Low Latency Queue (LLQ) Drop Test

•Guardian Index Leak Test

•Memory Leak Test

Low Latency Queue (LLQ) Drop Test

To support the low latency requirements of voice calls the UBR10012 Router uses per interface absolute priority queues. Verifying the drops in the queue is a cumbersome manual process. Because of this, the periodic LLQ Drop test has been implemented to monitor all low latency queues on the box for drops. The test is a non-proxy test case that runs on the RP.

For the specified slot/subslot or slot/bay pair, the test will walk all associated forwarding interfaces legacy, modular, integrated, and wideband and look for drops on the interface low latency queue (if one exists). If drops are found, the test case reports a failure to the GOLD infrastructure and log a system log message with pertinent information.

Note The LLQ Drop test runs on demand with a default period of one (1) hour. It can be configured to run as often as every one minute.

Table 2 provides details regarding the supported hardware, test names, and criteria for displaying the test results.

Table 2 Hardware Support Matrix for LLQ Drop Test

Supported Line Card and SPA
Test Name
Criteria To Display Result

5x20 line card

Test520LLQDrops

For 5x20 line cards, the test returns per port results with a port corresponding to a downstream interface.

20x20 line card

Test2020LLQDrops

For 20x20 line cards, the test returns per port results with a port corresponding to a controller.

Modena SPA

TestModenaLLQDrops

On Modena SPA, the test returns global results.


Guardian Index Leak Test

For remote downstreams using SPAs, the Guardian maintains stat indices for remote service flows, PHS indices for voice flows on NB modems and BPI indices for encrypted modems. The index associations are maintained on the host mac-domain. There could be cases where the service flow has been destroyed or the cable modem has been kicked offline and the corresponding indices have not been de-allocated on the guardian. Any index leaks arising out of corner cases or race conditions would cause the index table to run out of indices which would then prevent any new modems to come online or new service flows to be created.

Periodic GOLD test (TestBlazeIndexLeak) has been introduced for 5x20 line cards to catch these index leaks early. TestBlazeIndexLeak test is a proxy test which runs on the linecard per slot or subslot. The number of Blaze indices are compared on each mac-domain host with the indices allocated by the guardian. If inconsistencies are found, error message is reported on the line card, with the mac-domain host inconsistencies. The error message displays the allocating guardian, the host line card on which the test fails and the margin observed.

Note The TestBlazeIndexLeak test runs on demand with a default period of eight (8) hours.

Table 3 provides details regarding the supported hardware, test names, and criteria for displaying the test results.

Table 3 Hardware Support Matrix for Guardian Index Leak Test

Supported Line Card and SPA
Test Name
Criteria To Display Result

5x20 line card

TestBlazeIndexLeak

For 5x20 line cards, the test returns per port results with a port corresponding to a downstream interface.


Memory Leak Test

As part of health monitoring tests, GOLD test case for detecting memory leaks in IOS have been added. The programmed approach covers potential leaks in IO Buffers and Processor Heap Memory. Most of the approaches to detect memory leak, require human analysis or tool based post-processing of outputs from various show commands. The Memory Leak Test adds a programmatic implementation inside IOS code itself to detect and signal any `sizeable levels of IOS memory leaks' occurring over-time. The TestMemLeaks test case is automatically kick-started by GOLD on both PRE and CLC. One hour after card bootup, the test starts sampling free-memory data every 2 minutes in the background and then after every two hours it generates Leak test results for GOLD.

Test Result Behavior: The GOLD TestMemLeak failures are persistent failures, i.e. if the test fails due to a leak detected during a two hour window, the test fails from here on till card reboot, even if no new leaks were detected during ongoing two-hour sampling window.

Memory: The TestMemLeaks test adds some fixed-size static data-structures that take less than 10KB of fixed memory. To run per-RU-IO-buffer leak test, dynamic List is also allocated to get per-RU-stats, and these list elements are all freed before the test is over.

The Memory Resource Monitoring test case added as TestMemLeaks currently covers the following two approaches:

•Free Memory Trending

•I/O Memory Buffer Hold Accounting

Free Memory Trending

Aggregate level memory leaks can be detected using Free Memory Trending. Free memory trending requires system to get baseline usage numbers after one hour of system boot-up, and collect free memory samples every few minutes. Apply the free memory trending approach after you have enough samples. Periodically keep a watch on trend of free, lowest and largest block levels, by performing:

•Leak Trending check: Size of the Lowest Free Memory, Current Free Memory. Compare these samples to previous values and if all these parameters indicate a gradually leaking memory, and signal it as a test failure. If the following conditions are significantly found to be true, the logic alarms leaking memory.

–FreeBytes of next sample are lower than FreeBytes of previous sample, AND

–Lowest free in this sample is within 10KB bytes of freeBytes; AND

–If lowest free in this sample is lesser than lowest block of previous sample

–If such conditions are found to be true for more than 25% of periodically collected samples, LeakTrend is assumed.

•Lower Threshold Check: Compare the free memory threshold to total memory on the card.

If the above two checks fail, a red flag is raised as an error message that memory on the box has been gradually leaking.

•If Largest Free is less than 1 MB (min. buffer size level for safe allocation) i.e. even if Largest free memory is above risk thresholds but if `Lowest Sized buffer' reaches dangerous levels (like 1MB), then the logic signals memory leak error.

I/O Memory Buffer Hold Accounting

This section discusses, how I/O memory buffer leak scan algorithm works. To detect I/O memory leaks, besides the free-memory trending approach, the buffer life span analysis approach is also considered, where old buffers stored for more than a specified threshold of time are considered leaking. The command show buffers leak resource user displays a detailed summary of buffers that are older than a minute in the system, on a per Resource-User basis.

Note The TestMemLeaks test runs on demand with a default period of two (2) hours.

Table 4 provides details regarding the supported hardware, test names, and criteria for displaying the test results.

Table 4 Hardware Support Matrix for Memory Leak Detection

Supported Line Card and SPA
Test Name
Criteria To Display Result

5x20 line card

TestMemLeaks

Poll, collect, and compare samples of Processor Memory Leak and I/O Memory Buffer leak.

20x20 line card

TestMemLeaks

Poll, collect, and compare samples of Processor Memory Leak and I/O Memory Buffer leak.


How to Manage Diagnostic Tests

This section describes how to manage the diagnostic tests. The following GOLD commands are used to to manage the ondemand and periodic diagnostic tests:

SUMMARY STEPS

1. diagnostic ondemand

2. show diagnostic ondemand

3. diagnostic start {bay | slot | subslot}

4. show diagnostic content

5. show diagnostic result

6. show diagnostic events

7. diagnostic stop {bay | slot | subslot}

8. configure terminal

9. diagnostic bootup level {minimal | complete}

10. show diagnostic bootup level

11. diagnostic event-log size size

12. diagnostic monitor interval {bay slot/bay | slot slot-no | subslot slot/subslot} test {test-id | test-id-range | all} hh:mm:ss milliseconds days

13. diagnostic schedule module {module-number | slot/subslot} test {test-id | all | complete | minimal | non-disruptive | per-port}

14. show diagnostic schedule

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

diagnostic ondemand

Example:

Router# diagnostic ondemand iteration 50

Configures the ondemand diagnostic parameters such as iteration-count and action-on-error. These parameters signify the number of times the test is run and the execution action when a failure is detected. These parameters are used when the command diagnostic start is executed. In the given example, the iteration count to the same ondemand diagnostic test again is configured as 50.

Note By default, iteration-count is 1, action-on-error is continue, and error count is 0.

Step 2 

show diagnostic ondemand settings

Example:

Router# show diagnostic ondemand settings

Displays the ondemand diagnostic settings configured using the command diagnostic ondemand.

Step 3 

diagnostic start {bay slot/bay | slot slot-no} test {test-id | test-id-range | all | complete | minimal | non-disruptive}

Example:

Router# diagnostic start bay 1/0 test 1 all

Starts an ondemand diagnostic test.

•bay slot/bay—Indicates the card slot and bay number where the diagnostic test is executed. The bay keyword is used to refer a SPA on the router. The valid range for the slot number is from 1 to 8 and 0 to 3 for the bay number.

•slot slot-no—Indicates the slot number of the full-height line card where the diagnostic test is executed. The slot keyword is used to refer a full-height line card on the router. The valid range for slot is from 1 to 8.

•subslot slot/sub-slot—Indicates the slot and subslot number of half-height line card where the diagnostic test is executed. The subslot keyword is used to refer a half-height line card on the router. The valid range for the slot number is from 1 to 8 and 0 to 1 for the subslot number.

•test— Specifies a test to run.

•test-id—Identification number for the test to run.

•test-id-range—Range of identification numbers for tests to run.

•minimal—Runs minimal bootup diagnostic tests.

•complete—Runs complete bootup diagnostic tests.

•non-disruptive—Runs the non disruptive health-monitoring tests.

•all—Runs all diagnostic tests.

Step 4 

show diagnostic content

Example:

Router# show diagnostic content

Displays the registered tests, attributes, and the configured interval at which the test runs.

Note To view the registered test details for a specific SPA, full-height line card, or half-height line-card, use the keywords bay, slot, or subslot.

Step 5 

show diagnostic result

Example:

Router# show diagnostic result

Displays the diagnostic test results for a SPA, full-height line card, or half-height line card.

Step 6 

show diagnostic events

Example:

Router# show diagnostic events

Displays the diagnostic event log details for all the SPAs, full-height line card, and half-height line cards installed on the Cisco UBR10012 Router.

Step 7 

diagnostic stop {bay slot/bay | slot slot-no} test {test-id | test-id-range | all | complete | minimal | non-disruptive}

Example:

Router# diagnostic stop bay 1/0 all

Stops the ondemand diagnostic test.

Step 8 

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 9 

diagnostic bootup level {minimal | complete}

Example:

Router(config)# diagnostic bootup level complete

Configures the bootup diagnostic level.

•minimal—Specifies minimal diagnostics.

•complete—Specifies complete diagnostics.

Step 10 

show diagnostic bootup level

Example:

Router# show diagnostic bootup

Displays the configured bootup diagnostic level.

Step 11 

diagnostic event-log size size

Example:

Router(config)# diagnostic event log size 10000

Modifies the diagnostic event log size dynamically.

•size—Diagnostic event-log sizes. The valid values range from 1 to 10000 entries.

Step 12 

diagnostic monitor interval {bay slot/bay | slot slot-no} | subslot slot/subslot} test {test-id | test-id-range | all} hh:mm:ss milliseconds days

Example:

Router(config)# diagnostic monitor interval bay 1/0 test 2 06:00:00 100 20

Configures the health monitoring diagnostic test interval to rerun the tests.

•hh:mm:ss—Hours, minutes, and seconds interval configured to run the test again.

•milliseconds—Number of milliseconds between tests.

•days—Number of days between tests. The valid range is from 0 to 20.

Step 13 

diagnostic schedule module {module-number | slot/subslot} test {test-id | all | complete | minimal | non-disruptive | per-port}

Example:

Router(config)# diagnostic schedule slot 1 test complete daily 08:00

Schedules the online diagnostic test to run at a designated time, or on daily, weekly or monthly basis.

•module-number—Specifies the module number.

•per-port—Selects the per-port test suite.

Step 14 

show diagnostic schedule

Example:

Router# show diagnostic schedule

Displays the current scheduled diagnostic tests.

Configuration Examples for GOLD Feature

The following example shows a sample output of the test configuration, test attributes, and the supported coverage test levels for each test and for each bay/slot/subslot: 

Slot 1: 2jacket-1

  Diagnostics test suite attributes:

    M/C/* - Minimal bootup level test / Complete bootup level test / NA

      B/* - Basic ondemand test / NA

    P/V/* - Per port test / Per device test / NA

    D/N/* - Disruptive test / Non-disruptive test / NA

      S/* - Only applicable to standby unit / NA

      X/* - Not a health monitoring test / NA

      F/* - Fixed monitoring interval test / NA

      E/* - Always enabled monitoring test / NA

      A/I - Monitoring is active / Monitoring is inactive

                                                                    Test Interval

  ID   Test Name                                    Attributes      day hh:mm:ss.

  ==== ============================================ ============    =============

    1) TestJacketSample --------------------------> ***N****I       not configured  n/a

        Bay 1/0: 2jacket-1

          Diagnostics test suite attributes:

            M/C/* - Minimal bootup level test / Complete bootup level test / NA

              B/* - Basic ondemand test / NA

            P/V/* - Per port test / Per device test / NA

            D/N/* - Disruptive test / Non-disruptive test / NA

              S/* - Only applicable to standby unit / NA

              X/* - Not a health monitoring test / NA

              F/* - Fixed monitoring interval test / NA

              E/* - Always enabled monitoring test / NA

              A/I - Monitoring is active / Monitoring is inactive

                                                                            Test

 Interval

          ID   Test Name                                    Attributes      day

hh:mm:ss.

          ==== ============================================ ============    ====

=========

            1) TestModenaSample --------------------------> ***N****I       not configured  
n/a

            2) TestModenaLLQDrops ------------------------> ***N****A       000 
01:00:00.00 1

Additional References

For additional information related to health monitoring, see the following references:

Related Documents

Related Topic
Document Title

CMTS commands

Cisco IOS CMTS Cable Command Reference

System Event Archive (SEA)

SEA feature for the Cisco UBR10012 Router


Standards

Standards
Title

No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.

—


MIBs

MIBs
MIBs Link

No new or modified MIBs are supported by this feature, and support for existing MIBs has not been modified by this feature.

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

http://www.cisco.com/go/mibs


RFCs

RFCs
Title

No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.

—


Technical Assistance

Description
Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

http://www.cisco.com/support


Feature Information for GOLD for the Cisco CMTS Routers

Table 5 lists the release history of this feature.

Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.

Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.

Note Table 5 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release. Unless noted otherwise, subsequent releases of that Cisco IOS software release also support that feature.

Table 5 Feature Information for GOLD for the Cisco CMTS Routers

Feature Name
Releases
Feature Information

Generic Online Diagnostic (GOLD) subsystem support for the Cisco CMTS Routers

12.2(33)SCC

GOLD is a health monitoring feature implemented to run diagnostic tests and poll for system components, which do not generated errors. This feature was introduced for the MC5x20, MC20x20 cable line cards, Modena SPA, Jacket cards, PRE2, and PRE4 route processors.

The following commands are new or modified:

•diagnostic start

•diagnostic stop

•diagnostic ondemand

•show diagnostic bootup

•show diagnostic content

•show diagnostic description

•show diagnostic events

•show diagnostic ondemand

•show diagnostic result

•show diagnostic schedule

•diagnostic bootup

•diagnostic event-log

•diagnostic monitor

•diagnostic schedule


Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2009 Cisco Systems, Inc. All rights reserved.