· Separation of service features from basic functions—Device software is segmented into boot, system, and feature images. The images can be upgraded individually.

· Independence between service features—Features run independently. One feature can be added or upgraded without affecting the operation of the system or other features.

· Support for hotfix—Patch images are available to fix system bugs without a system reboot.

· Hardware redundancy—In an IRF fabric, one member device can be upgraded while other member devices are providing services.

For more information about images, see "Upgrading software."

ISSU methods

ISSU supports the following upgrade types:

· Compatible upgrade—The running software version is compatible with the upgrade software version. This upgrade type supports the ISSU methods in Table 1.

· Incompatible upgrade—The running software version is incompatible with the upgrade software version. The two versions cannot run concurrently.

This upgrade type supports only one upgrade method (also called incompatible upgrade). This method requires a cold reboot. It is service disruptive if hardware redundancy is not available.

Table 1 ISSU methods for compatible upgrade

ISSU method	Description
Incremental upgrade: · Service Upgrade · File Upgrade	Upgrades only segments that contain differences between the new and old software versions. · Service upgrade—Upgrades service features. The upgrade does not affect the operation of features that are not being upgraded. · File upgrade—Upgrades hidden system program files. The system can provide services during the upgrade.
ISSU Reboot	Reboots CPUs to complete software upgrade. During the reboot, the data plane can still forward traffic. This method saves all data (running, configuration, and hardware) and status to memory before rebooting CPUs. For services that require regular communication with their peers, this method uses protocol agents to maintain their connectivity and status. After the reboot, all data is restored to CPU.
Reboot	CAUTION: The Reboot method is service disruptive if the device stands alone. As a best practice, schedule the downtime carefully to minimize the upgrade impact on the services. This method reboots both the control and data planes to complete the software upgrade.

ISSU commands

ISSU provides the install and issu command sets. After you identify the ISSU method, use Table 2 to choose the command set you want to use.

Table 2 Command set comparison

Item	issu commands	install commands
Upgrade types	· Compatible. · Incompatible.	Compatible.
Patch install/uninstall	Not supported.	Supported.
Upgrade mode	Chassis by chassis.	Chassis by chassis.
Impact on the system	Large.	Small.
Technical skill requirements	Low. As a best practice, use this command set.	High. Administrators must have extensive system knowledge and understand the impact of each upgrade task on the network.

Preparing for ISSU

To perform a successful ISSU, make sure all the preparation requirements are met.

Identifying availability of ISSU and licensing requirements

Read the software release notes to identify the following items:

· Support of the device for ISSU.

· Licensing requirements for the upgrade software images.

If the upgrade software images require licenses, make sure the device has the required licenses before ISSU. For more information about license installation, see "Managing licenses."

Verifying the device operating status

Use the display device command to verify that all member devices are operating correctly.

1. Use the dir command to verify that all member devices has sufficient storage space for the upgrade images. If the storage space is not sufficient, delete unused files by using the delete command. For more information, see "Managing the file system."

2. Use FTP or TFTP to transfer upgrade image files to the root directory of any storage medium in the IRF fabric.

Identifying the ISSU method

1. Execute the display version comp-matrix file command for the upgrade image version.

2. Check the Version compatibility list field.

¡ If the running software version is in the list, a compatible upgrade is required.

¡ If the running software version is not in the list, an incompatible upgrade is required.

3. Identify the ISSU method:

¡ If a compatible upgrade is required, check the Upgrade Way field to identify the ISSU method. For more information about ISSU methods, see Table 1.

¡ If an incompatible upgrade is required, check the end of command output for the Incompatible upgrade string.

Verifying feature status

For service continuity during ISSU, configure the following feature settings:

Feature	Setting requirements
GR/NSR	Enable GR or NSR for protocols including LDP, RSVP, OSPF, ISIS, BGP, and FSPF.
BFD	Disable BFD for protocols including LDP, RSVP, OSPF, ISIS, RIP, BGP, VRRP, and NQA.
Ethernet link aggregation	Use the long LACP timeout interval (the lacp period short command is not configured) on all member ports in dynamic aggregation groups.
IRF	Configure IRF bridge MAC persistence as follows: · Compatible upgrade—Configure the irf mac-address persistent timer or irf mac-address persistent always command. · Incompatible upgrade—Configure the irf mac-address persistent always command if the bridge MAC address is the MAC address of the device for which you want to execute the issu load command.

