Meraki Limitations when compared to competition?

[drumphile]

Hi Folks,

I'm a long time network engineer, and this is my first post here.  I've worked with Cisco enterprise products most of my career, but have also worked extensively with Fortinet, Palo Alto, Aruba/HP, and Checkpoint devices.  A former colleague of mine recently took a job at a company and is working on a project where he is trying to use another brand via its cloud-management platform to develop a templated, zero-touch provisioning solution which is highly repeatable.  He is really struggling as it seems that the competitive product is very flakey and is very easy to break if certain configuration options/steps aren't followed precisely.   I personally think that his company would be better served using Meraki products, but I'm fairly new to the product and how much it has evolved since Cisco purchased them 10 years ago.  I have had excellent success supporting Meraki for a couple of my clients, but I haven't designed any new solutions with them so I'm not entirely up to date with about what Meraki's limitations are and why someone might choose another solution over Meraki, except for maybe complex large-enterprise environments which require a high amount of customization.   

Interested to hear what any of you has to say about Meraki's limitations/problem areas in 2022....

So, would anyone here care to let me know - what would cause someone to maybe not consider Meraki?  Please be honest. Thanks!

[GIdenJoe · Accepted solution]

Hey,

If you are used to working with Cisco gear you should know that in Meraki you don't have a real peek inside the inner workings of the gear itself.  There are no debug modes, so you can only rely on general logging, your own knowledge and packet captures.

Due to being easy and extremely managable you do miss out on features that are almost taken for granted in Cisco gear.

Usually when there are some kind of complexities or special requirements you really need to research if Meraki is a good fit because it's quite hard trying to shoe horn your wanted features in if they aren't supported.

That said however the biggest positive is the ease of managing your gear from anywhere and the fact that you don't need any extra servers to just monitor your network and clients.  It comes with the license.

My personal peeves:
MX: no support for route based IPsec VPN's, no spanning-tree and port-channel support, no full FTP or other protocols with secondary sessions support. no service objects support (yet), no support for public NAT subnet behind MX (your interfaces need to be in the same subnet as NAT'ed addresses), limited to two WAN interfaces, no ECMP routing on static routes, no switchport monitoring

MS: small TCAM memory space causing limited QoS, ACL, Filter-ID ACL support. no strict priority queue, no ECMP routing on static routes, no SFP DOM monitoring, no modern network support yet (VXLAN-EVPN).

MR: no explicit state machine monitoring for each connection.

[PhilipDAth]

I'm a Cisco reseller.  Maybe 99% of my Cisco Enterprise customers have moved to Meraki or substantially to Meraki.

Powerful reasons are the massive reduction in labour to maintain and operate the network due to massive simplification, and commonly a lower cost to buy the Meraki kit.

[DarrenOC]

Another reseller here.  The large majority of our client base is now Meraki having been legacy enterprise Cisco.

As @PhilipDAth states the Meraki products are easier to deploy and manage.

There are some sticking points with Meraki templates which I believe may be documented.  If not, run a search of this forum and you’ll probably come across them.

[BlakeRichardson]

@drumphile Meraki use to offer free hardware for attending webinars, I am not sure if this is still the case but it would be worth talking to your account manager and finding out.

Having some kit that you can muck around with without affecting end-users is a massive help. 

[Aaron_Wilson]

Meraki templates blow other vendors "1 button config" out of the water. Meraki gives you everything you need, where as other vendors expose the API and expect you to write the automation.

Having said that, the templates are living and breathing. That is good and bad. For this reason I created a base line network which serves as a template when I don't want the living/breathing template. I simple copy that base network for new networks which are non-template based, adjust the subnets, and be on my merry way.

Another issue is you can't have templates by device type in a network. I'd love to have a network where I can do the MX or MS manually, but then the wireless in the network is bound to a template.

Like the others mentioned, many love Meraki for the simplicity. It has allowed me to ship gear without ever putting a pre-config on it or going through some convoluted provisioning process. But like they also said, if you need some super advanced feature, insight, or nerd knobs, that is when it starts to fall apart. I find the UI in the dashboard and the warnings to offset some of the things you would miss from a device with CLI.

Oh, and only 2 possible WAN ports is another annoying thing.

[Ryan_Miles]

On the template front you have some options. For switches if they're not bound to a switch profile they don't pick up anything from the template.

I have several customers that require what you mentioned with MX & MS not template bound and MR networks template bound. In these cases they don't use combined networks. This way they can just bind all the network X-wireless networks to the template and leave the network X-appliance & network X-switch networks unbound. I realize this isn't as nice as having a combined network with parts of it bound and other unbound, but it works.

Good suggestion about the baseline or golden template idea. Whether it's a template or network you clone from I often see folks use these methods.

As for 2 WANs. Hopefully one day that'll no longer be a limitation.