on
02-08-2021
12:49 PM
- edited on
04-26-2022
07:19 AM
by
kgoode
Smart Licence Using Policy simplifies the way End Customers activate and manage their licenses. SL now supports simpler and more flexible offer structures, allowing customers to have an easier, faster, and more consistent way to purchase, renew, or upgrade their licenses.
This new version supports the following Cisco products: Cisco Catalyst 9000 series switches, routing platforms such as the ASR1K, ISR1K, ISR4K, Cisco Catalyst 9800 Series Wireless Controllers, IoT routers and switches, ACI, NX-OS, MDS, and a few Collab products (CME, SRST, CUBE).
Customers and Partners can upgrade their devices to the newest version of IOS-XE (available via Software Download) and NX-OS.
If you have support questions about Smart Accounts and Software Licensing, open a case via Support Case Manager (SCM). To learn more on how to open a case in SCM, click here.
Resources
Smart Licensing FAQ Document - including Smart Licensing Using Policy
Smart Licensing Using Policy Configuration Guide
Cisco Smart License Utility (CSLU) Download
Introduction to Smart License Using Policy Video: English, Chinese (Mandarin), Chinese (Traditional), Japanese, Korean
Title | Video |
CSLU Windows: Install, Set up, Uninstall | |
CSLU connected with device initiated workflows (PUSH mode) | |
CSLU connected with device initiated workflows (PULL mode) | |
CSLU connected to Product Instance and disconnected from Cisco | |
No CSLU - Product instance direct-connect using trust token | |
No CSLU - Product instance direct-connect to get authorization code for HSECK9 license | |
No CSLU, product instance air-gapped - get offline RUM/ACK and Auth-request | |
Brownfield upgrade – SL EVAL, Registered, RTU (focus on reporting) | |
Brownfield upgrade – PAK (focus on auth-codes) | |
Brownfield upgrade – SLR (focus on auth-codes) |
If it is still required to report on license usage then it seems that this is reverting to pure trust based manual license operation, or what do I miss?
Announcing this with 15 days notice isn't great... Especially since the information currently available is "thin" to say the least.
I've been discussing this with our Cisco reps and the BU and I'm hoping the following information that I have received so far will help provide some clarity. The licensing options prior to this announcement were SL, SLR and PLR. On Oct 30th the BU will add another option, Smart Licensing Enhanced (SLE), to the group of licensing options. As of Oct 30th the licensing options will be SL, SLE (minimum of IOS XE 17.3.2), SLR and PLR. Devices that support 17.3.2+ will have SLE enabled by default and will not be required to check in or register. The only exception to this is if the device needs to change its service level.
I sent a follow on message asking for additional clarity on the following:
1 - Will this affect any/all current devices that are upgraded to 17.3.2XE or is just for new devices shipping with 17.3.2XE?
2 - Will this automatically change the way my currently deployed devices will register once they have been upgraded to 17.3.2 or above?
3 - Will I have the option to manually change to SLE as a registration method once a device is upgraded to 17.3.2XE or above?
I will post a follow up once I receive a response to these questions.
Hope this is helpful,
Chuck McFadden
(please mark helpful post as helpful)
Further clarification, as promised:
It appears that this is only for new devices that are shipping with 17.3.2 and above. The bottom line APPEARS to be that new devices will not be shipping with the 90-day trial license and instead will just work at the subscription level that is installed at the time of shipment. As we likely all know, the trial license has really never meant anything because it will work regardless. Apparently the new devices will no longer have the trial license and, instead, can be registered via SL, SLR, PLR or the new SLE. This should not affect any existing devices. Bottom line from what I am hearing is that even though the message is a bold yellow banner on the Cisco Software page this isn't really that big of a deal.
I stated "APPEARS" above because I do not work for Cisco and I'm only passing along my interpretation of the information that I am getting from them. So my final suggestion on this topic would be to discuss this issue with your Cisco support staff, or open a ticket with TAC as suggested in the "Support" section of the original post.
Hope this is helpful,
Chuck McFadden
(please mark helpful post as helpful)
I have a 4461 with PLR licenses with a few sip phones registered against it. The router is isolated but we use it for internal communications. When i upgraded from 17.3.1a (which along with all previous versions works fine) to 17.3.2 as a test. The SIP service failed to load, it was pending a license report acknowledgement, I assume that meant a transport to or from cisco (it didnt seem to be a eula type of acknowledgement). Does anyone know if this deployment type is no longer feasible with 17.3.2? Its a bit annoying that they change the way things work on the fly. I know i should probably just not upgrade, but there is something annoying when you have a fairly new product and have to stop using the latest releases because they make something non-functional.
the error was: %SIP-1-LICENSING: SIP service disabled until license report is acknowledged
this seems contrary to the general release notes, as the intent seemed to be make the licensing more flexible out of the box not more restrictive. Based on that error it appears an isolated router cant run in PLR unless I am missing a command etc that will allow it to proceed.
***edit, so the video was helpful, but truthfully I hate it more now then i did before heh
UPDATE: I have been informed that DNAC will work as a proxy for CSSM.
Original comment:
Our 90+ NADs were deployed using RFC1918 addresses and are not allowed outside of the SDA underlay. This was purpose built and would be quite an undertaking to redesign. We register the NADs via SLR using DNAC as the proxy (License Manager-->All Licenses-->Actions-->Manage License Reservation-->Enable License Reservation). This method has been working fairly well for more than two years. With the new licensing model will DNAC work as a proxy to CSSM or will we now need to use the new CSLU?
Thank you!
Chuck McFadden
(please mark helpful post as helpful)
When will this be available for FirePower Hardware, like 2110, etc, and ASA's ?
Here's a question: What about the on-prem CSSM VM (I think it used to be called the SSM Satellite)? We have a lot of product instances registered on it. Are we going to have to migrate them all over to a VM running CSLU?
Personally, I'm finding this to be a mixed bag. On one hand, it's nice that we don't have to worry about evaluation licenses anymore. On the other hand, I don't like the fact that CSLU runs on Windows only. It appears the Linux VM is getting replaced by it for similar on-prem functionality so that basically means I now have to spin up a Windows VM to run CSLU so it'll always be on for the devices to do their regular reporting. We have too many devices to do the manual reporting option on them.
Hello,
i'd like to see the last 2 videos (brownfield upgrade) for the disconnected CSLU and the no CSLU with air gapped.
Thanks a lot!
Hi @rrumney. I have the same question as you. We have a bunch of gear pointing to our CSSM On-Prem and we've recently upgraded a pair of 9500s to 17.3.3 only to find that the licensing has completely changed. Did you ever figure this out? And if so, could you share what your solution was? Thanks.
Here is the official web page from Cisco.
I'm confused....
So I'm about to deploy TrustSec to the rest of my plant. I need ALL of my Switches showing all the Go Signs in the CLI I found that my team deploying our replacements was using an old expired Smart License key so I have about 40 switches that were all upgraded to 17.3.3 without being registered to smart licensing... Now going through the entire guide it seems there is no idtoken option anymore? How will I get them registered?
Also would like to know if anyone knows of a more confusing licensing process than this? If you are trying to tell me i'm "GOOD" on licenses to just trust you... THen how about when I do "show license" on my device it just responds back with a simple "Your Licenses are all good Mr Turner"... Someone please tell me that this isn't just a Cisco problem. All the other switches I could buy from other vendors would have the same mystic licensing process that you aren't allowed to understand...
ANyone want to try to decode this?
Utility:
Status: DISABLED
Smart Licensing Using Policy:
Status: ENABLED
Data Privacy:
Sending Hostname: yes
Callhome hostname privacy: DISABLED
Smart Licensing hostname privacy: DISABLED
Version privacy: DISABLED
Transport:
Type: Callhome
Miscellaneous:
Custom Id: <empty>
Policy:
Policy in use: Merged from multiple sources.
Reporting ACK required: yes (CISCO default)
Unenforced/Non-Export Perpetual Attributes:
First report requirement (days): 365 (CISCO default)
Reporting frequency (days): 0 (CISCO default)
Report on change (days): 90 (CISCO default)
Unenforced/Non-Export Subscription Attributes:
First report requirement (days): 90 (CISCO default)
Reporting frequency (days): 90 (CISCO default)
Report on change (days): 90 (CISCO default)
Enforced (Perpetual/Subscription) License Attributes:
First report requirement (days): 0 (CISCO default)
Reporting frequency (days): 0 (CISCO default)
Report on change (days): 0 (CISCO default)
Export (Perpetual/Subscription) License Attributes:
First report requirement (days): 0 (CISCO default)
Reporting frequency (days): 0 (CISCO default)
Report on change (days): 0 (CISCO default)
Usage Reporting:
Last ACK received: <none>
Next ACK deadline: Nov 20 18:26:45 2021 CDT
Reporting push interval: 30 days
Next ACK push check: <none>
Next report push: Aug 22 19:26:39 2021 CDT
Last report push: <none>
Last report file write: <none>
Trust Code Installed: <none>
The first-rate manner to hold any port from doing any trunking is configuring the port as get right of entry to port, that you reputedly already did. That should be sufficient.
I have upgraded three 9300L switches to 17.3.3 and all works well with reporting through the CSLU. However when I look at the devices in the Smart Account instead of seeing them in the sub virtual account they are now located in the default account. If I move them back to the virtual account they are back in the default account withing 24 hours. Also they no longer report as their host name but as PID and UDI which will be painful when trying to identify a missing device.
I have raised support call for this but on the chance that someone has found a solution?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: