Thanks to a couple of recent conversations, I thought it was time to stir the wireless pot a little. First was my retweet of an excellent DNS workaround post from Justin Cohen (@CanTechIt). One of the responses I got from wireless luminary Andrew von Nagy (@RevolutionWifi):
This echoed some of the comments that I heard from Sam Clements (@Samuel_Clements) and Blake Krone (@BlakeKrone) during this video from Cisco Live Milan in January:
During that video, you can hear Sam and Blake asking for a few features that aren’t really supported on Meraki just yet. And it all comes down to a simple issue.
Should It Just Work?
Meraki has had a very simple guiding philosophy since the very beginning. Things should be easy to configure and work without hassle for their customers. It’s something we see over and over again in technology. From Apple to Microsoft, the focus has shifted away from complexity and toward simplicity. Gone are the field of radio buttons and obscure text fields. In their place we find simple binary choics. “Do You Want To Do This Thing? YES/NO”.
Meraki believes that the more complicated configuration items confuse users and lead to support issues down the road. And in many ways they are absolutely right. If you’ve ever seen someone freeze up in front of a Coke Freestyle machine, you know how easy it is to be overwhelmed by the power of choice.
In a small business or small enterprise environment, you just need things to work. A business without a dedicated IT department doesn’t need to spend hours figuring out how to disable 802.11b data rates to increase performance. That SMB/SME market has historically been the one that Meraki sells into better than anyone else. The times are changing though.
Exceptions Are Rules?
Meraki’s acquistion by Cisco has raised their profile and provided a huge new sales force to bring their hardware and software to the masses. The software in particular is a tipping point for a lot of medium and large enterprises. Meraki makes it easy to configure and manage large access point deployments. And nine times out of ten their user interface provides everything a person could need for configuration.
Notice that was “nine times out of ten”. In an SME, that one time out of ten that something more was needed could happen once or twice in the lifetime of a deployment. In a large enterprise, that one time out of ten could happen once a month or even once a week. With a huge number of clients accessing the system for long periods of time, the statistical probability that an advanced feature will need to be configured does approach certainty quickly.
Meraki doesn’t have a way to handle these exceptions currently. They have an excellent feature request system in their “Make A Wish” feedback system, but the tipping point required for a feature to be implemented in a new release doesn’t have a way to be weighted for impact. If two hundred people ask for a feature and the average number of access points in their networks is less than five, it reflects differently than if ten people ask for a feature with an average of one thousand access points per network. It is important to realize that enterprises can scale up rapidly and they should carry a heavier weight when feature requests come in.
That’s not to say that Meraki should go the same route as Cisco Unified Communications Manager (CUCM). Several years ago, I wrote about CSCsb42763 which is a bug ID that enables a feature by typing that code into an obscure text field. It does enable the feature, but you have no idea what or how or why. In fact, if it weren’t for Google or a random call to TAC, you’d never even know about the feature. This is most definitely not the way to enable advanced features.
Making It Work For Me
Okay, the criticism part is over. Now for the constructive part. Because complaining without offering a solution is just whining.
Meraki can fix their issues with large enterprises by offering a “super config mode” to users that have been trained. It’s actually not that far away from how they validate licenses today. If you are listed as an admin on the system and you have a Meraki Master ID under your profile then you get access to the extra config mode. This would benefit both enterprise admins as well as partners that have admin accounts on customer systems.
This would also be a boon for the Meraki training program. Sure, having another piece of paper is nice. But what if all that hard work actually paid off with better configuration access to the system? Less need to call support instead of just getting slightly better access to engineers? If you can give people what they need to fix my problem without calling for support they will line up outside your door to get it.
If Meraki isn’t willing to take that giant leap just yet, another solution would be to weight the “Make A Wish” suggestions based on the number of APs covered by the user. They might even do this now. But it would be nice to know as a large enterprise end user that my feature requests are being taken under more critical advisement than a few people with less than a dozen APs. Scale matters.
Yes, the headline is a bit of clickbait. I don’t think it would have had quite the same impact if I’d titled it “How Meraki Can Fix Their Enterprise Problems”. You, the gentle reader, would have looked at the article either way. But the people that need to see this wouldn’t have cared unless it looked like the sky was falling. So I beg your forgiveness for an indulgence to get things fixed for everyone.
I use Meraki gear at home. It works. I haven’t even configured even 10% of what it’s capable of doing. But there are times when I go looking for a feature that I’ve seen on other enterprise wireless systems that’s just not there. And I know that it’s not there on purpose. Meraki does a very good job reaching the customer base that they have targeted for years. But as Cisco starts pushing their solutions further up the stack and selling Meraki into bigger and more complex environments, Meraki needs to understand how important it is to give those large enterprise users more control over their systems. Or “It Just Works” will quickly become “It Doesn’t Work For Me”.
100% Agree… nothing else can be said, that you did not just say.
Curious to see which features you feel are missing. It’s possible I just haven’t noticed them yet, as we move to a more complex network infrastructure. Currently, we’re doing 802.1x for our enterprise devices, and a simple splash-screen for our guests. We’re moving toward requiring sign-in for the guests, but that’s not terribly difficult either.
We also do web filtering and firewall off the guest network from our production network.
What am I missing and what am I about to bang my head up against that I need to be worried about?
There are a few things I run into with Meraki that bother me – I do a fair share of it, and some in larger enterprise. Simple things like the status of an ethernet port on an MX I cannot see – or – no routing protocols on their firewall products (BIG PROBLEM). The lack of rate control capability on wireless AP’s, there are some issues here.
The product is amazing, small clients get the benefits of Prime, ISE and WCS without having to build those products out. IT Service Providers can provide easy remote support, there are clear benefits.
Meraki is a product that is very successful when it is very carefully qualified. However if you sell it improperly qualified, you are in a world of hurt simply because features you probably assumed existed – are simply not there.
Thanks for clarifying – that may be why I haven’t run into issues with it so far. We are only doing Meraki wireless. We don’t have an MX or any of their switches. All our switches are Cisco and we use someone else entirely for the security appliance.
The Wireless is great, so are the MX devices – they do some innovative things that are great. The MX series firewalls do some amazing things like Auto VPN even behind other firewalls, the VPN is 1000X easier than on an ASA platform, so is client VPN, Radius is super easy.. Wait, no routing protocols? Only 2 Internet ports? Limited route tracking? proprietary DMVPN.. — yes limitations, but sized right, Meraki is a dream to work on.
The switches are fine, they are switches, for the clients you would put them in – they are great and easy to manage, however again, limited features, for small and medium businesses they are great.
Meraki is a great product for multi site, heavy dispersed retail, massive multi site, however it is quite common to see Meraki Switches and Wireless — but a more enterprise type firewall/router like an ISR.
Hey cantechit – I just wanted to check whether your opinion has changed with Meraki advances / releases over the past 2 years? I’m looking at replacing an ASA 5510 firewall with a pair of MX100s (clustered). I was looking to use the advanced security license to add functionality such as content filtering, anti-malware/virus/phishing protection and IDS/IPS.
Do you know if those issues you highlighted on the MX have been addressed yet?
I’m in your exact boat. I’ve already deployed Meraki wireless and love it for the management and ease of use. However, I just purchased two MX100’s and several MX65’s to replace my old 5510 and 2800’s. I may need to return them. There just isn’t enough flexibility or features to replace the 5510. Small example, no split tunnel vpn. Meraki’s solution is to literally load routes on the client after each connection. Really? I really wanted this to work but I think I may be defeated. Look very carefully at your environment and get some Meraki expert as a consultant to go through it with you before jumping like I did.
Meraki is not for any environment and any good network architect would perform a due diligence before replacing classic enterprise hardware. At least know the new infrastructure before entering any PoCs. They have done a remarkable good job by hiring sellers with no network knowledge to convince the market (CEOs and other inexperienced) that network infrastructure can be designed operated and managed just by clicking 2 buttons. When the truth is it is simple implementations of the most basic standards with bells and whistles on top.
Split tunneling is well documented as a feature, unless you are talking about something else.
I was on a call with a support tech who also confirmed.
Just ran into one Meraki issue. The install instructions do not, as far as I can see, mention not mounting the AP against metal. I was just at a site where there were Meraki AP problems, and when I looked up, they were velcro-mounted to the HVAC ducts. Which might just explain some of the issues: multi-pathing.
What I suspect is missing is “boundary definition”. From the above plus a small university situation. Users need to know when they have a complex RF environment and get professional advice. Site with no drop ceiling, exposed ducts, metal lights, etc. is one. University with many dorm devices and perhaps needing a dense AP deployment is another. This was basically highlighted above: “how do you know when Meraki is or is not right for your site”. Or in some cases, perhaps Meraki with a slosh of professional assistance?
I’ll also note that CiscoLive had some great WLAN talks. But what stood out for me was the massive complexity suggested by “here are the many best practices but YMMV on each of these”, in a very long list.
That’s a great point, but I think that has doesn’t just apply to Meraki. Any customer that doesn’t recognize they have a complex RF environment probably needs to look for professional assistance with the specification, not just the install.
I think for a lot of people, myself generally included, wireless is still this fuzzy technology. I understand how it works for the most part, but I’m not an RF guy. That’s why we have a VAR that can provide those services.
Pingback: Digital Lifestyle
I agree with the sentiment of the post. I actually wish for CLI access to the gear, but I seriously doubt that will ever happen..
The idea of an advanced UI is good, but on the other hand I would hate for it to end up looking like an Aerohive dashboard 🙂 My dream would be allowing CLI access and having some support policies about using it and a method to restore to a previous config. This might give both customers and Meraki support what they want/need. If I do something dumb in the CLI and mess up my config they can tell me nicely that the policy is to use GUI for supported configurations and click this button to restore your gear to the last good config and try again.
I read somewhere Meraki has doubled revenue each year since acquisition and is around 1B per year. that is not chump change even for Cisco and if true I think it is not sustainable to grow liek that without adding features for more complex and enterprise environments.
Bigger question would be needing to be asked how does this new system interact with older hardware, to be honest I suspect this may be only for home networks rather than enterprise. I doubt you will see this used in conjunction with a network size of 500-5,000 computers.. Though i would like to hear your thoughts on its capacity on all features enabled and how it handles 1gb to 100gb back planes within network and Internet access..
I ask this as we are within the stage of having to go 10gb or better for LAN access in the next 3-10 years if we want to look blue ray or better streaming access we’re at the physical limits of what can be achieved on 1gb networks of the last 15-20 years..x
Pingback: Meraki goes iWAN, but retires a marketed feature. | cantechit - Technology and IT BLOG
Good to see the return of the paper clip as an engineering tool ( to reset boxes) , last time i used one was 25 years ago on 3270/serial converter.
Cisco won the router wars in 90’s due to its CLI, the others had GUI , which were rather flaky.
Like Nortel’s Site Mangler!
We’ve had a lot of push back from people due to Meraki’s licensing system. It’s hard for first timers to test out Meraki since without a license it’s main attraction-the cloud managed system- doesn’t function. I like your take on Meraki good points!
I agree… There is more than hardware features that grade a network platform enterprise capable. A few being level of support, troubleshooting (hardware), capacity and performance management which is utterly impossible. Try looking at the oid of the used MIB its really basic. But there might be parts of an enterprise infrastructure that could be served by Meraki products if expectations to reliability is not top priority. In regards to Meraki wireless I would never deploy it in production environments like storage areas hospitals factories trainstations or airports etc. I would without a doubt go for a wireless controller that implement a full l3/l2 mobility architecture 802.11v/k/w MCS rates airtime fairness to mention a few. Its not magic its just Meraki.
Last Thursday evening we upgraded all our Meraki access points to the latest firmware. On Friday morning people started complaining about not being able to connect to the wifi network, error messages whilst connecting, or if they were able to connect, they had no internet access. Around 1/5 of the users (100 out of 500) reported problems. Our helpdesk had a queue of people with problems connecting their devices.
After fruitless troubleshooting and rebooting all switches and access points, I created a case with Meraki support.
It appears that there is a known issue with the latest wireless firmware, but that Meraki went ahead and forced the update on us anyhow.
How can Meraki expect to be taken seriously as an Enterprise company, if they release firmware updates that have known issues? Are they using their customers as a testbed, or are they not testing their updates before sending out?
If you are considering using Meraki in an Enterprise environment, think twice. For the kind of money they charge, I would expect better reliability than this.
Try searching your eventlog for DFS events and you will see your APs constantly changing channels due to false-positives.
Hi Richard, Have you managed to resolve your wireless issue? We have had the same issues since upgrading our access points on the 22nd December and have spent he past 2 weeks taking the same troubleshooting steps hat you have mentioned, we are about to raise a case with Meraki this week but after seeing your post was wondering if you have managed to fix your issues? Where meraki support able to roll back your firmware version or help in resolving your issue at all?
Yes, it was resolved by doing a downgrade to previous firmware. That fixed the problem immediately. Meraki support knew about the issue and have a case open with the development team for fixing it. No information on when an update will be available yet.
Do you mind me asking, why has it taken a month before you opened a case with Meraki? Do you not have support from them? Are you not reliant on your wifi (like we are)?
Had another problem with Meraki this year. Upgraded to latest firmware on December 26, when the users came back in January wifi did not work properly. Tried to roll-back, but because it was more than 2 weeks later it is not allowed to roll-back. Spent 1 month (seriously) on the phone with Meraki support, troubleshooting the issues. After 1 month they eventually agreed to roll-back to previous version (other company had the same issue as us). And problems are solved again. WTF?!?
Has anyone had any experience in building a Meraki Core stack with 4 x MS425-32 switches?
Hi Alex – any luck on this one? I am looking at a similar solution and was wondering if you had proceeded and had any gotchas you’d like to share?
Pingback: Is Patching And Tech Support Bad? A Response | The Networking Nerd
Pingback: Meraki Is Almost An Enterprise Solution | The Networking Nerd