For an ISSU Reboot upgrade on a single-member IRF fabric, also verify that the following features are disabled:

Feature	Remarks
Spanning tree feature	If the spanning tree feature is enabled, service discontinuity might occur during the upgrade because the feature advertises the network topology change.
Dynamic Ethernet link aggregation	During an ISSU reboot, only static aggregation is supported, and dynamic aggregate interfaces might not be able to provide services.
CFD	If CFD is enabled, the CFD CC feature will be disabled during an ISSU reboot, which results in traffic abnormality.
DLDP	If DLDP is enabled, the peer device might consider a link a unidirectional link and shut down the port because it cannot receive probe packets.
Loop detection	If loop detection is enabled, the peer device might enable looped ports because of false loop removal detection.

Determining the upgrade procedure

1. Use Table 2 to choose an upgrade command set, depending on the ISSU method.

2. Identify the hardware redundancy condition.

ISSU can maintain service continuity only when the IRF fabric has multiple members and uses the ring topology.

IMPORTANT:

If hardware redundancy is not available, service discontinuity is not avoidable. Make sure you understand the impact of the upgrade on the network.

3. Choose the correct procedure from the procedures described in "Performing an ISSU by using issu commands" or "Performing an ISSU by using install commands."

Understanding ISSU guidelines

During an ISSU, use the following guidelines:

· In a multiuser environment, make sure no other administrators access the device while you are performing the ISSU.

· Do not perform any of the following tasks during an ISSU:

¡ Reboot, add, or remove member devices.

¡ Execute commands that are not related to the ISSU.

¡ Modify, delete, or rename image files.

· You cannot use both install and issu commands for an ISSU. However, you can use display issu commands with both command sets.

· The following protocols will recalculate topology after an ISSU reboot if a peer keepalive timeout has occurred:

¡ Multicast protocols—PIM, IGMP, MLD, IGMP snooping, and MLD snooping.

¡ Routing protocols—OSPF, IS-IS, and BGP.

¡ FCoE—FIP snooping and FSPF.

After an ISSU, you must log in to the device again before you can configure the device.

Logging in to the device through the console port

Log in to the device through the console port after you finish all the preparation tasks and understand all the ISSU guidelines. If you use Telnet or SSH, you might be disconnected from the device before the ISSU is completed.

Saving the running configuration

Use the save command to save the running configuration.

Performing an ISSU by using issu commands

The ISSU procedure varies depending on whether the IRF fabric has a single or multiple members.

Upgrading a multichassis IRF fabric

Performing a compatible upgrade

For a compatible upgrade on a multichassis IRF fabric, upgrade a subordinate member first. Then, upgrade the master and the other subordinate members.

To perform a compatible upgrade:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. (Optional.) Set the automatic rollback timer.	issu rollback-timer minutes	By default, the automatic rollback timer is set to 45 minutes. This timer starts when you execute the issu run switchover command. If you do not execute the issu accept or issu commit command before this timer expires, the system automatically rolls back to the original software images.
3. Return to user view.	quit	N/A
4. Load the upgrade images as main startup software images on subordinate members.	· Use .bin files: issu load file { boot filename \| system filename \| feature filename&<1-30> } * slot slot-number&<1-9> · Use an .ipe file: issu load file ipe ipe-filename slot slot-number&<1-9>	Specify the member ID of a subordinate member for the slot-number argument.
5. Perform a master/subordinate switchover.	issu run switchover	N/A
6. (Optional.) Accept the upgrade and delete the automatic rollback timer.	issu accept	N/A
7. Upgrade the remaining members to complete the ISSU.	issu commit chassis chassis-number	IMPORTANT: After executing the command for one member, you must wait for the member to restart and join the IRF fabric before you execute the command for another member. Repeat the issu commit command to upgrade the remaining members one by one, including the original master. To manually roll back to the original software images during this ISSU process, use the issu rollback command. For more information about rollback, see Fundamentals Command Reference.

Performing an incompatible upgrade

For an incompatible upgrade on a multichassis IRF fabric, upgrade one or more subordinate members first. As a best practice, upgrade half of the subordinate members first. Then, upgrade the master and the other subordinate members.

