Home page logo
/

nanog logo nanog mailing list archives

Re: riverbed steelhead
From: Eric Cables <ecables () gmail com>
Date: Mon, 25 Apr 2011 13:48:34 -0700

Some other considerations for Cisco vs. Riverbed are:

Unified vs. Partitioned Data Store:
Riverbed's data store is unified across all connected appliances, whereas
Cisco partitions its data store across each connected appliance.  This means
that a data pattern seen once on Riverbed will be "warm" for subsequent
transfers regardless of the destination office, whereas Cisco will need to
perform a cold transfer for each branch, to populate the respective
partition.

FIFO vs. LRU:
Cisco's data store expires patterns using FIFO, whereas Riverbed defaults to
LRU (Least Recently Used).  I prefer LRU since it means that commonly
accessed data won't arbitrarily be deleted.

Encrypted MAPI support:
Riverbed supports it, and Cisco does not ("it's coming").

Central Manager:
Cisco requires a central manager, whereas Riverbed does not.  Riverbed does
have a Central Management Console, but when the environment is <10
Steelheads, it's really not all that relevant.

On-box Reporting:
Cisco's on-box reporting is pretty terrible, whereas the Steelhead interface
provides a lot of easy to gather statistics & connection information.
 Cisco's response to this was to invest in a NetFlow tool for visibility,
which most environments have, but sometimes running a quick report on the
box is easier, and this can add to the overall project cost if a commercial
product is used.

I'm sure there are more pros to Riverbed, but this is what I could think of
off the top of my head.

One thing I will mention is that Riverbed's v-Steelhead product, which is
their virtual Steelhead offering, may pair very nicely with Cisco's SRE "UCS
Express" offering for a single box solution.

-- Eric Cables


On Mon, Apr 25, 2011 at 12:30 PM, James Michael Keller <
jmkeller () houseofzen org> wrote:

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.

-James


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

Andrey

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?


mike

 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
price.

Jon








  By Date           By Thread  

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