Cisco MDS-9124 Troubleshooting Guide - Page 52

Disruptive Module Upgrades Chapter 2 Troubleshooting Installs, Upgrades, and Reboots Send documentation comments to [email protected] Guidelines for Reboots Cisco SAN-OS allows for three different types of system restarts: • Recoverable-A process restarts and service is not affected. • Unrecoverable-A process has restarted more than the maximum restart times within a fixed period of time (seconds) and will not be restarted again. • System hung/crashed-No communications of any kind is possible with the system. Schedule the reboot to avoid possible disruption of services during critical business hours. Note Log messages are not saved across system reboots. However, a maximum of 100 log messages with a severity level of critical and below (levels 0, 1, and 2) are saved in NVRAM. You can view this log at any time with the show logging nvram CLI command. Disruptive Module Upgrades Software upgrades for the SSM, MPS-14/2, MSM-18/4 module, or the IP Storage (IPS) services modules are disruptive. These modules use a rolling upgrade install mechanism where the modules are upgraded in sequence. After the first module upgrade finishes, and before the next module upgrade begins, Cisco SAN-OS introduces a time delay to ensure that all applications in the module reach a steady state. The IPS modules require a five-minute delay before the next IPS module upgrade can guarantee a stable state. SSM supports nondisruptive upgrades for the Layer 1 and Layer 2 protocols under the following conditions: • SSM is running Cisco SAN-OS Release 2.1(2) or later and upgrading to a later release. • The SSM hardware has the ELPD image for Release 2.1(2) installed. Use the show version module epld CLI command, and verify that the epld version is 0x07 or later. • You have turned off all Layer 3 services on the SSM by deprovisioning the DPPs for Layer 3 service. Troubleshooting a Nondisruptive Upgrade on a Fabric Switch When a nondisruptive upgrade begins, the system notifies all services that an upgrade is about to start, and finds out whether or not the upgrade can proceed. If a service cannot allow the upgrade to proceed at this time (for example, FSPF timers are not configured to the default value, or a CFS operation is in progress), then the service will abort the upgrade. If this occurs, you will be prompted to enter the show install all failure-reason command to determine the reason why the upgrade cannot proceed. ... Do you want to continue with the installation (y/n)? [n] y Install is in progress, please wait. Notifying services about the upgrade. [# ] 0% -- FAIL. Return code 0x401E0066 (request timed out). Please issue "show install all failure-reason" to find the cause of the failure.