(→Q: How do I delete an In-Use license?)
(→Q: How do I delete an In-Use license?)
|Line 73:||Line 73:|
Always make a backup of the running configuration. Switching to IP Base will remove the commands of the features not included in the IP Base license. After switching back to
Always make a backup of the running configuration .
Switching to IP Base will remove the commands of the features not included in the IP Base license. After switching back to , it is required to add all the configuration.
Latest revision as of 18:45, 9 February 2018
Frequently asked questions regarding Cisco Smart Licensing (SL) support for the Cisco Cloud Services Router CSR1000V.
Q: What happens when the CSR first comes up and CANNOT connect to the Smart Licensing (SL) portal?
The CSR will not consume an entitlement and will boot up in the default mode. The default mode throughput is 100 Kbps, with all feature enabled - that is, AX package level.
Q: How often does the CSR communicate with the SL portal? What is the size of the messages?
When the CSR first comes up with the appropriate SL configuration, it will attempt to communicate and register with the SL portal to get a valid entitlement. There are two kinds of recurring communications that also occur.
- ID certificate renewal: The ID certificate is required to maintain security. It happens every 6 months and is comprised of about 2KB of data going out from the product and a response of about 5KB.
- License consumption report: The license consumption report is sent on initial configuration, whenever license consumption changes (up or down), and once every 30 days to stay in synch. The sizes of these messages can vary depending mostly on the number of different types of licenses consumed. A CSR will send something in the order of 1KB and the response will be in the order of 2-3KB.
The low bandwidth consumed by these messages implies that Smart Licensing is a viable option even in battlefield scenarios where CSRs communicate over low speed radio links.
Q: What happens if the CSR loses connectivity to the SL portal?
The CSR itself will continue to run at the current licensed level in perpetuity unless it reboots and still cannot connect to the portal when it comes back up. If this occurs, the CSR will fall back to the default mode (100 Kbps AX).
The SL portal will continue to consume the entitlement for 90 days after it has detected that the CSR has lost connectivity. After the 90 day period, the entitlement will be released back into the pool for other CSRs to consume.
Q: How do you ensure that an entitlement is released when a CSR no longer requires it?
The default behavior is described in What happens if the CSR loses connectivity to the SL portal? . However, if you plan to delete a CSR instance, a CLI (license smart deregister) can be proactively issued on the CSR to deregister itself. The entitlement will then be released on the SL portal and the CSR can be deleted. The entitlement can also be deleted manually on the SL portal. See Is there an API into the portal available that can be used to remove an entitlement when no longer required?.
Q: Is there an API into the portal available that can be used to remove an entitlement when no longer required?
No, there is no API available currently. If the hosts running the CSR suffer an outage and are no longer recoverable, then the customer will be expected to manually remove the entitlements that those CSRs were consuming prior to the outage.
Q: Is the token used for recurring communication? What is the default life of the token?
The token is a string that is unique to every customer and identifies a CSR instance as belonging to a particular customer/virtual account. The token is created on the SL portal and the string generated is configured (can be included in the bootstrap configuration) on the CSR. It is only used during initial registration. It has a default life of 30 days but can be set to expire after a period of 1 to 365 days. Token creation is a manual process – there is no API available.
The token can be revoked at any time on the SL portal. This implies that new CSR instances attempting to use a revoked token to register will be unsuccessful. This could be useful when a Service Provider deploys CSRs on the end customer premises (Enterprise Data Center) but wishes to restrict any fraudulent new registrations when the Enterprise is no longer a customer of the Service Provider.
Q: What happens when the license period expires?
When the term based license expires, the CSRs will continue to operate at the last licensed level in perpetuity. The only exception is when the CSR reboots and does not find a valid entitlement on the portal. When this happens, the CSR will fall back to the 100 kbps level.
Q: Is there a need to reboot CSR to get to the correct throughput value?
The CSR needs to be rebooted only when changing the technology package level (that is, moving from one license boot level to another) Example: IPBASE to AX level.
After the CSR comes up in a given technology package level, the license boot level is fixed. Executing
platform hardware throughput level MB <10|50|100|250|1000|2500|5000|10000>
requests entitlements at the specified boot level. So if CSR comes up in security level, we will end-up requesting sec_10M or sec_100M and so on based on the throughput configuration.
Q: How do I delete an In-Use license?
Often customers face a situation where the “Active, In-Use” license is about to expire and a newer throughput license cannot be activated, as the throughput is not higher than that of the current license. In such situations, the objective is to get rid of the “Active, In-Use” license and activate the new license. We cannot remove an “In-Use” license immediately. Instead, we need to first change it to “Not-In-Use” state, and then the license can be cleared.
For example, to clear an ax_100M “In-Use” license:
- Switch the CSR boot level temporarily to some other level, such as “ipbase” (license boot level ipbase) and reboot the CSR.
- Clear the license (license clear ax_100M).
- Switch back to original “ax” boot level and reboot CSR.
Important Note: Always make a backup of the running configuration before changing the license. Switching to IP Base will remove the commands of the features not included in the IP Base license. After switching back to AX, it is required to add again all the configuration.