This blog covers some undocumented tidbits about Nexus Licensing that you might want to know about. Thanks to Vinny Clements for some good discussions and for actually taking the bull by the horns and getting the problem solved instead of waiting for TAC or the VAR to solve the problem. Thanks also to Jason Miller for quickly providing some answers.
Scenario: Customer’s VAR (or Cisco?) had shipped a bunch of Nexus 7009’s to the site with installed licenses in bootflash. Unfortunately the licenses were somewhat randomized, apparently because the person who put them into bootflash and installed the licenses didn’t realize they tie back to the chassis serial number. Symptoms included some weird show license output. Docwiki said another possible cause could be corrupted bootflash. That didn’t seem likely. So the question was: how to get the licenses onto the right box with minimal disruption?
Solution: The problematic licenses contained the serial number in the license filename. So they were copied to flash on the right machine. All VDC configs on the Nexus 7000 were saved, just in case. Install license was run for the correct license. That took, according to show license output. But the old wrong license still showed up, along with some signs it wasn’t the right license, even after deleting it. Rebooting did not clear that up.Running “clear license” got the Nexus 7000 to forget about it. Problem solved!
As far as I could see, none of this is documented. There is a pretty good document covering basic license manipulations, see the Cisco NX-OS Licensing Guide, currently found at http://www.cisco.com/en/US/docs/switches/datacenter/sw/nx-os/licensing/guide/Cisco_NX-OS_Licensing_Guide_chapter1.html.
The way we read it, we thought we might have to uninstall the bad license before installing the right one. And to uninstall a license, you have to first remove all configs and features that require that license. So the first plan was to erase all configs and VDC’s (after saving copies offline), reboot, uninstall the wrong license, install the correct license, blow in the VDC 1 config, make sure the other 2 VDC’s were created and allocated the right ports, then blow in their configs. TAC, Cisco SE, and responsible (irresponsible?) VAR were tried in parallel. The emailed TAC response was pretty useless, didn’t really even make sense. (TAC Tier 1, you know how that goes — we didn’t wave my CCIE number and use the get-out-of-Tier-1-free card.) The other responses were of the “dunno, will ask someone who might know variety”.
After discussion, we agreed to try the above “Solution” approach and it worked.
Cautionary Scenario #2: A secondary problem is that the customer site does not have possession of the license PAK information. They had emails from the VAR with copies of the license files, and what looked like output from the Cisco licensing web page. However the line for PAK info was blank.
I always want to know the PAK numbers, prior experience suggests they’re just as critical as the actual hardware. If there was a chassis RMA or other problem, and you don’t hold your own PAK’s, you might suffer days or longer getting the VAR to find the PAK numbers, work with Cisco on licensing to new chassis, etc. I’ve heard some horror stories about trying to sort out this sort of licensing mess, usually when the site unpacks like kids at Christmas (paper flying everywhere) and the PAK cardboard pages get tossed in the giant designated trash box with all the wrapping and other material.Almost every Nexus class I teach has someone in it where they unpacked like this, only to later realize they’d thrown out that key PAK info (key in more ways than one!).
The word “mess” comes in that Cisco will want you to work through your VAR, and your VAR may not be able to find the numbers either, so proving you paid for the licenses then could be an issue, with lots of people in the food chain that want proof you’re not pulling a fast one. Cisco can grant temporary grace period licenses to get you up and running, but then the challenge is getting a solution out of all the bureaucracies before the grace period expires.
Key discovery: Factory-installed licenses don’t have a PAK. The order comes with an SO number which you can use with TAC just like a PAK number if and when you need to relicense a chassis.
This seems new and little-known among partners and even Cisco SE’s. It sounds like Cisco was trying to simplify the process in some ways, but didn’t communicate or document the process changes well. And thanks, I’d prefer to stick with a PAK, and address the end-user concerns about having re-licensing bureaucracy challenges on top of RMA and failed hardware stress.
Oh, in case your reaction is like mine, “thanks but I think I’ll skip factory installed licenses and install my own licenses so as to get a piece of paper with a PAK on it”, I’m told that not an option for equipment bundles. This is something the Cisco or VAR SE should probably manage expectations on during the sales call, now that they’ve read this blog and know about this!
Open questions. Hey, I don’t know it all.
- It looks like the .lic license files are ASCII in sort of XMLor partial XML format. Some seemed to have the PAK in them, others did not. The forwarded emails had blank PAK fields (as mentioned above). If Cisco would embed the PAK in the factory-installed license file, and tell us that, then inventing a new “SO” number wouldn’t be necessary. I think most of us are smart enough to make offline backups of license files.
- Can you rename license files? It would be nice if the name indicated which license each file licenses. Cryptic numbers and letters aren’t very informative. Yes, you can use a show command to tell if you have a functioning switch. What about my offline backup copies? I need to know which license the file enables, and also which chassis (serial number) it belongs on. [Suggestion to Cisco: embed that info into the .LIC file in a clear-cut way, and communicate that it is there? And/or put at least the platform and type of license (Enterprise, or whatever) into the name.]