Analyzing analytic offerings

In case you’ve been living under a rock recently, the calm before the 802.11ax storm seems to increasingly be around Wi-Fi Assurance and/or Analytics. In particular, how is your Wi-Fi network performing and how happy are your clients (devices, not users). Most solutions on the market leverage a healthy dose of buzzwords to accomplish answering this question – most notably Machine Learning (ML), Artificial Intelligence (AI), Big Data, and don’t forget Cloud – to make you, the consumer feel like you’re genuinely on the bleeding edge of what a health related system can give you. It struck me during the recent MFD3 event that each of these solutions has a different way to approach the Assurance/Analytics problem, and of course each touts theirs as being ‘the best’ way to get all of the data needed to give you actionable data. Here is my take on the pro’s and con’s of some of the leading/competing solutions:

1) Mist Systems

Mist Systems claims to be the the First & Only AI-Driven WLAN – a bold statement indeed! Their primary source for retrieving statistics about users performance is directly inline from AP. This ‘at the edge’ approach allows them a deep insight into the radio and first hop performance of applications on their network. With a healthy punting of metadata to the Cloud, they claim to achieve “Automation & Insight through AI”.

Pro: A great example of ‘Cloud enabled’ Analytics and they do seem to genuinely seem to be hyper-focused on WLAN performance.

Con: Requiring Mist infrastructure means rip & replace for many organizations. Being hyper-focused on WLAN hardware leaves many organizations splitting their LAN infrastructure between vendors and that certainly diminishes the ‘one throat to choke’ troubleshooting. Visibility is at the AP layer only, ultimately leading to assumptive troubleshooting when issues outside of their visibility arise. Being a nascent company (and one of the last WLAN-only players) makes me wonder how long before they’ll be acquired.

Consumption: Cloud with a premium capex spend as well as ongoing required opex.

Bold claims!

Bold claims!

2) Cisco Meraki

Since being acquired by Cisco in November 2012, Meraki has continued to deliver on bringing features to market through their flagship product, the Meraki dashboard. The closest anyone comes to a ‘single pane of glass’ management portal, Meraki continues to shine for those Cloud-friendly organizations that have hyper-value on a single point of administration for their network. Generally, these tend to be the highly distributed organizations as opposed to the campus enterprise. Meraki’s ‘Wireless Health’ feature is in beta now and was ‘automagically’ delivered to existing customers.

Pro: Meraki’s AGILE product development targets the 80/20 rule pretty squarely. It’s ‘good enough’ for a lot of folks, and it’s ‘free’ to existing customers (if you don’t consider opex an expense of course).

Con: Wireless Health is Wi-Fi only – with no end to end correlation of their switches or security appliances, and it fragments the message around full-stack solutions. While focusing on making an ‘okay for most’ product, they certainly lose out on much of the deeper technical data commonly found in some of the larger platforms.

Consumption: Cloud with a premium capex spend as well as ongoing required opex (free to existing paying customers).

Slap a beta logo on it, call it good!

Wireless Health from Meraki

3) nyansa

Arguably *the* pioneer in Wi-Fi Assurance and Analytics, they were founded in 2013 and have a head start on most of the players in the market. Interestingly enough, nyansa is the only player in this space that not only doesn’t manufacture hardware to pitch at you, they work with an ever-growing number of existing infrastructure providers (including most of the major ones!). Leveraging an onsite ‘crawler’ to gather the data and to punt metadata to the Cloud, the onsite components are generally lightweight and assuming you’re already a VM friendly organization, no real hardware requirements (including any ripping and replacing of APs) is needed.

Pro: They’ve been at it a longer than anyone else and are clearly ahead of the game. They accept data from a variety of network sources including your LAN infrastructure so their ability to more accurately pinpoint issues is likely to be more accurate than a Wi-Fi only solution. Being able to ‘compare’ your data to peers of your own ilk is an interesting proposition and clearly one of the premier features they hang their hats on.

Con: Having an analytics only platform that’s not tightly coupled with your infrastructure leads me to wonder about the long-term stickiness of the solution. The perceived high-cost of the solution, has lead many to ‘deploy, diagnose, then remove’ – very much defeating the long term goals of Analytics and Assurance platforms. Ongoing success when ‘all is good’ is very hard to demonstrate and the vendor neutral approach leaves them vulnerable.

Consumption: Primarily an opex play since there isn’t really a capex component to speak of (no APs or appliances to install).

That's not creepy at all.

nyansa

 

4) 7signal

