Adventures in Meraki land

Started by Nerm, March 29, 2018, 02:54:13 PM

Previous topic - Next topic

Nerm

Bear with me as this is going to be a long post. It has been a little over two years now since I was put in a situation where I had to get up close and personal with the entire Meraki product platform. What I mean by "put in a situation" is the company I work for had decided to abandon their existing traditional Cisco infrastructure and go all Meraki before I was hired. Once I was hired I was handed the Meraki keys and told to make it work. This post is a few of the things I have learned along the way in hopes that someone else might find this entertaining or even useful.

A little background for understanding my perspective: My title is Sr. Network Administrator but my role is more Global Network Architect in reality. I work for a medium sized enterprise that employs 10,000+ globally. We have an interesting mix of location types. We support small sales office and retail locations with less than 20 users and also large campus locations with thousands of users. The majority of our locations however are large manufacturing and warehousing facilities where wireless can be a challenge at times. We have 5 main data centers (3 in the US, 1 in Europe, and 1 in China).

Meraki Cloud Platform

The Meraki cloud platform itself is actually quite stable. The dashboard is easy to navigate and understand which is great when your day-to-day network admins are of the more junior variety. Most of my problems start with the fact that Meraki knows and anticipates this reality. They know who their customers are and expect the majority of their users to not be experienced network engineers. Advanced features and outside the norm configurations are not readily available. No BGP or PBR for example.
One thing I really like about the Meraki cloud platform is the "single pane of glass" for management when you have lots of locations. The firmware updating process couldn't be any easier IMO.

Meraki Security Appliances

Good:
Analytics, client tracking, content filtering/etc, and HA functionality on the MX series of products is pretty good.

Bad:
Static routing is your only option on Meraki firewalls. Actually routing in general (outside of default routes) is one of the biggest weaknesses of the entire Meraki product family.

Ugly:
VPN, VPN, VPN!!! Unless you are doing Meraki-to-Meraki their VPN solution is absolutely painful. The slogan for this product line should be "does not play well with others". Also if you need a client VPN solution stay very far away IMO.

Meraki Switches

The Meraki switch product lines are good for the access layer, however trying to use them any higher has proven to be difficult in a large enterprise environment. Given more time to mature they will get better in the distribution layer. IMO however the Meraki switches at this time have no business in the enterprise core or data center space. My biggest issue here is the cost. Meraki isn't necessarily cheap to use at the access layer, but if your everyday network admins are not experienced it is much easier for them to manage the network stack. Things like switch stacking, port aggregations, and large port density management are pretty good.

Meraki AP's

If there is one place where the Meraki platform has not only been acceptable but has even impressed is in the wireless spectrum. The AP's themselves are high quality/performance and durable. Most of my supported environments are manufacturing/warehousing and they have held up to the harsh conditions quite well. Just about all of the features you would expect from an enterprise class wireless product is available to you. One cool thing is the AP's can mesh backhaul through each other in the event of an uplink failure to the AP. Roaming handoff is also excellent compared to other products I have worked with.

One place we have experienced issues is legacy RF support. For example, if you still have to support some ancient legacy RF warehousing equipment that only supports 802.11b and WEP you might run into some challenges.

Summary

In summary here are some use cases where I think Meraki is a good or even ideal solution and some use cases where I would consider other solutions.

Ideal Use Case:
-Small/Medium business with minimal IT workforce resources.
-Managed Service Providers. This platform was clearly designed with the MSP that supports small/medium sized businesses in mind.
-Environments that have lots of smaller locations to manage like in the retail or food industry.
-Remote locations where there is little to know onsite IT presence.
-Just about any scale wireless deployment.

Good Use Case:
-Medium/Large enterprise switching at the access layer only or maybe at the distribution layer also if you are a 100% OSPF shop.
-Environments where the network team is not highly experienced and could benefit from some hand holding.

