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.  

From the vice perspective, they just are not as robust as some of the other vendors. They have limitations in throughput and the number of circuits that they can support on a wide area network. Their higher-end security is all cloud-based. They have some capability with the premise-based solutions, but the higher ends are all cloud-based, and that's via Cisco Umbrella.

Their support can be better. They do not offer a lot of hands-on support for their products.

The advanced license is expensive. Part of the cost involved is high. If you are only a small or medium business, it may not be the best option. For branch divisions, yes. This is a very useful product and I don't have any problem with the CAPEX however, I have a problem with the OPEX as the OPEX part of the advanced license is quite expensive. 

We'd like features that provide more transparency when there are issues. Right now, it's hard to get clarity on problems. We need more visibility.

There are literally things you cannot do in a graphical user interface that can be done from a command line. Certain commands that you can issue to any device from a command line are basically explicit; the same as a server or any other IP or any computer-related piece of hardware. If you can get to the command line, you can give it explicit instructions that basically tell it to do something that's hard to describe in a graphical environment. Periodically, there are some issues that you have to figure out how to work around.  That's a very technical thing, most people won't run into it. 

I think they should enhance the security. I feel like the security is decent, but some other people that I work with say there are better options available. Cisco requires you to upgrade the firmware to custom firmware on the devices you want to go beyond Diffie-Hellman five. DH5 is in the lower part of the spectrum. Other devices, even Cisco devices are using DH15 or higher. I think DH24 is the highest that's currently available. 

The feature set right now requires a firmware upgrade that's custom to enable that kind of encryption. They should just have it in a dropdown. If they could fix that, I could tell my other colleagues, "Hey, look, Cisco can do it right out of the box." To enable higher-end encryption, higher than Diffie-Hellman five, DH5, requires a custom firmware. If they could make that built into the standard firmware as an option, I would love that. 

I think that from Cisco's perspective, they've chosen not to do that simply because it requires more performance.

That's how they keep it because they say, "Oh, look at the performance. It's the same as the other guy." Yeah, but the other guy's using DH15 or DH14 and you're using DH5. The level of encryption means more horsepower required from the processor on the devices so that's why it increases the footprint. The more CPU, the hotter it gets and then it doesn't last as long; the performance is not as good because it's using more resources, etc. Cisco should definitely sell equipment with better processes or better performance for our processes because that would give us a higher level of encryption on our firewalls.

We have had some problems doing the implementation. We had to open a case with Cisco. The deployment was solved with Cisco's tech help. 

In terms of the applications, the policies that we configured didn't work as expected. However, Cisco's tech also helped us deal with this as well. 

Meraki has a limitation in the number of links that it can work. For example, in Cisco, we can work with many, many links if you link with Viptela, however, in Meraki, we just get to work with two links or a maximum number of three links including the LAN link. It was a problem. When clients need many links and you have just two links it's a problem.

Meraki is more or less an intelligent load balancing. A lot of features are missing that other SD-WAN solutions have. For example, forward error correction and WAN optimization. These features are missing.

The best thing would be if you could have more than two uplinks in the Meraki Gateways. Also, forward error correction would be nice to have.

I do need to explore the solution a bit more before really finding fault in anything.

The distribution could be improved. We have a lot of problems with distribution. The late deliveries likely have to do with the time it takes for the fabrication of components. It is a principal problem at this moment.

It would be helpful if there was reporting. I'd like to be able to hand reports related to performance right over to clients. 

We are resellers, meaning we are a certified partner of Meraki and, as such, it is my job to sell Meraki products to our customers on the Korean market. Occasionally, I encounter issues concerning the price. It would be good if the price were more attractive to the market. The pricing is not that cost-effective to the customer. 

Cisco potential or actual customers who use Cisco classing models, such as 2,900 switches and other routers, must consider the management of the Cisco product in respect of the desired implementation and not just the classing models. It would be much better were Meraki to provide comprehensive virtual management tools. 

The Cisco market team provides customers with any technical support they may need. Overall, we are satisfied with the support, although I cannot state this unequivocally, since there are certain issues we have encountered when opening a ticket.

This vendor has issues with the supply chain that need to be improved.

Meraki SD-WAN could improve on the lead time, but this is not a problem only with Cisco. there's a global shortage of chipsets. Additionally, the solution has limited features. It's quite a standard product and not very easily upgradeable or stackable. 

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.

If you compare Meraki with other solutions, the level of security is minimal.

The security needs to be improved, which is why we also use FortiGate. Meraki offers the client basic security, it is not the same as what FortiGate is offering. The customers question the security as they see that they have some loopholes. They feel that a hacker can easily enter your data. When you operate the network to the family, on the outside a hacker can see the IP address inside the network.

Customers will request a firewall to protect the network.

I would like to see Meraki include firewall security. Also, they should have encryption inside the router to make the data secure.

With Meraki, it's more of a basic connectivity. It doesn't have all the feature sets that a Cisco SD-WAN solution has. It's limited. 

The product needs to offer connectivity in the major clouds due to the fact that everybody has at least part of their workloads in the cloud.

The solution could be improved if it added more security features, especially monitoring endpoints with rogue network applications.

An area for improvement would be to add 4G bonding and allow Meraki devices to support dual 4G SIM cards.

The product could be improved by being made more simple to use. We had some issues integrating our MPLS with Meraki SD-WAN 

Some features that should be included in the next release are micro-segmentation, ITS-related features, and inspection and detection for anti-malware. 

I also think that they need to improve their hardware. They have some devices that support Wi-Fi, but not LTE and they have some other devices that only support LTE but not Wi-Fi. 

I think Meracki still has some work to do in terms of catching up with other companies when it comes to AI. 

The solution sometimes drops VoIP calls, which is a nuisance. The solution is not true SD-WAN, rather L3 VPNs. All they do is put a wrapper around it so that you don't have to configure it, but it lacks controllers. 

You need to have internet access to configure the solution. You cannot do it locally, there should be a local option.

The security and upgrading could improve in this solution.

In an upcoming release, they could add more security features, such as antivirus.

There should be a few more options for security parameters. It is currently not very customizable. It should be a little bit more customizable. 

I would like to see more functions added to the next release of Meraki SD-WAN.