7signal has been fairly quiet on the Assurance front as of late, but they’re worth a mention. Being the pioneer in sensor driven tests, hanging an ‘eye’ to connect to your network and measure/gather various statistics about how well it’s performing has been their pitch from day 1. Falling more on the ‘stats digestion’ side of the house rather than on the ML/AI side of the spectrum, 7signal is worth noting due to their synthetic testing that closely mimics what a client sees on the network.

Pro: Client first is the best way to view the network and a sensor (or embedded into a client) is the only way to get this data.

Con: Having *only* client data means that correlation has to happen in a guesswork fashion. Coupled with a difficult install and a user interface that could stand a healthy dose of sprucing up and the platform overall is feeling pretty stale.

Consumption: Capex spend for the sensors and ongoing support and maintenance. On premises deployment model with ‘lightweight-at-best’ analytics.

5) Aruba

Aruba acquired Rasa in May of 2016 to become part of the Aruba Clarity team. They’ve since changed gears and are rolling the Rasa features into NetInsight. They’ve been relatively quiet on the productization front here, opting instead to show it off at events like Aruba Atmosphere and Mobility Field Day events. They get some interesting insights out of the education campus use case they show but I’ve not seen any readily actionable insights that don’t require some level of Data Scientist level of queries. They have the potential to move the needle in the industry here, but making it easy to use is clearly something they’re struggling with.

Pro: Buying a ready made analytics company reduces their time to market and clearly Aruba is moving aggressively to get into the analytics game here. If you’re an Aruba Wi-Fi, AirWave, or Clarity/NetInsight customer, they have some big things in store.

Con: Today the data is clearly difficult to get at. Usability leaves a lot to be desired and there is some pretty unclear things about where the platform is going. Between the legacy Clarity offering, the Rasa integration, NetInsight, and don’t forget about the recent Niara acquisition on the security side. There are lots of moving pieces here and Aruba will have to bring some quick clarity (hah!) to their consumption model.

Consumption: NetInsight productization is currently TBD, but I expect it will be Cloud-first, if not Cloud-only by the time you can get your hands on a production ready solution.

Doing thoughtful things.

Thoughtful people

6) Cisco Enterprise

Cisco has been focused on DNA-Center, the successor to the APIC-EM platform. The platform runs ‘apps’ on top, and one of the flagship applications shipping today is DNA Assurance. This platform is the ‘all-in’ Cisco assurance platform that takes data from everywhere you can think of – netflow feeds from your WLC and/or switch, radio data from the AP, synthetic data from sensors, and feedback from actual clients. In short, they take the best of all worlds and attempt to lump it into one big platform without giving people the heebie-jeebies about their data being in the Cloud.

Pro: Ambitiously Cisco is taking the ‘whatever you can feed me’ approach to Analytics and Assurance. The more feeds you can send to it, the better. This allows organizations to deploy the solution components that make sense to them and add more later if they want improved fidelity. Deploying an Analytics platform that you can actually run onsite in a 1RU appliance is no small feat and will be an undoubted boon for those Cloud adverse.

Cons: All of that horsepower isn’t cheap. Coupled with Cisco’s somewhat tarnished reputation as of late around code quality makes some people nervous about ‘one box to rule them all’, but this should generally be a mitigated concern for out-of-band analytics. Of course, this all works best if you’re Cisco end to end and that could be perceived as a negative to some.

Consumption: On premises hardware appliance fed by Cloud updates for the applications. Your Cisco ONE licensing consumption model and Smart Licenses will be key to getting this off of the ground, but so far there is no ‘break if you don’t pay’ approach.

I hope that the roll-up was a useful overview to the Analytics and Assurance market as it sits today. Did I miss anyone? Let me know and I’ll try and get a summarization up for you ASAP!

Advertisements

Meraki gets smart

I’m a fan of antennas. They’re pretty awesome components of Wi-Fi networks and I think they’re one of the most under-appreciated and oft-overlooked components, so when someone introduces a new antenna related technology, I tend to sit up and take notice!

 Recently, Meraki released their new external antenna model APs, the MR42E and MR53E. In the past, if you needed antenna flexibility in a Meraki solution, you had to use their outdoor rated AP. This introduction, in addition to rounding out their AP portfolio, snuck a new innovation into the market that Meraki has dubbed ‘Smart Antennas’. With the promise of auto-identifying an antenna to the AP, I couldn’t not know more about it! One of the more notable aspects of using external antennas is the potential risk to exceed regulatory compliance. While not terribly complex, the risks for getting it wrong could see the Feds breathing down your back – and nobody wants that! In addition to self-identification for compliance reasons, the new models of APs include more connectors than one might otherwise expect – 5 connectors for the MR42E, and 6 for the MR53E! This breaks down to 3 Wi-Fi antennas, 1 security/scan antenna, and 1 BLE/IoT antennas for the MR42E, and the same compliment on the MR53E with one more Wi-Fi antenna to support that 4th spatial stream. Without delving into each individual component, I really wanted to get a feel for if this thing did what it promised it would do, so I hooked them all up to their respective ports:

