Meraki SD-WAN Reviews

Our company uses the solution for side-to-side or branch connectivity to our data center. We have 70 branches and about 3,000 end users in our environment.  

The solution operates via zero-touch configuration. We do not have to physically visit branches to configure. We just send the points to our locations for seamless, push configuration from the cloud. 

The firewall included in the antivirus protection includes many features such as IPS and traffic shipping rules.  

The solution is quite user friendly and has predefined functions that you click to deploy. 

A run optimization feature is needed to reduce the bandwidth for any uploaded content. 

I have been using the solution for four years. 

The stability is very good so is rated an eight out of ten. 

The solution is scalable from a security perspective. 

Endpoint security can be managed by the end users or other third-party tools. We use Trend Micro for endpoint security. 

Scalability is rated a six out of ten. 

Our company is layer one and we have certified experts in-house, so we handle most technical issues.

Responses are not very clear when we escalate issues. Support is located in the UK and we have to get our account manager to connect us with the team in the UK. 

Technical support is rated a five out of ten. 

Neutral

The setup is easy once you are used to it. Our first setup took a bit of time but now we process setups very efficiently. 

The setup time depends on the site, user load density, and network gateway policies. It could date one day to go through all the steps for a more complex setup because you need to create the policies, map them, and integrate the active directory with the policies. 

We implement the solution in-house. 

The solution offers yearly licenses and product lines or prices are readily available on their website. 

We purchased the solution in 2018 and it is still supported. 

The solution does not include a run optimization feature for reducing bandwidth like what is available in other products. 

I recommend the solution but would like it to provide better optimization. If it does, then the solution would be considered an absolute star product. 

I rate the solution an eight out of ten. 

I primarily use it to connect sites to each other over an overlay network, with protection from the next-generation firewall in the Meraki ecosystem.

The most valuable feature for me is the security functionality, its integration with Wi-Fi, and the switching approach.

The license model may need improvement because if we need to renew something, we need to completely renew the license model.

An additional feature I would like is the 5G solution. It is not yet there.

I have been using the solution for more than four years. We are using the latest version, which is cloud-based.

The stability of this solution is fine. It has a Fusion version. It does what it prompts.

The solution is scalable. It is scalable for mid-tier deployments, but not for major ones.

The technical support is decent if you open a ticket, but it can sometimes take quite a while. As for product development, it's a much more difficult story, as they have a very lengthy development cycle.

It is a cloud-based solution, so the initial setup is straightforward. Onboarding a customer can be done in a few weeks.

The deployment process is easy. It's a cloud-based system that is activated by attaching the serial number, and then the system goes live. So it's easy to set up.

The license model depends on the customer and can be a yearly license, a three-year license, or a five-year license. There may be additional costs for certain licenses, such as Umbrella licenses or advanced licenses. The pricing ultimately depends on the functionality the customer requires.

Overall, I would rate the solution an eight out of ten.

It's for enterprise networking. So some of the customers are from the BFSA domain, and some of the customers are from manufacturing. It's a distributed customer base.

Any customer looking for a single solution that can serve them for network security, which can serve them for the SD-Branch all branch networking. We use it for this purpose. It's used for a combination of SD-WAN and SD-Branch plus security.

Everything is under one umbrella. The Meraki dashboard is one of the valuable features which I use. I can control the devices across walls and across the landscape.

It's not difficult to set up the solution. 

The solution is stable.

It can scale well. 

The cloud area and the security area can be improved. Meraki has a limitation, especially on the cloud. If I deploy the services on the cloud and I want to make a site-to-site connection or maybe I have to do some sort of routing, inbound routing, it is not properly working with the Cisco Meraki. It needs to be matured a bit.

They need to offer proper integration of the security features. They talk about the next-gen technology, the next-gen UTM feature. It's not a complete security solution, however. 

I've used the solution for about five years now. 

The solution is stable and reliable. There are no bugs or glitches. It doesn't crash or freeze. 

We can easily scale the solution. 

We are supporting multiple customers that use this solution. There are approximately 5,000 people using the access. 

We are well connected with the RR account manager. He is based out of Australia. Every time, whenever we have some sort of need, he is the go-to guy for us.

