Meraki SD-WAN Reviews

Our primary use is providing services to clients. I work as a regional team lead for network operations. Part of the responsibilities include looking out for evolving technologies and leverage cost benefits while improving services. Because I overlook 1,600 sites within the organizations spread across 52 countries, we can use that buying power to influence pricing.  

When we started using Meraki in 2016, we were just experimenting. By virtue of the results that we got based on using Meraki — the flexibility coupled with the simplicity at the same time realizing that we would experience significant cost optimization — that made Meraki our option A. In our initial estimation, we were able to reduce about 30% of our recurring costs on one site. Since we decided to go with it, we just rolled out 230 sites to the platform and we have many more sites that are coming on to the platform over the next year.  

In fact, next year we are targeting about 1,000 sites to be on the platform. We started with just three sites as a test in 2016 and today that has grown to 230. It keeps growing because more countries have heard about the cost optimization and they are indicating their interest having heard the result. For instance, Switzerland has been the latest country we converted. We have 65 sites in Switzerland. We started the project in June and we have been able to move 59 of the 65 sites to Meraki as of today. At the end of this month, the entire migration for the whole of Switzerland will be complete. That is 65 sites in just 4 months.  

Our journey in moving to Meraki is in progress but we expect to experience a huge benefit in the bottom line of operational costs.  

Honestly, even just converting the few sites we have migrated so far from the original way we configured them, we have realized a 20% to 30% difference in recurring costs compared to when we were fully on MPLS (Multi-Protocol Label Switching). By the time we move the bulk of our site, the projection is that we might actually be realizing closer to 40% or 50% reduction in operations costs. In this COVID era economy, everyone is looking for cost optimization. That, for us, will be a significant one.  

One of the other good things I see is that Meraki can react fast to emerging trends. For example, we have a VPN. We are looking at most people's workday actually becoming stay-at-home. In two years, maybe the approach of staffing will become increasingly more virtual. That would change a lot of things in the way even use people. With Meraki, we have the availability to support work-from-home in a way that we could not with MPLS.  

One thing I would say that could be improved is the VPN client. I noticed that when we use a VPN client we have access to the network where the VPN is hosted. I would like to see the possibility of having the VPN access able to connect to more than one network and to more easily make secure connections from one site to another. If Meraki can work on that, it would be a very good enhancement.  

Another thing that I would like to see Meraki make better use of is virtual connect. Today we have only the virtual MX100. Earlier in the year, because of our joining with the cloud, we had to integrate AWS into Meraki. The limitation has not been so bad to this point. The questions I have arise because our journey to the cloud is not going to end. It is something we are increasing and we have made plans in our roadmap to move more of our applications to the cloud. That means that we have more sites accessing applications via the cloud and it will stress those capabilities. We need to have solutions in place before issues arise.  

If we do not use direct connect, the only other option is to go the Meraki way using BGP (Border Gateway Protocol). There is a limitation in terms of the number of concurrent connections. That would prove to be a challenge if we are only relying on the MX100. There are possibilities that we can exploit using dual MX100s, but the question is still that we have not tested it to know how that really works. We do not know if the simplicity and the optimization that we already have achieved with the physical devices would be maintained. Those are questions we can not really answer right now. But I think it is something that is worth looking into and something we will eventually have to resolve.  

Another thing I also want to mention is the idea of using a warm spare or hot standby for high-availability and failover. It is a good idea to have a warm spare, but I also notice that it may be possible to do something using different switching. We have stacking technology where you can use a stack or you can do virtual switching on the 9500. I am thinking if we have something similar to that applied to create high availability for Meraki, that will go a long way to help solve the potential issue. In the case of the warm spare, If I boot the warm spare this means we have one concentrator that handles the downstream in this case, but then the up-stream is different. There are always issues around that downstream flow because you are going through one single link. But if the two can be virtually connected — just like they are in StackWise Virtual —  then I think it makes the traffic flow easier and it will be handled better.  

It is like ZRP (Zone Routing Protocol). ZRP has some issues too because it introduces another layer of complexity in the fact that you have to be sensing the heartbeats between the two different Meraki devices via another switch. In my opinion that makes it a bit unstable. If we can have something more like the StackWise Virtual approach to add availability on the physical Meraki device, that is the way to go in my opinion. It is a good thing that you can share a single license over the two devices, so it is walking in the right direction in that regard.  

