Limitations

The ISSU process currently has the following limitations and considerations:

Management modules

In order for ISSU to work the switch chassis needs to have two management modules installed.

Line card support

The ISSU version released in 10.10 only supports line cards with model numbers ending in A or B, i.e. LCs with model numbers following the format "ROX_A" and "ROX_B". Newer LCs will be supported in later versions. Mixed mode (i.e. a chassis with A or B line cards and newer line cards) is not supported in ISSU.

Hardware faults

It is recommended that hardware faults are resolved prior to performing ISSU. Fan faults and abnormal temperature statuses should be addressed. Fans may increase in speed during the ISSU process.

Prohibited operations

During ISSU the following operations are not permitted:

  • Any hardware hot swap
  • Pressing any button

Performing any of these operations during an ISSU could put the system in an error state that could adversely affect the ISSU.

The system may not be able to address failures during the ISSU. E.g., if network protocols require blocking a port, flush MAC, or routing tables, etc. the switch would not be able to react to those tasks until the ISSU is complete.

Scheduled jobs

Since no configuration is allowed during the ISSU, it is possible that some scheduled jobs will fail if they are attempted while the ISSU is in progress. Users can check for the "ISSU is in-progress, configuration is not allowed" message to find out if any scheduled job has failed. It is recommended to not execute any scheduled job during ISSU.

Information not updated during ISSU

During ISSU the following information may not be current until after ISSU completes:

  • Link state. Transitions may not be reflected until ISSU is done.
  • Temperatures.
  • Power consumption values.
  • System state as indicated by LEDs.
  • MAC Learning.
  • Change in MAC for a neighbor via Gratuitous ARP.
  • Some counters will stop increasing their value during ISSU.

Show tech

The show tech command is enabled during ISSU using the CLI, however it isn't possible to use it with the REST API.

Features that don't support uninterrupted operation during ISSU

During ISSU the following features may be interrupted until after ISSU completes:

PIM with MSDP

Currently, PIM is not supported in ISSU on RP routers, therefore traffic loss is expected during ISSU on RP routers where PIM and MSDP are enabled.

Dynautz ISSU

All Dynamic Authorization requests will be rejected with NAK during ISSU operation.

BFD ISSU

It's important to note that this mechanism is only recommended for sessions that have a failure detection time higher than 6 seconds (e.g. Tx=Rx=3000 and Detect Multiplier=2, or Tx=Rx=2000 and Detect Multiplier=3). The setup should have less than 64 sessions, otherwise the ISSU failover might not be hitless for all sessions.

NAE

NAE will have a momentary disruption during ISSU events due to the failover event. See the Network Analytics Engine Guide for more information.

Feature readiness check

ISSU will fail if the feature ready check does not pass. The feature ready check validates that none of the following features are in a failed state:

  • ACLs, object groups, and their applications
  • Classifier policies, classes, and their applications
  • Port-access polices, classes, and their applications
  • Port-access group-based policies, classes, and their applications
  • Active PBR actions and their applications

In general, if any of the above is in a failed state Aruba recommends fixing it and then upgrading to the newer operating system image using the system reboot method instead of ISSU. Some of the failed state will remain even after it is fixed on a running system and a reboot is good best practice for clearing it.

There are system validation checks to ensure that all line card part numbers end in an A or B.

VSX environments

In order to minimize a potential downtime, it is strongly recommended that in a VSX topology ISSU is performed at different times for each switch. E.g.,

run ISSU on the primary switch, verify that it was successful, and then perform ISSU for the secondary switch.