Typically, SMUs do
not have a large impact on device operations. SMU versions are synchronized to
the package major, minor, and maintenance versions they upgrade.
SMUs are not an alternative to maintenance releases. They provide a
quick resolution of immediate issues. All defects fixed by SMUs are integrated
into the maintenance releases.
Actual deployment of SMUs might vary based on your device. Usually,
software can be patched simply by restarting the process. However, based on the
device, if the process to be patched cannot be restarted, the SMU is
implemented either through a reload or ISSU.
The effect of an SMU
depends on its type:
SMU—Causes a process or group of processes to restart on activation.
a reload of the whole switch and a parallel reload of supervisors and line
SMU—Based on the line card type. The supervisor pushes the SMU to all impacted
line cards. Activation of the line card SMU requires a reload of the switch.
using ISSU orchestration.
SMU—Requires activation before a dependent SMU is loaded. A SMU can have one or
more SMU as prerequisites.
Contains cumulative fix for previously loaded SMUs and supersedes the former.
For information on upgrading your device to a new feature or maintenance
release, see the
Cisco Nexus 7000 Series NX-OS Software Upgrade and Downgrade
A SMU consists of the SMU binary file and an accompanying README.txt
which contains any associated caveats. The naming convention for an SMU is as