In this article we will review the ISSU options on Comware5 devices. ISSU stands for In Service Software Update and the goal is to minimize downtime during firmware updates.
This article applies only to Comware5 devices (Comware7 has many more options related to ISSU) !
In service software update on Comware5 devices is not based on a local-OS in service update, but relies on IRF to provide “minimal” downtime.
There are 3 versions of ISSU:
- Compatible: 2 software versions can actively exist in the same IRF system. Procedure can be done with “issu” cli commands.
- Incompatible: only 1 version can exist actively in the IRF system. Procedure can be done with “issu” cli commands.
- Unknown: official ISSU update to/from that version is not possible. ISSU-like update possible with a manual procedure (not through “issu” cli commands), using MAD assistance.
IRF assisted ISSU will reboot 1 unit in the IRF system, wait for it to come back online, next reboot another unit in the IRF system. When a unit is rebooting, it is really down, so any host which is single-wire connected to this unit will be offline.
The ISSU process assumes hosts or peer devices are dual-connected to 2 different IRF members. When 1 switch reboots, it will be the NIC teaming or Link-Aggregation of the peer device which will perform the failover and use the other link.
Note : When using more than 2 units in the IRF system, ISSU assumes the peer devices are connected to all switches in the IRF system. For example: if you have a server IRF system with 4 switches, server are assumed to be connected to each of the 4 switches. This is highly unlikely, and therefore I recommend to stick to 2 units in the IRF system for any deployment which requires ISSU. When a customer can have a maintenance window and accepts downtime, more than 2 switches in the IRF can be used of course.
Compatible ISSU will only be possible for minor firmware updates, typically within the same major release and between Pxx (patch level) versions of the firmware. For example R1202P02 and R1202P06 will likely be compatible. R1202P02 and R1308 will likely be incompatible.
Basically compatible ISSU means that these versions of the firmware can co-exist together inside the same active IRF system. (IRF typically requires all units to have the exact same firmware). Thanks to the ISSU commands, it would be possible to have IRF unit 1, for instance the master, with R1202P02 and unit 2 with R1202P06, both active in the same IRF system.
Running these inside the same IRF system implies that they share the same control plane databases (ARP tables, STP tables, LACP tables etc). When the IRF master goes down, the other IRF members have the full active control plane databases, so they can continue at nearly the same point where the master was stopped. Downtime is typically sub-second and similar to a link-aggregation single link failure.
Incompatible ISSU is typically possible between consecutive major firmware updates, like R1200 to R1210.
Major updates can introduce new features/protocols, so the control plane database structures may not be compatible between these major versions. This means that these 2 versions cannot exist together in the same IRF system, they cannot share the control plane database.
Downtime is typically several seconds (also depends on which L2/L3 protocols are being used). Procedure is still very easy, since normal cli commands can be used.
For some reason (unknown to me), the ISSU cli commands cannot always be used between all versions. This will be seen as Unknown in the ISSU status, and it simply means ISSU cli commands cannot be used to update the firmware. Officially, a full reboot is required (causing x minutes of downtime). We will take a look at a manual procedure which makes it very similar to the Incompatible ISSU system.
In the next articles, I will review each of these ISSU types.