On the security features, when compared to Fortinet, they have more patterns and AI-generated ones. Meraki SD-WAN is slowly implementing AI, but it is not yet full-fledged. If AI comes into the picture, it will be helpful. I work with Fortinet where with a single command you can deploy the entire SD-WAN along with FortiGuard within minutes. For AI, it can discover and connect, but currently, we are doing it manually.

In Meraki SD-WAN, some features require additional licenses and subscriptions. If these were bundled together, such as 10 or 20 licenses, it would be very helpful for a mini branch or small campus area coverage.

The main point for improvement for Meraki SD-WAN is that they could provide more troubleshooting tabs on the GUI. For instance, when performing a TCP dump or packet capture on some ports on uplinks, this should be available on the GUI.

It would simplify troubleshooting and allow for deeper investigations when accessibility is granted for these two types of troubleshooting tools, which are already permitted on other vendors such as VeloCloud, which was part of VMware and now belongs to Broadcom.

VeloCloud provides much more detail and many more tabs for troubleshooting everything, such as ARP, IPv4, IPv6, TCP dumps, routing, and switching. Users do not need to access the device CLI to dive deep into troubleshooting, as everything is accessible through the GUI in VMware. Cisco should enhance the GUI interface to provide more details for users to troubleshoot.

The security integration in Meraki SD-WAN is not as good as the competition, such as Fortinet. Customers are moving away due to this reason, as Meraki lacks in offering advanced security features, which is crucial for many enterprise clients. Cisco's AI capabilities and Meraki are about seventy percent caught up with competitors like Juniper Mist in terms of AI integration.

Some advanced networking features are not currently available in the Meraki product but are on their roadmap. These features are available in Cisco's higher-end solutions. Additionally, I would like to see a blade switch in the product.

Meraki did the job for what I needed. The key principle to follow is to let the problem drive the solution. Don’t pick a solution and try to force your problem into it. In our case, our needs drove the solution, and Meraki fit those needs best.  If I were looking for more throughput, there would be better solutions. For example, Palo Alto and Fortinet can offer higher bandwidth capacities. I sized the solution based on the bandwidth available, which we likely won’t exceed.

The main feature we needed was maintaining the system with minimal staff and without outsourcing support. Defining our needs led us to AutoVPN, which fits our requirement for minimal support. Meraki was the right product to meet these needs. If your priority is backend traffic and bandwidth, and you don’t need to filter traffic and scan for malware, geofence, or mesh networks, there are better options with more capacity. But that wasn’t our need.

The real issue is that many people pick a solution and try to adapt their business model, which is the wrong approach. In the long run, that limits you.

In Meraki SD-WAN, we have some limitations with the traffic shaping capabilities.

There is nothing specific that I want to say, but the solution is improving daily. The tool comes up with new features and new capabilities. The solution is moving away from small business use cases to large-sized enterprise customers.

I am okay with whatever Meraki is currently supporting in the solution. My concern revolves around the WAN part of the solution since if we consider traditional routing, it doesn't support all routing protocols. Right now, my company is very limited in BGP and OSPF scenarios.

They have to ask us many questions about configurations. It could be improved with some automation to trigger, for example, telemetry data, so we can determine the state of the deployment as of day zero and day one.

Meraki SD-WAN has to significantly improve the company's network performance. Though Meraki SD-WAN's network performance is better than that of the MPLS circuit and other technologies, it can still improve.

The tool needs to focus on network stability, better prices, good performance, and low-cost bandwidth to improve its solution. I want the tool's cost to be less and performance to be higher.

If Meraki can add more features on the reporting side, that will be convenient for us because we have to rely on a different product for monitoring and reporting. That is one of the challenges. Apart from that, everything is good.

If I gauge the reporting features, suppose for device performance-related things and transactions, in terms of throughput and the types of issues we receive on the network side. If those can come into the reporting format, it will be very helpful. 

Many customers ask for their performance, transactions, and throughput. It is very difficult to get the report from connected devices. In that case, we have to go for additional management tools or monitoring tools, which can give us good features. Like earlier, we used Cisco Works. In the same way, we need to implement another product.

In the past, I have used it up to a 250 Mbps device. If we add around seven hundred to eight hundred users, the performance degrades. Meraki might have recently added more devices with higher capacity, but I haven’t had hands-on experience with those. 

Sometimes we face issues with VPN connections when someone connects from a different time zone, like from Georgia to the Middle East. These kinds of issues occur, but other than that, nothing major.

It is effective and easy to set up, although a bit expensive, but it gets the job done with a simple configuration. 

However, Meraki isn't as flexible for more unique needs but works excellently within its defined scope.

I'd like to see improvements in the client VPN area. Currently, we use L2TP over IPSec, which, while widely supported, can be buggy on Windows due to Microsoft's implementation, not Meraki's. 

Cisco's AnyConnect is an alternative, but it's proprietary. An open-source option like WireGuard or TailScale, especially WireGuard for compliance reasons, would be a valuable addition to Meraki's offerings. 

WireGuard would be a perfect fit due to its simplicity and set-and-forget configuration

The licensing price is a bit expensive in comparison to other products that have more capabilities. 

The interface in the VPN management system can be a bit complex for users to understand. The usability could be improved so that users can access things more quickly. 

From a dashboard perspective, identifying issues can be challenging if one or two individuals experience trouble. Another area for improvement is in wireless management, where external tools might be needed to troubleshoot noise and environmental factors causing network issues.

