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 <
jmkel...@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<ferna...@gmail.com
>> >wrote:
>>
>> On Thu, Apr 21, 2011 at 2:49 PM, harbor235<harbor...@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
>>>
>>>
>>
>>
>
>
