Remember to read the basic ISSU article first:

https://abouthpnetworking.com/2014/03/24/comware5-issu-basics/

In the previous post we have seen the compatible ISSU type.

https://abouthpnetworking.com/2014/03/24/comware5-issu-compatible/

In this article, we will look at the detailed steps of the Incompatible ISSU.

Detailed steps for Incompatible ISSU

These are the steps for the incompatible ISSU:

1. Save configuration and check device
2. Download software
3. Check incompatible version
4. issu load
5. issu run switchover
   

This is the sample base diagram for 2 core switches which will be updated from a version R2200 to R2300:

Save Configuration and check device

Verify all units are online and have the same current software versions.
Verify MAD has been configured to ensure proper external port down results during the 2 master phase.

save
display device
display irf
display mad verbose

Download software

Use ftp/tftp to get the new image on all units. Make sure you copy the file to each member local flash.

Check incompatible version

Next verify the new version is incompatible, this output is using fictive versions R2200 and R2300

display version comp-matrix file R2300.bin 

Number of Matrices in Table = 1 
Matrix for A5xxx 
Running Version: R2200 
Version Compatibility List: 
R2300(Incompatible)

ISSU Load

In this step, a member device will be loaded with the new release R2300. The current master remains master with R2200. The member will not join the IRF system again, but will become a new IRF partition, acting as its own master. It will not synchronize the control plane (IRF) tables with the current master.

This will effectively create a split brain situation, which will be resolved by MAD (this is why MAD configuration is required for this method). MAD will shutdown the externally facing interfaces. The IRF physical links remain up (but they are not used by IRF !). The IRF links will be used in the next steps to signal a switchover.

issu load file R2300.bin slot 2 force

The force keyword is required for the incompatible updates.

• Loading phase:

• Unit 2 will be rebooting:

Once unit 2 has rebooted with the R2300 release, it will not join the existing IRF, but remains a separate IRF partition. MAD process will ensure the external interfaces are shutdown. So you have a “brand new” switch running R2300, but it is disconnected from the network:

ISSU Run switchover

In this step, the existing master will reboot and control is handed over to the new version. This step is done through a single command:

issu run switchover slot 2

However, you should realize that this command will actually perform 2 actions:

• reboot the existing master (equivalent to “reboot” on unit 1)
• enable the external facing interfaces on the new master (equivalent to the “mad restore” command in case of a real split brain)

This is not important yet, but I will take advantage of this knowledge to perform a manual ISSU procedure for Unknown ISSU types in the next article.

Unlike the compatible ISSU, there is no rollback option here, so the original master (unit 1) will now immediately boot with the new R2300 version.

This will result in the final setup:

Optional: Revert IRF Master

Just like the previous Compatible method, the admin could now revert the original unit 1 as master with a reboot of unit 2. This step was already covered in the previous article, so the diagram is not included in this article.

Conclusion

Although Incompatible seems very similar to the compatible update, you should realize that the switchover means:

• Disconnect existing production switch
• Connect a new switch to the network

So all control plane protocols need to start from scratch (STP, LACP, OSPF, etc). For basic L2 switching, this will just take a few seconds, but for the L3 protocols, this will be longer.

With some OSPF tuning (as simple as hello timers to 1 sec), the routing table can be operational within 5-10 seconds, but do not expect to go under that number.