Cisco Nexus 7000 Series NX-OS Software Upgrade and

For more information on configuration sessions, see the Cisco Nexus 7000 Series NX-OS System Management Configuration Guide.

Cisco NX-OS Software Upgrade Guidelines

Note

Cisco Nexus 7000 Series NX-OS Release Notes contain specific upgrade guidelines for each release. See the Release Notes document for the target upgrade release before starting the upgrade.

Before attempting to use ISSU to upgrade to any software image version, follow these guidelines:

• Scheduling

Schedule the upgrade when your network is stable and steady. Ensure that everyone who has access to the device or the network is not configuring the device or the network during this time. You cannot configure a device during an upgrade.

• Space

Verify that sufficient space is available in the location where you are copying the images. This location includes the active and standby supervisor module bootflash: (internal to the device). Internal bootflash: has approximately 250 MB of free space available.

• Hardware

Avoid power interruption during any install procedure, which 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 device has a route to the remote server. The device and the remote server must be in the same subnetwork if you do not have a router to route traffic between subnets.

• Software images

◦Ensure that the specified system and kickstart images are compatible with each other.

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

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

◦Retrieve the 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 using the remote server parameters and the filename to be used locally.

ISSU Paths for Cisco NX-OS Release 8.2(1)

See the below for the in-service software upgrade (ISSU) path to Cisco NX-OS Release 8.2(1).

5

Table 1: Supported ISSU Paths for the Cisco Nexus 7000 Series Platform (Cisco NX-OS Release 8.2(1))

Target Release

NX-OS Release 8.2(1)

Current Release Supporting Direct ISSU Upgrade to Target

Release

8.1(1)

8.0(1)

7.3(2)D1(1)

Note

Multi-hop ISSU is not supported. If you are upgrading from any release other than the non-disruptive upgrade releases listed in the above table, a reload is required.




Target Release



Release

8.0(1)

7.3(1)D1(1)

7.3(0)DX(1)

7.3(0)D1(1)

Note





Target Release



Release

7.3(1)D1(1)

7.3(0)DX(1)

7.3(0)D1(1)

6

Note


In-Service Software Upgrade (ISSU)

To perform an ISSU upgrade to Cisco NX-OS Release 8.0(1) and later releases, follow these steps:

1

Enter the show running-config aclmgr inactive-if-config command for all VDCs.

2

Enter the clear inactive-config acl command for all VDCs.

3

If the configuration has any mac packet-classify configurations on any interfaces, remove all of the configurations by entering the no mac packet-classify command.

4

Start the ISSU procedure.

In-Service Software Upgrade (ISSU) Caveats

• When you perform ISSU to upgrade to a new Cisco NX-OS release, the default CoPP policy for the new release is not applied.

Because you might have your own configured CoPP policy and want to continue using it, the policy for the earlier release continues to be applied. However, if you have not modified the default CoPP policy in earlier versions, it is recommended that when you install Cisco NX-OS Release 5.2 or later releases, you should apply the latest default CoPP policy for the upgrading version by using the copp profile [strict | moderate | lenient] command. This action removes the previous policy and applies a new CoPP policy. Note that reapplying copp profile configuration removes CoPP momentarily on the chassis for the new configuration to take into effect. Hence, this needs to be done in a maintained environment.

• ISSU upgrade from Cisco NX-OS 7.3.x releases to Cisco NX-OS Release 8.0(1) with RISE configuration:

◦RISE configuration must be removed prior to starting your upgrade to Cisco NX-OS Release 8.0(1). ISSU performs compatibility check and blocks the upgrade if RISE is configured.

◦If the RISE feature is not configured, there is no impact on the ISSU.

◦If the RISE feature is configured you will be prompted to remove this feature in order to proceed with the ISSU.

You can proceed with the upgrade only after you disable this feature.

◦Sample CLI Output

"Running-config contains configuration that is incompatible with the new image (strict incompatibility).

Please run 'show incompatibility-all system <image>' command to find out which feature needs to be disabled.

”.

Pre-upgrade check failed. Return code 0x40930029 (Current running-config is not supported by new image).

switch# show incompatibility-all system n7000-s2-dk9.8.0.1.bin

Checking incompatible configuration(s) for vdc 'switch':

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

