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.

Advertisements

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.