Re: riverbed steelhead

[Eric Cables <ecables () gmail com>]

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