Meraki SD-WAN could be improved by including full feature routing functions similar to a normal Cisco router. It would also benefit from self-healing capabilities, where it can automatically reboot or reset if the VPN stops working.

The solution must provide more security features.

The configuration from the firewall side could be improved a little bit more.

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

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.

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. 

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.

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.

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.

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.  

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

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

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.

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.

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

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.

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.

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 product supports small and medium business solutions. It could be improved to support more enterprise use cases.

The solution can support more security features like the Cisco firewall.

Meraki SD-WAN had trouble prioritizing traffic for VoIP calls, specifically for Microsoft Teams. They faced challenges for sometime when you set up QoS on Meraki's access points. There are profiles available for different services, such as Microsoft Teams, which effectively put all the rules in place for you. During their SD-WAN deployment, these profiles were not accessible to them. It's possible that Meraki has since introduced them. Therefore, having profiles for different services would be beneficial.

Meraki SD-WAN could make the license cheaper; the licenses cost a fortune.

I don't have any notes for improvement. 

Technical support could be more knowledgeable and responsive. 

You do have to pay for the solution in perpetuity. 

The granularity could be improved. It's not very granular for URL filtering or content filtering. If you want to do a specific route or a specific rule, that feature is lagging a bit. 

The stability could also be improved.

The security could improve in Meraki SD-WAN.

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.

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.

The blocklist on the Cisco Meraki side isn't complete or very large. We'd like to see them update and expand this. 

People are struggling a little bit with the lead times right now. It’s hard to actually get the hardware. There’s a long waiting list. That said, I’m unsure as to if that's anything that any manufacturer could really control right now.

Meraki is not viewed as an enterprise solution. It's more of a medium SMB-type solution. Although that really shouldn't be the case, I do see that it has that stigma associated with it.

I'm not particularly close to it. Because our infrastructure team is in charge of that. I'm more on the information security side. But, from what I understand, the product works well and there isn't much that can be done to improve it.

More automation is always a good thing, but I'm not particularly close to the Meraki. That is more of an infrastructure team's responsibility. I'm not too familiar with the Meraki environment, but I suppose more automation is always a good thing.

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

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. 

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. 

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. 

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.

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.

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.

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. 

This solution can only support up to two WAN ports. However, many of our customers would like to have four WAN ports.

This solution comes without NAT support enabled. If you need it, then NAT has to be enabled.

If this solution were cheaper then it would be of interest to smaller companies.

Because I have not been using the product for very long, I'm really just learning it and being overwhelmed by the amount of information that I can actually get from the system. There is really nothing that I can think of at the moment that needs to be improved. I'm just really happy about basically everything. It might happen that something will become important sometime as we get more used to the product and we are able to look into it better. But for the moment it seems to cover everything we need.  

Possibly there may be more options for integration between computers, projectors, television — sort of being able to more easily make everything included in one solution. It would be even more useful.  

We selected this solution because it needs to be always connected. In some cases, like an Internet outage, this can make the solution unmanageable.

If the network disconnects, we have access to the device but cannot make any changes.

I would like to see more flexibility in our choices of customization for our needs.

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

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

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

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

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.

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.

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.

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. 

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

The solution needs to enact more advanced protections. 

The port density should be improved because this solution is limited to two. We are getting more and more use cases where clients have more than two internet connections and require more than two ports. There should be three or four ports. It is possible to work around this limitation by using a layer two switch, but it does not provide the same flexibility as the statically assigned port.

The price of this solution is too high for smaller companies in Africa, where it is the enterprises that can afford it.

When there is an issue, I find it difficult to figure out what is going wrong because the logs do not provide as much information as solutions from HP. With HP you have the CLI, but with Meraki, there is no CLI and I find it a little bit annoying because you always have to work with the interface. In this regard, the interface could be improved.

Being able to log in remotely via SSL and access a CLI would be helpful because I prefer the CLI over a graphical interface.

I think that it is the right time to research features such as IPsec IKEv2 and SSL decryption.

I would like a faster installation time in the next release.

It should be easier to install BGP and it should have a better backup. 

The solution needs a multi-use provider portal.

I'm not on the technical side, so I don't know if there is an area of the solution that needs improvement. There is a wish button in the product, and we're fine with that. 

The pricing could be a bit lower.

The solution lacks a certain amount of functionality and features.

The VRRP design needs improvement.

They stopped doing WAN optimization as a feature set, which is now lacking. They need to relook at that and consider WAN optimization as an option. 

I know that they have improved the security and have taken that off and that to me is critical on the MX. That's where they lack.

The reporting needs to be looked at. It needs to be more granular. The reporting on the actual solution isn't what the customers are wanting to get.

Scalability could improve to accommodate a larger enterprise.

In the next release, I would like to see the WAN optimization.

The solution could be improved if it added more features, especially monitoring and reporting features.

The security of the solution needs to be improved.

The adoption of endpoint services or endpoint security should be developed in future releases.

Perimetral security for new requirements on financial networks and DRP systems, like SAP. 

It should send email alerts.

There is a point in a very large organization where you hit the VPN limit, or tunnel limit.

Some of the on-premise security features of Meraki SD-WAN are on the cloud and some of my customers do not want to use the cloud. They should have on-premise security features for those that do not want to use the cloud.

In a future release,  Meraki SD-WAN should improve the integration with other solutions.

The integration with other tools must be improved.

Regarding the integration part, the VPN connection for third parties needs to be elaborate.