That’s a lot of cables!

Fired up the AP, claimed the hardware in my dashboard account and went poking on the antenna settings! Sure enough, where you would normally define an antenna, the exact model number of the antenna array I had was shown!

The cloud got it right!

Hoping it wasn’t fluke of some sort, I powered off the AP, disconnected them all, and tried again. Sure enough, this time, the dashboard presented me with the expected drop down list of available antennas.

The cloud still wants to help out.

I was impressed, it was magic, it worked automatically and wonderfully – and I had to know how. One screwdriver later (the tool, not the drink), I had done the unthinkable, and performed the ill-advised dissection of the shiny new antenna looking for something out of place:

No stranger to the inside of an antenna, the culprit jumped out at me pretty readily:

What appears to be a Maxim Integrated DS2431 1-wire EEPROM was sitting inline just before an antenna element. I traced it back to the connector and found it belonged to the externally-labeled IoT connector:

So, I dutifully connected just the IoT port to the AP, fired it up and viola! The dashboard indicated that the antenna was identified properly despite the fact that only 1 of the 6 connections was attached. This seems to reinforce that Meraki has indeed found a pretty intuitive way to integrate a digital component onto an analog line (as opposed to Cisco that has actual digital connectors in the DART) for a one-time polling of the antenna ID. This was further reinforced by booting the AP without the IoT port connected (so it did not identify the antenna correctly) and then re-attaching it without powering down the AP. After a day of uptime, the AP never properly re-identified it’s antenna. This means that, if you’re using the Meraki smart antenna solution:

  1. Make sure that the antenna cables are attached to the proper port using the silkscreen indicator on the RP-TNC connectors
  2. Make sure that if you change any antenna ports (especially the IoT port), you should reboot the AP so it can properly identify itself to the AP, and subsequently the cloud

It remains to be seen what kind of ecosystem Meraki intends to develop with 3rd party antenna developers, but rest assured, if you want to use a 3rd party antenna today on these new Meraki APs, you certainly can – you just need to log into the dashboard and make sure you pick the equivalent Meraki antenna that closest matches the gain of your 3rd party antenna.

The Cloud giveth, the Cloud taketh away

We all love ‘The Cloud’. It’s flexible, fast, always (mostly) available, and takes our business agility to heretofore unknown heights – but what happens when the service you’re using in the cloud goes a different direction than you need or want it to?

Meraki has been touting the Cloud flexibility as *the* single most important reason to move to their infrastructure management platform. This brings with it a whole host of great things like access-anywhere management, rapid feature development, and a whole new paradigm of how to configure your infrastructure equipment. In one move, Cisco has rocketed past the CLI based days of old, past ‘here’s a pretty GUI’ to 100% web driven, ‘don’t worry your pretty little head about it’ dashboards for everything from configuration, monitoring, troubleshooting, and deployment. It works and it works well.

Today marks the closing of Copy – a Cloud based file sync service from Barracuda and it got me thinking. When someone shudders their doors and it’s ‘just files’, you go to another Cloud based service provider – in this case Dropbox or box.com. What happens when/if Meraki goes away? Okay, they’re under the wing of big-brother Cisco now, so the chances of that happening are basically nil, but what if you ratchet that concern back a notch? What if they make a change you don’t like? What about ‘perpetual beta’ features such as the Remote Control that have been in beta since prior to the Cisco acquisition? What happens if you don’t pay your bill? Those of us familiar with Cloud services like Office 365 know that when you stop paying, you stop playing and for software based services (like Copy today) that doesn’t seem to as big as a deal to most people. What happens when that service is your network?

Remote control

Perpetual Beta features

When Meraki adds a new feature to their product, the Cloud enables rapid deployment of those features. This is good. What happens when they remove a feature you use such as WAN Optimization? As you an see here Meraki decided to retire what they perceived to be either a little-used feature or a feature that was too difficult to maintain to keep functioning properly.

WAN Opt

WAN Optimization, gone baby, gone!

What happens when Meraki decides to artificially cap the performance of your router (intentionally or unintentionally) to 50M?

Z1 Cap

Astute reddit users, always on the lookout.

