Cisco Nexus 5020 Switch Installation Guide

Cisco Nexus 5500 Series NX-OS Software

Upgrade and Downgrade Guide, Release

7.1(0)N1(1a)

First Published: January 29, 2014

Last Modified: January 09, 2015

This document describes how to upgrade or downgrade Cisco NX-OS software on Cisco Nexus 5500

Series switches and Cisco Nexus 2000 Series Fabric Extenders. Use this document in combination with documents listed in the

“Obtaining Documentation and Submitting a Service Request” section on page 41

.

This document includes these sections:

•

•

•

•

•

Information About Software Images, page 2

Supported Hardware, page 2

Upgrade Guidelines, page 3

Using the Install All Command, page 4

•

•

•

•

Upgrading the BIOS and Power Sequencer Images, page 5

Impact of Upgrades and Downgrades, page 5

Upgrading Procedures, page 21

Disruptive Installation Process, page 30

•

Forcing an Upgrade, page 30

Upgrading from Cisco NX-OS Release 5.1(3)N2(1c) and Earlier Releases (Disruptive Upgrade), page 31

•

•

•

•

•

Minimizing the Impact of a Disruptive Upgrade, page 36

Monitoring the Upgrade Status, page 38

Downgrading from a Higher Release, page 39

Troubleshooting ISSUs and Disruptive Installations, page 40

Obtaining Documentation and Submitting a Service Request, page 41

Americas Headquarters:

Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA

Information About Software Images

Information About Software Images

Cisco Nexus devices are shipped with the Cisco NX-OS software preinstalled on the switches. Before you upgrade or downgrade from an existing image, you should read through the information in this document to understand the guidelines, prerequisites, and procedures for upgrading the software. For updated information about the Cisco NX-OS software for the Cisco Nexus device, see the Release Notes for your platform.

The Cisco NX-OS software consists of the kickstart image and the system image. The system image includes the software for the Cisco Nexus device and the Cisco Nexus Fabric Extenders (FEXs) that are connected to the switch. The images contain a major release identifier, a minor release identifier, and a maintenance release identifier. The images might also contain a rebuild identifier, which can be referred to as a support patch. The following figure shows the version identifiers that are used with a combination of platform-independent and platform-dependent schemes for the Cisco NX-OS software.

Figure 1 Cisco NX-OS Version Identifies

The platform designator is N for the Cisco Nexus device. Applicable features, functions, and fixes in the platform-independent code are present in the platform-dependent release.

Supported Hardware

Cisco Nexus devices are shipped with the Cisco NX-OS software preinstalled.

Cisco Nexus 5500 Platform Switches and Associated Expansion Modules

•

•

•

•

•

•

•

Cisco Nexus 5596UP

Cisco Nexus 5596T

Cisco Nexus 5548UP

Cisco Nexus 5548P

N55-M16P

N55-M16UP

N55-M8P8FP

2

Cisco Nexus 5500 Series NX-OS Software Upgrade and Downgrade Guide, Release 7.1(0)N1(1a)

Upgrade Guidelines

Upgrade Guidelines

When upgrading system software, follow these guidelines:

• Configuration changes

You cannot enter global configuration mode during an upgrade. You should save, commit, or discard any active configuration sessions before you upgrade or downgrade the Cisco NX-OS software image. The active configuration session is deleted without a warning during a reload.

Use the show configuration session summary command to verify that there are no active configuration sessions.

switch# show configuration session summary

There are no active configuration sessions

For more information on configuration sessions, see the System Management Configuration Guide for your platform.

Note CLI and SNMP configuration change requests are denied during an in-service software upgrade (ISSU).

•

•

•

•

•

•

•

•

Topology—You should make topology changes, such as Spanning Tree Protocol (STP) or Fiber

Channel (FC) fabric changes, that affect zoning, Fabric Shortest Path First (FSPF), or FC domains before you perform an upgrade. You should perform module installations or removals only before or after an upgrade.

Scheduling—You should upgrade when your network is stable and steady. Ensure that everyone who has access to the switch or the network is not configuring the switch or the network during this time.

You cannot configure a switch during an upgrade.

Space—Verify that sufficient space is available in the location where you are copying the images.

The internal bootflash requires approximately 200 MB of free space.

Hardware—Avoid power interruptions during an installation procedure. Power interruptions can corrupt the software image.

Connectivity to remote servers—Configure the IPv4 address or IPv6 address for the 10/100/1000

BASE-T Ethernet port connection (interface mgmt0). Ensure that the switch has a route to the remote server. The switch and the remote server must be in the same subnetwork if you do not have a router to route traffic between subnets.

Software image—Ensure that the specified system and kickstart images are compatible with each other as follows:

–

–

If the kickstart image is not specified, the switch uses the current running kickstart image.

If you specify a different system image, ensure that it is compatible with the running kickstart image.

Retrieve compatible images in one of two ways:

– Locally—Images are locally available on the switch.

– Remotely—Images are in a remote location and you specify the destination by using the remote server parameters and the filename to be used locally.

Command—Use the following commands to prepare for and install the new software:

– Use the ping command to verify connectivity to the remote server.


3

Using the Install All Command

– Use the dir command to verify that the required space is available for the image files to be copied.

– Use the show install all impact command to identify the upgrade impact. This command displays information that describes the impact of the upgrade on each Cisco Nexus Fabric

Extender such as the current and upgrade-image versions. This command also displays if the upgrade is disruptive or the reason why the upgrade is disruptive, if the Cisco Nexus Fabric

Extender needs to be rebooted, and the reason why it needs to be rebooted.

Note We recommend that you log in to the console port to begin the upgrade process. In virtual port channel (vPC) topologies, you should start with the device that is the primary device.

• Terminology

Table 1 summarizes the terms used in the

install all command output to verify module and software image compatibility.

Table 1

Term bootable

Impact

Install-type

Reason show install all impact Command and Output Terminology

Definition

Ability of the module to boot or not boot based on image compatibility.

Type of software upgrade mechanism—disruptive or nondisruptive. reset—Resets the module.

sw-reset—Resets the module immediately after a switchover.

rolling—Upgrades each module in sequence.

copy-only—Updates the software for BIOS, loader, or boot ROM.

Incompatible image—The new upgrade image is not ISSU compatible with the current image.

Using the Install All Command

The install all command triggers an ISSU on Cisco Nexus devices and Cisco Nexus Fabric Extenders.

The following images are upgraded during the installation:

• Kickstart image

•

•

•

•

System image

Fabric Extender image

System BIOS

Power sequencers on the system

The install-all command provides the following benefits:

• You can upgrade the Cisco Nexus devices and the Cisco Nexus Fabric Extenders using just one command.

•

•

You can receive descriptive information about the intended changes to your system before you continue with the installation. For example, it identifies potential disruptive upgrades.

You can continue or cancel the upgrade when you see this question (the default is no):

Do you want to continue (y/n) [n] : y


4

Upgrading the BIOS and Power Sequencer Images

•

•

•

•

•

•

You can upgrade the Cisco NX-OS software using a nondisruptive procedure, when supported.

The command automatically checks the image integrity, which includes the running kickstart and system images. The command sets the kickstart and system boot variables.

The command performs a platform validity check to verify that a wrong image is not used.

Pressing Ctrl-C gracefully ends the install all command. The command sequence completes the update step in progress and returns to the EXEC prompt.

After entering the install all command, if any step in the sequence fails, the upgrade ends.

The following message appears to warn you about the impact of upgrading the power sequencer:

Warning: please do not remove or power off the module at this time.

Note: Power-seq upgrade needs a power-cycle to take into effect.

Note After a successful power sequence upgrade, you must switch off the power to the system and then power it up.

• You can enter the force keyword to perform a disruptive upgrade. For information on forcing an upgrade, see

“Forcing an Upgrade” section on page 30 .

Upgrading the BIOS and Power Sequencer Images

Changes to BIOS and power sequencers are rare; however, when they occur, they are included in the

Cisco NX-OS system image, and the BIOS and power sequencer are upgraded. The summary displayed by the installer during the installation process indicates the current version of the BIOS and power sequencer and the target version.

Note After a successful power sequence upgrade, you must switch off the power to the system and then power it up.

Impact of Upgrades and Downgrades

Cisco NX-OS supports in-service software upgrades (ISSUs) that allow a Cisco Nexus device and any connected FEXs to be upgraded without any traffic disruption (with a brief control plane disruption). A few conditions have to be met for the system to be upgraded through an ISSU process—the access layer topology should be ISSU compliant, the current and target versions should be ISSU capable, and the network should be stable.

If the conditions required for an ISSU are not met or if you intend to downgrade the software version, the installation process is disruptive. For example, the Cisco Nexus device and any connected FEXs are rebooted, which causes a disruption. If Cisco’s virtual port channel (vPC) is configured on Cisco Nexus devices, it is possible to achieve an upgrade/downgrade with very minimal traffic disruption to servers/hosts.


5

In-Service Software Upgrades

Table 2

Current Cisco NX-OS Release

7.0(5)N1(1a)

