Riverbed RiOS Eases WAN-traffic Taming
With the economy slowing down and IT budgets getting tighter, trying to sell your boss on some new network equipment might defy conventional wisdom. But if the equipment helps reduce time wasted when working over a WAN, or better yet, improves overall WAN usage and user productivity, it might not be as difficult a sale as you thought.
Now in its fifth release, Riverbed Technologies RiOS WAN acceleration operating system adds some new features to an already impressive list of services and also includes better centralized management through the Central Management Console (CMC). New to RiOS 5 is native Exchange 2007 support, easier HTTPS configuration, and a better QoS engine. Overall WAN performance is on par or better than in previous releases, with CIFS (common Internet file system) traffic showing a modest increase and FTP cold pass improving significantly.
As with my previous reviews, my WAN test bed comprised a Shunra VE simulating my various WAN circuits, a client PC running Windows XP Pro and MJT Net Macro Scheduler, and a Windows 2003 Small Business Server. This time around, I added a second desktop running Windows Vista Business Edition and Office 2007, and another server running Windows Server 2003 R2 with Exchange 2007. As before, WAN speeds tested were 128kbps with 40ms latency and T1 (1.54Mbps) with 500ms latency and 0.5 percent packet loss.
Riverbed provided me with three WAN acceleration appliances (models 520, 1020, and 1520). The 520 and 1020 installed in front of a "branch" office with the 1520 accelerating traffic to and from the datacenter. The Centralized Management Console allowed me to monitor all three Steelheads, collate performance reports, and push out software updates. All four 1U appliances were easy to install and get online in a test configuration with the entire setup taking less than two hours to complete.
Test results nearly mirrored RiOS 4 results except for an increase in first pass FTP performance. Previously, a 155MB ISO in the T1 test took nearly 31 minutes to transfer. Now, first-pass times are in the nine-minute range. Subsequent passes are right in line with previous results (averaging slightly more than one minute).
If It Isn't Broken...
This release of RiOS refines an already stable and well rounded offering, adding and tweaking instead of ripping and replacing. One of the items that falls into the "tweaked" category is secure Web traffic (HTTPS). It is now easier to configure Steelheads to optimize SSL traffic than it was with RiOS 4.
Previously, admins had to manually establish a trust between appliances by copying certificates between Steelheads. Now, when a Steelhead tries to optimize HTTPS between an acceleration pair, the remote Steelhead will automatically send its certificate to the other Steelhead, which in turn gray-lists the appliance. An admin then either accepts or rejects the gray-listed appliance. If the appliance is rejected (blacklisted), it will not be able to optimize SSL traffic but will instead simply pass it on over the WAN un-optimized. By creating this automated certificate facility, SSL configuration is much easier and less prone to error while allowing IT to maintain control over how and when HTTPS traffic is optimized.
Standard HTTP traffic also received a performance upgrade in RiOS 5. RiOS 4's HTTP optimization worked well with static Web content but didn't provide much help with dynamic. RiOS 5's HTTP engine now includes two new features specifically tailored to dynamic Web pages; Parse & Pre-fetch and Metadata Response. Parse & Pre-fetch parses the HTML page, downloads the objects, and stores them on the client side Steelhead for faster access. Metadata Response is useful when cache-control headers are involved. For example, if the browser sends out an "if modified since" request, the client-side Steelhead can respond to it locally, thus reducing the round trip across the WAN.
Another unique feature to RiOS 5 is its capability of accelerating native Exchange 2007 traffic. I tested this feature with a Windows Vista client and Office 2007 saving an attachment from the Exchange message store locally. I also copied the attachment to a file share across the WAN and saw the file served out of the local cache, reducing overall transfer time.
New to RiOS 5 is a better QoS engine. Now admins can not only employ rate limiting between sites, but they can also assign a priority to traffic that passes through. For example, admins can define 2Mbps of traffic from datacenter to remote office A and 3Mbps of traffic from datacenter to remote office B. Within each link, admins can then prioritize specific traffic types, such as HTTPS and CIFS. Each link is unique and can have its own traffic prioritization policy.
Available since RiOS 4, MX-TCP's capability of nearly eliminating TCP's slow start after packet loss directly benefits from the new QoS engine. MX-TCP is so aggressive that in some situations, it can consume all available bandwidth, thus "starving" other traffic. The QoS engine works perfectly in this situation, preventing one traffic flow from filling the pipe and obstructing another flow.
I Can See Clearly Now...
One knock against many WAN optimization appliances is they tunnel or repackage the TCP/IP packets between appliances blinding WAN-monitoring tools. Riverbed has provided export to NetFlow for a while now for WAN monitoring, but RiOS 5, in addition to RiOS's native transport, includes two additional modes of operation: Port Transparency and Full Transparency.
With Port Transparency, as in native mode, each Steelhead will still use its respective IP addresses as the source and destination addresses for each packet but will keep the original destination TCP/IP port. In Full Transparency mode, the Steelheads leave both the original source and destination IP addresses the same as the destination port. Riverbed recommends that admins use the native tunneling between Steelheads unless the network is very complex or IP address accounting is required. Full Transparency may also require router changes and has been known to cause issues with stateful inspection firewalls.
One feature that I know network admins will really appreciate is that the Steelhead appliance no longer loses network connection on a restart of the core services. This means that when a policy change or other modification is made to a Steelhead and IT restarts the services, network traffic is no longer disrupted. I tested this feature by doing a continuous ping across the WAN while restarting the services, and not once did I drop a packet.
Management for All
Riverbed's CMC is a great tool for monitoring and managing multiple Steelhead appliances. One of the better features is the "touchless configuration." Admins can deploy a Steelhead to a remote office and once installed, have it "phone home" to download its optimization policy. A CMC can also fetch configurations from other Steelheads and push them out to help eliminate any "fat finger" errors.
During my evaluation, I updated the images on all three Steelheads from my CMC with a single mouse click. The CMC had the latest image pre-staged on it and I simply chose the Steelheads I wanted to update and clicked OK. This step couldn't have been any easier.
Another reason to consider a CMC: It will collate all of the reports from each Steelhead it manages and store the information for as long as one year. A typical Steelhead can only keep about 30 days' worth locally. So if longer trending and analysis is required, the CMC is the best way to go. Out of the box, a single CMC can manage as many as 10 Steelheads.
With all of the bells and whistles available in RiOS 4, I wondered how Riverbed could build (yet another) better mousetrap. The new QoS and Exchange 2007 engines are welcome additions, and the improved HTTP support for dynamic content is terrific. The almost automated HTTPS certificate sharing makes configuration of secure traffic acceleration even easier. Are there any negatives? Well, it still won't unpack itself.