Positive

We use a variety of SD-WAN technologies. 

The solution is very easy to deploy.

How long it takes depends on the kind of site you are setting up. If I'm tiering the site, and have 20 users or 30 users and have a couple of links and the security postures are not very complex, maybe I can do the deployment in a week's time. 

I can do two or three cuts over a week if it is small. You can bifurcate. I don't have any ready-made answer as to how long it will take as every setup is different. 

We do look into ROI and show clients possible ROI if they decide to go with Meraki. 

The price of the solution varies. It depends on the customer. For most of the customer deployments, we tend to do either three or five years of licensing. Having a longer-term give us some discounting in terms compared to one year.

We are partners. 

We use the MX64 deployment, although it goes all the way up to 300.

I don't want to be Meraki biased, however, if anyone is looking for the kind of solution that can include the branch office or the network security or even a Cisco Umbrella kind of solution, Meraki is the right choice.

From an SD-WAN perspective, I would rate the solution seven out of ten. I'm just cutting down three numbers due to the lacking of cloud networking and the weaker security posture.

The tool makes it easier for us to communicate with other offices without using an MPLS network.

The solution is easy to use. The product enables us to connect with other offices easily. It provides alerts to notify us if a site is down or up. I haven’t faced any challenges while integrating Meraki into existing infrastructures.

The solution must provide more security features.

I haven’t had any issues with the tool’s stability. That is why we use it.

The tool is scalable. We deal with medium-sized businesses with around 100 users.

The support is pretty good. The support team is pretty knowledgeable.

Positive

The initial setup is straightforward. I rate the ease of setup a ten out of ten. The deployment can be done in an hour if everything is connected properly. We need two network technicians for the deployment. It is simple to use. It does not require any maintenance.

The product is not very expensive. I rate the pricing a five out of ten. The price is not a huge deal-breaker.

I evaluated other products, but Meraki was cheaper.

We configured the VPN feature in our organization. It works well. I will recommend the solution. It is easy to use. Overall, I rate the product a ten out of ten.

The auto VPN feature is important because it automates many tasks, making things simpler and faster. It helps with setting up devices and changing configurations without manual effort.

Meraki SD-WAN helps save money by monitoring applications and ensuring service levels. This gives businesses a clear view of how well their operations are running and whether service providers meet their needs.

The Meraki SD-WAN has been mainly focused on Wi-Fi in the past, but with the introduction of the client, they're likely to enhance their AI-driven initiatives. This could mean providing more predictive insights to customers, but it might take time to develop fully.

The tool has challenges with features like multiple-link support, which currently only supports up to three links. Additionally, it doesn't offer router integration, and forward error correction is another missing feature. The scalability of Meraki SD-WAN is good, but there are limitations to the performance of the concentrator devices, especially in larger deployments. While the cloud scale is not an issue, the performance of the devices in branches and data centres is limited.

This can be an issue for larger customers with high traffic volumes. The roadmap includes plans to improve scalability, but progress may be slow.

I rate the tool's deployment a ten out of ten. 

The tool's support is not very good. The process is ongoing while they are not fully integrated with Cisco TAC. 

Neutral

Regarding pricing, Meraki SD-WAN is quite competitive, especially compared to solutions like Fortinet. However, it's essential to consider that Meraki requires cloud orchestration, which adds to the overall cost. Overall, it's one of the most competitive solutions from Cisco for SD-WAN.

Meraki SD-WAN is one of the best and easiest solutions to implement. It's very user-friendly, making it simple for users and partners to sell and deploy. Additionally, it offers a range of security features and the ability to integrate with SaaS platforms. However, compared to other vendors, it lacks some important features, and although they're on the roadmap, they're taking a bit longer to roll out.

The product is successful in various environments, especially in retail and specific industries like finance. Retail accounts for around 30 percent of its usage. I would rate the Meraki SD-WAN a nine on a scale of one to ten. It's simple to use, scalable and offers easy access to the API. However, it's not a perfect ten because it lacks some important features, and it is slow in terms of rolling out these features for customers. 