7.0(5)N1(1)

7.0(4)N1(1)

7.0(3)N1(1)

Upgrade/Downgrade Impact

Upgrade to NX-OS Release

7.1(0)N1(1a)

Downgrade from NX-OS Release

7.1(0)N1(1a)

Nondisruptive upgrade (ISSU) Disruptive downgrade.

Note Doing a disruptive upgrade between incompatible images will result in loss of certain configurations such as unified ports, breakout, and FEX configurations. See CSCul22703 for details.


With a single supervisor system such as the Cisco Nexus device, an ISSU on the Cisco Nexus device causes the supervisor CPU to reset and load the new software version. The control plane is inactive, but the data plane keeps forwarding packets that lead to an upgrade with no service disruption. After the

CPU loads the updated version of Cisco NX-OS, the system restores the control plane to a previously known configuration and the runtime state and the data plane are synchronized. Because the data plane keeps forwarding packets while the control plane is upgraded, any servers that are connected to the Cisco

Nexus device access layer should see no traffic disruption.

ISSU and Layer 3

Cisco Nexus devices support Layer 3 functionality. However, the system cannot be upgraded with the

ISSU process (nondisruptive upgrade) when Layer 3 is enabled. You must unconfigure all Layer 3 features to be able to upgrade in a nondisruptive way with an ISSU. You must remove the Layer 3 license.

ISSU Supported Topologies

This section includes the following topics:

•

•

•

•

•

•

•

•

•

•

ISSU Support For Cisco Nexus Fabric Extenders, page 7

ISSU Support for vPC Topologies, page 7

ISSU Support for vPC Topologies with Fabric Extenders, page 8

ISSU Support with Fibre Channel and FCoE Topologies, page 9

Summary of ISSU-Supported Topologies, page 9

Summary of ISSU Unsupported Topologies, page 12

Management Services After an ISSU, page 16

Fibre Channel/FCoE Protocol and Services During an ISSU, page 16

Layer-2 Protocols Impact, page 18

Ethernet Interfaces on the Switch and the Fabric Extenders, page 18


6


ISSU Support For Cisco Nexus Fabric Extenders

Cisco Nexus Fabric Extenders act as line cards to Cisco Nexus devices. The Fabric Extenders add flexibility to the data center networking infrastructure by decoupling the physical and logical (Layer 2) topology, reducing the operation expense by lowering management and troubleshooting points, and building a larger Layer 2 fabric that is loopfree, with a single layer of switching.

The ISSU process initiated on the Cisco Nexus devices upgrades the entire access layer including the switch and the FEXs that are connected to the switch.

An ISSU first upgrades the switches. Once the switch is operational with the upgraded software, the

FEXs are upgraded. The FEX upgrades are done one FEX at a time. An upgrade of the Cisco Nexus

Fabric Extenders is nondisruptive, which is similar to the upgrade of the switch.

The time required for an ISSU to complete depends on the number of FEXs that are connected. You should plan a maintenance window with the total upgrade time in mind. The entire upgrade is nondisruptive and is not expected to cause any outage to connected servers.

ISSU Support for vPC Topologies

An ISSU is completely supported when two switches are paired in a vPC configuration. In a vPC configuration, one switch functions as a primary switch and the other switch functions as a secondary switch. They both run the complete switching control plane but coordinate forwarding decisions to have optimal forwarding to devices at the other end of the vPC. Additionally, the two devices appear as a single device that supports EtherChannel (static and 802.3ad) and provide simultaneously data forwarding services to that device.

While upgrading devices in a vPC topology, you should start with the switch that is the primary switch.

The vPC secondary device should be upgraded after the ISSU process completes successfully on the primary device. The two vPC devices continue their control plane communication during the entire ISSU process (except when the ISSU process resets the CPU of the switch being upgraded).

This example shows how to determine the vPC operational role of the switch: switch-2# show vpc brief

Legend:

(*) - local vPC is down, forwarding via vPC peer-link vPC domain id : 668

Peer status : peer adjacency formed ok vPC keep-alive status : peer is alive

Configuration consistency status : success

Per-vlan consistency status : success

Type-2 consistency status : success vPC role : primary

Number of vPCs configured : 70

Peer Gateway : Disabled

Dual-active excluded VLANs : -

Graceful Consistency Check : Enabled

Auto-recovery status : Enabled (timeout = 240 seconds) vPC Peer-link status

You can monitor the status of an ISSU on the primary device, after the primary switch reloads by using the show install all status command.

Any attempt to initiate an upgrade on the vPC peer switch when an ISSU is in progress on the other switch is blocked.


7


Note During an upgrade, the configuration on peer switches is locked and the vPC state on vPC peer switches is suspended until the upgrade is complete.

Verifying the vPC Status on a Peer Switch During an Upgrade

To view the vPC status, enter the show vpc command on a peer switch as follows: switch-2# show vpc

Legend:

(*) - local vPC is down, forwarding via vPC peer-link vPC domain id : 668

Peer status : peer adjacency formed ok vPC keep-alive status : peer is alive

Configuration consistency status : success

Per-vlan consistency status : success

Type-2 consistency status : success vPC role : primary

Number of vPCs configured : 70

Peer Gateway : Disabled

Dual-active excluded VLANs : -

Graceful Consistency Check : Enabled

Auto-recovery status : Enabled (timeout = 240 seconds) vPC Peer-link status

--------------------------------------------------------------------id Port Status Active vlans

-- ---- ------ --------------------------------------------------

1 Po501 up 1,1009-1029,2000-2002,2008-2020 switch-1# 2014 Jan 24 13:56:38 switch-1 %$ VDC-1 %$ %VPC-2-VPC_ISSU_START: Peer vPC switch

ISSU start, locking configuration

2014 Jan 24 12:31:37 switch-1 %VPC-2-PEER_KEEP_ALIVE_SEND_FAIL: In domain 668, V

PC peer keep-alive send has failed

Viewing System Messages on Peer Switches

A keepalive message, such as the following, might appear on a peer switch during an upgrade:

2014 Jan 24 12:31:38 switch-1 %VPC-2-PEER_KEEP_ALIVE_RECV_FAIL: In domain 668, VPC peer keep-alive receive has failed

Installation status messages, such as the following, might appear on peer switches as the primary switch is upgraded.

2014 Jan 24 13:58:20 %SATCTRL-FEX126-2-SATCTRL_IMAGE: FEX126 Image update in progress.

2014 Jan 24 14:06:40 switch-1 %$ VDC-1 %$ %SATCTRL-FEX126-2-SATCTRL_IMAGE: FEX126 Image update complete. Install pending

ISSU Support for vPC Topologies with Fabric Extenders

An ISSU is supported in vPC topologies that include FEXs that are connected in dual-homed topologies to a parent switch and when the FEX is in a single-homed topology.

8



ISSU Support with Fibre Channel and FCoE Topologies

ISSUs are supported on access layer switches when Fibre Channel and Fibre Channel over Ethernet

(FCoE) is enabled. You must ensure that the FC fabric is stable before initiating an ISSU in this topology.

Summary of ISSU-Supported Topologies

Figure 2 shows an access switch topology.

Figure 2 Access Switch Topology

Aggregation

Cisco Nexus

Device

Figure 3 shows a vPC peering topology.

Figure 3 vPC Peering Topology

Aggregation

Cisco Nexus

Device

Cisco Nexus

Device

Figure 4 shows a virtual modular system with static fabric connectivity for FEXs.


9


Figure 4 Virtual Modular System with Static Fabric Connectivity for FEXs

Cisco Nexus Device

Cisco Nexus

Fabric Extender

Cisco Nexus

Fabric Extender

Hosts Hosts

Figure 5

shows a vertical modular system.

Figure 5 Vertical Modular System

Cisco Nexus Device

Cisco Nexus

Fabric Extender

Cisco Nexus

Fabric Extender

Hosts Hosts

Figure 6

shows a vPC-peered dual-supervisor virtual modular system with dual-homed FEXs.

10



Figure 6 vPC-Peered Dual-Supervisor Virtual Modular System Dual-Homed FEXs

Aggregation

Cisco Nexus

Device

Cisco Nexus

Fabric Extender

Cisco Nexus

Device

Cisco Nexus

Fabric Extender

Figure 7 figure shows a vPC-peered dual-supervisor virtual modular system with dual-homed and

single-homed FEXs.

Figure 7 vPC-Peered Dual-Supervisor Virtual Modular System Dual-Homed and Single-Homed

FEXs

Aggregation

Cisco Nexus

Device

Cisco Nexus

Fabric Extender

Cisco Nexus

Device

Cisco Nexus

Fabric Extender

Figure 8 shows a vPC-peered dual-supervisor virtual modular system with dual-homed FEXs.


11


Figure 8 vPC Peered Dual-Supervisor Virtual Modular System Dual-Homed FEXs

Aggregation

Cisco Nexus

Device

Cisco Nexus

Device

Cisco Nexus

Fabric Extender

Cisco Nexus

Fabric Extender