Perform this task in user view.

Step	Command	Remarks
1. Load the upgrade images as main startup software images on subordinate members.	· Use .bin files: issu load file { boot filename \| system filename \| feature filename&<1-30> } * slot slot-number&<1-9> · Use an .ipe file: issu load file ipe ipe-filename slot slot-number&<1-9>	Specify the member ID of a subordinate member for the slot-number argument. As a best practice on a ring-topology IRF fabric, specify half of the subordinate members for this command to reduce service interruption. Make sure the specified subordinate members are physically connected.
2. Perform a master/subordinate switchover to complete the ISSU process.	issu run switchover	To roll back to the original software images during this ISSU process, use the issu rollback command. This ISSU process does not support automatic rollback. For more information about rollback, see Fundamentals Command Reference.
3. Verify that the ISSU is finished.	display issu state	If the ISSU state field displays Init, the ISSU is finished.

Upgrading a single-chassis IRF fabric

Performing a service upgrade or file upgrade

Perform this task in user view.

Step	Command	Remarks
1. Load the upgrade images as main startup software images.	· Use .bin files: issu load file { boot filename \| system filename \| feature filename&<1-30> } * slot slot-number · Use an .ipe file: issu load file ipe ipe-filename slot slot-number	Specify the member ID of the device for the slot-number argument.
2. Complete the ISSU process.	issu commit slot slot-number	Specify the member ID of the device for the slot-number argument. To roll back to the original software images during this ISSU process, use the issu rollback command. This ISSU process does not support automatic rollback. For more information about rollback, see Fundamentals Command Reference.
3. Verify that the ISSU is finished.	display issu state	If the ISSU state field displays Init, the ISSU is finished.

Performing a reboot/ISSU reboot/incompatible upgrade

Step	Command	Remarks
1. Load the upgrade images as main startup software images.	· Use .bin files: issu load file { boot filename \| system filename \| feature filename&<1-30> } * slot slot-number · Use an .ipe file: issu load file ipe ipe-filename slot slot-number	Specify the member ID of the device for the slot-number argument.
2. Verify that the ISSU is finished.	display issu state	If the ISSU state field displays Init, the ISSU is finished.

Step

Command

Remarks

1. Load the upgrade images as main startup software images.

· Use .bin files:
issu load file { boot filename | system filename | feature filename&<1-30> } * slot slot-number

· Use an .ipe file:
issu load file ipe ipe-filename slot slot-number

Specify the member ID of the device for the slot-number argument.

2. Verify that the ISSU is finished.

display issu state

If the ISSU state field displays Init, the ISSU is finished.

Performing an ISSU by using install commands

ISSU task list

Tasks at a glance	Remarks
(Optional.) Decompressing an .ipe file	To use install commands for upgrade, you must use .bin image files. If the upgrade file is an .ipe file, perform this task before you use install commands for upgrade.
(Required.) Perform one of the following tasks to update software: · Installing or upgrading software images ¡ Installing or upgrading images except for patches ¡ Installing patch images · Uninstalling feature or patch images ¡ Uninstalling feature images ¡ Uninstalling patch images	Perform an activate operation to install new images or upgrade existing images. Perform an inactivate operation to uninstall feature or patch images. An image is added to or removed from the current software image list when it is activated or deactivated.
(Optional.) Rolling back the running software images	Perform this task to roll back running software image status after activate or deactivate operations. A commit operation removes all rollback points. You can perform this task only before software changes are committed.
(Optional.) Aborting a software activate/deactivate operation	You can perform this task while an image is being activated or deactivated. This task is available only for service upgrade or file upgrade.
(Optional.) Committing software changes	This task updates the main startup image list with the changes. If service upgrade or file upgrade is performed, you must perform this task for the changes to take effect after a reboot.
(Optional.) Verifying software images	Perform this task to verify that the software changes are correct.
(Optional.) Removing inactive software images	Perform this task to remove images

Decompressing an .ipe file

Perform this task in user view.

Step	Command
1. (Optional.) Identify images that are included in the .ipe file.	display install ipe-info
2. Decompress the .ipe file.	install add ipe-filename medium-name:

Installing or upgrading software images

