What needs improvement with Meraki SD-WAN?

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.

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.

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

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.

The solution must provide more security features.

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.

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 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.

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.

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

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.

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

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

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 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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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 security of the solution needs to be improved. The adoption of endpoint services or endpoint security should be developed in future releases.