Category Archives: Wireless Networking

Transparency as a Service- Yes, Please

Whether it’s in our personal relationships or technical careers, honesty and transparency go a long way. None of us are perfect, and even our best efforts can be undermined by an errant cut and paste, a cocked connector, or any number of soft or hard goof-ups. You know the routine- fix it quick, own up to it, and have a talk with yourself (even if the boss gives you a free pass) about what you’ll do different next time to not repeat the error.

Transparency and honesty show character and confidence- you’re big enough to admit your snafus, because they hopefully don’t happen often. But take it in the opposite direction and your credibility goes in the toilet. Show that lack of transparency or repeat the offense too often, and there may be no salvaging your good name. None of this is news, right? And what does this have to do with networking?

Consider this message that many Meraki customers recently received:
Meraki Lost

In this case, I lost a handful of floor plans that had APs placed on them from just a couple of my many sites, other people lost more. Meraki came out with guns a’ blazin’, and basically said “we screwed up”. I like the approach, and I also value that the cloud dashboard provides a natural conduit for the vendor to push information in front of the customer. 

Then there’s this sort of thing, from Aruba, Cisco, and other vendors:
Aruba Sec

That one came in my email, and the proactive notice is appreciated as it saves me from having to go out and dig around. But… vendors can do more. Even in the absence of the ability to push notifications as with a cloud dashboard, they can leverage email culled from support contracts to warn of catastrophic bugs ahead of customers hitting them.

I’m not inviting vendors to spam us with every bug that any customer hits, as that does nobody any good and wouldn’t be practical. But I can remember a day when my environment was ground zero for discovering a fairly catastrophic bug that had profound implications for the stated capabilities of a given hardware platform. As best as I can tell, pretty much no other customers were made privy to the information, and I saw at least half a dozen cases over the next couple of years where the same limitation was hit (the product data sheet should have been updated to reflect the discovery- it was that bad and blatant). Customers talk and share information. This situation felt real, real sleazy from where I sat, and seemed a natural candidate for sharing with anyone who had that component on paid support. Instead, vendor credibility was bludgeoned.

I like these from Cisco, released quarterly (some Cisco-sensitive content removed from attached):
cisco code

This is something all vendors should be doing. At the same time- there is so much bad code out there, customers deserve better communications on what really shouldn’t be used. It’s just confusing as hell when the “recommended” code is several versions behind others that are out in the wild available for download. I propose crystal clear warning labels on the download page, and calling the non-recommended code versions “beta”, as they often feel as such.

In closing, whether “honesty is the best policy” is applicable, or “sunlight is the best disinfectant” seems more appropriate, you get the point. Enterprise systems just cost too much and budget-minded IT teams are being tasked with doing ever more with less resources. We need that transparency thing from vendors, now more than ever. It keeps us from making mistakes that can be prevented if we only knew what the vendor already knows, and keeps the vendor’s credibility in good standing- and that is one thing you can’t put a price on.

 

Catching Up With Netscout on Their Flagship WLAN Support Tool

linklive_solutions_smIt’s not often that most of us get to spend time with product managers at big-name Silicon Valley network companies. I’ve been extremely fortunate in this regard through my participation in the Tech Field Day franchise, and recently had the opportunity to once again hang out for a bit with Netscout, in their own offices. The topic of this visit was the company’s super popular AirCheck G2, and our host was the awesome Chris Hinsz. (Chris makes the rounds at a lot of conferences and industry events, and is passionate about helping to make the WLAN world a better place. If you ever get the opportunity to talk with him, I guarantee it’ll be time well spent.)

If you are not familiar with the AirCheck G2 yet, let’s get you squared away.

The G2 is Generation 2, given that THIS AirCheck is the follow on to the original Fluke Networks AirCheck. The division of Fluke Networks that developed the AirCheck was bought by Netscout, hence the vendor name change along the way. If you’re interested in a unique way the original AirCheck was put into service for law enforcement, have a look at another Network Computing article I did back in the day. But alas, I digress…

Back to Mobility Field Day and the G2.

Hinsz did two sessions for MFD. In the first, he provided an intro to the tester and the handy Link-Live cloud service for those who may not be familiar with it. The video is here. He also provided insight into advanced tips and shortcuts on the G2, which you can review in this video. Even if you own and use a an AirCheck G2, you just might find something new to try via these videos.