Restrictions and guidelines

Use one of the following methods to perform this task:

· Chassis by chassis—Activate all the images on one member device, and then move to the next member device.

· Image by image—Activate one image on all member devices before activating another image.

To install an image, you must begin with the master device. To upgrade an image, you must begin with a subordinate device.

You can install up to 32 .bin files on the device, including one boot image file, one system image file, and up to 30 feature or patch image files.

Installing or upgrading images except for patches

Perform this task in user view.

Step	Command
1. (Optional.) Identify the ISSU method and possible impacts of the upgrade.	install activate { boot filename \| system filename \| feature filename&<1-30> } * slot slot-number test
2. Activate images.	install activate { boot filename \| system filename \| feature filename&<1-30> } * slot slot-number

Installing patch images

Before installing patch images, check whether the device is already running patch images.

· If not, install patch images.

· If yes, read the release notes to identify the functionality differences between the running patch images and the new patch images.

¡ If the new patch images cover all functions provided by the old patch images, loading the patch images overwrites the old patch images. After installing the new patch images, delete the old patch images from the storage medium to release the storage space.

¡ If the new patch images do not cover one or more functions provided by the old patch images, loading the patch images does not affect the old patch images. The device uses both the new patch images and the old patch images. Do not uninstall or delete the old patch images.

Perform this task in user view.

Task	Command
Activate patch images.	install activate patch filename { all \| slot slot-number }

Uninstalling feature or patch images

The uninstall operation only removes images from the current software image list. For the change to take effect after a reboot, you must perform a commit operation to remove the images from the main startup image list.

Uninstalled images are still stored on the storage medium. To permanently remove the images, execute the install remove command. For more information, see "Removing inactive software images."

Boot and system images cannot be uninstalled.

Uninstalling feature images

Perform this task in user view.

Task	Command
Deactivate feature images.	install deactivate feature filename&<1-30> slot slot-number

Uninstalling patch images

Perform this task in user view.

Task	Command
Deactivate patch images.	install deactivate patch { all \| filename slot slot-number }

Rolling back the running software images

For each service or file upgrade performed through activate or deactivate operation, the system creates a rollback point. The rollback points are retained until any of the following event occurs:

· An ISSU reboot or reboot upgrade is performed.

· The install commit command is executed.

After an ISSU reboot or reboot upgrade is performed, you can roll back the running software images only to the status before any activate or deactivate operations are performed.

After a commit operation is performed, you cannot perform a rollback.

For a rollback to take effect after a reboot, you must perform a commit operation to update the main startup software image list.

To roll back the software, execute the following commands in user view:

Step	Command	Remarks
1. (Optional.) Display available rollback points.	display install rollback	A maximum of 50 rollback points are available for service and file upgrades. The earliest rollback point is removed if this limit has been reached when a rollback point is created.
2. Roll back the software.	install rollback to { point-id \| original }	N/A

Aborting a software activate/deactivate operation

This task is available only for service upgrade or file upgrade performed through activate or deactivate operation. After the operation is aborted, the system runs with the software images that it was running with before the operation.

Step	Command
1. Press Ctrl+C while a software image is being activated or deactivated.	N/A
2. Abort a software activate/deactivate operation in user view.	install abort [ job-id ]

Committing software changes

If the ISSU method is service upgrade or file upgrade for an activate or deactivate operation, the main startup image list does not update with the changes. The software changes are lost at reboot. For the changes to take effect after a reboot, you must commit the changes.

Perform this task in user view.

Task	Command	Remarks
Commit the software changes.	install commit	This command commits all software changes.

Verifying software images

Perform this task to verify the following items:

· Integrity—Verify that the boot, system, and feature images are integral.

· Consistency—Verify that the same active images are running across the entire system.

· Software commit status—Verify that the active images are committed as needed.

If an image is not integral, consistent, or committed, use the install activate, install deactivate, and install commit commands as appropriate to resolve the issue.

Perform this task in user view.

Task	Command
Verify software images.	install verify

Removing inactive software images

Removing a software image deletes the image file permanently. You cannot use the install rollback to command after the operation.

Perform this task in user view.

Task	Command
Remove inactive software images.	install remove [ slot slot-number ] { filename \| inactive }

