Lab test: Riverbed Steelhead hones its edge
The world's best WAN accelerator turns performance and manageability up a notch in version 5.0
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.