Speeding up the delivery of applications and data to remote users is the No. 1 goal of WAN acceleration and optimization. Not only does it help get more done over the same amount of bandwidth -- or less -- but WAN optimization appliances reduce response times and overcome latency inherent to long-distance WAN links. Using a combination of file- and byte-segment caching, TCP optimizations, and application-specific acceleration, WAN acceleration appliances help move the data that drives business.
One vendor that I've long wanted to test is Juniper and its WXC line of WAN acceleration appliances. I was originally scheduled to evaluate Juniper's appliances back in early 2007, but due to a scheduling conflict, I was not able to get my hands on the gear. Now, only 18 months later, I was able to finally plug a pair of WXC 1800s into my well-worn WAN acceleration test bench to see how they fared.
The WXC 1800 offers a good mix of application acceleration, TCP optimization, byte-level caching (Network Sequence Cache), and central management. The appliance is one of only a couple WAN optimization appliances I've tested that can handle CIFS traffic that's been signed by SMB (Server Message Block). It also can accelerate SSL-encrypted packets including users with client certificates.
My WAN test bed was laid out as with previous tests: a Shunra VE simulating the various WAN links and impairments, a client PC running Windows XP Pro and MJT Net Macro Scheduler, and a Windows Small Business Server 2003 as the data source and Exchange server. As before, WAN speeds tested were 128kbps with 40ms latency and T1 (1.54Mbps) with 500ms latency and 0.5 percent packet loss.
My WXC 1800s came licensed for a 2Mbps WAN link (up to 64,000 concurrent TCP flows); the system comes standard with two 10/100 Mbps Ethernet ports. A manual bypass switch on the front panel determines if the appliance fails open or fails to wire in the event of a hardware problem. Failing to wires is a nice safety feature for busy WANs.
Installing the pair of appliances took roughly an hour to complete. Part of the setup process entails defining one appliance, typically near the datacenter, as the registration server. The registration server keeps track of all other connected WXCs, including the subnets behind each appliance. This allows Juniper to handle a variety of network topologies, such as hub and spoke and fully meshed. Unlike the Riverbed Steelhead, which automatically sniffs out the other appliances, Juniper requires each appliance be explicitly pointed to the registration server. Juniper argues that this helps admins maintain control over traffic flows and allows for better traffic management.
Accelerate your brain
Overall, the WXC 1800 did a good job of accelerating my traffic over the WAN. CIFS traffic showed a decent performance increase in both "cold" (first pass) and "warm" (subsequent) runs. Juniper posted a cold time of 54 minutes, 21 seconds (a 4.5 times improvement) when copying many small files (641 files totaling 9MB ) over my long, dirty T1, with the warm pass only marginally better at 53 minutes, 29 seconds (a 4.6 times improvement). In comparison, Riverbed's latest release posted a cold time of 23 minutes, 49 seconds (a 10.4 times improvement) and warm pass of 19 minutes, 8 seconds (a 12.9 times improvement). The baseline nonoptimized times took nearly four hours to complete.
FTP traffic also saw a significant increase over nonoptimized, but still lagged Riverbed's quicker times. A single ISO image (155MB) took a little less than 48 minutes (a 3.3 times improvement) to transfer over the T1; warm passes took just more than three minutes (a 50 times improvement). Riverbed's times were 11 minutes cold (a 14.6 times improvement) and 30 seconds warm (a 320 times improvement). Nonoptimized times were more than two and a half hours.
Optimizing SSL traffic is very important in the enterprise, and the list of vendors capable of doing it is relatively short. Juniper's SSL support is slightly different from Riverbed's. Riverbed automatically passes the server-side SSL certificate from the datacenter appliance to the branch office appliance, requiring the certificate to be present on each in order to encrypt/decrypt the traffic (classic man-in-the-middle).
Juniper also requires the SSL certificate on the datacenter appliance, but not the branch side. Instead, as a client requests an SSL connection to the server, the datacenter WXC transparently intercepts the request, establishes the session key, and passes this information to the branch office WXC. The branch office appliance does not store the session key or any other SSL information on disk; it is only kept in volatile memory for the duration of the SSL conversation. From this point on, the appliance can "see" the SSL traffic and apply optimization techniques to it. This works with client-side SSL certificates, too, allowing users of two-factor authentication to participate in accelerated traffic. I really like the ease of setup and the additional security provided by client-side certificates.
Unlike the Riverbed Steelhead and the Cisco Wide Area Application Engine, Juniper's WXC 1800 can optimize SMB-signed traffic. SMB signing, which is on by default on Windows 2003 and 2008 domain controllers, places a digital signature into each SMB packet to secure network communications between Windows clients and servers. To accelerate this traffic, Juniper requires a valid domain user account on each appliance in order to negotiate a key to decrypt each packet. Once decrypted, each traffic flow is tested against established policy and any optimization techniques are applied. Now network admins no longer have to disable SMB signing in order to optimize Windows traffic.
Admins want to know just how much of their bandwidth they are getting back. The reporting support in WXC is solid with useful predefined reports, but for those who like to look at trends over more than a week's time, plan on exporting the collected statistics to another platform (the Traffic report is the only one that includes "all" as a time period). Creating a report, such as FTP compression over the past week, was straightforward and easy to read.
To really exploit the information collected by the WXC's, admins will want to deploy Juniper's CMS (Central Management Server). CMS allows for comprehensive trend analysis to help predict future bandwidth needs as well as more detailed reporting on appliances scattered across the WAN. It also provides a platform for IT to push out software upgrades and configuration changes across the WAN.
Even though it was a long time in coming, I am happy to have had a chance to evaluate the WXC 1800 from Juniper. Although the appliances didn't score fastest in my tests, they did provide a good overall acceleration of my test traffic and included features lacking in other devices. I like the SSL support and also the ability to optimize SMB-signed traffic; this will become more important as Microsoft evolves its server line. Reporting is good if not overly flashy, with the only shortcoming in long-term trend analysis.
Protocol support (25.0%)
Overall Score (100%)
|Juniper WXC 1800||8.0||9.0||9.0||8.0||9.0|
Having trouble installing and setting up Win10? You aren’t alone. Here are many of the most common...
Hot or not? From the web to the motherboard to the training ground, get the scoop on what's in and...
Confidence in our power over machines also makes us guilty of hoping to bend reality to our code
Microsoft says its new Azure cloud database is all types of databases in one. Here's why that might be...
Edge computing will not replace cloud computing, though the two approaches can complement each other ...
The Rust-like open source language tackles application development where asynchrony leads to...
The popular code repository is trying to be a one-stop shop for developers to get more of their work...