Meraki SD-WAN offers a platform where Cisco manages your database. The platform is cloud-based and accessible through the URL. This means that Cisco has access to all of your devices, but it also means that if you need to make changes, Cisco can control it. One of the benefits of this system is that if you experience any loss of connectivity, Cisco can support you.

Meraki SD-WAN provides an open platform for users, allowing them to tailor their bandwidth usage. Additionally, it allows you to monitor customer usage and distinguish between different types of URLs they use, which can be non-production, production, confidential, or non-confidential.

From my end, I cannot submit any details on the areas of the product that need improvement because I am currently on the audit format.

In terms of additional features that could be included in the next release of the solution, it would be useful to have proxy software that can be managed from a mobile device. As engineers, sometimes we need remote access, which can be a challenge, especially during off-shifts when we can't log in to our environment. If there was a platform that allowed us to access our credentials, it would enable us to provide support to the customer while also improving vendor productivity.

I have been using Meraki SD-WAN for three years now, and in my experience, it's one of the best solutions.

Stability-wise, I rate this solution an eight and a half out of ten. I would like improved stability in Meraki SD-WAN. Also, it is a very user-friendly solution. So, whenever you want to implement a new site, you can get options that are user-friendly and UI-based, which are very straightforward in nature. Basically, there are no complexities involved. So, a person involved in the solution's implementation can understand everything.

Meraki SD-WAN is a scalable solution because changes are being made to the solution, enabling it to work in different environments. In short, the perfect set of decisions is being made for the solution. I have experience working with the solution on a range of user scales, from 500 to 10,000 users.

Since I am a consultant currently, I won't be able to say whether I have plans to increase the solution's usage since I am presently not working on the solution.

Meraki SD-WAN's technical support can be considered a very fast one. I rate the solution's technical support nine and a half out of ten.

Positive

I have previously used Viptela SD-WAN.

Meraki SD-WAN’s setup is straightforward because Cisco has control over everything. The solution is deployed in a cloud environment from the first day, which has been my experience since 2013 when using cloud-based solutions was not as prevalent as it is now.

I won't be able to speak about how many days it took to deploy the solution since I am not involved in its technical part.

To deploy Meraki SD-WAN, you need to connect your devices with the Cisco cloud environment, for which you need to give the gateway from your devices, and that message needs to be connected with the Cisco environment. Once connected, Cisco will provide you with the platform to manage your devices. Since they have admin rights, everything will be managed by Cisco.

Regarding the personnel involved in the deployment and maintenance of the solution, if we consider the operations part, which includes a VCP and a person for DRP, four people are involved, including a lead and a manager.

I believe Cisco offers some of the best solutions. Meraki's routers, switches, and wireless solutions are some of the best.

You need an open platform to work with Meraki SD-WAN, whereas Aruba can be a bit more complex. That's why Cisco Meraki SD-WAN is generally preferred. Overall, I rate this solution a nine out of ten.

We are using this solution for productivity, in terms of the users, and simplicity in terms of ease of management, although the capabilities of the platforms are a little restricted. As is the resilience, just because of the hub and spoke nature at significant volume. I use the solution a lot in retail stores.

The solution is deployed on-prem and on the cloud. We are using the latest version.

The solution is pretty reliable.

Scalability could be improved. Yes, you can add more than 300 or 400 sites onto it, but because it's not a true SD-WAN and, effectively, it's just a Multi-VRF, it's all hub and spoke at that point. That's the nature of the design, but that's what keeps it simple to administer. So, it's a trade off.

I have been using this solution for about 10 years.

We haven't had any issues with stability.

The scalability could be better. Typically, when I get beyond 300 or 400 sites, depending on the criticality of service, I will normally move away from Meraki and look at either Viptela or Versa.

We have 4,000 end users and no plans to increase that number.

I can fall back on my service provider if I need any additional technical support.

Initial setup is straightforward. For deployment and maintenance, I have three people that are capable of dealing with it and that is basically just to  make sure I've got cover within the team, but typically one person is administrating at any one time.

There are no licensing costs for the product subscription.

I would rate this solution 8 out of 10. 

I would recommend this solution, particularly supported by VM02.

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.