Those of you who manage distributed networks often support locations that have slow or high-latency connectivity. Have you ever wondered how to get more out of those slow, often expensive links? There is a way to squeeze more out of them: WAN optimization.

WAN optimization reduces bandwidth consumption between sites and significantly accelerates application performance for users at remote locations. This is the first part of a two-part series on Meraki’s WAN optimization. In this part, we’ll take a closer look at some of the techniques that together provide up to 209X improvement compared to un-optimized links. In part 2, we’ll see how one of our customers has reaped the benefits of the MX and its WAN optimization. In case you missed it, check out the introduction to WAN optimization.

WAN optimization is most beneficial for sites that have narrow bandwidth and/or high latency WAN links, and it can help get the best performance out of those sub-optimal links. It’s built in to the Meraki MX and accelerates FTP, HTTP, Windows file sharing (CIFS/SMB), and other TCP-based traffic between sites. This significantly reduces the time to transfer data between different locations and also reduces the bandwidth consumption at those sites.

The amount of performance improvement depends on the traffic type, the data transferred, and the existing WAN link performance between locations. The chart below shows the results of The Tolly Group’s benchmark performance evaluation of Meraki’s MX Cloud Managed Security Appliance when using WAN optimization, in this case for FTP file transfers in three WAN link scenarios.

Tolly Group – WAN optimization performance for FTP file transfers

In the chart, the term baseline denotes a file transfer without WAN optimization, cold run denotes the first time data is transferred with WAN optimization, and warm run denotes subsequent data transfers with WAN optimization enabled. The complete Tolly report, including performance results of other protocols, is available for download here.

The MX uses three independent techniques to achieve these performance gains:

  • link compression
  • byte level caching
  • protocol-specific optimization

Link compression

Link compression is pretty straightforward: it acts like zip for your network connection. If traffic can benefit from compression, the MX compresses the data before sending it across the WAN. At the other end, the receiving MX decompresses the traffic. If a file is already heavily compressed, for example if the user is sending a .zip file, then further compression provides no benefit, and may actually be worse. In that case, the MX won’t try to compress it any further. All of this is completely transparent to the end user.

Byte level caching

Byte level caching and de-duplication ensure that data isn’t transferred across the WAN unnecessarily when it is already in the local cache. In the case that data has previously been transferred across the WAN, a user requesting such data will simply receive it from the MX Security Appliance at the local site. Caching and data redundancy elimination allow the MX to identify cached data even if a file’s name or contents are changed, or even if the contents are transferred over a different protocol, e.g., a file downloaded over HTTP but uploaded via Windows file sharing.

Protocol-specific optimization

Many protocols were designed for local area networks and don’t perform as well on today’s wide area networks, due to excessive error-checking or “chatty” algorithms. WAN optimization optimizes these protocols, for example by minimizing round-trip acknowledgement delays, and significantly reduces the overall latency of the transactions. Optimized protocols include HTTP, FTP, and CIFS.

Enabling WAN optimization

To enable WAN optimization, you’ll need a site-to-site VPN network with two or more MXs, one at each of the sites that transfer data between them. WAN optimization is included in the MX’s Enterprise and Advanced Security licenses, and is included in all the MX models. All of them, except for the MX60, include an internal hard drive for byte level caching. The hard drive capacity is 1 TB, except for the MX600 (4 TB). If you’re curious about VPN, check out the blog post on the MX’s integrated site-to-site VPN tools.

Stay tuned for part two

In the second part of this series, we’ll look at how Vector Media, an advertising and media services company, deployed the Meraki MX in their distributed organization. With many sites spread across the US, some locations only have access to low performance, expensive WAN links. Stay tuned to learn how they’ve been able to cut their connectivity costs and improve their network operations.