Aside from the two sessions referenced here, it was a pleasure talking with Hinsz and his team about what else is going on with the AirCheck G2. This awesome unit is truly one of the favorite tools used by many a WLAN pro given it’s versatility and portability. It’s a safe bet that we’ll be hearing more about the AirCheck story as Netscout continues to listen to what it’s customers need, given that we’re only a couple of years into the life-cycle of this tester.

 

Mojo Networks Touts Lower Networking Costs, No More Vendor Lock-In at Mobility Field Day 2

Mojo Networks never fails to provide an interesting presentation. Recently, I sat in Mojo’s conference room in San Jose for the fourth time in roughly as many years to hear what the company is up to, and what their vision for the future is. At Mobility Field Day 2 (MFD2) I found myself fairly riveted to CEO Rick Wilmer’s introductory session. Why? Because if Wilmer’s vision of WHAT COULD BE takes root, it could disrupt the WLAN industry (and beyond) in some profound ways.

Wilmer pulled no punches describing what the typical margin is for wireless access points sold to customers- 70%. That’s 70% per AP, times hundreds of thousands of APs generating much revenue for WLAN vendors. Wilmer sees a world where the advantage shifts to the customer when it comes to wireless access points, but we’ll get to that.

Then there’s vendor lock-in… I remember back in the early days of LWAPP (the thin AP protocol), I had very naive and childish visions of a protocol so sparkly-wonderful-special that I might be able to mix components from Vendor A and Vendor B on the same damn network. I was all a-tingle, for about 30 seconds. Then I was slapped with the reality that what comes out of the antennas might be mostly-standards-based, but there is and would continue to be zero compatibility between vendors under the hood. Ah well, I was a silly wireless child then. But Wilmer’s vision touches that as well.

If you watch the MFD2 Wilmer session, you’ll not hear a CEO harping on buzzy claims of Machine Learning and crazy wonderful feature sets. (That all comes later in Mojo’s other presentations, and even then what could be a Bucket o’ Buzzwords is really just incorporated into what Mojo does, versus the vendor hanging a bunch of impressive terminology in the air and hoping that you salivate over it.) Wilmer paints a vision of commodity-priced access points- and eventually switches and security appliances- being cloud managed in an open source framework where innovation is driven by the greater technical community instead of any single vendor’s skewed view of the feature world.

Cloud management, software-defined everything, and open hardware standards CAN replace bloated, proprietary systems as shown in different examples made by Wilmer’s team in presentations that came after his. The technical stuff is interesting, and you should watch Mojo’s story from MFD2 all the way through. But just as significant is Mojo’s idea of a new business model that flies in the face of convention, and could capitalize on the success of the Open Compute Project (OCP) in building white box data center components as that model stretches into wireless access.

It’s a fairly bold premise, and I applaud Mojo for taking a truly unique and interesting path. Hopefully they find some big allies soon to help push this vision along.

See Mojo Networks at Mobility Field Day 2 here, and catch up on all things Mojo at the company’s blog.


Some of my past coverage of Mojo Networks (and Airtight)

Leaked Intel Rocks the Wi-Fi World

In a mind-blowing release of leaked intelligence reports this week orchestrated by Archimedes McGeraldo-Fitzperhume, the head of WifiLeaks, the WLAN community is scrambling to digest and to react to a series of shocking revelations.

This tight-knit ecosystem of designers, engineers, installers, vendors, and salespeople is no doubt dumbfounded to it’s core over secrets that are no more, and it’s a safe bet many are scrambling to come up with damage-control strategies in the face of these shocking allegations.

Among the most salacious bombshells:

  • Tom Hollingsworth is a cyborg. 
  • Wireless LAN Professionals is a front for a radical paramilitary Wi-Fi organization. Beloved patriarch of the Wi-Fi community Keith Parsons is actually Major General Parsons, the brain and muscle behind a number of secret programs. Among the many operations in progress at the group’s clandestine facilities in Elk Snout, Utah:
    • Colonel Randall von Naggle heads up Men Who Stare at Wi-Fi, an experimental initiative that uses ESP to see RF cells
    • Dr. Clemente Samuelson has almost perfected “Lefty”, a hyper-sophisticated robotic hand capable of pouring whiskey and used for grabbing one’s own ass
    • Commander Lucille Hubersmythe is training an elite squadron of very flexible WLAN warriors for anticipated operations against the Xirrian Liberation Front
    • Next-Gen Videologist Benjamin Freedmanistan has mastered time travel, and will soon be livestreaming events yet to happen
  • Global Warming is actually the result of two major contributing factors:
    • the heat generated by all of the WLAN analytics crunching that is going on in murky data centers around the planet
    • uneaten gluten