One other feature that probably can be added might be on the Meraki switches. We have Meraki switches working with the MX100. I know that the access key on MX switches is more-or-less like other switches, but it is not as flexible as what we had when we are using the local traditional packet switches.  

Then there is also, the handling of the spanning tree. With some configuration, the traditional switches can be made to handle some things that I have not seen the Meraki switches capable of handling. So they might also want to introduce EtherChannel on Meraki switches to improve those capabilities. But these are a lot of things that are somewhat peripheral to the SD-WAN itself.  

On SD-WAN specifically, I can see that we have a default class for voice. I think that maybe that can be expanded to take care of more classes. I know the service class is defined, but if it can be expanded, then we can be more confident in providing voice services. One of the concerns has always been the performance of the voice services we can provide. From the experience I have in testing so far, if you have a good link, there may not really be a cause for concern in delivery. At the end of the day, the voice traffic is not impacted because of that good link. A major concern in our case now has been when we have a local voice solution that only sites within the country access. Providing reliable service might be an issue because of the latency.  

Voice services depend on UDP (User Datagram Protocol). If voice services depend on UDP and then traffic goes beyond the threshold, packages can drop beyond a particular latency and the services are not able to retransmit. So the package drops. What I am looking for is adding some additional classes of services that can help with this issue of dropping packets. I think that is one other thing that Meraki can be looking into.  

There have been issues around NAT-Unfriendly (Network Address Translation) situations. I know there is a technical explanation for that. In some cases, it is a little bit sad that you have to use manual NAT instead of using automatic channels. The manual process has its own cons as well. Even though it is easy, there may be something that can be done to work with automatic channeling. For instance, today there are quite a number of sites that are on 4G and are working perfectly well with Meraki. When we have sites in countries that have 4G that want to move to Meraki we have to tell them to find out from their provider to make sure that they are not using APM (Application Performance Management). If they are, it will always generate NAT-Unfriendly behaviors. Meraki solutions should work to resolve this issue for those who have to use G4.  

I have been using Meraki SD-WAN for four years now, starting in 2016.  

It is very stable based on our experience and the application performance has been superb. It is much better compared to what we had before when we were using MPLS. The fact is that this solution introduces quite a lot of flexibility and that it is SSO (Single Sign-On) adaptable is helpful. At the same time, we have good scalability. Those are major benefits for us.  

We have a complicated application landscape where we have quite a number of applications that are either hosted locally, hosted regionally, or also hosted in the cloud. Navigating this landscape while on MPLS was quite challenging. With the SD-WAN it is quite simple. The integration has been quite flexible as well. One of the good things that we have seen about this solution is that SD-WAN is able to talk to sites on MPLS and vice versa. That has really helped in terms of migration. It has really been a wonderful story all along the way.  

The organization I work for is in about 90 countries and then of course we have plants that are very big in some cases. We have about 1000 users in one location. In some cases, we have around 500 users. In some countries, we have only four or five plants; in some other countries, there are eighty plants all with varying numbers of users. The Meraki product can be scaled to fit all these needs.  

At one of the biggest plants we had to deploy, we had to use an MX100 in that location. That is because we were going to make it a hub as well. Being a hub, all the locations within that country were also going to be connecting to it. In our deployment approach, we have to consider whether they have local traffic and locally-used data application services. When that is the case we set up a local hub in the country to reduce latency. This is so that applications that are susceptible to latency are able to perform optimally. Then we have applications where we have specifications that require hosting them at the global business center at the central concentrated hub which is in Paris. We have to have a flexible solution to meet all of these needs.  

A good thing with Meraki is that it uses Auto VPN technology. It is not a case where the connection is moving from hub to hub, it a case of having a kind of a cloud where each hub participates and can push traffic dynamically. What I see in Auto VPN is like a Layer 3 MPLS. The difference is that MPLS uses switches where the Auto VPN simply has a concentrated hub. We can let the VPN registry handle that connection centrally. It can be an advantage when you do not have to change connections from one hub to the other. In some cases, we use the MX-67 in plants depending on what needs they have for availability and capacity needs.  