No incompatible configurations

Checking dynamic incompatibilities for vdc 'switch':

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

Service : iscm , UUID: 1144 Description : Rise ISSU script Compatibility requirement: STRICT

Workaround:

ISSU from version < 8.0(1) not supported when Rise feature is enabled.

7

• ISSU upgrade from Cisco NX-OS 7.3.x releases to Cisco NX-OS Release 8.0(1) with VXLAN configuration in a vPC setup:

ISSU upgrade from Cisco NX-OS 7.3.x releases to Cisco NX-OS Release 8.0(1) with VXLAN configuration in a vPC setup can result in a traffic loss when the second vPC peer is upgraded.

The following upgrade steps are recommended as the workaround for this issue:

◦Shutdown vPC on the vPC secondary and reload with 8.0(1).

◦Perform no shut vpc after the system is operational.

◦Perform a vPC role change so that vPC secondary becomes a vPC primary.

◦Shutdown vPC on the other peer that is still running 7.3 release and reload with 8.0(1).

◦Perform no shut vpc after the system is operational.

◦Optionally, a vPC role change can be performed to get the latest peer back to vPC primary.

• If ISSU fails during a FEX module upgrade, you need to clear the flash as per the following steps and then proceed with the upgrade:

◦rlogin to the failing FEX—rlogin 192.0.2.<FEX-ID> -l root

◦umount /mnt/cfg

◦flash_eraseall /dev/mtd5

◦mount -t jffs2 -rw /dev/mtdblock5 /mnt/cfg

The mount command enables you to mount a file from a source folder to a destination folder.

• FCoE FEX

◦Post ISSU you need to change port-channel load-balance for FEX, from default VDC, in order to apply load-balancing for SAN traffic.

Device(config)# port-channel load-balance src-dst mac fex 101

◦You can revert back to default load-balance after changing the load-balance for FEX.

• For details on ISSU for other earlier releases refer to the following: http://www.cisco.com/c/en/us/td/docs/switches/datacenter/ sw/7_x/nx-os/release/notes/7x_nx-os_r elease_note.html.

• For multi-hop ISSU scenario for releases earlier than Cisco NX-OS Release 7.2(0) refer to the following: http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/release/notes/62_nx-os_r elease_note.html#pgfId-812362 .

Non In-Service Software Upgrade (Non-ISSU)/Cold Boot Upgrade Steps

Cisco NX-OS Release 8.2(1) has the following cold boot support matrix:

Target Release Current Release Supporting Cold-Boot Upgrade to Target Release

8

8.2(1) 8.1(1)

8.0(1)

7.3(2)D1(1)

7.3(1)D1(1)

7.3(0)DX(1)

7.3(0)D1(1)

7.2(2)D1(2)

7.2(2)D1(1)

7.2(1)D1(1)

7.2(0)D1(1)

6.2(18)

6.2(16)

6.2(14)

6.2(12)

6.2(10)

6.2(8b)

6.2(8a)

6.1(5a)

Note

Non-ISSU upgrades are also referred to as cold boot upgrade.



9

8.1(1) 8.0(1)

7.3(2)D1(1)

7.3(1)D1(1)

7.3(0)DX(1)

7.3(0)D1(1)

7.2(2)D1(2)

7.2(2)D1(1)

7.2(1)D1(1)

7.2(0)D1(1)

6.2(18)

6.2(16)

6.2(14)

6.2(12)

6.2(10)

6.2(8b)

6.2(8a)

6.1(5a)

Note




10

8.0(1) 7.3(2)D1(1)

7.3(1)D1(1)

7.3(0)DX(1)

7.3(0)D1(1)

7.2(2)D1(2)

7.2(2)D1(1)

7.2(1)D1(1)

7.2(0)D1(1)

6.2(18)

6.2(16)

6.2(14)

6.2(12)

6.2(10)

6.1(5a)

Note


To perform a non-ISSU upgrade (cold boot upgrade) to Cisco NX-OS Release 8.0(1) and later releases from any prior supported releases in the above table follow these steps:

1

Change the boot variable.