This story continues to unfold, and it will no doubt get worse before it gets better.

<WTF did I just read? This was actually an April 1 (April Fools’ Day in the US) draft that I started, and never published. Just found it, and pushing it out for giggles.>

Mist Systems Polishes Their Message at Mobility Field Day 2

It’s always refreshing when a truly original story comes along in the WLAN world. Mist Systems isn’t quite brand new (I wrote about them for Network Computing back in 2016) but their approach is fresh enough to cause some good energy in the room when you do get the chance to hear a briefing from the company’s top dogs, and I recently got that chance again at Mobility Field Day 2.

Here’s the thing about Mist, now- today: if you’re not careful, their story can sound like another one of the many from network vendors where terms like AI and Machine Learning are bandied about like the Buzzword Flavors of the Month. But Mist was talking this language well ahead of the current curve. Where established vendors are largely painting their long-running gear up in a coating of hype and APIs, Mist is actually new magic built by data scientists and proven network visionaries. It’s heady, exciting stuff.

But can Mist make a legitimate go of it as new player in the Big Customer Kickball Game where most current potential customers have already chosen a side? Here, only time will tell as Mist’s marketing paradigm is put to the test. I can share my own opinions and gut reactions from the Mobility Field Day for you to consider, and welcome any dissenting opinions or comments:

In Mist’s Favor

  • When Bob Friday and team tell the tech story behind Mist, it’s impressive and believable
  • Mist is the real deal when it comes to Machine Learning, etc- where the message feels forced with other vendors
  • Mist seems to have mastered the UI challenge (put lots of important stuff in front of the WLAN admin without making it feel like overload) with their cloud dashboard
  • Mist uses no controllers (bug hotels) or user-upkept bloated NMS system
  • They tell a great story on bug management and code quality
  • The virtual BLE beacon thing is huge. As in freakin huge. And it can stand alone even if you don’t need Mist’s WiFi solution
  • Nyansa-like analytics are compelling
  • Long-time users of established systems are getting burned out in spots on license overkill, huge costs- creating potential openings for a WLAN vendor change

Of Concern

  • Mist is late to the overall WLAN party, so is up against established players
  • The lack of switches and security appliances can be problematic in some RFPs, and when looked at through bullshit lenses lenses like Gartners Magic Quadrant
  • We’re still not hearing enough about “unnamed Fortune Blah Blah Blah customers” to really do our own independent verification of how Mist is working out in the real world
  • Mist is just getting ready to ship outside APs later in 2017, and how that impacts their analytics (especially when outside/inside WLAN are managed in same pain of glass) remains to be seen

I really enjoyed what I saw and heard from Mist, and it’s obvious that the company’s leaders truly believe in their baby’s potential. And- you don’t just have to hear my opinion… form your own after watching the Mist MFD session here.

 

 

 

 

Mobility Field 2 Shows Evolving Nature of WLAN Industry

MFD2The “Tech Field Day” series of events has been  an important part of my professional development life for the last several years. I’ve had the good fortune to be a frequent delegate, and I have watched Wireless Field Day (WFD) morph into Mobility Field Day (MFD) in parallel with the changing nature of the WLAN industry. As we get ready to descend upon Silicon Valley for MFD2, I can’t help but think about what this round of vendor participants says about the general state of WLAN things.

This go round, you won’t see the usual suspects many folks think of when contemplating enterprise Wi-Fi. MFD2 is more about performance measurement and alternatives to the WLAN same-old with Mist Systems, Nyansa, Cape Networks, Mojo Networks, and another performance measurement vendor to be announced soon.

So why no bigtime flashy AP makers?

Here’s my take on that, and there are a few contributing factors:

  • The biggest guns have relegated their WLAN parts and pieces to non-headline status. Each has declared “We’re a software company!” of late, and is now devoting time to weaving together Intent-Based Network Fabrics With SDN Flavor Crystals. And… they have their own hyper-glitzy events where non-technical Hollywood-types make attendees swoon. Meh.
  • Extreme Networks is buying up almost everyone else, so the number of competing players is decreasing.
  • Ubiquiti is now #3 in market share, and seemingly needs none of these events to get their message of “economy-priced but half-way decent networking” out to the masses.

By now, WLAN is so tightly integrated with the rest of the network (in most environments) it doesn’t command the stand-alone Wow Factor it once did. But… in the rush to build feature-heavy (I’d even say “gratuitously bloated”, but I can be a wanker about these things) super systems, the big guns haven’t done all that well in natively providing many of the capabilities that MFD 2’s vendors will be briefing us (and those tuning in live) on.

