Switching from traditional Cisco to Meraki?

[amarquez2]

Has anyone made the move from being a traditional Cisco environment to Meraki? I'm just curious as to if anyone's done that here. 

[NolanHerring]

I'm sure some have. I have migrated some small sites before myself. Do you have any specific questions regarding if someone has done so?

[amarquez2]

I'm mostly curious as to if switching to Meraki helped save money or costs more to maintain.

[NolanHerring]

Well, I can say that pricing is what it is. It is either cheaper or more expensive. Meraki however is usually less expensive, even in the long run with the license model they have.

Depends on the environment and what your aiming to do with it. Is it complicated or simple? There are many features with cisco gear that Meraki might not have, vice versa. It makes it simpler for sure in my opinion. Cisco requires you to really know how to configure gear, CCNA skills or above. They also allow you to do much more complicated and more 'enterprise' designs etc.

I have cisco switches with a show run-time over 4 years. A Meraki switch usually will last about 9 months before I'm forced to do a firmware upgrade. Not saying that is good or bad.

[HitoshiH]

If I would add some advantages of migration to Meraki MS switch,

You would get the following advantages to reduce management / installation cost:

• Reducing operational cost by using virtual stacking technology to update switch port configuration for all of target switches at once (You do not need to connect your console cable or SSH connection to individual switch to make any change anymore / You can update thousands of switch ports beyond each physical switches)
• Remote Layer 1 troubleshooting (Cable test) and packet capture via dashboard which reduce cost for onsite troubleshooting
• Live topology view of Layer 2 and Layer 3 for your powerful remote management which helps centralising your network management from remote location
• Zero touch installation / replacement in DHCP environment in case of unit gets fault (Reducing cost for dispatching local technician for installation and replacement)
• Protecting network from rogue DHCP server which would reduce need of troubleshooting
• Upgrading firmware (OS) can be done and scheduled via dashboard for entire network without preparing firmware on local FTP server and executing command per switch

[Stealth_Network]

I have both hybrid environments (both) and full swap out.

As stated costs are only one factor. From the technical side you need to fully understand what you need as Meraki does have limitations over traditional Cisco gear. Sometimes you don't come across them until after the fact 😉

It really depends on what features you need.

[DarrenOC]

We’re continually doing this for our customers.  WLCs being swapped out for Meraki MR’s, no issues there.  Just be careful when replacing the legacy switches if you find yourself with a combined network of both. Run a search for Meraki and Cisco switches and spanning-tree.

[PhilipDAth]

I would guestimate around 90% of our customers have migrated from Cisco Enterprise to substantially Cisco Meraki.

[BlakeRichardson]

CIsco make both enterprise and small business hardware. I think most users would be able to migrate successfully, those that require features that Meraki don't support then obviously not. 

In reality most users networks are pretty straight forward. 

[amarquez2]

I feel our network is really simple as most of it is L2. I'm guessing we could keep our core as traditional Cisco and move our distribution switches and APs to Meraki I just wonder if the Meraki switches will work with our Cisco VoIP phones.

[DarrenOC]

Your Cisco phones will continue to work so don’t worry there.  We have Meraki edge switches in and working fine with Cisco, Yealink, Polycom etc 

[amarquez2]

That's great to hear! I really like how easy it is to get an AP set up compared to Cisco. I see a lot of potential with Meraki in our environment.

[Network-dad]

I'm in the middle of a long migration from my Cisco ASA's and Catalyst Switchgear and it's going very well! One really cool thing I just found out today in the ECMS2 (Engerning Cisco Meraki Solutions) class today. There is a script to import ASA configs to your MX. Really helps to streamline the process.

Meraki MX Converter - Import ASA config files and automatically adapt rules to the target MX. This script will parse through an existing ASA config and generate Meraki MX compatible FW rules. The script supports objects(network/service). It'll build iterative or multi-source/multi-destination L3 based rules. It'll then configure the target MX network with the ruleset mapping to the new interfaces."
https://github.com/wifiguru10/Meraki_MX_Converter

[PhilipDAth]

OMG that is an excellent script @Network-dad .

[Roger_Beurskens]

We've got several customers switched to Meraki from conventional Cisco.

One thing to keep in mind is iscsi storage traffic over meraki switches.

I would strongly advise not to use meraki for them but use catalyst or even nexus.

Besides buffering and latancies the problem is with updating the networks, you jst must sometime.

This wil result in a maintenance window (yes even though your network design is good, you dont want to take any risks)

Luckily this became a bit better with the staged updates.

In a conventional setup, those switches don't even have internet connection and are managed oob.

Just can't do that with meraki.

[PhilipDAth]

>One thing to keep in mind is iscsi storage traffic over meraki switches.

With storage you really should be using two switches, and one of those switches should not be in a stack with the primary switch (often you just put it on its own).  The non-stacked switch goes to the secondary ports of everything using the storage.  Put the second switch in a seperate Meraki network with a different maintenance window so it never reboots at the same time as the main switch(es).

Ideally the storage system will support using different subnets for the primary and second NICs.  So in a perfect work you have a VLAN on the primary switch and another different VLAN on the secondary switch, and these VLANs do not leave their respective switches.  Each of those VLANs has a unique subnet used for the storage primary and secondary NICs (as well as associated servers).

And you use MPIO to pull everything together.

This concept applies weather you are using FibreChannel or IP storage, and irrespective of all vendors.

[Roger_Beurskens]

You're completely right. it's a little different mindset.
but making 2 networks just for a storage network sound just dull 😉

problems do arise when you have a predecessor who had the great idea of getting 3 ms350's in a stack, using them as collapsed core, connecting servers and running storage over it.
Just because the pre-sales guy at the time did think running on 3 instead off 5 switches was a lot cheaper.
He had no idea of a descent network design 😉

We've learned from that and now are using nexus 3k's for storage networks.

I just wanted to point out, you not only have to think about network design, but also the setup in the meraki portal like you said.

[KRobert]

From a hardware perspective, the cost isn't probably too off from traditional. What you will save in costs are time and user training management. Traditional uses CLI and you should definitely have some idea of how to navigate CLI when configuring traditional managed switches. We are slowly replacing all of our Access switches with Meraki equipment.

a couple negatives of Meraki equipment compared to traditional is the need for the dashboard to make any substantial changes and it is a subscription base model. The Meraki equipment needs internet access and if your license expires and after multiple grace periods and warnings, Meraki can shutdown your network. Wit h traditional equipment, apart from necessary IOS updates, the equipment can just keep running with or without internet access or support.