What is our primary use case?
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.
How has it helped my organization?
Our journey in moving to Meraki is in progress but we expect to experience a huge benefit in the bottom line of operational costs.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I have been using Meraki SD-WAN for four years now, starting in 2016.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
How are customer service and technical support?
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.
How was the initial setup?
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.
What's my experience with pricing, setup cost, and licensing?
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.
What other advice do I have?
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.