Configuring On-Demand Online Diagnostics
You can run the on-demand online 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.
You should run packet-switching tests before memory tests. Run the memory tests on the other modules before running them on the supervisor engine.
Note Do not use the diagnostic start all command until all of the following steps are completed.
Because some on-demand online diagnostic tests can affect the outcome of other tests, you should perform the tests in the following order:
1. Run the non-disruptive tests.
2. Run all tests in the relevant functional area.
3. Run the TestTrafficStress test.
4. Run the TestEobcStressPing test.
5. Run the exhaustive memory tests.
To run on-demand online diagnostic tests, perform this task:
Step 1 Run the non disruptive tests.
To display the available tests and their attributes, and determine which commands are in the non disruptive category, enter the show diagnostic content command.
Step 2 Run all tests in the relevant functional area.
Packet-switching tests fall into specific functional areas. When a problem is suspected in a particular functional area, run all tests in that functional area. Not all functional areas are present on each module. If you are unsure about which functional area you need to test, or if you want to run all available tests, enter the complete keyword.
Step 3 Run the TestTrafficStress test.
This is a disruptive packet-switching test that is only available on the supervisor engine. This test switches packets between pairs of ports at line rate for the purpose of stress testing. During this test all of the ports are shut down, and you may see link flaps. The link flaps will not recover after the test is complete. The test takes several minutes to complete.
Disable all health-monitoring tests for the module being tested before running this test by using the no diagnostic monitor module module test all command.
Step 4 Run the TestEobcStressPing test.
This is a disruptive test and tests the Ethernet over backplane channel (EOBC) connection for the module. The test takes several minutes to complete. You cannot run any of the packet-switching tests described in previous steps after running this test. However, you can run tests described in subsequent steps after running this test.
Disable all health-monitoring tests for the module being tested before running this test by using the no diagnostic monitor module module test all command. The EOBC connection is disrupted during this test and will cause the health-monitoring tests to fail and take recovery action.
Step 5 Run the exhaustive-memory tests.
All modules have exhaustive memory tests available on them. Because the supervisor engine goes into an unusable state and must be rebooted after the exhaustive memory tests, run the tests on all other modules first. Some of the exhaustive memory tests can take several hours to complete because of the large memory size of the modules.
Before running the exhaustive memory tests, all health-monitoring tests should be disabled on the module that will run the exhaustive memory tests because the tests will fail with health monitoring enabled and the switch will take recovery action. Disable the health-monitoring diagnostic tests by using the no diagnostic monitor module module test all command.
Perform the exhaustive memory tests in the following order (you can skip any tests not available for a particular module):
1. TestFibTcamSSRAM
2. TestAclQosTcam
3. TestNetFlowTcam
4. TestAsicMemory
5. TestAsicMemory
You must reboot the supervisor engine after running the exhaustive memory tests before it is operational again. You cannot run any other tests on the supervisor engine or other modules after running the exhaustive memory tests. Do not save the configuration when rebooting as it will have changed during the tests. You will need to power cycle the modules before they can be operational. After a module comes back on line, reenable the health monitoring tests using the diagnostic monitor module module test all command
To set the bootup diagnostic level, perform this task:
|
|
Router#
diagnostic ondemand {iteration
iteration_count
} | {
action-on-error {continue | stop
}[
error_count
]}
|
Configures on-demand diagnostic tests to run, how many times to run (iterations), and what action to take when errors are found.
|
This example shows how to set the on-demand testing iteration count:
Router# diagnostic ondemand iteration 3
This example shows how to set the execution action when an error is detected:
Router# diagnostic ondemand action-on-error continue 2
Router#
Scheduling Online Diagnostics
You can schedule online diagnostics to run at a designated time of day or on a daily, weekly, or monthly basis for a specific module. 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:
|
|
Router(config)#
diagnostic schedule
{
module
num
}
test
{
test_id
|
test_id_range
|
all
} [
port
{
num
|
num_range
|
all
}] {
on
mm
dd
yyyy
hh
:
mm
} | {
daily
hh
:
mm
} | {
weekly
day_of_week
hh
:
mm
}
|
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.
|
This example shows how to schedule diagnostic testing on a specific date and time for a specific module and port:
Router(config)# diagnostic schedule module 1 test 1,2,5-9 port 3 on january 3 2003 23:32
This example shows how to schedule diagnostic testing to occur daily at a certain time for a specific port and module:
Router(config)# diagnostic schedule module 1 test 1,2,5-9 port 3 daily 12:34
This example shows how to schedule diagnostic testing to occur weekly on a certain day for a specific port and module:
Router(config)# diagnostic schedule module 1 test 1,2,5-9 port 3 weekly friday 09:23
Configuring Health-Monitoring Diagnostics
You can configure health-monitoring diagnostic testing on specified modules while the router 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.
To configure health monitoring diagnostic testing, perform this task:
|
|
|
Step 1
|
Router(config)#
diagnostic monitor interval
{
module
num
}
test
{
test_id
|
test_id_range
|
all
}
[
hour
hh
] [
min
mm
] [
second
ss
] [
millisec
ms
] [
day
day
]
|
Configures the health-monitoring interval of the specified tests for the specified module. The no form of this command will change the interval to the default interval, or zero.
|
Step 2
|
Router(config)#[no] diagnostic monitor {module
num
} test {
test_id
|
test_id_range
| all}
|
Enables or disables health-monitoring diagnostic tests.
|
This example shows how to configure the specified test to run every two minutes:
Router(config)#
diagnostic monitor interval module 1 test 1 min 2
This example shows how to run the test on the specified module if health monitoring has not previously been enabled:
Router(config)#
diagnostic monitor module 1 test 1
This example shows how to enable the generation of a syslog message when any health monitoring test fails:
Router(config)#
diagnostic monitor syslog