While the WAN Optimization removal is clearly an intentional move and the Z1 cap is clearly unintentional, these both raise very significant questions about allowing someone else to be the ultimate authority for the features that are deployed on hardware you’ve purchased. What is your recourse when this happens? Open a support ticket? Make a wish? Roll back the firmware (hah!)? With no fail-safe mode of operation by design, when you lock yourself into a Cloud based infrastructure product, you are ultimately at the mercy of using features how and where they determine are best suited. Your only recourse is to scrap your gear if they make a decision to go in a direction that you no longer support. What is the environmental impact to this business model? How many Cloud-only products end up in landfills because of expired licenses? How much eWaste is generated because the product has stopped functioning (not through MTBF, but intentionally crippling through code)? You used to have options like Cucumber Tony and OpenWRT, but apparently Meraki has fixed the technical loophole that those folks used to use for the MR-12 and MR-16 Access Points by way of a Trusted Platform Module.

What is your take on Meraki and other Cloud based services that you operate your business with? Cloud based products are great and work as designed – but is loss of features something you consider prior to your investment in a solution? Does your organization rely on perpetually beta features that never seem to make it into production? Has a feature been ‘pulled out from underneath you’? What are you doing with that old AP/switch/firewall that is perfectly good hardware but you let the license lapse on? Inquiring minds want to know – please leave me a comment and let me know how you and your organization handles this kind of quandary!

Meraki: The bolt on Cloud that wasn’t

When Cisco acquired Meraki last year, there was much confusion. Being ‘down in the trenches’ I struggled as much as the next guy trying to wrap my head around the acquisition and I believe I have a good handle on it. Others not so much. I regularly consult with customers that are just as confused today as they were last year. Cloud is such an over used buzz word and so many vendors are trying to jump on the buzzword bandwagon de jour that it’s easy to get lost admist the jargon and solutions, much less the technical merits or differences in the platforms. I’m here to offer some advice on the strategy and perhaps a perspective on the acquisition that you haven’t yet considered. First some advice:

Don’t purchase Meraki Access Points. You read that right. Don’t do it. Also, don’t purchase Meraki switches. For that matter, don’t buy the Meraki firewall either. If you purchase a Meraki Access Point, a Meraki switch, or a Meraki firewall, you’re not buying an Access Point, you’re not buying a switch, you’re not buying a firewall. You’re buying ‘The Cloud’. When you consider purchasing infrastructure equipment that is ‘Cloud Enabled’, this should be a purchase that lines up with your organizations Cloud Strategy first and foremost. Don’t have a Cloud Strategy? Don’t be so sure. There are a few questions to ask yourself before you jump to that conclusion. Does your organization use DropBox? Salesforce.com? Office 365? Webex or Goto Meeting? Google Mail? All of these are examples of Cloud Applications. If you use these, someone, somewhere in your organization has made the determination to embrace services from ‘The Cloud’. Understand this strategy. Understand what this enables. Understand what this means to your data and where your data lives. Then (and only then) should you consider purchasing ‘Cloud Managed Infrastructure devices’.

Let’s be frank about it, there’s nothing special about the hardware in a Meraki Access Point. There’s nothing special about the hardware in a Meraki Switch, nothing special about the hardware in a Meraki firewall. When you purchase Meraki equipment, this gear is purpose built to be Cloud Managed with features driven by that Cloud Management. When you make a Meraki purchase, purchase an end-to-end Cloud-enabled infrastructure. If it’s right for one component, it’s right for all of them. If it’s not right for all of them, it’s not right for any of them.

Now some perspective. Everyone is talking about Cloud. Everyone wants in on the Cloud action. Everyone is ‘bolting on’ Cloud to their existing products in some fashion or another. When Cisco purchased Meraki, they made a decision to not ‘bolt on’. They decided to pick the one organization that understood Cloud from bottom to top and embrace that strategy despite the fact that there was some hardware overlap. The Meraki acquisition wasn’t about Access Points, switches, or firewalls. It was about finding the one organization that was never built for ‘on premises’ management and this shines through in every aspect of their products. Others tout ‘free protocols’, ‘cloud provisioning’, or a variety of other nonsense but at the end of the day, these are bolt-on solutions that are all afterthoughts. I would encourage you to revisit the Meraki product portfolio but when you do, ask yourself the following questions:

  • What are my existing Cloud Applications?
  • How do I rely on ‘the Cloud’ today?
  • Do I want to leverage that existing strategy in my infrastructure?
  • Do I want a solution that is built from the ground up around ‘the Cloud’ with a no-compromises featureset or do I want to deal with someone bolting on features to their existing ‘heavy gear’?

Then go buy a Meraki AP.