Displaying and maintaining ISSU

The display issu state command applies only to an ISSU that uses the issu series commands. All the other display commands and all reset commands can be used during an ISSU, regardless of whether the install or issu commands are used.

Execute display commands in any view and reset commands in user view.

Task	Command
Display version compatibility information.	display version comp-matrix
Display ISSU status information.	display issu state
Display automatic rollback timer information.	display issu rollback-timer
Display active software images.	display install active [ slot slot-number ] [ verbose ]
Display inactive software images.	display install inactive [ slot slot-number ] [ verbose ]
Display main startup software images.	display install committed [ slot slot-number ] [ verbose ]
Display backup startup software images.	display install backup [ slot slot-number ] [ verbose ]
Display ongoing ISSU activate, deactivate, and rollback operations.	display install job
Display ISSU log entries.	display install log [ verbose ]
Display software image file information.	display install package { filename \| all } [ verbose ]
Display the software images included in an .ipe file.	display install ipe-info ipe-filename
Display rollback point information.	display install rollback
Display all software image files that include a specific component or file.	display install which { component name \| file filename } [ slot slot-number ]
Clear ISSU log entries.	reset install log-history oldest log-number
Clear ISSU rollback points.	reset install rollback oldest point-id

Troubleshooting ISSU

Failure to execute the issu load/issu run switchover/issu commit/install activate/install deactivate command

Symptom

The following commands cannot be executed:

· issu commands—issu load, issu run switchover, and issu commit.

· install commands—install activate and install deactivate.

Solution

To resolve this issue:

1. Use the display device command to verify that all cards are not in Fault state.

2. Use the display system internal ha service-group command to verify that the Action field is 0 for each service.

3. If the problem persists, contact H3C Support.

ISSU examples for using issu commands

Software image upgrade to a compatible version

Upgrade requirements

As shown in Figure 1, the IRF fabric has two members.

Upgrade feature1 from R0201 to R0202. The two versions are compatible.

Figure 1 Network diagram

Upgrade procedure

# Save the running configuration.

<Sysname> save

# Download the image file that contains the feature1 image from the TFTP server.

<Sysname> tftp 2.2.2.2 get feature1-r0202.bin

% Total % Received % Xferd Average Speed Time Time Time Current

Dload Upload Total Spent Left Speed

100 256 100 256 0 0 764 0 --:--:-- --:--:-- --:--:-- 810

# Display active software images.

<Sysname> display install active

Active packages on slot 1:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0201.bin

Active packages on slot 2:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0201.bin

# Identify the ISSU method to be used for the upgrade and view the possible impact of the upgrade.

<Sysname> display version comp-matrix file feature flash:/feature1-r0202.bin

Feature image: flash:/feature1-r0202.bin

Version:

V700R001B31D002

Version Compatibility List:

V700R001B31D001

V700R001B31D002

Version Dependency System List:

V700R001B31D001

V700R001B31D002

Slot Upgrade Way

1 Service Upgrade

2 Service Upgrade

Influenced service according to following table on slot 1:

flash:/feature1-r0202.bin

feature1

Influenced service according to following table on slot 2:

flash:/feature1-r0202.bin

feature1

The output shows that an incremental upgrade is recommended. The feature1 module will be rebooted during the upgrade process.

# Upgrade feature1 on the subordinate member.

<Sysname> issu load file feature flash:/feature1-r0202.bin slot 2

This operation will delete the rollback point information for the previous upgrade and maybe get unsaved configuration lost. Continue? [Y/N]:y

Upgrade summary according to following table:

Copying file flash:/feature1-r0202.bin to slot2#flash:/feature1-r0202.bin......Done.

flash:/feature1-r0202.bin

Running Version New Version

Alpha 0201 Alpha 0202

Slot Upgrade Way

2 Service Upgrade

Upgrading software images to compatible versions. Continue? [Y/N]:y

This operation might take several minutes, please wait...Done.

# Perform a master/subordinate switchover.

<Sysname> issu run switchover

Upgrade summary according to following table:

flash:/feature1-r0202.bin

Running Version New Version

Alpha 0201 Alpha 0202

Slot Switchover Way

1 Active standby process switchover

Upgrading software images to compatible versions. Continue? [Y/N]:y

