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) !
ISSU Types
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.
ISSU Requirements
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
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
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.
Unknown ISSU
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.
About Aruba Networks 
Pingback: Comware5 ISSU: Compatible | About HP Networking
Pingback: Comware5 ISSU: Incompatible | About HP Networking
Pingback: Comware5 ISSU: Unkown (manual procedure) | About HP Networking
Thanks for your detailed info. I find it so difficult to find Comware information other than from HP and H3C which are never a fun read. I’d like to use iMC to upgrade my switches including six IRF stacks including a 3 member stack. I have a few of them in remote locations with no IT staff.
Hello!
Is note about 2 switches in IRF for ISSI still valid for comware 7?
Thank you!
For incompatible and in my experience: yes. You can work around this with a 4 unit setup by linking servers with p1 to unit1/p2 to unit3 and other servers with p1 to unit2/p2 to unit4. That allows you to reboot units 1/2 or 3/4 together, while keeping the servers with 1 leg online.
Thank you very much, I’ll use our switches in IRF pairs 🙂
That does not work easily if the connectivity is different kind in IRF stack (RJ45/SFP)
So the servers can only be connected to RJ45 while satellite edge switches are on SFP
I do not understand your comment, why would the connectivity of the server or satellite switches be related to ISSU?
4 member IRF, 2 x HPE 5900AF-48XGT-4QSFP & 2 x HPE 5900AF-48XG-4QSFP
How to perform ISSU on that stack?
Hi Sebus,
1/ For compatible updates (most of the 5900 firmware updates are compatible nowadays, which is very good news), you can do a clean ISSU and reboot the members 1 by 1. So all dual-connected devices should remain connected to the network.
2/ For incompatible updates, you can use the cabling workaround mentioned in previous comment above, but that should have been done at installation time (you could change this afterwards, but that would be a configuration tricky process if this needs to be done online).
So you would have SW1 48XGT, SW2 48XG (‘A’ side connections for the servers and the access switches), then SW3 48XGT, SW4 48XG (‘B’ side connections for the servers and access switches). This allows you to setup a forced split-brain (SW1/SW2: production online vs SW3/SW4: MAD disabled), upgrade SW3/SW4 to the new release, let SW3/SW4 reboot and form a new stack (but their external ports remain down because of MAD), then perform the switchover. Both servers and user access switches always have 1 leg connected to either SW1/SW2 or SW3/SW4 stack partitions.
3/ If you do no like 2/ stick to my original rule (not HPE rule, this is a personal recommendation) : If you want ISSU, stick to 2.
So how would you configure the network?
### ScenarioA:
Make the server IRF stack pure L2 access stack of 2 switches, make a core IRF stack of 2 switches that performs the L3 routing between all server subnets and all user subnets. Configure a BAGG (linkagg) between them, this BAGG will permit all server VLANs.
+ Easy central routing
– However, routed communication between servers must travel extra switch hops.
### ScenarioB
Make the server IRF stack L3 for the server VLANs. Make the Core IRF stack L3 for the user subnets. Configure a BAGG between Server and Core IRF that permits 1 VLAN (a routed IP transit subnet between the 2 routers).
Since a BAGG (bridge) linkagg is used, it is still possible to have ‘exception’ VLANs, that simply stretch from a user Switch, over the Core, to the Server switch to some server, so you have best of both worlds. You can decide which switch (Core or server) will be taking the L3 role for these exception VLANs (or some other device such as the firewall).
+ Local hop routing and switching (fastest server to server access, good for server low latency)
+ Maintains flexibility for both L3 and L2 connectivity requirements throughout the entire network
– 2 routing points to manage
I hope this makes sense!