This section explains considerations that apply to a High Availability configuration, when running a software version that supports SLP.

Trust Code Requirements in a High Availability Setup

In Dual Supervisor setup, two trust codes are installed. The active Product instance can submit the requests for both the supervisors and install the trust codes that are returned in an ACK.

Policy Requirements in a High Availability Setup

There are no policy requirements that apply exclusively to a High Availability setup. As in case of a standalone product instance, only one policy exists in a High Availability setup as well, and this is on the active. The policy on the active applies to the standby in the setup.

Product Instance Functions in a High Availability Setup

This section explains general product instance functions in a High Availability setup, and what the product instance does when a standby is added.

For trust codes: The active product instance can request (if necessary) and install trust codes for standby.

For policies: The active product instance synchronizes with the standby.

For reporting: Only the active product instance reports usage. The active reports usage information for standby.

In addition to scheduled reporting, the following events trigger reporting:

• The addition or removal of a standby. The RUM report includes information about the standby that was added or removed.

• A switchover.

• A reload.

For addition of a standby:

• A product instance that is connected to CSLU, does not take any further action.

• A product instance that is directly connected to CSSM, performs trust synchronization. Trust synchronization involves the following:

  • Installation of trust code on the standby if not installed already.

  • Installation of policy and purchase information, if applicable.

  • Sending of a RUM report with current usage information.

This section describes how upgrade or migration to SLP is handled. It also clarifies how SLP handles all earlier licensing models including: the earlier version of Smart Licensing, Right-to-Use Licensing (RTU), and how evaluation or expired licenses from any of the earlier licensing models are handled in SLP environment.

To migrate to SLP, you must upgrade to a software version that supports SLP. After you upgrade, SLP is the only supported licensing model and the switch continues to operate without any licensing changes. The SLP section provides details and examples for migration scenarios that apply to Cisco Nexus Switches.

Note

When migrating from traditional licensing model to SLP, license conversion takes place automatically. This Device Led Conversion (DLC) process is triggered when traditional licenses are detected on the device during an upgrade. DLC request is sent to CSSM as part of the license report and may take up to an hour to complete.

Identifying the Current Licensing Model Before Upgrade

Before you upgrade to SLP, if you want to know the current licensing model that is effective on the switch, enter the show running license all command in privileged EXEC mode. This command displays information about the current licensing model for all except the RTU licensing model.

How an Upgrade Affects Enforcement Types for Existing Licenses

An unenforced license that was being used before upgrade, remains available after upgrade. All licenses on Cisco Nexus Switches are unenforced licenses. This includes licenses from the earlier licensing models as follows:

• Traditional Licensing (PAK)

• Smart Licensing

• Right-to-Use (RTU) Licensing

• Evaluation or expired licenses from any of the above-mentioned licensing models

How an Upgrade Affects Reporting for Existing Licenses

When you upgrade to a software version which supports SLP, reporting is based on the reporting requirements in the policy which can be displayed in the output of the show license status command for the following licenses:

• Traditional Licenses (PAK)

• Smart Licenses (Registered and Authorized licenses)

• Right-to-Use (RTU) Licenses

• Evaluation or expired licenses

How an Upgrade Affects Transport Type for Existing Licenses

The transport type, if configured in your existing setup, is retained after upgrade to SLP.

When compared to the earlier version of Smart Licensing, other transport types are available with SLP. There is also a change in the default transport mode. The following table clarifies how this may affect upgrades:

How an Upgrade Affects the Token Registration Process

In the earlier version of Smart Licensing, a token was used to register and connect to CSSM. ID token registration is not required in SLP. The token generation feature is still available in CSSM and is used to establish trust when a switch is directly connected to CSSM. For more information, see Connected Directly to CSSM.

To downgrade, you must downgrade the software version on the switch. This section provides information about downgrades for new deployments and existing deployments (you upgraded to SLP and now want to downgrade).

New Deployment Downgrade

This section applies if you had a newly purchased switch with a software version where SLP was already enabled by default, and you want to downgrade to a software version where SLP is not supported.

The outcome of the downgrade depends on whether a Trust Code was installed while you were still operating in the SLP environment, and further action may be required depending on the release you downgrade to.

If the topology you implemented while in the SLP environment was connected directly to CSSM, then a trust code installation can be expected or assumed, because it is required as part of topology implementation. For any of the other topologies, trust establishment is not mandatory. Downgrading switches with one of these other topologies will therefore mean that you must restore licenses to a registered and authorized state by following the procedures that are applicable in the Smart Licensing environment. The following table displays the outcome and action for new deployment downgrade to Smart Licensing.

Upgrade and Then Downgrade

If you upgrade to a software version that supports SLP and then downgrade to any of the earlier licensing models, license consumption does not change, and any product features you have configured on the product instance are preserved – only the features and functions that are available with SLP are not available anymore. Refer to the corresponding section below to know more about reverting to an earlier licensing model.

Upgrade to SLP and Then Downgrade to Smart Licensing

The outcome of the downgrade depends on whether a Trust Code was installed while you were still operating in the SLP environment, and further action may be required depending on the release you downgrade to. See Table 1.