This operation might take several minutes, please wait...Done.

# Upgrade the feature on the original master.

<Sysname> issu commit slot 1

Upgrade summary according to following table:

flash:/feature1-r0202.bin

Running Version New Version

Alpha 0201 Alpha 0202

Slot Upgrade Way

1 Service Upgrade

Upgrading software images to compatible versions. Continue? [Y/N]:y

This operation might take several minutes, please wait...Done.

# Verify that both members are running the new image.

<Sysname> display install active

Active packages on slot 1:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0202.bin

Active packages on slot 2:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0202.bin

Software image upgrade to an incompatible version

Upgrade requirements

As shown in Figure 2, the IRF fabric has two members.

Upgrade feature1 from R0201 to R0202. The two versions are incompatible.

Figure 2 Network diagram

Upgrade procedure

# Save the running configuration.

<Sysname> save

# Download the image file that contains the R0202 feature1 image from the TFTP server.

<Sysname> tftp 2.2.2.2 get feature1-r0202.bin

% Total % Received % Xferd Average Speed Time Time Time Current

Dload Upload Total Spent Left Speed

100 256 100 256 0 0 764 0 --:--:-- --:--:-- --:--:-- 810

# Display active software images.

<Sysname> display install active

Active packages on slot 1:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0201.bin

Active packages on slot 2:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0201.bin

# Identify the ISSU method to be used for the upgrade and view the possible impact of the upgrade.

<Sysname> display version comp-matrix file feature flash:/feature1-r0202.bin

Feature image: flash:/feature1-r0202.bin

Version:

V700R001B31D002

Version Compatibility List:

V700R001B31D002

Version Dependency System List:

V700R001B31D001

V700R001B31D002

Incompatible upgrade.

The output shows that the two versions are incompatible. The cards will be rebooted for the upgrade.

# Upgrade feature1 on the subordinate member.

<Sysname> issu load file feature flash:/feature1-r0202.bin slot 2

This operation will delete the rollback point information for the previous upgrade and maybe get unsaved configuration lost. Continue? [Y/N]:y

Copying file flash:/feature1-r0202.bin to slot2#flash:/feature1-r0202.bin......Done.

Upgrade summary according to following table:

flash:/feature1-r0202.bin

Running Version New Version

Alpha 0201 Alpha 0202

Slot Upgrade Way

2 Reboot

Upgrading software images to incompatible versions. Continue? [Y/N]:y

This operation might take several minutes, please wait...Done.

# Upgrade feature1 on the original master.

<Sysname> issu run switchover

Upgrade summary according to following table:

flash:/feature1-r0202.bin

Running Version New Version

Alpha 0201 Alpha 0202

Slot Upgrade Way

1 Reboot

Upgrading software images to incompatible versions. Continue? [Y/N]:y

This operation might take several minutes, please wait...Done.

# Verify that both members are running the new image.

<Sysname> display install active

Active packages on slot 1:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0202.bin

Active packages on slot2:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0202.bin

Software image rollback example

Rollback requirement

As shown in Figure 3, the IRF fabric has two members.

Roll back feature1 from R0202 to R0201 after upgrading it from R0201 to R0202. The two versions are compatible.

Figure 3 Network diagram

Rollback procedure

# Save the running configuration.

<Sysname> save

# Download the image file that contains the R0202 feature1 image from the TFTP server.

<Sysname> tftp 2.2.2.2 get feature1-r0202.bin

% Total % Received % Xferd Average Speed Time Time Time Current

Dload Upload Total Spent Left Speed

100 256k 100 256k 0 0 764k 0 --:--:-- --:--:-- --:--:-- 810k

# Display active software images.

<Sysname> display install active

Active packages on slot 1:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0201.bin

Active packages on slot 2:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0201.bin

# Identify the ISSU method to be used for the upgrade and view the possible impact of the upgrade.

<Sysname> display version comp-matrix file feature flash:/feature1-r0202.bin

Feature image: flash:/feature1-r0202.bin

Version:

V700R001B31D002

Version Compatibility List:

V700R001B31D001

V700R001B31D002

Version Dependency System List:

V700R001B31D001

V700R001B31D002

Slot Upgrade Way

1 Service Upgrade

2 Service Upgrade