Summary of ISSU Unsupported Topologies

Two important spanning tree-related requirements for a Cisco Nexus device that is undergoing an ISSU are as follows:

• STP-enabled switches cannot be present downstream to the switch undergoing an ISSU.

• You cannot configure the STP Bridge Assurance feature except on a vPC peer link. Bridge

Assurance is enabled when you configure an interface as a spanning-tree port type network.

A switch that is undergoing an ISSU has an inactive control plane while the switch is reset and the new software version is loaded. Not following these restrictions could render the network unstable if there are any unexpected topology changes

If the STP conditions are not met, the installation check indicates that the upgrade would be disruptive.

In this case, you can perform an upgrade at a later time after making the necessary changes to the topology to meet these conditions or perform a disruptive upgrade.

12



Figure 9 shows a Cisco Nexus device that is connected to a blade switch that is running STP.

Figure 9 Connection to a Blade Switch Running STP

Cisco Nexus Device

Blade Switches

Figure 10 shows a Cisco Nexus device that is connected to a downstream switch that is running STP.

Figure 10 Connection to a Downstream Switch Running STP

Cisco Nexus Device

Downstream switch

Figure 11 shows a Cisco Nexus device that is running Bridge Assurance with another switch.

Figure 11

Aggregation

Cisco Nexus Device Running Bridge Assurance with Another Switch

Bridge assurance enabled

Cisco Nexus

Device Undergoing

ISSU


13


Figure 12 shows dual-homed FEXs connected to a stub switch.

Figure 12

Cisco Nexus

Device

Dual-Homed FEXs Connected to a Stub Switch

Cisco Nexus

Fabric Extender

Figure 13 shows a single-homed FEX that is connected to stub switches.

Figure 13

Cisco Nexus

Device

Single-Homed FEX Connected to Stub Switches

Cisco Nexus

Device

Cisco Nexus

Fabric Extender

Figure 14 shows a dual-homed FEX that is connected to stub switches.

14


Figure 14

Cisco Nexus

Device

Dual-Homed FEX Connected to Stub Switches

Cisco Nexus

Device

Cisco Nexus

Fabric Extender


ISSU Prerequisites

You must follow the upgrade guidelines listed in the “Upgrade Guidelines” section on page 3 in order

for ISSU to work correctly. Make sure that the network is stable and no changes are made while an ISSU is in progress. Make sure that you check for feature compatibility between the current running release and the target release.

Figure 15 shows upgrade restrictions.

Figure 15 Upgrade Restrictions

The specific requirements for a nondisruptive upgrade (ISSU) are as follows:


15


•

•

•

Topology requirements — A Cisco Nexus device on which an ISSU is being initiated should not be in one of the unsupported topologies listed in the previous figure. No interface should be in a spanning-tree designated forwarding state. Also, do not configure Bridge Assurance on any interface of the Cisco Nexus device . vPC peer-link is an exception to these requirements.

Layer 2 requirement— The ISSU process aborts if the system has any Link Aggregation Control

Protocol (LACP) fast timers configured.

FC/FCoE requirements—Check that the topology is stable for an ISSU to work correctly. You must check the following:

–

–

Domain Manager—As part of the installation process, domain manager checks if the fabric is in a stable state. If the fabric is not stable, the installation aborts.

CFS—As part of the installation process, Cisco Fabric Services (CFS) checks if any application

(ntp,fsm, rcsn, fctime) is locked. If any application is holding a CFS lock, the installation aborts.

–

–

Zone Server— The installation process aborts if a zone merge or zone change request is in progress.

FSPF—As part of the upgrade process, Fabric Shortest Path First (FSPF) verifies if the configured interface dead interval is more than 80 seconds; otherwise, the installation aborts.

Management Services After an ISSU

Before the switch is reset for an ISSU, inband and management ports are brought down and are brought back up after the ISSU completes. Services that depend on the inband and management ports are impacted during this time.

Table 3 lists the services that are impacted during an ISSU reset.

Table 3 Inband and Management Ports Services Impacted During ISSU Reset

Service

Telnet/SSH

AAA/RADIUS

HTTP

NTP

Description

When an ISSU resets the system to load the target Cisco NX-OS version, all

Telnet/SSH sessions are disconnected and need to be reestablished after the

ISSU completes.

Applications that leverage the AAA Service (such as login) are disabled during an ISSU, because all Network Management services are disabled during this time.

HTTP sessions to the switch are disconnected during an ISSU reboot. After the reboot, the HTTP is restarted and the switch accepts an HTTP sessions.

NTP sessions to and from the switch are disrupted during an ISSU reboot.

After the reboot, NTP session are reestablished based on the saved startup configuration.

Fibre Channel/FCoE Protocol and Services During an ISSU

During an ISSU, the control plane is offline for up to 80 seconds. Any state changes in the network during this time are not processed. Depending on the change, the impact might vary. We recommend that you ensure a stable fabric during an ISSU. See the following table for other ISSU impacts.

16



Table 4 ISSU Impact to Fibre Channel and FCoE Services

Service

Name Server

Description

When a new switch in the fabric is brought up and queries the Name Server on the ISSU switch, the ISSU switch cannot respond and does not receive

Nx_port information.

Domain Manager

CFS

Domain Manager on a switch undergoing an ISSU does not process any

BF/RCF/DIA/RDI caused by topology changes, which might result in traffic disruption in the fabric.

During an ISSU upgrade, CFS applications on other switches cannot obtain

CFS locks on the ISSU switch, which might result in CFS distribution failures until the ISSU completes.

N-Port Virtualization During an ISSU, the NPV process is down. Any FLOGI/fdisc or logon request from a server fails until the ISSU completes.

Zone Server During an ISSU, because EPP and merge requests are not processed, the peer switch cannot bring up E and TE ports connected to the ISSU switch until the ISSU completes.

FSPF

EPP

FCoE NPV Links

A peer switch zone change request is not answered by the switch undergoing an ISSU. Any zone configuration changes on other switches connected to the

ISSU switch fails until the ISSU completes.

Before the switch reboots for an ISSU, the switch transmits an FSPF hello on all interfaces to prevent neighbor switches from marking routes to the

ISSU switch as down. Any topology changes during this time are also not acted upon until the ISSU completes.

During an ISSU process, EPP messages are not received/transmitted on the

ISSU switch. New ports in FC port channels are not negotiated until the

ISSU completes. Additionally, FC Trunk Mode changes (E port to TE Port and vice versa and the allowed VSAN list) are also not processed.

When the NPV/FCoE NPV switch is logged into a core switch through an

FCoE NPV link, it punches heartbeats, FIP keepalives (FKA), toward the core switch for its own internal login session and all the host login sessions pinned through this FCoE NPV link. This FKA interval of 8 seconds is less than the ISSU downtime. Enter the disable-fka command on the core switch

VFC parameters to ensure that the core switch ignores any FKA events.


17


Layer-2 Protocols Impact

Table 5 lists the ISSU impacts to Layer 2 protocols.

Table 5 ISSU Impact to Layer 2 Protocols

Protocol

LACP

IGMP

DCBX and LLDP

CDP

L2MP IS-IS

Description

IEEE 802.3ad provides for the default slow aging timers to be transmitted once every 30 seconds in steady state and to expire after 90 seconds. An

ISSU should not impact peers that rely on LACP because the recovery time is less than 90 seconds.

Fast LACP timers (hello=1 sec, dead=3 sec) are not supported with a nondisruptive ISSU.

IGMP does not disrupt existing flows of multicast traffic that are already present, but new flows are not learned (and are dropped) until an ISSU completes. New router ports or changes to router ports are not detected during this time.

DCBX uses LLDP to exchange parameters between peer devices. Because

DCBX is a link-local protocol, when the switch undergoes an ISSU, the age time is increased on all ports on the switches and FEXs that are being upgraded.

Manual configurations are ignored during this time.

During an ISSU, the time-to-live value is increased (180 seconds) if it is less than the recommended timeout value. The configuration is ignored if manually specified.

Before a switch reboots for an ISSU, the switch transmits Layer 2 IS-IS hellos on all interfaces to prevent neighbor switches from marking routes to the ISSU switch as down. Any topology changes during this time are also not acted upon until the ISSU completes.

Ethernet Interfaces on the Switch and the Fabric Extenders

To avoid link-down to link-up transitions during the control plane outage time, the laser is turned off for administratively up ports that are operationally down. This situation occurs during the ISSU reboot starting state when the switch and the FEX applications stop communicating with each other. After the

ISSU reboot and a stateful restart, the laser is turned back on. This action prevents the link state from transitioning from down to up during an ISSU.

PreInstallation Checks

You should do certain sanity checks to ensure that the system is ready for an ISSU and to understand the impact of ISSU:

• Enter the show incompatibility command to verify that the target image is feature-wise compatible with the current image.

•

•

Enter the show logging level command to ensure that the severity level for all processes is set to 5 or below.

Enter the show install all impact command to identify the upgrade impact.

18



•

•

•

•

Enter the show fex command to verify that all the FEXs are online.