Optel was recently still using an MX100 as a central concentrated hub. When we looked at trying to be proactive and doing capacity planning, we decided to add capacity in anticipation of additional sites that will be added. To increase the capacity of the device at the central hub we just bought an MX450 that we are going to use to replace the MX100. We also upgraded our link. Initially, the uplink was 100 megs. Now we have moved to one gig just in anticipation of other sites that will be added. That type of capacity scaling is fairly easy.   

I have a team that has about nine engineers covering about two countries. With them, we try to do as much automation as possible because the size of the group is really too small to service the number of sites that they are responsible for. However, we have been able to manage quite a lot of automation because we have Meraki to help manage that.  

The same site is also responsible for voice services and they are responsible for the LAN, in each of those locations. We are also responsible for the WAN services which are used exclusively for the firewall and the security services.  

There and some other technologies like joining the cloud and moving some things to AWS. That is one of the things we try to do to leverage our automation. For instance, on Meraki, upgrades have to be applied from time to time. Up to now, we have tried to work that on a particular schedule. But even in scheduling, you discover that the time updates need to occur varies because not all locations are within the same time zone.  

What we have tried to do is work with some API scripting using Assertible and Postman to look at how to automate some processes like applying those software updates automatically. We also notice that from time-to-time when new projects come in there is a need for us to update the firewall rules on each of the Meraki devices. This is really a very tedious manual process. To resolve this we now put a new kind of scripting in place so that we can just specify the rules that we want to create and that can be applied across all the devices on the dashboard. This scales the capabilities of what Meraki can carry out.  

I noticed that recently there was a new feature that was added called Network Object. I have ideas about what I think it should be able to do, but I have not explored it yet. It is still something that will be tested out and I will see. But new features are also coming out all the time that scale the way we are able to use the product.  

We do contact technical support a lot. One of the things we make a habit of doing is to contact Meraki support when we have any doubt about the steps we need to take. For instance, in the beginning, when we started out with a COL (Combined Licensing) licensing model, we might have situations where some operations would feel cheated if they licensed a device with a five-year license contract. They might check the dashboard and they would realize that they only had four years and maybe two months. Of course, questions arose when they paid for five years and saw they only got four years two months.  

That was a really tough one because we noticed that even after we migrated there were a lot of issues in terms of some device licensing. We had to work with the support team a lot to be able to have that resolved. When those licenses were finally recovered we had to go on our own, one by one, to match the reconciled license with devices so we can a reconciliation across the board.  

We have used support when we were trying to do upgrades and we ran into some challenges. I recall there was a case in Qatar where all the sites went down because someone mistakenly changed something about the licensing. Everything just went off straight-away. We raised a case to support and it was over the weekend. They just picked up the phone and someone at Meraki picked it up and worked throughout the whole of that Saturday. By evening all the sites were back. It was good because Sunday is a working day in Qatar. The issue resolved on Saturday and by Sunday morning everyone was able to get to work and they were happy. Tech support is willing to go the extra mile to resolve issues.  

The difficulty level of the initial setup actually depends on the site. In most cases, the level of difficulty is not really an issue with Meraki. The issue is the local LAN where you are trying to integrate Meraki. For instance, there are some cases where we had to do some LAN cleanup before Meraki could be integrated. But when the LAN is in good, clean condition with a proper hierarchical work structure, within a matter of a maximum of 45 minutes or an hour, we are done. If the LAN is not structured, we can be on it for days.  

One time, we had to do a migration in Cameroon that was very difficult. We had to go back several times until we realized that their LAN was really in a bad shape and it was causing other issues that we did not anticipate. We agreed the best thing we could do was to revamp the LAN before we tried the migration again. It was not only a case of having to redesign the LAN. There were many VLANs that were also not configured properly. The whole site installation was just a kind of lopsided. We had to spend quite a bit of time to do a proper cleanup and create a proper hierarchical structure for the LAN before we could even attempt to integrate Meraki. Eventually, we were able to successfully integrate. Without these kinds of issues and where the LAN is well structured, within forty-five minutes we are out of the place.  

I can say that the pricing is fair, but if they can make it less it would be even more attractive.  

I think Meraki is also doing something good with their pricing in the sense that any license you buy until January 2021 gets you an extra year for that purchase. So if you buy a five-year license now, you actually get six years. The customers always want more when it comes to savings and Meraki is recognizing that.  