Influenced service according to following table on slot 1:

flash:/feature1-r0202.bin

feature1

Influenced service according to following table on slot 2:

flash:/feature1-r0202.bin

feature1

The output shows that an incremental upgrade is recommended, and the feature1 module will be rebooted during the upgrade process.

# Upgrade feature1 on the subordinate member.

<Sysname> issu load file feature flash:/feature1-r0202.bin slot 2

This operation will delete the rollback point information for the previous upgrade and maybe get unsaved configuration lost. Continue? [Y/N]:y

Copying file flash:/feature1-r0202.bin to slot2#flash:/feature1-r0202.bin......Done.

Upgrade summary according to following table:

flash:/feature1-r0202.bin

Running Version New Version

Alpha 0201 Alpha 0202

Slot Upgrade Way

2 Service Upgrade

Upgrading software images to compatible versions. Continue? [Y/N]:y

This operation might take several minutes, please wait...Done.

# Perform a master/subordinate switchover.

<Sysname> issu run switchover

Upgrade summary according to following table:

flash:/feature1-r0202.bin

Running Version New Version

Alpha 0201 Alpha 0202

Slot Switchover Way

1 Active standby process switchover

Upgrading software images to compatible versions. Continue? [Y/N]:y

This operation might take several minutes, please wait...Done.

# Display active software images.

<Sysname> display install active

Active packages on slot 1:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0201.bin

Active packages on slot 2:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0202.bin

# Roll back feature1 to R0201.

<Sysname> issu rollback

This command will quit the ISSU process and roll back to the previous version. Continue? [Y/N]:Y

# Verify that both members are running the old image.

<Sysname> display install active

Active packages on slot 1:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0201.bin

Active packages on slot 2:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0201.bin

ISSU examples for using install commands

Software image upgrade example

Upgrade requirements

As shown in Figure 4, the IRF fabric has two members.

Upgrade feature1 from R0201 to R0202. The two versions are compatible.

Figure 4 Network diagram

Upgrade procedure

# Save the running configuration.

<Sysname> save

# Download the .ipe file that contains the R0202 feature1 image from the TFTP server.

<Sysname> tftp 2.2.2.2 get feature1-r0202.ipe

% Total % Received % Xferd Average Speed Time Time Time Current

Dload Upload Total Spent Left Speed

100 256k 100 256k 0 0 764k 0 --:--:-- --:--:-- --:--:-- 810k

# Decompress the .ipe file.

<Sysname> install add flash:/feature1-r0202.ipe flash:

# Display active software images.

<Sysname> display install active

Active packages on slot 1:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0201.bin

Active packages on slot 2:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0201.bin

# Identify the ISSU methods for the upgrade and view the possible impact of the upgrade.

<Sysname> install activate feature flash:/feature1-r0202.bin slot 2 test

Copying file flash:/feature1-r0202.bin to slot2#flash:/feature1-r0202.bin......Done.

Upgrade summary according to following table:

flash:/feature1-r0202.bin

Running Version New Version

Alpha 0201 Alpha 0202

Slot Upgrade Way

2 Service Upgrade

Influenced service according to following table on slot 2:

flash:/feature1-r0202.bin

feature1

<Sysname> install activate feature flash:/feature1-r0202.bin slot 1 test

Upgrade summary according to following table:

flash:/feature1-r0202.bin

Running Version New Version

Alpha 0201 Alpha 0202

Slot Upgrade Way

1 Service Upgrade

Influenced service according to following table on slot 1:

flash:/feature1-r0202.bin

feature1

The output shows that both members require a service upgrade and the feature1 module will be rebooted during the upgrade process.

# Activate the new feature1 image to upgrade feature1.

<Sysname> install activate feature flash:/feature1-r0202.bin slot 2

flash:/feature1-r0202.bin already exists on slot 2.

Overwrite it?[Y/N]:y

Copying file flash:/feature1-r0202.bin to slot2#flash:/feature1-r0202.bin......Done.

Upgrade summary according to following table:

flash:/feature1-r0202.bin

Running Version New Version

Alpha 0201 Alpha 0202

Slot Upgrade Way

2 Service Upgrade

Upgrading software images to compatible versions. Continue? [Y/N]:y

This operation might take several minutes, please wait...Done.