Enter the show vpc role command to verify the vPC switch role in a vPC topology.

Enter the install all command to update to the latest Cisco NX-OS software.

Review the installer impact analysis and choose to continue.

Note The switch might reload at this time and cause a traffic disruption if the upgrade i s not an ISSU.

•

•

•

Monitor the installation progress.

Verify the upgrade.

Enter the show install all status command to verify the status of the installation.

The following table lists the show commands that identify the impact or potential problems that might occur when performing an ISSU.

Table 6 Upgrade show Commands

Command show incompatibility system show logging level show install all impact

Definition

Displays incompatible configurations on the current system that impact the upgrade version. You must use the system image file.

Displays the facility logging severity level configuration.

Logging levels for all processes must be set at 5 or below when performing an ISSU. Processes with a logging level greater than 5 do not appear when you enter the show install all impact command.

Displays information that describes the impact of the upgrade on each Fabric Extender, including the current and upgrade-image versions. This command also displays if the upgrade is disruptive or not and if the Fabric Extender needs to be rebooted and the reason why.

show spanning-tree issu-impact Displays the spanning-tree configuration and whether or not there are potential STP issues.

show lacp issu-impact show fcoe-npv issu-impact

Displays the port priority information and whether or not there are potential issues.

Checks whether disable-fka is set on any of the FCoE NPV (VNP) ports as a pre-ISSU check.

You can also perform the following tasks to identify potential problems before they occur:

•

•

Ensure that you have enough space to store the images on bootflash:

Display incompatible configurations on the current system that will impact the upgrade version.

switch-2# show incompatibility system bootflash:n5000-uk9.7.1.0.N1.1a.bin

No incompatible configurations

• D isplay the status of FEXs connected to the system as follows: switch# show fex

FEX FEX FEX FEX

Number Description State Model Serial

------------------------------------------------------------------------


19


20

126 FEX126 Online N2K-C2232TM-E-10GE SSI153501JG

127 FEX127 Online N2K-C2232TM-E-10GE SSI153402XS

144 FEX144 Online N2K-C2232PP-10GE SSI1405704A

•

D isplay the STP configuration and whether potential STP issues exist as follows: switch# show spanning-tree issu-impact

For ISSU to Proceed, Check the Following Criteria :

1. No Topology change must be active in any STP instance

2. Bridge assurance(BA) should not be active on any port (except MCT)

3. There should not be any Non Edge Designated Forwarding port (except MCT)

4. ISSU criteria must be met on the VPC Peer Switch as well

Following are the statistics on this switch

No Active Topology change Found!

Criteria 1 PASSED !!

No Ports with BA Enabled Found!

Criteria 2 PASSED!!

No Non-Edge Designated Forwarding Ports Found!

Criteria 3 PASSED !!

ISSU Can Proceed! Check Peer Switch.

•

Use the show lacp issu-impact command to display if any port or a peer switch is configured in rate fast mode.

Verify that an ISSU is nondisruptive. You can display the information about the impact of the upgrade on each FEX and include details such as the upgrade image versions. This command also displays if the upgrade is disruptive/nondisruptive and the reason why.

switch# show install all impact kickstart bootflash:n5000-uk9-kickstart.7.1.0.N1.1a.bin system bootflash:n5000-uk9.7.1.0.N1.1a.bin

Verifying image bootflash:/n5000-uk9-kickstart.7.1.0.N1.1a.bin for boot variable

"kickstart".