When looking at this type of solution, there are several things to consider that are useful to know before you begin your research.  

One: you have to have an understanding of the existing network. That is crucial. If you do not understand the existing structure of the network, it will be difficult to be able to adapt it. If you are planning to move into an SD-WAN, you want to look at replicating the existing network structure. So, the first thing is how flexible the solution is in being able to adapt to your existing architecture.  

Secondly: you have to look at how simple it is going to be to manage. The GUI interface of the product that you choose should be well-designed so that it makes the product easy-to-use.   

Third: you will want to look at and be aware of the redundancy features that are available. If you are considering switching to an SD-WAN, one of the key things you need to look and have a solution for is what will happen in the event of a failure. You need to know how the system will handle it.  

Fourth: you have to know the physical devices that will be in those locations converting to SD-WAN and how resilient they are. The type of routing protocols that are supported is very important. If the kind of routing protocol is not properly supported or if they are proprietary then it becomes a big issue.  

Fifth: you also want to consider the manufacturing company and its product support. The support has to be very solid. If the support is not solid, then you might run into quite a number of issues. The more you engage the support, the better because they can grow their knowledge base and you can learn. Of course, a good thing about Meraki is that the support is solid. I can say that because we have had quite a number of issues and support has been able to rise up to the occasion each time. Also part of support is the documentation for use. This is also key because there will be instances that you have to go and look into the documentation to check on how to do things properly. You want to have a good resource where you can read up on some stuff and then be able to apply what you read so that it is not always necessary to look to support for help.  

Any time of the day, I will recommend this product. It is quite flexible. We have been able to put it to the test because we have a very complex network environment considering the number of sites. I mentioned I have 1,600 sites and globally we have 3,625 sites. Some applications are hosted centrally in the global data center and there are also layers upon layers of applications that are used in different countries based on the different business requirements and environments. Meraki has helped us to handle this efficiently.  

With Meraki, we have been able to simplify so many of those situations. For example, we have some locally hosted applications in some of the countries that require an IPSec (Internet Protocol Security) VPN tunnel for access. Without Meraki, it requires some third-party access or interaction with the locally hosted application. With Meraki, we can get away from this issue.  

Before using SD-WAN, we had to have too many hubs. This was the case whether the location was the global data center or a regional one. At some point, we ran out of public address space. With Meraki coming in, we have been able to sort that out. This is because we can do many-to-one mapping even if we have several applications hosted there. So with a many-to-one map, you can have as many services as you need of that one application on the same platform. The only distinguishing part will be the port you are communicating with and the remote IP.  

Using Meraki just solves a lot of problems. There was one problem we were having that we had to send to our solutions team. There was a lot of back and forth on details. Then while we were waiting someone on our team suggested that we could just use Meraki for resolving the issue. There is a Layer 7 feature that was able to help create the solution. So we used that and it was resolved. The solutions team came back again asking about the status of the issue and we just said that we had moved on because the problem was resolved. They were curious as to how we resolved the issue. We told them that we just used Meraki. They wanted to be sure that it was secure. Because of the way we implemented it, it was very secure.  

If I am going to look at the biggest lesson I have learned from using Meraki SD-WAN it is that you have to have an open mind as to what the product can achieve. Always believe in possibilities. Today, it is like a mantra that is being used across the organization.

I recall when we started four years ago, no one was actually interested in what we were doing with Meraki. Then we encountered an issue that we needed to look into finding a solution for. The issue was that we did not want to start increasing bandwidth because increasing bandwidth on MPLS is crazy. You have to pay through the nose. We knew that there was going to be more demand from business operations because at that time we were planning to deploy SAP (Systems Applications and Products in Data Processing). There were also some demands from business operations that even the technical team at SAP said were not possible to achieve.  

I recall a meeting with my manager who told me that he brought me on to the team to look for and find a solution to the issue. He told me that even SAP said it was not possible to resolve. It appeared that it was a dead-end, but it was not really a dead end. It was an opportunity to bring on something new as a solution. People on the team were not sure whether we were going to be able to make it work. But somebody had to sit with it and try solutions to figure out a way to make it work.  

