Legitimizing Cisco Software Downloads Without Relying On SmartNet – Packet Pushers

I think it’s fair to say that Cisco is a software company at heart. You could argue the point that when you buy a Cisco-branded product, it’s often a piece of hardware that arrives in a sturdy box, surrounded by foam and plastic, and featuring that new kit smell. A router. A switch. A firewall. But what makes the kit do something special? The software. The hardware is just the incidental platform that allows Cisco’s intellectual property to do the packet manipulation magic you’re really paying for.

If you only did a cursory read of my rant about Cisco’s recent IOS download policy changes, you might think that I want Cisco to give away their software for free under all circumstances. That’s not the case. Why? I believe in Cisco’s right to make money off of their intellectual property, in the same way that I believe in the right of bloggers to maintain control of the content they write. I write, and occasionally, in venues other than Packet Pushers, I get paid for it. If someone takes what I write and presents it as their own, that’s plagiarism, a theft of my intellectual property whether I was profiting from that property or not. While I choose to share my content freely most of the time, sometimes I do not. That’s a decision I make and within my control. Software vendors clearly have this same freedom. Some open-source diehards would disagree with this philosophy on a moral basis, but I believe people & corporations have a right to earn money in whatever legitimate way they see fit. Therefore, I’m not suggesting Cisco can or can’t limit who has access to what bits of their property.

But I am saying that Cisco’s doing it wrong, for the reasons I cited in the previous post.

That post has received a good bit of traffic and many commiserating comments, so let’s open a dialogue on how to fix the situation. First, I’m writing as an engineer. I’m not a manager. I’m not an accountant. I’m not a paper-pusher. I have a job to do which is to design, implement, and maintain networks. That job frequently requires that I upgrade router, switch, and firewall software. I support largely Cisco kit, and so from my engineer’s perspective, I see the issues as follows:

1. Bugs are ever-present in Cisco software. I don’t overly criticize Cisco here; bugs are a problem endemic to the process of software development. I don’t expect perfect code every time. I barely even hope for it, to be fair. I myself can’t even write a simple script without a few revisions to get it right. However, when I have a known bug present in code that Cisco sold to me, I do expect that I won’t have to pay for the upgrade that fixes the bug. I also expect that I’ll have access to the upgraded software image without having to open a TAC case or otherwise jump through hoops. How? I’ll get to that.
2. When Cisco sells me a hardware module that requires an software upgrade to support, I expect the needed software to be available to me as a implicit part of the hardware purchase. Consider that when you buy a newer linecard for a chassis switch, it is very common for a software upgrade to be required before the chassis will recognize the linecard. I have found this true with ISR G2 routers as well, where certain newer modules aren’t supported by the IOS version we’d standardized on, necessitating an upgrade.
3. When I wish to upgrade Cisco hardware to take advantage of new features, I am entirely comfortable with having to pay for that. However, engineers are not usually the ones maintaining SmartNet contracts. To couple my CCO ID with a SmartNet contract number as an entitlement test is a broken idea right out of the gate. What do I, as an engineer, very often have access to from the CLI on my Cisco hardware? The device serial number(s). Serial numbers are right there in a “show version” or “show module”. While not consistent through the years, this functionality has gotten better over time such that I can usually provide this information to TAC even when my troubled device is far away.

So how do I think the Cisco software download process should work?

Cisco should stop assigning SmartNet contract numbers and using them as unique identifiers. Cisco already has unique identifiers: the hardware device serial numbers. If you’re thinking about software such a Cisco Security Manager, then the Product Authorization Key could serve the same purpose. When tied to software device serial number or software PAK, the question of download legitimacy then becomes much simpler.

So how would this process work in my brave new world?

1. When Cisco hardware or software is purchased, the customer is well-known, and the serial number or PAK is well-known. Tie the two together. Cisco knows about customers. Require that the VAR or channel-partner make the link when pushing the unit out of distribution and towards the end-user. Customers will generally have one ID. Large customers who require more granular control over their accounting processes can split up IDs by business unit, geographical site, or other means as they see fit, but all IDs belonging to a customer are tied to a master customer ID. If you’ve ever dived into a SmartNet contract consolidation project, you know that Cisco already does this. I’m not asking for anything new.
2. Make it hard to create new customer IDs. There’s only a handful of reasons that a new customer ID should be created, and it’s not that the VAR didn’t feel like figuring out the existing one.
3. Tie hardware modules to a parent serial number. Again, Cisco already has the means for this. When a new module will require an upgrade of the IOS in the parent serial number device, that forms an entitlement.
4. Tie SmartNet coverage to the serial number as either “covered” with an end date, “not covered”, or “covered under warranty.”  As hardware is ordered and shipped with specific software licenses, this should also be known to Cisco. If I buy a switch with the IP Base feature set running 15.0 mainline code, that should be known. When a customer adds a new module to the parent chassis requiring an upgrade, Cisco could lump that under “covered under warranty.”
5. Network engineers are employed by customers. Consultants are employed by customers. VARs are employed by customers. So, tie the CCO IDs of these folks to the customer ID. The customer can determine which CCO IDs are allowed to open TAC cases or download software on their behalf.
6. With all of that done, it becomes much more straightforward to download software. I login with my CCO ID. I am now known to Cisco in association with my customer ID (or multiple IDs, if I’m a consultant with supporting many Cisco customers). All serial numbers my company has purchased are known to Cisco. At a glance, I can see the serial number, device type, and status of “covered,” “not covered,” or “covered by warranty.” The appropriate software entitlements tied to that serial number would also be present, including code train and feature set. Cisco should know that the code they shipped me was subsequently changed to a deferred status, and therefore entitled to an upgrade within the same code train. Cisco should know that the device is covered by SmartNet, and therefore what software the device is entitled to. Etc.
7. Implement a “three-for-free” policy. Uncovered serial numbers should be allowed a download as a freebie, up to perhaps three per CCO ID. I see this as having three benefits. One, it presumes innocence instead of guilt on the part of the Cisco customer. Two, it probably bails a customer out of a bad situation not of their making. Three, it creates a sales opportunity for Cisco. “CCO ID blah-blah used one of his freebies to download IOS for an uncovered Catalyst 3560G switch. Let’s follow up with him to enroll this device in SmartNet coverage.” Or…“CCO ID blah-blah used one of his freebies to download IOS for this EOL device. Let’s recommend to him a replacement for his Catalyst 4006.” If the uncovered device ends up as removed from the serial number roster or covered by a contract, the CCO ID is given the freebie back.

Would this be easy for Cisco to do? I bet it would be a data mining challenge for them – and probably not an easy one. Is it do-able? The way I see it, they already have all of this information in their systems – it’s a matter of tying it together in a way that is easy for customers to leverage. Have I accounted for all situations and addressed all contingencies? Probably not, but I’d like to think I got my head wrapped around the challenge, at least from an end-user perspective.

So now it’s your turn. On the assumption that the current system Cisco has implemented is broken, what do you think of my ideas? How would you fix Cisco’s software entitlement enforcement system?