Example for Cisco NX-OS Release 8.2(1): boot kickstart bootflash:/n7000-s2-kickstart.8.2.1.bin sup-1 boot system bootflash:/n7000-s2-dk9.8.2.1.bin sup-1 boot kickstart bootflash:/n7000-s2-kickstart.8.2.1.bin sup-2 boot system bootflash:/n7000-s2-dk9.8.2.1.bin sup-2



2

Enter the copy running-config startup-config vdc-all command.

3

Enter the reload command to reload the switch.

Note

Allow time after the reload for the configuration to be applied.

11

Reload based NXOS downgrades involve rebuilding the internal binary configuration from the text-based startup configuration. This is done to ensure compatibility between the binary configuration and the downgraded software version. As a result, certain specific configuration may be missing from the configuration, after downgrade, due to ASCII replay process. This would include FEX HIF port configuration and VTP database configuration. Furthermore, NX-OS configurations that require VDC or switch reload to take effect may require additional reload when applied during the downgrade process. Examples of this include URIB/MRIB shared memory tuning, custom reserved VLAN range and Fabricpath Transit Mode feature. In order to mitigate this during downgrade, you should copy your full configuration to bootflash/tftpserver.

Feature Support:

Any features introduced in a release must be disabled before downgrading to a release that does not support those features.

Unsupported Modules:

When manually downgrading from a Cisco NX-OS Release to an earlier release, first power down all modules that are unsupported in the downgrade image. Then, purge the configuration of the unsupported modules using the purge module module_number

running-config command.

For complete instructions on upgrading your software, see the Cisco Nexus 7000 Series NX-OS Upgrade Downgrade Guide.

Non-In-Service Software Upgrade (Non-ISSU)/Cold Boot Upgrade Caveats

• When you perform a cold boot upgrade to a new Cisco NX-OS release, the default CoPP policy for the new release is not applied. Because you might have your own configured CoPP policy and want to continue using it, the policy for the earlier release continues to be applied. However, if you have not modified the default CoPP policy in earlier versions, it is recommended that when you install Cisco NX-OS Release 5.2 or later releases, you should apply the latest default CoPP policy for the upgrading version by using the copp profile [strict | moderate | lenient] command. This action removes the previous policy and applies a new CoPP policy. Note that reapplying copp profile configuration removes CoPP momentarily on the chassis for the new configuration to take into effect. Hence, this needs to be done in a maintained environment.

Cold boot/Reload upgrades from Cisco NX-OS 7.3.x releases to Cisco NX-OS Release 8.0(1) and Cisco NX-OS Release 8.1(1) with RISE Configuration

• RISE configuration must be removed prior to starting your upgrade to Cisco NX-OS Release 8.0(1)/Cisco NX-OS Release

8.1(1). ISSU performs compatibility check and blocks the upgrade if RISE is configured. There is no warning displayed or prevention for the reload upgrade. Therefore make sure to remove RISE configuration before the reload upgrade.

◦There is no system check to block this upgrade path.

◦Ensure that the RISE feature is disabled before attempting to upgrade to Cisco NX-OS Release 8.0(1)/Cisco NX-OS

Release 8.1(1). After upgrading to Cisco NX-OS Release 8.0(1)/Cisco NX-OS Release 8.1(1), configure RISE services as required. The RISE feature configuration can be verified by using the show rise and show run services sc_engine commands.

◦If you upgrade to Cisco NX-OS Release 8.0(1)/Cisco NX-OS Release 8.1(1) with the RISE configuration, RISE services will become unstable and unmanageable.

◦Steps to identify the error condition:

Even if the show feature command output shows RISE as enabled, no output will be displayed if you run the show

rise and show run services sc_engine commands.

◦Steps to recover:

The only way to recover from this condition is to do a reload ascii on the switch.

ASCII Configuration Replay

12

Saving VLAN Configuration Information:

Because a VLAN configuration can be learned from the network while the VLAN Trunking Protocol (VTP) is in a server/client mode, the VLAN configuration is not stored in the running configuration. If you copy the running configuration to a file and apply this configuration at a later point, including after a switch reload, the VLANs will not be restored. However, the VLAN configuration will be erased if the switch is the only server in the VTP domain.

The following steps list the workaround for this limitation:

• Configure one of the clients as the server.

• Complete the following steps:

◦Copy the VTP data file to the bootflash: data file by entering the copy vtp-datafile bootflash: vtp-datafile command.

◦Copy the ASCII configuration to the startup configuration by entering the copy ascii-cfg-file startup-config command.

◦Reload the switch with Cisco NX-OS Release 6.2(2) or a later release.

This limitation does not apply to a binary configuration, which is the recommended approach, but only to an ASCII configuration.

In addition, this limitation applies to all Cisco NX-OS software releases for the Cisco Nexus 7000 series.

Rebind Interfaces command is not automatically executed when Replaying ASCII configuration in Cisco NX-OS Release

6.2(x):

The rebind interfaces command introduced in Cisco NX-OS Release 6.2(2) is needed to ensure the proper functionality of interfaces in certain circumstances. The command might be required when you change the module type of a VDC. However, because of the disruptive nature of the rebind interfaces command, for Cisco NX-OS Release 6.2(x) prior to Cisco NX-OS Release 6.2(8), this limitation applies only when all of the following conditions are met:

• The ASCII configuration file is replayed in the context of the default VDC or the admin VDC, and at least one VDC has an F2e

Series or an F3 Series module listed as supported module types either before or after the replay.

• The limit-resource module-type commands listed in the ASCII configuration file requires that rebind interfaces command be executed.

The following steps list the workaround for this limitation:

• Manually enter the rebind interfaces command wherever needed to the ASCII configuration file for replay.

• Enter the rebind interfaces command immediately after you enter the limit-resource module-type command.

• Ensure that the ASCII replay properly applies all interface configurations for all interfaces in the relevant VDCs.

Note

If you boot up the switch without any startup configuration, this limitation might apply to an ASCII replay.

The reason is that without a startup configuration, the default VDC might still have certain interfaces automatically allocated. Because of this possibility, follow the approaches to work around the limitation.

Non In-Service Software Downgrade (non-ISSU)/Cold Boot Downgrade Steps

Instructions provided below list the steps for the cold boot (non-ISSU) downgrade. The example provided below is for a cold boot downgrade for the following:

• A switch that is running Cisco NX-OS Release 8.2(1) and needs to reload with Cisco NX-OSRelease 6.2(8a).

• A switch that is running Cisco NX-OS Release 8.1(1) and needs to reload with Cisco NX-OSRelease 6.2(8a).

13

• A switch that is running Cisco NX-OS Release 8.0(1) and needs to reload with Cisco NX-OSRelease 6.2(12).

Refer to the ASCII Configuration Replay caveats section for specific configuration caveats.

• Save the switch configuration.

◦Enter copy running-config bootflash:<config.txt> vdc-all command.

• Change the boot variable to boot the target release.

• Enter copy running-config startup-config vdc-all command to save the boot variable.

• Enter write erase command to erase running configuration on the switch.

• Enter reload command.

Once the switch and all the modules are up with the target image, do the following:

• Enter the copy bootflash:<config.txt> running-config command.

• Verify that the switch is configured correctly.

• Replay the configuration copy to check if fex interfaces exist.

◦Enter the copy bootflash:<config.txt> running-config command.

Terminology

This table summarizes the terms used in the install all command output for checking compatibility.

Table 4: install all Command Output Terminology

Term

bootable impact install-type reset sw-reset rolling copy-only

Definition

The module's ability to boot or not boot based on image compatibility.

The type of software upgrade mechanism—disruptive or nondisruptive.

Resets the module.

Resets the module immediately after a switchover.

Upgrades each module in sequence.

Updates the software for BIOS, loader, or bootrom.

Commands to use

• Verify connectivity to the remote server using the ping command.

14

Cisco Nexus 7000 Series NX-OS Software Upgrade and

Cisco NX-OS Software Upgrade Guidelines

Related manuals

Table of contents

Cisco Nexus 7000 Series NX-OS Software Upgrade and

Cisco NX-OS Software Upgrade Guidelines

Related manuals

Cisco

Nexus 7000 4-Slot

Cisco

Nexus 7700 18-Slot Switch

Cisco

Nexus 7000 4-Slot

Cisco

Nexus 7000 10-Slot

Cisco

Nexus 5010

Cisco

Nexus 5010

Cisco

Nexus 5020

Cisco

Nexus 5020

Table of contents