[####################] 100% -- SUCCESS

Verifying image bootflash:/n5000-uk9.7.1.0.N1.1a.bin for boot variable "system".

[####################] 100% -- SUCCESS

Verifying image type.

[####################] 100% -- SUCCESS

Extracting "system" version from image bootflash:/n5000-uk9.7.1.0.N1.1a.bin.

[####################] 100% -- SUCCESS

Extracting "kickstart" version from image bootflash:/n5000-uk9-kickstart.7.1.0.N1.1a.bin.

[####################] 100% -- SUCCESS

Extracting "bios" version from image bootflash:/n5000-uk9.7.1.0.N1.1a.bin.

[####################] 100% -- SUCCESS

Extracting "fexth" version from image bootflash:/n5000-uk9.7.1.0.N1.1a.bin.

[####################] 100% -- SUCCESS

Performing module support checks.

[####################] 100% -- SUCCESS

Notifying services about system upgrade.

[####################] 100% -- SUCCESS


Upgrading Procedures

Compatibility check is done:

Module bootable Impact Install-type Reason

------ -------- -------------- ------------ ------

1 yes non-disruptive reset

2 yes non-disruptive rolling


126 yes non-disruptive none

127 yes non-disruptive none


Images will be upgraded according to following table:

Module Image Running-Version New-Version Upg-Required

------ ---------------- ---------------------- ---------------------- ------------

1 system 7.0(3)N1(1) 7.1(0)N1(1a) no

1 kickstart 7.0(3)N1(1) 7.1(0)N1(1a)

1 bios v3.6.0(05/09/2012) v3.6.0(05/09/2012) no

1 power-seq v2.0 v2.0 no

1 SFP-uC v1.0.0.0 v1.0.0.0 no



126 fexth 7.0(0)N1(1) 7.1(0)N1(1a) yes

127 fexth 7.0(0)N1(1) 7.1(0)N1(1a) yes

133 fexth 7.0(3)N1(1) 7.1(0)N1(1a) yes

1 microcontroller v1.2.0.1 v1.2.0.1 no switch-1#

• Check whether disable-fka is set on any of the FCoE NPV (VNP) ports as a pre-ISSU check as follows: switch# show fcoe-npv issu-impact show fcoe-npv issu-impact

-------------------------

Please make sure to enable "disable-fka" on all logged in VFCs

Please increase the FKA duration to 60 seconds on FCF

Active VNP ports with no disable-fka set

----------------------------------------


The ISSU process is triggered when you enter the install all command. This section describes the sequence of events that occur when you upgrade a single Cisco Nexus device or a single Cisco Nexus device that is connected to one or more FEXs.

Note To use the ISSU process for Release 4.2(1)N1(1) through Release 5.1(3)N2(1c), you must first upgrade to Release 5.2(1)N1(1). After that, use the ISSU process to upgrade from 5.2(1)N1(1) to Release 7.0.

The section includes the following topics:

•

Installation At-a-Glance, page 22


21


•

•

•

•

•

•

•

Copying the Running Configuration from an External Flash Memory Device, page 23

Copying the Startup Configuration from an External Flash Memory Device, page 24

Upgrade Process in a Non-vPC Topology, page 25

Upgrade Process for a vPC Topology on the Primary Switch, page 28

Upgrade Process for a vPC Topology on the Secondary Switch, page 29

Upgrading a Direct vPC or a Single-Homed FEX Access Layer, page 36

Upgrading a Dual-Homed FEX Access Layer, page 39

Installation At-a-Glance

Table 7 shows an overview of the upgrade process.

Table 7 Upgrade Process At-a-Glance

Task

Upgrade Preparation

Pre-ISSU Checks

Steps

1.

Log in to the first Cisco Nexus device. We recommend that you log in to the console port. In vPC topologies, you should start with the switch that is the primary switch.

2.

Log in to Cisco.com to access the Software Download Center. To log in to Cisco.com, go to http://www.cisco.com/ and click Log In at the top of the page. Enter your Cisco username and password.

3.

4.

5.

6.

Choose and download the kickstart and system software files to the server.

Verify that the required space is available in the bootflash: directory for the image file(s) to be copied.

If you need more space in the bootflash: directory, delete unnecessary files to make space available.

Copy the Cisco NX-OS kickstart and system images to the bootflash using a transfer protocol such as ftp:, tftp:, scp:, or sftp.

7.

8.

1.

2.

3.

4.

5.

Compare the file sizes of the images that were transferred using the dir bootflash command. The file sizes of the images obtained from

Cisco.com and the image sizes of the transferred files should be the same.

Complete the above steps for each Cisco Nexus device in the topology.

Enter the show incompatibility command to verify that the target image is feature-wise compatible with the current image.

Enter the show install all impact command to identify the upgrade impact.

Enter the show spanning-tree issu-impact command to display the impact of the upgrade impact.

Enter the show lacp issue-impact command to display the impact of the upgrade.

Enter the show fex command to verify that all the FEXs are online.


22


Table 7 Upgrade Process At-a-Glance (continued)

Task

Upgrade Begins

Upgrade Verification

Steps

1.

2.

3.

Enter the show vpc role command to verify the vPC switch role.

Enter the install all command to update to the latest Cisco NX-OS software.

Peruse the installer impact analysis and accept to proceed.

The installer on the Cisco Nexus 5500 upgrades the software. The switch is now running the new version of the software.

1.

Enter the show install all status installation.

command to verify the status of the

Copying the Running Configuration from an External Flash Memory Device

You can copy configuration files from an external flash memory device.

Note This procedure applies to the Cisco Nexus device that is running Cisco NX-OS Release 5.0.2 and later releases.

Step 1

Step 2

Step 3

Step 4

Step 5

Before You Begin

Insert the external flash memory device into the active supervisor module.

Command or Action dir usb1 :[ directory/ ]

Example : switch# dir usb1: copy usb1 :[ directory/ ] filename

{ bootflash :} [ directory/ ] filename

Example : switch# copy usb1:n5000-uk9.7.1.0.N1.1a.bin bootflash:n5000-uk9.7.1.0.N1.1a.bin

copy usb1 :[ directory/ ] filename running-config

Example : switch# copy usb1:dsn-config.cfg running-config copy usb1 :[ directory/ ] filename running-config

Example : switch# copy usb1:dsn-config.cfg running-config show running-config

Example : switch# show running-config

Purpose

(Optional) Displays the files on the external flash memory device.

Copies the image from an external flash memory device into the bootflash. The case sensitive.

filename argument is

Copies the running configuration from an external flash memory device. The sensitive.

filename argument is case

(Optional) Copies the running configuration from an external flash memory device to the bootflash.

(Optional) Displays the running configuration.


23


Step 6

Step 7

Command or Action copy running-config startup-config

Example : switch# copy running-config startup-config show startup-config

Example : switch# show startup-config

Purpose

(Optional) Copies the running configuration to the startup configuration.

(Optional) Displays the startup configuration.

Copying the Startup Configuration from an External Flash Memory Device

You can recover the startup configuration on your Cisco NX-OS device by downloading a new startup configuration file that was saved on an external flash memory device.

Note This procedure applies to the Cisco Nexus device that is running Cisco NX-OS Release 5.0.2 and later releases.

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7 dir { usb1 : |

Before You Begin

Insert the external flash memory device into the active supervisor module.

Command or Action usb2 :}[ directory/ ]

Example : switch# dir usb1: copy { usb1 : | usb2 :}[ directory/ ] filename

{bootflash:} [ directory/ ] filename

Example : switch# copy usb1:n5000-uk9.5.2.1.N2.2.bin bootflash:n5000-uk9.5.2.1.N2.2.bin

copy { usb1 : | usb2 :}[ directory/ ] filename startup-config

Example : switch# copy usb1:dsn-config.cfg startup-config copy { usb1 : | usb2 :}[ directory/ ] filename startup-config

Example : switch# copy usb1:dsn-config.cfg bootflash-config show startup-config

Example : switch# show startup-config copy running-config startup-config

Example : switch# copy running-config startup-config show startup-config

Example : switch# show startup-config

Purpose

(Optional) Displays the files on the external flash memory device.

Copies the image from an external flash memory device into the bootflash. The case sensitive.

filename argument is

Copies a saved configuration from an external flash memory device to the startup configuration. The filename argument is case sensitive.

(Optional) Copies a saved configuration from an external flash memory device to the bootflash. The filename argument is case sensitive.


(Optional) Copies the running configuration to the startup configuration.


24



Upgrade Process in a Non-vPC Topology

The following list summarizes the upgrade process in a non-vPC topology:

1.

The install all command triggers the installation upgrade.

2.

3.

4.

5.

6.

7.

8.

9.

The compatibility checks display the impact of the upgrade.

The installation proceeds or not based on the upgrade impact.

The current state is saved.

The system unloads and runs the new image.

The stateful restart of the system software and application occurs.

The installer resumes with the new image.

The FEXs are upgraded sequentially.

The installation completes.

This example shows how to display the ISSU process: switch# install all kickstart bootflash:n5000-uk9-kickstart.7.1.0.N1.1a.bin system bootflash:n5000-uk9.7.1.0.N1.1a.bin


"kickstart".

[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS



------ -------- -------------- ------------ ------

1 yes non-disruptive reset




------ ---------------- ---------------------- ---------------------- ------------

1 system 7.0(3)N1(1) 7.1(0)N1(1a) yes


25


1 kickstart 7.0(3)N1(1) 7.1(0)N1(1a) yes

1 bios v3.6.0(05/09/2012) v3.6.0(05/09/2012) no



1 microcontroller v1.2.0.1 v1.0.0.14 no

Do you want to continue with the installation (y/n)? [n] y

Install is in progress, please wait.

2014 Jan 24 17:05:25 switch-1 %$ VDC-1 %$ %VSHD-5-VSHD_SYSLOG_CONFIG_I: Configured from vty by root on vsh.5720

Performing runtime checks.

[####################] 100% -- SUCCESS

Notifying services about the upgrade.

[####################] 100% -- SUCCESS

Setting boot variables.

[# ] 0%2014 Jan 24 17:05:44 switch-1 %$ VDC-1 %$

%VSHD-5-VSHD_SYSLOG_CONFIG_I: Configured from vty by root on vsh.5739

[####################] 100% -- SUCCESS

Performing configuration copy.

[####################] 100% -- SUCCESS

Upgrade can no longer be aborted, any failure will result in a disruptive upgrade.

Requesting Line Cards to stop communication.

[####################] 100% -- SUCCESS

Requesting Sup Apps to stop communication.

[####################] 100% -- SUCCESS

Freeing memory in the file system.

[####################] 100% -- SUCCESS

Loading images into memory.

[####################] 100% -- SUCCESS

Saving supervisor runtime state.

[####################] 100% -- SUCCESS

Saving mts state.

[###############[ 4724.472603] writing reset reason 88, <NULL>

#####] 100% -- SUCCESS

Rebooting the switch to proceed with the upgrade.

All telnet and ssh connections will now be temporarily terminated.

[ 4726.274091] Starting new kernel

[ 4726.277312] Calling kexec callback

[ 4726.280005] Moving to new kernel

[ 4726.280005] Calling into reboot_code_buffer code

INIT: [ 6.186872] I2C - Mezz absent autoneg unmodified, ignoring autoneg unmodified, ignoring

Checking all filesystems..... done.

Loading system software

Uncompressing system image: bootflash:/n5000-uk9.7.1.0.N1.1a.bin Fri Jan 24 17:06:29 PST

2014

Load plugins that defined in image conf: /isan/plugin_img/img.conf

26


Upgrading Procedures load_plugin: Plugin-swid map exists. Any plugin exists in the map will be assigned from the map

Loading plugin 0: core_plugin...

load_plugin: Can't get exclude list from /isan/plugin/0/boot/etc/plugin_exclude.conf (rc

0x40ea0017)

Loading plugin 1: eth_plugin...

Loading plugin 2: fc_plugin...

ethernet switching mode

INIT: Entering runlevel: 3 touch: cannot touch `/var/lock/subsys/netfs': No such file or directory

Mounting other filesystems: [ OK ] touch: cannot touch `/var/lock/subsys/local': No such file or directory

/isan/bin/muxif_config: fex vlan id: -f,4042

Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config

Added VLAN with VID == 4042 to IF -:muxif:-

2014 Jan 24 17:06:56 switch-1 %$ VDC-1 %$ %USER-2-SYSTEM_MSG: CLIS: loading cmd files begin - clis

2014 Jan 24 17:06:58 switch-1 %$ VDC-1 %$ %SENSOR-3-SENSOR_MSG1: calling sensor_usd_init

2014 Jan 24 17:07:11 switch-1 %$ VDC-1 %$ %LOCAL7-3-SYSTEM_MSG: Server /usr/sbin/in.rexecd is not executable [line=12] - dcos-xinetd[3602]

2014 Jan 24 17:07:44 switch-1 %$ VDC-1 %$ Jan 24 17:07:26 %KERN-0-SYSTEM_MSG: [

6.186872] I2C - Mezz absent - kernel


7.721990] CMOS: Module initialized - kernel


8.966681] sd 0:0:0:0: [sda] Assuming drive cache: write through - kernel


8.967931] sd 0:0:0:0: [sda] Assuming drive cache: write through - kernel


34.406657] muxif kernel module v1.0 CISCO Systems - kernel


34.487864] inband dev 0:eth4 cd84c000 - kernel


34.572886] vlan: <3>4042 <3> 0 <3> 0 <3> 0 <3> 0 <3> 0 <3> 0 <3> 0 <3> 0 <3>

0 <3> - kernel


35.775275] Initializing fc2 proto - kernel


39.854139] PFM: 1 Initializing the kernel module - kernel










39.854236] PFM: 6 Initializing the platform specific module - kernel


40.066775] ksdwrap_kpss_restore_all_flags: ksdwrap kpss service open failed rc=-2 - kernel

2014 Jan 24 17:07:38 switch-1 %$ VDC-1 %$ %USER-2-SYSTEM_MSG: CLIS: loading cmd files end

- clis

2014 Jan 24 17:07:38 switch-1 %$ VDC-1 %$ %USER-2-SYSTEM_MSG: CLIS: init begin - clis

Continuing with installation process, please wait.

The login will be disabled until the installation is completed.

Performing supervisor state verification.

[####################] 100% -- SUCCESS

Supervisor non-disruptive upgrade successful.


27


Install has been successful.

This example show how to display information about the software version: switch# show version

Cisco Nexus Operating System (NX-OS) Software

TAC support: http://www.cisco.com/tac

Documents: http://www.cisco.com/en/US/products/ps9372/tsd_products_support_serie s_home.html

Copyright (c) 2002-2014, Cisco Systems, Inc. All rights reserved.

The copyrights to certain works contained herein are owned by other third parties and are used and distributed under license.

Some parts of this software are covered under the GNU Public

License. A copy of the license is available at http://www.gnu.org/licenses/gpl.html.

Software

BIOS: version 3.6.0

loader: version N/A

kickstart: version 7.0(0)N1(1)

system: version 7.0(0)N1(1)

Power Sequencer Firmware:

Module 1: version v4.0


Microcontroller Firmware: version v1.2.0.1

QSFP uC: Module not detected

BIOS compile time: 05/09/2012

kickstart image file is: bootflash:///n5000-uk9-kickstart.7.1.0.N1.1a.bin

kickstart compile time: 1/23/2014 4:00:00 [01/23/2014 05:38:54]

system image file is: bootflash:///n5000-uk9.7.1.0.N1.1a.bin

system compile time: 1/23/2014 4:00:00 [01/23/2014 08:56:30]

Hardware

cisco Nexus5548 Chassis ("O2 32X10GE/Modular Supervisor")

Intel(R) Xeon(R) CPU with 8253860 kB of memory.

Processor Board ID JAF1429AMFB

Device name: switch-1

bootflash: 2007040 kB

Kernel uptime is 0 day(s), 0 hour(s), 5 minute(s), 31 second(s)

Last reset at 82850 usecs after Fri Jan 24 17:06:14 2014

Reason: Reset due to upgrade

System version: 7.0(3)N1(1)

Service: plugin

Core Plugin, Ethernet Plugin, Fc Plugin

Upgrade Process for a vPC Topology on the Primary Switch

The following list summarizes the upgrade process on a primary switch in a vPC topology.

28



Note In vPC topologies, the two peer switches must be upgraded individually. An upgrade on one peer switch does not automatically update the vPC peer switch.

1.

4.

5.

2.

3.

6.

7.

The install all command issued on the vPC primary switch triggers the installation upgrade.



The configuration is locked on both vPC peer switches.




8.

9.

10.


The FEXs are upgraded sequentially.

The installation is complete.

When the installation is complete, the vPC primary switch and the FEXs that are connected to the primary switch are upgraded. The single-homed FEXs and the dual-homed FEXs are now running the upgraded software.

Note The dual-homed FEXs are now connected to the primary and secondary switches that are running two different versions of the Cisco NX-OS software. The vPC primary switch is running the upgraded version and the vPC secondary switch is running the original software version. The Cisco NX-OS software that are designed to allow an upgraded dual-home FEX to interoperate with vPC secondary switches running the original version of Cisco NX-OS while the primary switch is running the upgrade version.

Upgrade Process for a vPC Topology on the Secondary Switch

The following list summarizes the upgrade process on a secondary switch in a vPC topology.

1.

The install all command issued on the vPC second switch triggers the installation upgrade .

2.

3.



6.

7.

4.

5.

8.





The FEXs are upgraded sequentially. The upgrade completes on the single-homed FEXs and a sanity check is performed on the dual-homed FEXs.

Note The dual-homed FEXs were upgraded by the primary switch.

9.

The configuration is unlocked on the primary and secondary switches.


29

Disruptive Installation Process

10.

The installation is complete.

Disruptive Installation Process

Note Doing a disruptive upgrade between incompatible images will result in loss of certain configurations such as unified ports, breakout, and FEX configurations. See CSCul22703 for details.

The following lists the situations where a nondisruptive ISSU might not be possible when upgrading a

Cisco Nexus device:

• The topology and/or features are not ISSU ready. See the

“ISSU Prerequisites” section on page 15

for more information.

• The current release or target release is lower than Release 5.2(1)N1(1). An ISSU can work only when both the current and target releases are equal or later than Release 5.2(1)N1(1).

Note To use the ISSU process for Release 5.0(2)N1(1) through Release 5.1(3)N2(1c), you must first upgrade to Release 5.2(1)N1(1). After that, use the ISSU process to upgrade to Release

7.1(0)N1(1a).

•

•

The installation is a downgrade, such as a higher release to a lower release, unless stated otherwise in the

“Upgrade Guidelines” section on page 3 .

You want to do a disruptive upgrade. See the “Forcing an Upgrade” section on page 30 .

Forcing an Upgrade

You can choose to do a disruptive upgrade if one of the ISSU conditions are not met. One additional reason where you might choose to do a disruptive upgrade is when FEXs are upgraded in a rolling fashion (one FEX at a time), which requires a longer maintenance window. With a disruptive upgrade, all the connected FEXs are upgraded simultaneously, so the maintenance window can be shorter. If you need a shorter maintenance window (with traffic disruption), you can force a disruptive upgrade even if an ISSU can be leveraged. It is important to note the possibility of an outage if you do a disruptive upgrade.

switch# install all force kickstart bootflash:/kickstart_image.bin system bootflash:/system_image.bin

Installer is forced disruptive

Verifying image bootflash:/kickstart_image.bin for boot variable "kickstart".

[####################] 100% -- SUCCESS

Verifying image bootflash:/system_image.bin for boot variable "system".

...

You can also add the force keyword at the end of the install all command as follows: switch# install all kickstart bootflash:/kickstart_image.bin system bootflash:/system_image.bin force

Installer is forced disruptive


30

Upgrading from Cisco NX-OS Release 5.1(3)N2(1c) and Earlier Releases (Disruptive Upgrade)

Verifying image bootflash:/kickstart_image.bin for boot variable "kickstart".

...

Upgrading from Cisco NX-OS Release 5.1(3)N2(1c) and Earlier

Releases (Disruptive Upgrade)

This section describes how to upgrade from Cisco NX-OS Release 5.1(3)N2(1c) and earlier releases. An upgrade from these releases is disruptive. Upgrading a Cisco Nexus device also upgrades connected

Cisco Nexus Fabric Extenders.

Note To perform a nondisruptive upgrade from Cisco NX-OS Release 5.2(1)N1(1) and later releases, see

CSCul22703 for details. You can upgrade Cisco NX-OS Release 4.2(1)N1(1) through Release

5.1(3)N2(1c) using a two-step ISSU process.

DETAILED STEPS

Step 1 Log in to Cisco.com to access the Software Download Center. To log in to Cisco.com, go to http://www.cisco.com/ and click Log In at the top of the page. Enter your Cisco username and password.

Note Unregistered Cisco.com users cannot access the links provided in this document.

Step 2

Step 3

Access the Software Download Center at http://www.cisco.com/cisco/software/navigator.html?a=a&i=rpm . Navigate to the software downloads for Cisco Nexus devices. Links to the download images for the switch are listed.

Choose and download the kickstart and system software files to a local server.

Verify that the required space is available in the bootflash: directory for the image file(s) to be copied.

switch-2# dir bootflash:

238 Jul 14 12:09:03 2013 fc_features_pkg.lic

250 May 31 22:47:21 2013 lan_base_services_pkg.lic

15062 Jan 09 15:40:14 2014 mts.log

34419712 Dec 10 14:17:10 2013 n5000-uk9-kickstart.5.2.1.N1.6.bin

34672128 Jan 07 09:21:44 2014 n5000-uk9-kickstart.6.0.2.N1.2.bin

37228032 Jan 23 15:19:44 2014 n5000-uk9-kickstart.7.1.0.N1.1a.bin

37228032 Jan 24 12:01:59 2014 n5000-uk9-kickstart.7.1.0.N1.1a.bin.upg

175641212 Dec 10 14:18:14 2013 n5000-uk9.5.2.1.N1.6.bin

238082390 Jan 07 09:21:27 2014 n5000-uk9.6.0.2.N1.2.bin

241908702 Jan 23 15:20:36 2014 n5000-uk9.7.1.0.N1.1a.bin

241921735 Jan 24 12:03:00 2014 n5000-uk9.7.1.0.N1.1a.bin.upg

50767 Aug 30 10:40:56 2013 noPvlanHifStorm

15236 Jan 10 09:40:37 2014 span.log

8646 Aug 28 22:41:46 2013 standby-lacp-clihistory

8398 Jan 24 13:57:11 2014 stp.log.1

4096 Jan 01 13:41:30 2009 vdc_2/

4096 Jan 01 13:41:30 2009 vdc_3/

4096 Jan 01 13:41:30 2009 vdc_4/

641 Jan 24 13:58:15 2014 vfc_cnv.log

4096 Feb 19 11:22:03 2013 virt_strg_pool_bf/

268 Jan 24 13:58:42 2014 vlan.dat

Usage for bootflash://


31


Step 4

Step 5

Step 6

1171353600 bytes used

479551488 bytes free

1650905088 bytes total switch-2#

We recommend that you keep the kickstart and system image files for at least one previous software release to use if the new image files do not load successfully.

(Optional) If you need more space on the bootflash, delete unnecessary files to make space available.

switch-1# delete bootflash:n5000-uk9.6.0.2.N1.0.367.2P.bin

Do you want to delete "/n5000-uk9.6.0.2.N1.0.367.2P.bin" ? (yes/no/abort) [y] switch-1# switch-1# delete bootflash:n5000-uk9.6.0.2.N2.0.34.bin

Do you want to delete "/n5000-uk9.6.0.2.N2.0.34.bin" ? (yes/no/abort) [y] switch-1#

Copy the new kickstart and system images to the switch bootflash by using a transfer protocol such as

FTP, TFTP, SCP, or SFTP. The examples in this procedure use SCP. switch-1# copy scp://[email protected]//production/images/nexus5000/n5000-uk9-kickstart.7.1.0.N1.1a.bin bootflash: vrf management

The authenticity of host '171.70.173.76 (171.70.173.76)' can't be established.

RSA key fingerprint is d0:b6:3a:dc:04:6e:37:51:65:ee:be:97:11:15:ba:07.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added '171.70.173.76' (RSA) to the list of known hosts.

[email protected]'s password: n5000-uk9-kickstart.7.1.0.N1.1a.bin 100% 36MB 8.9MB/s 00:04

Copy complete, now saving to disk (please wait)...

switch-1#

Display the impact of the upgrade.

switch-1# show install all impact kickstart bootflash:n5000-uk9-kickstart.7.1.0.N1.1a.bin system bootflash:n5000-uk9.7.1.0.N1.1a.bin

Verifying image bootflash:/n5000-uk9-kickstart.7.1.0.N1.1a.bin for boot varia ble "kickstart".

[####################] 100% -- SUCCESS

Verifying image bootflash:/n5000-uk9.7.1.0.N1.1a.bin for boot variable "syste m".

[####################] 100% -- SUCCESS


[########### ] 50%

[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS


32



[####################] 100% -- SUCCESS



------ -------- -------------- ------------ ------

1 yes disruptive reset Incompatible image



------ ---------- ---------------------- ---------------------- ------------

1 system 5.1(3)N2(1) 7.1(0)N1(1a) yes


1 bios v3.6.0(05/09/2012) v3.6.0(05/09/2012) no



1 uC v1.2.0.1 v1.0.0.14 no

Step 7 switch-1#

Install the new images, specifying the new image names that you downloaded in the previous step.

switch-1# install all kickstart bootflash:n5000-uk9-kickstart.7.1.0.N1.1a.bin system bootflash:n5000-uk9.7.1.0.N1.1a.bin


"kickstart".

[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS


[####################] 100% -- SUCCESS



------ -------- -------------- ------------ ------

1 yes disruptive reset Incompatible image



33


34


------ ---------- ---------------------- ---------------------- ------------

1 system 5.1(3)N2(1) 7.1(0)N1(1a) yes


1 bios v3.6.0(05/09/2012) v3.6.0(05/09/2012) no



1 uC v1.2.0.1 v1.0.0.14 no

Switch will be reloaded for disruptive upgrade.

Do you want to continue with the installation (y/n)? [n] y

Install is in progress, please wait.

Performing runtime checks.

[####################] 100% -- SUCCESS

Setting boot variables.

[# ] 0%2014 Jan 24 21:58:15 switch-1 %$ VDC-1 %$

%VSHD-5-VSHD_SYSLOG_CONFIG_I: Configured from vty by on vsh.5943

[####################] 100% -- SUCCESS

Performing configuration copy.

[####################] 100% -- SUCCESS

Finishing the upgrade, switch will reboot in 10 seconds.

switch-1# Shutdown Ports..

writing reset reason 49,

2014 Jan 24 21:58:31 switch-1 %$ VDC-1 %$ Jan 24 21:58:31 %KERN-0-SYSTEM_MSG: Shutdown

Ports.. - kernel

2014 Jan 24 21:58:31 switch-1 %$ VDC-1 %$ Jan 24 21:58:31 %KERN-0-SYSTEM_MSG: writing reset reason 49, - kernel

Broadcast message from root (Fri Jan 24 21:58:36 2014):

The system is going down for reboot NOW!

INIT: Sending processes the TERM signal

2014 Jan 24 21:5Sending all processes the TERM signal...

Sending all processes the KILL signal...

Unmounting filesystems...

Resetting board

Restarting system.

ooting kickstart image: bootflash:/n5000-uk9-kickstart.7.1.0.N1.1a.bin....

...............................................................................

..........................................Image verification OK

INIT: [ 6.438002] I2C - Mezz absent devmemfd:0x7fc9eea8 phys->virt: 0x7fc9eec87fc9eea8-->0x8054d12 devmemfd:0x7fc9eef8 phys->virt: 0x7fc9ef187fc9eef8-->0x8054d12 devmemfd:0x7fc9eef8 phys->virt: 0x7fc9ef187fc9eef8-->0x8054d12 devmemfd:0x7fc9eef8 phys->virt: 0x7fc9ef187fc9eef8-->0x8054d12

Starting system POST.....

Executing Mod 1 1 SEEPROM Test:...done (0 seconds)

Executing Mod 1 1 GigE Port Test:....done (32 seconds)

Executing Mod 1 1 PCIE Test:.................done (0 seconds)

Mod 1 1 Post Completed Successfully

POST is completed can't create lock file /var/lock/mtab~194: No such file or directory (use -n flag to override)


Upgrading from Cisco NX-OS Release 5.1(3)N2(1c) and Earlier Releases (Disruptive Upgrade) nohup: redirecting stderr to stdout autoneg unmodified, ignoring autoneg unmodified, ignoring

Checking all filesystems..... done.

Loading system software

Uncompressing system image: bootflash:/n5000-uk9.7.1.0.N1.1a.bin Fri Jan 24 22:00:35 PST

2014

Load plugins that defined in image conf: /isan/plugin_img/img.conf

Loading plugin 0: core_plugin...

load_plugin: Can't get exclude list from /isan/plugin/0/boot/etc/plugin_exclude.conf (rc

0x40ea0017)

Loading plugin 1: eth_plugin...

ethernet switching mode

INIT: Entering runlevel: 3 touch: cannot touch `/var/lock/subsys/netfs': No such file or directory

Mounting other filesystems: [ OK ] touch: cannot touch `/var/lock/subsys/local': No such file or directory

/isan/bin/muxif_config: fex vlan id: -f,4042

Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config

Added VLAN with VID == 4042 to IF -:muxif:-

2014 Jan 24 22:00:58 switch-1 %$ VDC-1 %$ %USER-2-SYSTEM_MSG: CLIS: loading cmd files begin - clis


6.438002] I2C - Mezz absent - kernel

2014 Jan 24 22:01:09 switch-1 %$ VDC-1 %$ %USER-2-SYSTEM_MSG: CLIS: loading cmd files end

- clis

2014 Jan 24 22:01:09 switch-1 %$ VDC-1 %$ %USER-2-SYSTEM_MSG: CLIS: init begin - clis

2014 Jan 24 22:02:54 switch-1 %$ VDC-1 %$ %VDC_MGR-2-VDC_ONLINE: vdc 1 has come online

Step 8

User Access Verification switch-1 login:

Verify that the switch is running the required software release.

switch# show version

Cisco Nexus Operating System (NX-OS) Software

TAC support: http://www.cisco.com/tac

Documents: http://www.cisco.com/en/US/products/ps9372/tsd_products_support_serie s_home.html

Copyright (c) 2002-2014, Cisco Systems, Inc. All rights reserved.

The copyrights to certain works contained herein are owned by other third parties and are used and distributed under license.

Some parts of this software are covered under the GNU Public

License. A copy of the license is available at http://www.gnu.org/licenses/gpl.html.

Software

BIOS: version 3.6.0

loader: version N/A

kickstart: version 7.0(0)N1(1)

system: version 7.0(0)N1(1)

Power Sequencer Firmware:



Microcontroller Firmware: version v1.2.0.1

QSFP uC: Module not detected

BIOS compile time: 05/09/2012

kickstart image file is: bootflash:///n5000-uk9-kickstart.7.1.0.N1.1a.bin

kickstart compile time: 1/23/2014 4:00:00 [01/23/2014 05:38:54]

system image file is: bootflash:///n5000-uk9.7.1.0.N1.1a.bin

system compile time: 1/23/2014 4:00:00 [01/23/2014 08:56:30]


35

Minimizing the Impact of a Disruptive Upgrade

Hardware

cisco Nexus5548 Chassis ("O2 32X10GE/Modular Supervisor")

Intel(R) Xeon(R) CPU with 8253860 kB of memory.

Processor Board ID JAF1429AMFB

Device name: switch-1

bootflash: 2007040 kB

Kernel uptime is 0 day(s), 0 hour(s), 34 minute(s), 27 second(s)

Last reset at 82850 usecs after Fri Jan 24 17:06:14 2014

Reason: Reset due to upgrade

System version: 7.0(3)N1(1)

Service: plugin

Core Plugin, Ethernet Plugin, Fc Plugin switch-1#


A non-ISSU upgrade is a disruptive upgrade that results in the reload of the Cisco Nexus device and the

Cisco Nexus Fabric Extenders. The reload is a cold reboot that brings down the control plan and the data plane. The reload causes disruptions to the connected servers and hosts. When a vPC is deployed in the access layer, it is possible to minimize the impact of a non-ISSU upgrade. When one of the vPC switches is being reset during the upgrade process, all the server traffic can flow through its vPC peer.

Upgrading a Direct vPC or a Single-Homed FEX Access Layer

Figure 16 through

Figure 18 show topologies in which the access layer includes a vPC configuration to

hosts or downstream switches.

36



Figure 16 Hosts Directly Connected Directly to vPC Peers

Aggregation

Nexus 5010

Nexus 2000

Nexus 5020

Nexus 2000

Figure 17 vPC Peered Dual-Supervisor Virtual Modular System Dual-Homed FEXs and

Singled-Homed FEXs

Aggregation

Nexus 5010

Nexus 2000

Nexus 5020

Nexus 2000


37

Monitoring the Upgrade Status

Figure 18

Nexus 5010

Cisco Nexus Devices Connected to Downstream Switches

Nexus 5020

To upgrade the access layer without a disruption to hosts, follow these tasks:

•

•

Upgrade the first vPC switch (vPC primary switch). During this upgrade, the switch is reloaded.

When the switch is reloaded, the servers or the downstream switch detects a loss of connectivity to the first switch and starts forwarding traffic to the second (vPC secondary) switch.

Verify that the upgrade of the switch has completed successfully. At the completion of the upgrade, the switch restores vPC peering, connected Cisco Nexus Fabric Extenders, and all the links.

•

•

Upgrade the second switch. Repeating the same process on the second switch causes the second switch to reload during the upgrade process. During this reload, the first (upgraded) switch forwards all the traffic to/from servers.

Verify that the upgrade of the second switch has completed successfully.

Note Flows that are forwarded to a switch during an upgrade on the switch, fails over to the second switch.

Also, flows are redistributed when vPC peers are active. The traffic disruption is limited to the time required for the server or host to detect the link-down and link-up events and to redistribute the flows.

Note Upgrading Cisco NX-OS Software by changing the boot-variables and performing a reload is not supported in Cisco Nexus 5000 and 6000 Series Switches. This may result in loss of configuration and forwarding issues.

Monitoring the Upgrade Status

Table 8 lists the

show commands that are used to monitor installation upgrades.

Table 8 Monitoring the Upgrade Process

Command show fex show install all failure-reason show install all status show system internal log install details

Definition

Displays the Fabric Extender status during an ISSU.

Displays the applications that failed during an installation and why the installation failed.

Displays a high-level log of the installation.

Displays detailed logs of the last installation-related command.

38


Downgrading from a Higher Release

Table 8 Monitoring the Upgrade Process (continued)

Command show system internal log install history show tech-support

Definition

Displays detailed logs of the last five installation-related commands, from the oldest to the newest logs.

Displays the system and configuration information that you can provide to the Cisco Technical Assistance Center when reporting a problem.

This example shows the output from the show install all status command:

There is an on-going installation...

Enter Ctrl-C to go back to the prompt.

Continuing with installation process, please wait.

The login will be disabled until the installation is completed.

Performing supervisor state verification.

SUCCESS

Supervisor non-disruptive upgrade successful.

Pre-loading modules.

SUCCESS

Module 198: Non-disruptive upgrading.

SUCCESS

Module 199: Non-disruptive upgrading.

SUCCESS

Install has been successful. (hit Ctrl-C here)

This example shows the output from the show fex command on two vPC peer switches where FEX 126,

FEX 127, and FEX 133 are upgraded: switch-1(config)# sh fex

FEX FEX FEX FEX


------------------------------------------------------------------------

126 FEX126 FEX AA Upg Idle N2K-C2232TM-E-10GE SSI153501JG


133 FEX133 Online N2K-C2232PP-10GE SSI1350065L switch-2(config)# sh fex

FEX FEX FEX FEX


------------------------------------------------------------------------

126 FEX126 Hitless Upg Idle N2K-C2232TM-E-10GE SSI153501JG


133 FEX133 Online N2K-C2232PP-10GE SSI1350065L

Downgrading from a Higher Release

The procedure for entering the install all command to downgrade the switch is identical to using the install all command for a switch upgrade, except that the image files to be loaded are for an earlier release than the image that is currently running on the switch. You can use the show incompatibility


39

Troubleshooting ISSUs and Disruptive Installations system command to ensure that there are no feature incompatibilities between the current release and the target release. Note that downgrades are disruptive. Refer to the release-specific information section to get information about certain downgrades that are nondisruptive.

Note Before you downgrade to a specific release, check the release notes for the current release installed on the switch to ensure that your hardware is compatible with the specific release. You must be aware of special caveats before you downgrade the switch software to a Cisco NX-OS 4.0(0)-based release. See the Release Notes for your platform for details.

Troubleshooting ISSUs and Disruptive Installations

Some common causes for ISSU failure are as follows:

•

•

•

ISSU requirements are not met—Bridge Assurance is active or the switch is not a leaf node in the

STP topology. These problems are described in the commands explained in the

“ISSU Prerequisites” section on page 15 .

bootflash: does not have enough space to accept the updated image.

The specified system and kickstart are not compatible.

•

•

•

The hardware is installed or removed while the upgrade is in process.

Any power disruption that occurs while an upgrade is in progress.

The entire path for the remote server location is not specified accurately.

Related Documentation

Documentation for Cisco Nexus 5500 Series Switches and Cisco Nexus Fabric Extenders is available at the following URL: http://www.cisco.com/en/US/products/ps9670/tsd_products_support_series_home.html

The documentation set includes the following types of documents:

•

•

•

Licensing Information Guide

Release Notes

Installation and Upgrade Guides

•

•

•

•

Configuration Guides

Configuration Examples and TechNotes

Programming Guides

•

•

•

•

Operations Guides

Error and System Message Guides

Field Notices

Security Advisories, Responses and Notices

•

•

Troubleshooting Guide

Command References

MIB Reference Guide


40

Obtaining Documentation and Submitting a Service Request

Documentation Feedback

To provide technical feedback on this document or to report an error or ommission, please send your comments to [email protected]

. We appreciate your feedback.

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, using the Cisco Bug Search Tool (BST), submitting a service request, and gathering additional information, see What’s New in Cisco Product Documentation at: http://www.cisco.com/c/en/us/td/docs/general/whatsnew/whatsnew.html

.

Subscribe to What’s New in Cisco Product Documentation , which lists all new and revised

Cisco technical documentation as an RSS feed and delivers content directly to your desktop using a reader application. The RSS feeds are a free service.


41

42


Cisco Nexus 5020 Switch Installation Guide

Cisco Nexus 5500 Series NX-OS Software

Upgrade and Downgrade Guide, Release

7.1(0)N1(1a)

Information About Software Images

Supported Hardware

Cisco Nexus 5500 Platform Switches and Associated Expansion Modules

Upgrade Guidelines

Using the Install All Command

Upgrading the BIOS and Power Sequencer Images

Impact of Upgrades and Downgrades

In-Service Software Upgrades

ISSU and Layer 3

ISSU Supported Topologies

ISSU Support For Cisco Nexus Fabric Extenders

ISSU Support for vPC Topologies

Verifying the vPC Status on a Peer Switch During an Upgrade

Viewing System Messages on Peer Switches

ISSU Support for vPC Topologies with Fabric Extenders

ISSU Support with Fibre Channel and FCoE Topologies

Summary of ISSU-Supported Topologies

Summary of ISSU Unsupported Topologies

ISSU Prerequisites

Management Services After an ISSU

Fibre Channel/FCoE Protocol and Services During an ISSU

Layer-2 Protocols Impact

Ethernet Interfaces on the Switch and the Fabric Extenders

PreInstallation Checks

Upgrading Procedures

Installation At-a-Glance

Copying the Running Configuration from an External Flash Memory Device

Copying the Startup Configuration from an External Flash Memory Device

Upgrade Process in a Non-vPC Topology

Upgrade Process for a vPC Topology on the Primary Switch

Upgrade Process for a vPC Topology on the Secondary Switch

Disruptive Installation Process

Forcing an Upgrade

Upgrading from Cisco NX-OS Release 5.1(3)N2(1c) and Earlier

Releases (Disruptive Upgrade)

DETAILED STEPS

Minimizing the Impact of a Disruptive Upgrade

Upgrading a Direct vPC or a Single-Homed FEX Access Layer

Monitoring the Upgrade Status

Downgrading from a Higher Release

Troubleshooting ISSUs and Disruptive Installations

Related Documentation

Documentation Feedback

Obtaining Documentation and Submitting a Service Request

Related manuals

Cisco

Nexus 5020

Cisco

Nexus 5010

Cisco

Nexus 5020

Cisco

Nexus 5010

Cisco

Nexus 5548P Switch

Cisco

Nexus 2000 Series Fabric Extenders