Fork You, Forked Code

Alternative titles for this blog entry:

  • How Cisco’s PI Chases Customers To The Cloud
  • What The Hell Are They Thinking?

The above twenty words may sound like the start of a pretty serious rant, but they are not- I promise. To me, this blog is more a plea for relief, or akin to begging a beloved family member to start acting sensibly after going off the rails for a bit (hey, we’ve all been there…). But some behaviors should never be repeated, and we’re looking at one of them.

The topic- Cisco Prime Infrastructure (the wireless variant). The offense? 

“You can upgrade the following Cisco Prime Infrastructure (and
predecessor) products to Cisco Prime Infrastructure 2.1: Cisco Prime
Infrastructure, Cisco Prime Infrastructure″

 “There is no upgrade path from version 1.4.x to version 2.1 at present.”

<Pause… long sigh>

To understand the gravity of the situation on all levels, we have to talk about what preceded the angst (I’ll give the brief and sanitized version, there are actually a number of other really odd sub-plots in addition to this):

  • If you want/needed to run Cisco’s 3700 11ac access points, you had to go to WLC code 7.6x
  • To support 7.6x, you needed to go to Prime Infrastructure 1.4.x
  • To go to 1.4x meant that you accepted the fact that you couldn’t take 1.4 to 2.1 when 2.1 came out (Cisco declared it early on, but with no clear explanation that I ever heard)
  • So, some of us, because of operational need, had to subject ourselves to Prime Infrastructure Forked Code Hell
  • If you’ve been around long enough, you’ll remember back when Cisco forked their wireless controller code for outdoor mesh APs- if you wanted to run these access points, you needed special controller code and stand alone hardware dedicated to these APs. You’ll also remember the accompanying uproar by customers, and sheepish apologies by Cisco and promises that nothing like this would ever happen again once the disparate controller code was eventually re-merged.
  • Yet it has happened again. Forked code pain. And even though we knew it was coming, it really really sucks. I’m guessing many of us will end up devoting numerous man-days or man-weeks of time that should go to more productive pursuits to eventually rebuild our PI environments from scratch. God forbid that our data can’t be migrated, but we’ll see. This is one of those WLAN problems where the bigger your environment is, the more pain you will experience.

Ah well. So be it. We’ll do what needs to be done, to eventually get our PI 1.4x upgraded to 2.x so we can continue to stay current as our chosen WLAN product set evolves. But so far the only guidance on the topic is the terse:

“There is no upgrade path from version 1.4.x to version 2.1 at present.” 

Please, Cisco- make “No forked code-ever.” part of your mission statement. Enough is enough. We’re all in this together- you, us, and our wireless clients. Good Wi-Fi systems lose their shine when bad NMS is the lens you view them with.

The Other Dimension To This Tale

Getting out and about and interfacing with lots of other wireless customers and fellow analysts on those occasions that I exercise my media credentials, I hear a common theme:

One of the most appealing aspects of going to the cloud for WLAN is that you get to leave behind clunky network management systems that you are on the hook to build, upgrade, and suffer through.

I personally don’t buy into the “your controllers are bottlenecks!” Chicken-Littleism that can pervade cloud Wi-Fi marketing, but having used Meraki, Aerohive, and AirTight web-based management dashboards, I fully can get behind the message of letting the vendor deal with the pain of keeping up the management system.

When the NMS requires as much upkeep as the WLAN environment it’s supposed to manage, we’ve somehow moved ourselves into a very inefficient place that just isn’t sustainable. I’d love to see Cisco somehow move all, and I mean ALL, Prime Infrastructure operations to the cloud. I’ve done my part- I’ve built a really good WLAN that serves thousands and thousands of client devices a day on Cisco WLAN hardware. I just want to manage that environment well, not be a slave to poorly implemented NMS and a development mindset that somehow thinks forked code and all of it’s collateral damage and that forcing users to PI’s Lifecycle view  if they want to manage 5760 and 3850 is acceptable. Move the whole management paradigm to the cloud, and let us get back to managing WLANs instead of doing battle with PI.


As a parting gift, see if any of you can make heads or tails of this real-world quizzler:

“Prime Infrastructure 2.1 does not support any features that are introduced in Cisco WLC Releases and except the new access point platforms and the new mobility feature.”

Uh, sure. OK… let me go pour through release notes for all of the things that are implied to not be supported in this odd note… oy.



6 thoughts on “Fork You, Forked Code

  1. wirednot Post author

    Hi Frank- I do need to clarify: I’m lamenting Cisco’s wireless management upgrade process here, and not the entire market-leading product set. In my environment, we have a phenomenally reliable Wi-Fi network in general, and it’s larger than most. The 5508 controller is among the more reliable pieces of hardware I’ve ever used, we serve literally millions of wireless sessions in a year and hundreds of thousands in a week. Cisco’s APs are Cadillacs, and our local SE team is great. There are reasons why Cisco still owns this market, but Prime Infrastructure in it’s current and recent incarnations is not one of them, in my opinion. But my frustration here is strictly with PI and all that goes into it- not with all of Cisco wireless. To me, the proof is in the pudding, and our Wi-Fi pudding tastes pretty damn good in general.

    1. Matt

      Herein lies the problem with Cisco’s PI- the larger you want to scale your wireless infrastructure, the more vital good NMS becomes, to the point that Cisco wireless may end up trailing the pack when potential customers look at their options. PI has been out for more than two years now and it is still complete garbage. When coupling the high expense and the worst performance (read: increased cost of support) of any vendor NMS with the relatively high cost of the wireless infrastructure itself, Cisco is hurting themselves big time. When looking at how to upgrade their wireless, a major university in my city recently chose to throw out every single piece of Cisco wireless infrastructure and start all over with a competitor precisely because it became unmanageable at their scale. You said it yourself “Good Wi-Fi systems lose their shine when bad NMS is the lens you view them with.” If Cisco can’t compete on cost in addition to marring the reputation of their solutions because of PI, they lose business.

      Where Cisco has really gone here is that they’ve allowed the same software development teams that royally screwed up ciscoworks back in the day to be involved in LMS and now PI. And don’t let the fancy new (terrible) UI fool you- there is still a depressing amount of ciscoworks code lurking around in PI’s back-end. Anyone who has been with Cisco for the past 10 years knows that no matter how much you polish the turd that was ciscoworks, at the end of the day you still end up with a turd. Because Cisco is focusing their truly talented SW teams on UCS and APIC, I doubt we’ll ever see a traditional NMS that is even worth 10% of what Cisco is charging these days.

  2. tmcclintic

    I have not seen a good trend since we went from WCS to PI. Trying to merge LMS and WCS to a single system seems like a task too daunting to take on. Even those inside Cisco seem confused by the paths taken. Someone needs to grab this bull by the horns, get it under control and provide a consistent piece of software we can leverage for managing our large wireless systems.

    Slipping in this area and pushing cloud services to large deployments will allow companies to consider alternative vendors….

    I agree though, I want to manage my network. I do not want to spend large amounts of time having to manage the system that I use to manage my network.

  3. apcsb

    I believe Cisco doors this intentionally to let Cisco partners make money. When things are simple and intuitive, and hardware is cheap, how is partner supposed to make a living and differentiate from box movers? (Well, I know the answer for wireless, but look at what’s happening in switching). 😉


Tell me what YOU think.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s