The first six months were not a lot of fun. We were trying quite a number of different things and nothing was resolving the issue. But gradually we were gaining a better understanding of the technology and how it works. We learned more about what we could do to make potential solutions fit better with the existing structure that we had.  

That type of exploration is key to understanding the way the platform works and how you can apply solutions to your existing environment. I tell people now that it is not just about deploying a network. It is about understanding the technology you are trying to introduce so you can see how it can add value to the existing environment. That way, as we invest in potential solutions we are not wasting any money. We are actually getting value for any investment in technology and platforms because they may provide a solution or a unique capability now or in the future.  

For me, finding a solution is about having an open mind. You have to say to yourself that nothing is impossible. Of course, there is the tenacity that you have to have in trying to create the solutions. If that is not there, the effort at resolving an issue is just smoke. It may take some weeks to create some solutions. But the good is that you find it is possible to learn new ways to solve problems. When you get that solution, you have learned something. If your effort brings about a solution or not, you have learned. When it brings about a solution, you are just glad that you could resolve the issue. Then you move on to the next problem.  

On a scale from one to ten (where one is the worst and ten is the best), I would rate Meraki SD-WAN so far as an eight-out-of-ten. I say that I rate it as an eight because there is room for improvement. There will be a time in the future where Meraki will have to face emerging technologies and find solutions to integrating with that technology. They may also have to find solutions to things that come up and meeting new needs that arise.  

Before now Meraki had OSPF (Open Shortest Path First). Today we have BGP. When BGP was first introduced to me, I tried it out and it obviously had some instability. Because of that, we have not ended up deploying the use of it widely. But a problem came up in a meeting after I was first working with it and I said "BGP is back." I was joking, but also thought there might be a possibility it could resolve the issue. One of my senior colleagues said that we were not ready to go back to trying to work with that yet. I was joking but it is always good to have an open mind to ways you might resolve an issue. Some day in the future a tool that did not work for one thing might work for another.  

So I would rate Meraki SD-WAN as an eight because there is still room for feature development and facing the future of emerging trends. Technology solutions are coming that will have to be integrated and addressed.  

I'm able to access various ports for simple switches and then check things, like the information that I've gotten. We use the solution on a day-to-day basis. 

I like the part with the accessibility to the switches, the access point, and the firewalls. Having to set up a closed system singlehandedly and a lifetime guarantee on the equipment is a valuable part of this solution.

The area I think this solution should improve is the pricing.

I have been using this solution for about five years.

My impression is that this solution is quite scalable. There are around 800 users of this solution in our company right now.

My impression is that it was quite easy to set up this solution. Our model of deployment is hybrid.

When we were first looking to implement this solution, we were looking at pre-systems as we handle this one. Even though it was the priciest one, the day-to-day basis and the security were the best.

It was all done through a two-person team. Another member who wasn't on-site is an administrator and I was someone who is on-site. For example, the administrator sets up a new server from scratch and I take over from there, so we worked in collaboration all the time. I am also the person responsible for maintaining this solution.

I would rate the pricing of this solution a seven, on a scale from one to 10, with one being the worst and 10 being the best.

When it comes to giving advice to other people looking into this solution, I'd just say that this system is easy to maintain and quite secure with good quality equipment.

I would rate this solution as a whole a nine, on a scale from one to 10, with one being the worst and 10 being the best.

We mainly use Meraki SD-WAN for connecting sites.

The most valuable feature of Meraki SD-WAN is the Auto VPN.

Meraki SD-WAN could improve by adding wireless access time-scheduled and overall capabilities.

I have been using Meraki SD-WAN for approximately six years.

The price of Meraki SD-WAN could improve, it is expensive when compared to other solutions on the market, such as Aruba.

We have approximately 50 customers using this solution.

The solution has the ability to jump from one ISP to another with minimum downtime.

The speed at which we can change from one provider to another has been great.  

The added security has been useful. However, we are barely using all the capabilities of SD-WAN.

It's easy to set up. 

The solution is stable.

The scalability has been good.

The feature that we are interested in is working perfectly. It's a matter of cost and expenses that we may take some issue with.

We've used the solution for a while.

As far as we can tell, the stability's great. The speed is great. We didn't experiment with it that much to have the opportunity to really see any faults. We've just come in and tried to catch up with everything that was going on.

The solution can scale well. 