Bad Use Case:
-Unless your environment is small enough that you only do static routing and do not have an onPrem data center then I recommend staying away from Meraki at the core layer.
-Speaking of the data center just don't put Meraki in a data center environment.
-VPN anything! Probably the only situation I would recommend Meraki VPN is if you are a 100% Meraki shop.
-China! The Meraki dashboard just doesn't work well from within China.

Summary 2:

In the end the people responsible for the decision to abandon traditional Cisco and go 100% Meraki are no longer with the company and I am now tasked with an initiative to go back to more enterprise traditional product solutions and back out some of the Meraki decisions where they just don't fit.

wintermute000

#1
EXCELLENT post, thanks for putting your learnings out there
Care to elaborate more on the failings/missing bits aside from the lack of anything but static routing on the branch FW CPEs?

Also re: IPSEC VPN, is it just plain unreliable when connecting to any other vendor, do you have more specifics?

Have they tried to flog their 'SD-WAN' flavour yet?


Aside from routing and VPNs, what other requirements are driving you towards a more 'traditional' enterprise stack?


You might want to check out Juniper Sky Enterprise - Meraki like cloud based mgmt of good old traditional fully featured Juniper routers/switches/firewalls etc. - not sure if you're partial to JNPR but switching vendors is not out of scope, worth a look (as its definitely a full fat enterprise product stack). Have your MPLS/MP-BGP/VRFs etc. but also let your juniors change port VLANs by clicking a GUI, and no magic Meraki control plane (i.e. under the hood its as simple or complex as any traditional enterprise deployment can be using all our standard familiar protocols)

https://www.juniper.net/us/en/products-services/network-management/sky-enterprise/



Nerm

#2
Actually I am glad you mentioned SD-WAN because I missed that in my use cases. I would actually call it a good use case for SD-WAN but only if you are going all Meraki. Their SD-WAN functionality really needs 100% Meraki at the edge of all your locations to be realized. The VPN for example is very difficult to even establish tunnels with non-Meraki devices and just unreliable even if a tunnel is established successfully. The documentation says their MX's support PBR and it "technically" does but it is a very weak feature compared to other vendor routers/firewalls I have worked with. The reality is it just isn't mature enough for us yet. I think it will get there and if I were working for a different employer or even in a different industry my opinion at least of their firewall platform could be vastly different.

Aside from the VPN and routing limitations of the MX series the big thing across the entire Meraki stack is control. As I mentioned before this platform isn't intended for the experienced engineer. If like my work situation you need to support a lot of legacy, complex, and even strange configurations you can't dive into a CLI and get some of the nitty gritty information and setup some outside the box configurations. As an example of the "control" issue we had a need to have a specific SSID be 2.4Ghz only. We were not able to configure this ourselves and actually had to contact Meraki support to get the change made for us. We had a similar scenario to get some specific PBR functionality working the way we wanted.

We aren't ripping out Meraki left and right and going away from their platform entirely. What we are doing is realizing Meraki just will not work for us in some locations/situations and the problem as mentioned before if you aren't 100% Meraki you can't realize the platforms full features and capabilities as you would like. We are staying Meraki for all our smaller sales offices. For our warehouse/manufacturing locations we are staying or going back to Cisco at the core, and for access/distribution we could stay Meraki but due to cost we are evaluating other options. We only started Meraki in one data center and about faced pretty quickly so they never really got ingrained there.

If I were to move to the retail or similar industry with lots of small branch sites to manage I would not hesitate to use Meraki throughout.

EDIT: Another pain point I forgot to mention is that for the MX firewalls your internet hand-offs must be copper. The SFP slots cannot be used as "WAN" ports. In fact no ports can be used as "WAN" ports unless designated as WAN only and this cannot be changed from the default. If you need a different copper/SFP port to be your "WAN" link you're SOL same goes for if you need more than 2 "WAN" links.

deanwebb

I was reading and wondering about the throughput of the MX firewall, thanks for getting to that!

I know that Meraki is making inroads into many large companies and that ForeScout is looking at improving its integration with Meraki. We can work with the cloud management via 802.1X.
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.