<Sysname> install activate feature flash:/feature1-r0202.bin slot 1

Upgrade summary according to following table:

flash:/feature1-r0202.bin

Running Version New Version

Alpha 0201 Alpha 0202

Slot Upgrade Way

1 Service Upgrade

Upgrading software images to compatible versions. Continue? [Y/N]:y

This operation might take several minutes, please wait...Done.

# Display active software images.

<Sysname> display install active

Active packages on slot 1:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0202.bin

Active packages on slot 2:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0202.bin

# Confirm the software change.

<Sysname> install commit

Software image rollback example

Rollback requirement

As shown in Figure 4, the IRF fabric has two members. The feature1 feature has been upgraded from R0201 to R0202, but the software change has not been confirmed.

Roll back feature1 from R0202 to R0201.

Rollback procedure

# Display active software images.

<Sysname> display install active

Active packages on slot 1:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0202.bin

Active packages on slot2:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0202.bin

# Display available rollback points.

<Sysname> display install rollback

Install rollback information 1 on slot 1:

Updating from flash:/feature1-r0201.bin

to flash:/feature1-r0202.bin.

Install rollback information 2 on slot 2:

Updating from flash:/feature1-r0201.bin

to flash:/feature1-r0202.bin.

# Roll back feature1 to R0201.

<Sysname> install rollback to original

This operation might take several minutes, please wait...Done.

# Display active software images.

<Sysname> display install active

Active packages on slot 1:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0201.bin

Active packages on slot 2:

flash:/boot-r0201.bin

flash:/system-r0201.bin

flash:/feature1-r0201.bin

# Confirm the software change.

<Sysname> install commit

Software image patching example

Patching requirements

As shown in Figure 5, the IRF fabric has two members.

Patch the software images running on the members.

Figure 5 Network diagram

Patching procedure

# Download the patch images boot-patch.bin and system-patch.bin from the TFTP server to the root directory of the flash memory on the master.

<Sysname> tftp 2.2.2.2 get boot-patch.bin

File will be transferred in binary mode

Downloading file from remote TFTP server, please wait...|

TFTP: 100752 bytes received in 11 second(s)

File downloaded successfully.

<Sysname> tftp 2.2.2.2 get system-patch.bin

File will be transferred in binary mode

Downloading file from remote TFTP server, please wait...|

TFTP: 100112 bytes received in 9 second(s)

File downloaded successfully.

# Display active software images.

<Sysname> display install active

Active packages on slot 1:

flash:/boot.bin

flash:/system.bin

Active packages on slot 2:

flash:/boot.bin

flash:/system.bin

The output shows that the patch images are not active.

# Activate the patch images on the member devices.

<Sysname> install activate patch flash:/boot-patch.bin slot 1

<Sysname> install activate patch flash:/system-patch.bin slot 1

<Sysname> install activate patch flash:/boot-patch.bin slot 2

<Sysname> install activate patch flash:/system-patch.bin slot 2

# Display active software images.

<Sysname> display install active

Active packages on slot 1:

flash:/boot.bin

flash:/system.bin

flash:/boot-patch.bin

flash:/system-patch.bin

Active packages on slot 2:

flash:/boot.bin

flash:/system.bin

flash:/boot-patch.bin

flash:/system-patch.bin

# Confirm the software change.

<Sysname> install commit

# Display the main startup software images.

<Sysname> display install committed

Committed packages on slot 1:

flash:/boot.bin

flash:/system.bin

flash:/boot-patch.bin

flash:/system-patch.bin

Committed packages on slot 2:

flash:/boot.bin

flash:/system.bin

flash:/boot-patch.bin

flash:/system-patch.bin

The output shows that the patch images have been specified as the startup software images.

01-Fundamentals Configuration Guide

Performing a compatible upgrade

Restrictions and guidelines

Displaying and maintaining ISSU

Symptom

Solution

Upgrade requirements

Upgrade procedure

Upgrade requirements

Upgrade procedure

Rollback requirement

Rollback procedure

Upgrade requirements

Upgrade procedure

Rollback requirement

Rollback procedure

Patching requirements

Patching procedure

Cloud & AI

InterConnect

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Resources

Partner Business Management

Company Information

News & Events

Contact Us