We plan to increase it as much as can once we feel comfortable with the features of the product.

We did not previously use a different product. We tried Meraki first.

It is very straightforward to set up. We have two firewalls connected to the device. We're using Meraki since we're a Meraki user, and it makes sense to start with what we have. Basically, we take it from there. We have all our sites on Meraki, so it's the basic starting point.

The licensing is very expensive. 

The fact that it does not recognize our cost from the previous licenses is a big drawback. The price covers the licensing and the box itself. 

We are looking at other options right now. 

We deal with a reseller. We have 58 different networks. However, none of them has a particular server. We're using it to interconnect. We're using it all over the state. 

I'd advise potential new users to understand the costs that are likely involved first. 

I would rate the solution nine out of ten.

Meraki SD-WAN is a very good product as you get a backup for all the VPN and internet connections. You connect Meraki's cable, and you can have a secure port to deploy Meraki SD-WAN solution in the cloud, which is a very easy process to deploy. You can apply or make appliances for the other branches that you have, so it is easy to deploy Meraki in your network ecosystem.

Meraki can improve if it gets built in a way that provides network assistance. If Meraki obtains the technology to provide network assistance, then it can implement it manually in Meraki SD-WAN. With built-in network assistance, the tool will be one of the best tools in the market because its competitors are working on such a solution. I think if Meraki offers network assistance, it can improve in a much better manner.

I have experience using Meraki SD-WAN.

The technical support for the solution is very good. I rate the technical support a nine out of ten.

Positive

The difference between Fortinet and Meraki is in the area of pricing. FortiGate is cheaper than Meraki. FortiGate is a solution that is very similar to Meraki. Fortinet works on security, so it offers a few more features than Cisco Meraki. For example, Cisco Meraki has only two ports for doing the failover. FotiGate is available at a cheap price and has many ports to manage failover. Meraki only has two ports.

The product's initial setup phase is very easy.

One person can deploy the solution. People involved in the deployment of the product have CCNA certification.

The tool is plug-and-play in nature, so one who takes care of the product needs to have a basic knowledge of networking. Only those who have the basic knowledge can configure it and make policies in the Cisco Meraki platform.

The customer sees savings in the VPN area. If the customer has a VPN, they keep it along with the internet connection. The customers have Meraki SD-WAN, so they save by keeping the carrier's VPN solution. The VPN tool is more expensive than an internet connection.

The licensing is very easy to connect to the equipment. The tool offers term licenses. You have the same term licensing model available for all of your equipment, which is good for management. With other tools, the licensing models are similar to what Meraki offers. Meraki has many years of experience, so I prefer Meraki over the other products.

Meraki offers good pricing when compared to Fortinet and some of its competitors. The FortiGate and Cisco Meraki solutions have similar pricing.

I don't know how to explain how the tool's auto-VPN feature helps our company with operational efficiency.

I don't remember any issues with the VPN feature associated with Cisco Meraki.

When we tried integrating Meraki SD-WAN into our infrastructure, there were challenges. If the customer has another vendor's network, like an Aruba or Juniper network, the integration becomes complex because the engineer needs information about both the customer's network and the other vendor. The engineer needs to check if the configurations follow the same protocols, SSIDs, or VLANs.

I rate the tool a nine out of ten.

We used Meraki SD-WAN for connectivity between our stores, primary data center, and service locations.

Meraki SD-WAN improved the way my company functions because it allowed quicker time to market for connectivity, efficacy, and security. It also contributed to better expense management in terms of not using dedicated services, instead utilizing more public cloud services to establish connectivity.

What I found most valuable in Meraki SD-WAN is its simplicity. I also like its manageability.

The only area for improvement in Meraki SD-WAN is its licensing model, as well as its cost structure.

I have three to four years of experience with Meraki SD-WAN, and I used it in the past year.

Meraki SD-WAN is a stable solution. It had well-managed updates that created a pretty stable and manageable environment overall.

Considering the number of locations where Meraki SD-WAN was used, I found it scalable.

I would rate Meraki SD-WAN technical support as four out of five.

Positive

We didn't use other solutions apart from Meraki SD-WAN.

Meraki SD-WAN had a straightforward setup.

I've seen ROI from Meraki SD-WAN.

