Extreme Networks ExtremeWare 7.5, Command Reference Manual

Page: 706 / 2546

706 ExtremeWare 7.5 Command Reference Guide
Commands for Status Monitoring and Statistics
The
auto-recovery
option configures the number of times the system health checker attempts to
automatically reset a faulty module and bring it online. If the system health checker fails more than the
configured number of attempts, it sets the module to card-down.
NOTE
This threshold applies only to BlackDiamond I/O modules.
In ExtremeWare 6.2.1 or later, when auto-recovery is configured, the occurrence of three consecutive
checksum errors causes the packet memory (PM) defect detection program to be run against the I/O
module. Checksum errors may include internal and external MAC port parity errors, EDP checksum
errors, and CPU packet or diagnostic packet checksum errors. If defects are detected, the module is
taken offline, the memory defect information is recorded in the module EEPROM, the defective buffer is
mapped out of further use, and the module is returned to operational state. A maximum of 8 defects
can be stored in the EEPROM.
After the PM defect detection and mapping process has been run, a module is considered failed and is
taken offline in the following circumstances:
•
More than eight defects are detected.
• Three consecutive checksum errors were detected by the health checker, but no new PM defects were
found by the PM defect detection process.
•
After defects were detected and mapped out, the same checksum errors are again detected by the
system health checker.
The auto-recovery repetition value is ignored in these cases. In any of these cases, please contact
Extreme Technical Support.
If you specify the
online
option, the module is kept online, but the following error messages are
recorded in the log:
<WARN:SYST> card_db.c 832: Although card 2 is back online, contact Tech. Supp. for
assistance.
<WARN:SYST> card_db.c 821: Card 2 has nonrecoverable packet memory defect.
To view the status of the system health checker, use the
show diagnostics
command.
To enable the health checker, use the
enable sys-health-check
command.
To disable the health checker, use the
disable sys-health-check
command.
The alarm-level
system-down
option is especially useful in an ESRP configuration where the entire
system is backed by an identical system. By powering down the faulty system, you ensure that erratic
ESRP behavior in the faulty system does not affect ESRP performance and ensures full system failover
to the redundant system.
If you are using ESRP with ESRP diagnostic tracking enabled in your configuration, the system health
check failure will automatically reduce the ESRP priority of the system to the configured failover
priority. This allows the healthy standby system to take over ESRP and become responsible for handling
traffic.
I/O module faults are permanently recorded on the module’s EEPROM. A module that has failed a
system health check cannot be brought back online.