From innovative ways of showing what’s really going on with a given WLAN to to fresh approaches to WLAN architecture (as opposed to butting an API into years’ old code and declaring it new SDN), MFD2 will be interesting.

If you tune in live and would like to get a question to the vendors as they present their stuff, make sure to hit up a Delegate or two via Twitter so we can ask on your behalf.

 

 

 

Cisco DNA SD-Access: Evolution or Identity Crisis?

This blog will make the most sense to those who use (or are very familiar with) both Cisco and Meraki network environments. (Not you? Feel free to leave, but before you go let me at least show you my boat– and yes, it is for sale. OK, now get outta here.) For the rest of you… onward we go.

Get Your SD-Access Mind Right

I’ve been trying to educate myself on Cisco’s latest evolutionary moves, as I happen to be a twenty-year Cisco customer. There’s a lot of energy going on between DNA, SD-Access, THE NETWORK. INTUITIVE. (God that one is just terrible, I’m sorry) fabric this and that, and a procession of other grandly named initiatives. It’s all very fascinating, and impressive to a certain degree. I want to share my impressions on SD-Access specifically, and am curious what others in the game might think of my take on it after you digest all of this.

First- you have to understand what SD-Access is all about. This will get you started if you need a kick-start, but I suggest getting a better look by viewing these Techwise TV episodes.

Now the part about Meraki. After learning about SD-Access, it feels to me that Cisco is trying to somewhat “Merakify” their network approach. SD-Access even starts with the Meraki-style networky map, before continuing in many Meraki-ish ways:

Landing Page
SD-Access Map

Compare to the Meraki map:

Landing Page 2

Meraki Map

The similarities continue- in the videos the presenters enthusiastically talk about doing virtual configurations for equipment that’s not in place yet, etc. Much of this is Meraki 101 in look and feel, but with significant operational differences.

All That’s Good About Meraki, All That’s Bad About Cisco?

As a long-time Meraki customer, I have LOVED not having to deal with the administrative and OpEx pain that comes along with Cisco’s approaches at times. With Meraki there is NO bloated, chronically quirky NMS (like PI), or wireless controllers that have their own history of hardware and code issues. All that’s in the cloud, and someone else’s problem to keep up at upgrade and debug time.

(I am NOT saying Meraki is perfect, by any means. All solutions are trade-offs. I’m only pointing out that the hundreds of man-hours per year in OpEx troubleshooting bugs and such in PI and WLC have not had equal headache on the Meraki side for me.)

With SD-Access, it seems that APIC-EM becomes the on-premise magic that is equal to the magic that Meraki uses out in the cloud, but only for Merakifying traditional Cisco components. So at the end of it all, if you have the right Cisco components, SD-Access will give you a very Meraki-like experience from the admin side.

Now, I do realize that SD-Access does A LOT of stuff, and likely delivers some features that Meraki can’t right now. But..

I actually use daily many of the Cisco components that fall under the SD-Access framework, and they can demand copious amounts of care and feeding. For the Wireless LAN Controllers (just one example), you may have to play several rounds of Let’s Make a Deal with TAC to get code that works good enough in your environment- and the larger your environment, the harder it seems to be for Cisco to test at scale. Having been around this block with Cisco dozens of times, I have no reason to think the underlying culture of bug tolerance and hyper-complexity is probably going to change soon. So often-problematic components becomes part of a new, API-driven architecture? That’s fairly terrifying to me.

At the same time, achieving “The Meraki Experience” is an admirable goal, as using Meraki’s own approach has been fairly fantastic for me, by and large (with only the rare “oh shit” moment along the way.)

The Point

I think it’s awesome that Cisco can try to poach what’s good from Meraki (and visa versa), but it also makes for confusion. If Cisco is trying to be Meraki for access, then what’s Meraki supposed to be at the end of it all? Or will SD-Access be ultimately marketed as “on-premise Meraki” or some such?

Meanwhile, I can’t imagine the inevitable TAC case nightmare that will come when something isn’t working in SD-Access and I have to wade through PoE bugs on switches, any number of problems on WLCs, API debugs and ISE logs to figure out which part of the magic isn’t behaving THIS time around.  For me, if I want a Meraki-like experience, I think I’ll opt to stay with Meraki’s lack of in-house moving parts and give SD-Access a pass- at least until something happens on the Cisco side that convinces me the solution won’t be as buggy as is it’s parts.

_______
Your thoughts? Please share an opinion, as all are valued.