ISSU Load

In this step, a member device will be loaded with the new release R2200P02. The current master remains master with R2200. The member will join the IRF system again as member and synchronize the control plane (IRF) tables.

system-view
issu load file RR2200P02.bin slot 2

During the member 2 reboot, link-aggregation failover will ensure minimal (sub second) downtime:

After member 2 has reloaded, the network is fully operational:

ISSU run switchover

This step will make the member 2 the new master of the IRF system. This is the moment the master role will operate using the new release. Handing over the master role is done a reboot of the current master.

issu run switchover slot 2

During the member 1 reboot, link-aggregation failover will ensure minimal (subsecond) downtime.

After member 1 has reloaded, the network is fully operational. Member 1 will join the existing IRF system as a slave (since an existing Master was found during the boot process.)

ISSU accept

Some people expect the old master to come online with the new version, however, this is not the case. It will simply come online with the existing software version, as a slave of the master unit 2.

The reason is to provide an easy way to perform a roll-back of the update.

Suppose the R2200P02 would cause some OSPF or STP problem on the network. The admin will need to install and run R2200 again on the system. Since the member 1 is now booted with the old R2200 as slave, it would be sufficient to reboot the member 2 (current R2200P02 master). This would cause the member 1 to become master again, running R2200. This step is known as the ISSU rollback.

There is an automatic rollback timer when you start the ISSU process, so it is important to “clear” the timer to prevent an unwanted automatic rollback. The ISSU Accept will stop the rollback timer.

issu accept slot 2

ISSU commit

After the accept, the member 2 is still running R2200P02. But it is the only device running the new version. In this step, the remaining units will be updated to the new release.

issu commit slot 1

This will reboot member 1 again, but this time it will come online with the new release.

Again, during the reboot, link-aggregation will ensure quick fail-over. Once the unit 1 has rebooted, the network is active/active online again:

Optional: revert master to unit 1

For an IRF system, the location of the master device is not important. But if you prefer to have it on unit 1 as a default, you will need to revert it, since the previous state left unit 2 as the master. This not part of the ISSU cli commands, so just a manual reload of unit 2.

reboot slot 2

During the reboot, link-aggregation failover will ensure minimal downtime.

Final situation

At this point the IRF system has been full updated.

Conclusion

Compatible ISSU provides minimal impact, mainly due to the fact that the control plane is fully sychronized between the memberes at each step. This means LACP, STP, ISIS states are 100% synced and this will minimize the failover time.

However, you have to be lucky to get this one, since it typically only applies to Pxx versions of the major release.