I don't have information on the exact cost of Meraki SD-WAN, but I'd rate it a three out of five, just because the licensing model is very much associated with the Meraki solution. Meraki has its own pricing model.

Other solutions were evaluated, but I can't recall which ones off the top of my head.

Thousands of people used Meraki SD-WAN within the company. Meraki SD-WAN had a substantial deployment because the company I was in had quite a few locations. Hence, about fifteen to twenty people took care of the deployment, but to maintain and monitor Meraki SD-WAN, a minimum of two people would suffice.

There's no plan to increase Meraki SD-WAN usage because of the current economic conditions.

I'd recommend Meraki SD-WAN to others because it's easy to deploy and manage, but my advice is to be aware of the licensing and cost structure of Meraki SD-WAN.

My rating for Meraki SD-WAN is eight out of ten.

The best feature we're using is the packet shaping. We can feed the traffic shaping rules according to our requirements, so if we need application-based packet shaping, we can configure it. If we want URL-based traffic shaping, we can do that too.

Also, we can enable per-client bandwidth according to our requirements. 

The solution can only support two up-links, so if you have three internet lines, there is not a provision to connect the third internet line. There is a provision to use the cellular data like a dongle, and you can use that dongle to connect the third line. We need that feature because we need to have three internet lines. The product should be able to support more than three internet lines.

I've been working with Meraki for the last four and a half years. 

It is stable for my business requirements. Some of our locations are assembly branches, so we use MX60 at those locations. We use that effective product for user compatibility, and we haven't had any issues.

The solution is scalable. We have 100 locations using this solution. 

We had a licensing issue, so we contacted the support team and got a response. I would rate their help as a four out of five. 

Previously, we were using the MPLS network. We then removed the MPLS network and installed Meraki products, which are compatible with this technology, so that's why we're using this product now. 

The initial setup is very easy, you just need to configure the IP addresses, gateway, subnet mask, and DNS. Once it's connected to the internet, you have to claim the device on the dashboard, and then the dashboard will automatically show if it's online or not. Once it is online, you can configure the policies, as per your requirements, through the dashboard. The remaining part of the setup can be performed and configured on the dashboard.

It takes around 15 to 20 minutes to configure it. 

We have a yearly license. 

You can use this solution for SMB branches according to your requirements. At this time, you cannot use Meraki on a single device, so suppose you have a core suite, distribution suite, and access suite. If you're a data center, you cannot use the solution at this point.

I would rate this solution as an eight out of ten. It is very user-friendly, and it doesn't take much time to configure the simple dashboard.

We use it to provide our customers with a single dashboard for visibility, monitoring, and control across the networks. It makes it easy for us to integrate particular services with the customer's overall requirements.

The features of SD-WAN are very appealing because you have a centralized dashboard and multiple options to terminate. You have an internet leased line, which means that you can connect your broadband and 3G and 4G cellular networks on the same router. This makes it easy for us to manage everything on a single dashboard. That is, you can integrate multiple stacks in such a way that you do not have to maintain any other dashboard. You get single-pane-of-glass accessibility with Meraki.

Meraki is lagging behind in using a single pipe from service providers. That is, it would be good if they could use both the internet leased line and broadband connectivity.

In a future release, I would like to see integration with a security solution like Cisco Umbrella. This will give complete visibility on a single dashboard.

We started using this solution six months ago.

The data plane is installed on-premises, and the management plane is in the cloud.

It's very stable, and the overall cloud availability or management plan availability is almost 99.5%. It is absolutely awesome.

You can scale it at any level; there is no limit to the scalability. The best part is that it can be managed remotely. You do not have to send in an engineer. You just have to send the box to the customer, and they just have to plug it into the network. You can configure Meraki devices right from the workplace.

The technical support for this solution is absolutely superb. It's available 24/7. If our engineers are facing any issues, technical support is always available.

The replacement cycle is absolutely superb. Cisco support is globally number one, and I would give them a ten out of ten.

Positive

The initial setup is very simple.

The price can vary depending on the challenges that you need to address. When you look at the stability and reliability against the price, you absolutely get the value for the price.

I would recommend Meraki SD-WAN to those who have multiple sites across several different geographical locations and to those who really want to connect their branch offices, their depos, their factories, etc.

On a scale from one to ten, I would rate Meraki SD-WAN at nine.