Home page logo

nanog logo nanog mailing list archives

Re: riverbed steelhead
From: James Michael Keller <jmkeller () houseofzen org>
Date: Mon, 25 Apr 2011 15:30:16 -0400

On 04/25/2011 01:55 PM, Andrey Khomyakov wrote:
I personally would take Riverbed over Cisco for one main reason that I have
discovered when I was researching them (that was good 3-4 years ago and
cisco may have "improved" since).

Yes, they have improved dramatically in the last few years since the 4.x release.

Cisco "accelerates" based on application. That is to say if it's not a well
known application protocol, they do not do anything with it.
So, they are probably good for HTTP/FTP/Samba etc.

Riverbed does not care for applications (they still support application
based acceleration, but they also support non standard stuff). They take
something along the lines of data hashes and store them (along with data of
course). They just store raw bytes as opposed to a let's say a file. That
played out well when I had to make a decision about which brand to purchase
for the company that had a homegrown application. So in a nutshell, Riverbed
improved performance of that application (as well as all the standard
players like HTTP/FTP etc), while cicso said outright that they won't.

The current gen of WAAS works this way as well. The accelerators are configurable for defined services along with a default profile. There are several accelerators that are applied to each connection, starting with the most basic TCP session optimization for window sizes and other per packet modifications.

It then applies raw data optimizations such as the raw 'bit' database you mentioned, each WAE will attempt to find the largest unique run of bits and create a hash for that sequence and store it in it's local database which decays based on time and hit count. If both WAE's in the path have this hash that is all that needs to be sent, otherwise it sends the entire payload, which will then be cached on the second WAE going forward for repeat occurrences (cache expiration not withstanding...). It can also do LZ compression on the full payload when it needs to send it.

After that there are application protocol accelerators for common protocols like CIFS, HTTP, etc. These work on the session level and act as transparent proxies for the protocols and can include file cache's on the WAE. For other protocols like MS Video live streams, it can turn a uni-cast session from multiple clients into a single session up to the video server instead of multiple connections from each client.

You also have the option with these to push server certificates and private keys into the WAAS system with the Central Manager, which allows transparent SSL/TLS acceleration for internal applications along with encrypted local storage on the WAEs.

As an example, we had a commercial patch deployment system that would bog down on patch days or large updates like services packs. After the WAEs went in it improved a bit but was still a huge tax on the network even with sites that had local deployment servers for this application. After digging through the application traffic it was actually deploying with an HTTP server running on a high port. So we defined a new protocol in the CM for this port (you can also include src/dst in the configuration to narrow matching if needed). Now after the first download at an office location, the follow on requests as folks come into the office and power up are all served from local cache on the WAE.

Now that's if you are running something it does have an application level accelerator for, if it's some other protocol you can either take the default or enable or disable some of the packet level optimizations. For example, if your traffic is encrypted - it would make sense to disable the LZ and bit database processing and just leave the TCP session optimization enabled, since the processing time to do the compression will actually take longer then just transferring the original payload and also may be causing the packet to fragment and double the number of packets required, etc.

After purchase, we saw a dramatic improvement in "user experience"
(basically the complaints stopped) from our EU site that was accessing
windows (samba) based file servers in USA. Those guys at the time were
connected to the US office over MLPPP (4 T1s). Samba sucked for them along
with everything else.

Yes, deployment of most WAN accelerators that will do file caching will if not gain love from your users, it at least gets them off your back.


The only issue I had with Riverbed is their licensing model feels very
backwards. It took me a while to understand what we needed.


On Thu, Apr 21, 2011 at 10:36 PM, Jonathan Fernatt<fernattj () gmail com>wrote:

On Thu, Apr 21, 2011 at 2:49 PM, harbor235<harbor235 () gmail com>  wrote:

Anyone out there have experience with Riverbed Steelhead products?
Do they improve TCP performance over WAN links? is it worth the price?


I've had good experiences with both Riverbed Steelhead and Cisco WAAS
products. Both have a very short ROI. I think either are well worth the


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]