Cisco WAAS benchmarks, and WAN optimizers in general

Lately I’ve been dealing with WAN accelerators a lot, with the emphasis on Cisco’s WAAS (some other, smaller players are Riverbed, Juniper, Bluecoat, Tacit/Packeteer and Silverpeak). The premise is simple and compelling: Instead of having all those servers at your edge locations, move your users’ data to the core and make accessing the data feel almost as fast as having it locally, by deploying appliances that act as proxies. At the same time, you will actually decrease the WAN utilization, enabling you to use cheaper pipes, or at least not have to upgrade, where in the past you were planning to anyway.

There are significant other benefits (massive MAPI acceleration, HTTP, ftp, and indeed any TCP-based application will be optimized). Many Microsoft protocols are especially chatty, and the WAN accelerators pretty much remove the chattiness, optimize the TCP connection (automatically resizing Send/Receive windows based on latency, for instance), LZ-compress the data, and to top it all will not transfer data blocks that have already been transferred.

At this point I need to point out that there is a lot of similarity with deduplication technologies – for example, Cisco’s DRE (Data Redundancy Elimination) is, at heart, a dedup algorithm not unlike Avamar’s or Data Domain’s. So, if a Powerpoint file has gone through the DRE cache already, and someone modifies the file and sends it over the WAN again, only the modified parts will really go through. It really works and it’s really fast (and I’m about the most jaded technophile you’re likely to meet).

The reason I’m not opposed to this use of dedup (see previous posts) is that the datasets are kept at a reasonable size. For instance, at the edge you’re typically talking about under 200GB of cache, not several TB. Doing the hash calculations is not as time-consuming with a smaller dataset and, indeed, it’s set up so that the hashes are kept in-memory. You see, the whole point of this appliance is to reduce latency, not increase it with unnecessary calculations. Compare this to the multi-TB deals of the “proper” dedup solutions used for backups…

Indeed, why the hell would you need dedup-based backup solutions if you deploy a WAN accelerator? Chances are there won’t be anything at the edge sites to back up, so the whole argument behind dedup-based backups for remote sites sort of evaporates. Dedup now only makes sense in VTLs, just so you can store a bit more.

On Dedup VTLs: Refreshingly, Quantum doesn’t quote crazy compression ratios – I’ve seen figures of about 9:1 as an average, which is still pretty good (and totally dependent on what kind of data you have). I just cringe when I see the 100:1, 1000:1 or whatever insanity Data Domain typically states. I’m still worried about the effect on restore times, but I digress. See previous posts.

Anyway, back to WAN accelerators. So how do these boxes work? All fairly similarly. Cisco’s, for instance, does 3 main kinds of optimizations: TFO, DRE and LZ. TFO means TCP Flow Optimizations, and takes care of snd/rcv window scaling, enables large initial windows, enables SACK and BIC TCP (the latter 2 help with packet loss).

DRE is the dedup part of the equation, as mentioned before.

LZ is simply LZ compression of data, in addition to everything else mentioned above.

Other vendors may call their features something else, but at the end there aren’t too many ways to do this. It all boils down to:

  1. Who has the best implementation speed-wise
  2. Who is the best administration-wise
  3. Who is the most stable in an enterprise setting
  4. What company has the highest chance of staying alive (like it or not, Cisco destroys the other players here)
  5. What company is committed to the product the most
  6. As a corollary to #5, what company does the most R&D for the product

Since Cisco is, by far, the largest company of any that provide WAN accelerators (indeed, they probably spend more on light bulbs per year than the net worth of the other companies provided), in my opinion they’re the obvious force to be reckoned with, not someone like Riverbed (as cool as Riverbed is, they’re too small, and will either fizzle out or get bought – though Cisco didn’t buy them, which is food for thought. If Riverbed is so great, why would Cisco simply not acquire them?)

Case in point: When Cisco bought Actona (which is the progenitor of the current WAAS product) they only really had the Windows file-caching part shipping (WAFS). It was great for CIFS but not much else. Back then, they were actually lagging compared to the other players when it came to complete application acceleration. Fast forward a mere few months: They now accelerate anything going over TCP, their WAFS portion is still there but it’s even better and more transparent, the product works with WCCP and inline cards (making deployment at the low-end easy) and is now significantly faster than the competitors. Helps to have deep pockets.

For an enterprise, here are the main benefits of going with Cisco the way I see them:

  1. Your switches and routers are probably already Cisco so you have a relationship.
  2. WAAS interfaces seamlessly with the other Cisco gear.
  3. The best way to interface a WAN accelerator is WCCP. And it was actually developed by Cisco.
  4. The Cisco appliances are tunnel-less and totally transparent (I met someone that had Riverbed everywhere – a software glitch rendered ALL WAN traffic inoperable, instead of having it go through unaccelerated which is the way it is supposed to work. He’s now looking at Cisco).
  5. WAAS appliances don’t mess with QoS you may have already set.
  6. The WAAS boxes are actually faster in almost anything compared to the competition.

And now for the inevitable benchmarks:

Depending on the latency, you can get more or less of a speed-up. For a comprehensive test see this: http://www.cisco.com/application/pdf/en/us/guest/products/ps6870/c1031/cdccont_0900aecd8054f827.pdf

Another, longer rev: http://www.cisco.com/web/CA/channels/pdf/Miercom-on-Cisco-WAAS-Riverbed-Juniper-competitive.pdf

Yes, this is on Cisco’s website but it’s kinda hard to find any performance statistics on the other players’ sites showing Cisco’s WAAS (any references to WAFS are for an obsolete product). At least this one compares truly recent codebases of Cisco, Riverbed and Juniper. For me, the most telling numbers were the ones showing how much traffic the server at the datacenter actually sees. Cisco was almost 100x better than the competition – where the other products passed several Mbits through to the server, Cisco only needed to pass 50Kbits or so.

It is kinda weird that the other vendors don’t have any public-facing benchmarks like this, don’t you think?

However, since I tend to not completely believe vendor-sponsored benchmark numbers as much as I may like the vendor in question, I ran my own.

I used NISTnet (a free WAN simulator, http://www-x.antd.nist.gov/nistnet/) to emulate latency and throughput indicative of standard telco links (i.e. a T1). The fact that the simulator is freely available and can be used by anyone is compelling since it allows testing without disrupting production networks (for the record, I also tested on a few production networks with similar results, though the latency was lower than with the simulator).

The first test scenario is that of the typical T1 connection (approx. 1.5Mbits/s or 170KB/s at best) and 40ms of round-trip delay. I tested with zero packet loss, which is not totally realistic but it makes the benchmarks even more compelling. Usually there is a little packet loss, which makes transfer speeds even worse. This is one of the most common connections to remote sites one will encounter in production environments.

The second scenario is that of a bigger pipe (3Mbit) but much higher latency (300ms), emulating a long-distance link such as a remote site in Asia over which developers do their work. I injected a 0.2% packet loss (a small number, given the distance).

It is important to note that, in the interests of simplicity and expediency, these tests are not comprehensive. A comprehensive WAAS test consists of:

  • Performance without WAAS but with latency
  • Performance with WAAS but data not already in cache (cold cache hits). Such a test shows the real-time efficiency of the TFO, DRE and LZ algorithms.
  • Performance with the data already in the cache (hot cache hits).
  • Performance with pre-positioning of fileserver data. This would be the fastest a WAAS solution would perform, almost like a local fileserver.
  • Performance without WAAS and without latency (local server). This would be the absolute fastest performance in general.

The one cold cache test I performed involved downloading a large ISO file (400MB) using HTTP over the simulated T1 link. The performance ranged from 1.5-1.8MB/s (a full 10 times faster than without WAAS) for a cold cache hit. After the file was transferred (and was therefore in cache) the performance went to 2.5MB/s. The amazing performance might have been due to a highly compressible ISO image but, nevertheless, is quite impressive. The ISO was a full Windows 2000 install CD with SP4 slipstreamed – a realistic test with realistic data, since one might conceivably want to distribute such CD images over a WAN. Frankly this went through so quickly that I keep thinking I did something wrong.

T1 results
ftp without WAAS:
ftp: 3367936 bytes received in 19.53Seconds 168.40Kbytes/sec

Very normal T1 behavior with the simulator (for a good-quality T1).

ftp with WAAS:
ftp: 3367936 bytes received in 1.34Seconds 2505.90Kbytes/sec (15x improvement ).

Sending data was even faster:
ftp: 3367936 bytes sent in 0.36Seconds 9381.44Kbytes/sec.

waasT1

 

High Latency/High Bandwidth results

The high latency (300ms) link, even though it had double the theoretical throughput of the T1 link, suffers significantly:

ftp without WAAS
ftp: 3367936 bytes received in 125.73Seconds 26.79Kbytes/sec.

I was surprised at how much the high latency hurt the ftp transfers. I ran the test several times with similar results.

ftp with WAAS
ftp: 3367936 bytes received in 2.16Seconds 1562.12Kbytes/sec. (58x improvement ).

waaslat

 

I have more results with office-type apps but they will make for too big of a blog entry, not that this isn’t big. In any case, the thing works as advertised. I need to build a test Exchange server so I can see how much stuff like attachments are accelerated. Watch this space. Oh, and there’s another set of results at http://www.gotitsolutions.org/2007/05/18/cisco-waas-performance-benchmarks.html

Comments? Complaints? You know what to do.

D

18 Replies to “Cisco WAAS benchmarks, and WAN optimizers in general”

  1. Although my opinion is not very objective as I am an employee at Riverbed, your points about the benefits of Cisco over the competition are flawed.

    My responses below:

    1. “Your switches and routers are probably already Cisco so you have a relationship.”

    Having “one throat to choke” has some merit, but when it comes to choosing a WAN optimizationn vendor, other factors like best of breed product are viewed as more important.

    2. “WAAS interfaces seamlessly with the other Cisco gear.”

    Riverbed has over 2500 customers, most of them with Cisco infrastructure. Riverbed’s Steelhead appliance installs seamlessly in the most complex Cisco environments. Riverbed has hundreds of referenceable customers to prove it.

    3. “The best way to interface a WAN accelerator is WCCP. And it was actually developed by Cisco.”

    While WCCP is a deployment option, over 90% of Riverbed customers have deployed in-path, which has proven to be the fastest and easiest method of deployment.

    Also, WCCP is a standard protocol and is not controlled or owned by Cisco. Many network equipment vendors utilize WCCP.

    4. “The Cisco appliances are tunnel-less and totally transparent (I met someone that had Riverbed everywhere – a software glitch rendered ALL WAN traffic inoperable, instead of having it go through unaccelerated which is the way it is supposed to work. He’s now looking at Cisco).”

    Riverbed Steelhead appliances do not use tunnels, but the approach is different from Cisco’s. Over 2500 customers are running fine with Riverbed’s architectural approach.

    5. “WAAS appliances don’t mess with QoS you may have already set.”

    Riverbed works seamlessly with existing QoS infrastructures. Check out the Riverbed-sponsored online user community at http://www.wdsforum.org to discuss experiences with Riverbed customers.

    6. “The WAAS boxes are actually faster in almost anything compared to the competition.”

    This is not true. Riverbed is recognized by many as the fastest performer across the key applications. Check out the recent Network World shootout where Riverbed crushes Cisco and the rest of the WAN optimization pack.

    The Miercom results do not represent real customer workloads or environments.

    Regards,

    Bob Gilbert

  2. I’d re-iterate Bob’s comments, especially that “WAAS are actually faster”, this is a surprising comment. Considering the vast majority of the material on the net shows Riverbed in front of every other vendor. As someone who has benchmarked both WAAS & Riverbed in a lab on the latest and greatest from either vendor as of September 2007, Riverbed is leagues ahead:

    It took almost 5 hours to build a WAAS lab setup – this is based upon no initial knowledge of WCCP and not having used the product before.
    It took 15 minutes to build the Riverbed lab – this is based upon no initial knowledge of Riverbed and not having used the product before.

    Here’s a small set of the tests I ran:
    Acceleration results across a 128Kb/s with 10ms latency:
    Open 5.4Mb Excel doc across link from within Excel (not just file copy but open file as well)
    WAAS Riverbed

    Benchmark 580 secs 580 secs
    Cold 81 secs 75 secs
    Warm 39 secs 8

    5.4Mb Excel above is a working document with likely repeated patterns throughout.

    Test Example 2
    Remotely browse C:\winnt\system32, time taken to list folder contents
    WAAS Riverbed
    Benchmark 20 20
    Cold 12 8
    Warm 5 1

    FTP 9.2Mb Divx File (Transformers promo) across link
    WAAS Riverbed
    Benchmark 710 710
    Cold 89 37
    Warm 11.2 1.4

    Some other notes:
    * It took 2 reboots of each Cisco WAE to get them out of an error state. I had to follow a 22 page doc from Cisco just to get the setup to a basic level. Then the WAE came back when I re-applied the default policy saying that their roles had changed and I had to reboot them again…
    * This is not a dig at Cisco, their product has huge advantages over a WAN without WAAS. From my results Riverbed is a clear leader, especially in a large rollout, you simply ship the boxes from the manufacturer to your 100’s of remotes offices, get the local staff to plug it in and the box configures itself completely (from the box DHCP’ing itself, then looks up a standard Riverbed DNS hostname to find the central config server and configures itself, upgrades firmware etc).
    * Documentation and support for Riverbed is very consistent and clear. The interface on the Riverbed is easy to use and follow. I’m still trying to work out how to clear the DRE cache on the Cisco’s 48 hours later so I can rerun tests… I’ve been digging through Cisco.com for hours.
    * WAAS are IBM servers, Riverbed’s are Dell servers. My experience sides with IBM for better build quality & reliability.
    * I managed to break the Riverbed acceleration on the small link above by running 3 tests in parallel which meant the file-lock messages couldn’t get across the link, changing the port for the file locks and QoS’ing it stopped this happening.
    * See which other large companies have bought, in my research, this showed most large financials bought the same vendor. I’m not going to name them, but you can easily guess. Following the herd is definitely a safe & proven path to follow.
    * My advice is, don’t believe what you read about one sided reports, ask for reports of people who’ve tried both and run your own tests with the leading vendors yourself. There’s definitely a huge gap between certain vendors.

    Think about how much effort you’ll need to implement maintain WAN acceleration, this should probably be number 1 on your priority list. I see at the moment the WAAS being a huge sucker for resources, when it might be cheaper to simply throw more bandwidth at it than hiring more resources. How easily can you turn off acceleration for a particular host in Riverbed/Cisco? Riverbed in a few seconds, Cisco? write an ACL for each site that’s affected, which may amount to several hundred VLANs, and several hundred lines of code… across lots and lots of sites… good luck.

    One more item of food for thought:
    * Riverbed developed their product
    * Cisco bought their product. It may be badged Cisco, and have a slightly IOS’ish CLI, it’s not Cisco (I guess like a lot of their other products), so has many years before it’s really mature like their switching & routing platforms.
    * Cisco sell their product as being more scalable, I’ve not been able to ramp up my testing to this sort of level so can’t comment. My thought is how many commercial companies on this planet have a datacentre MPLS/WAN link that requires gig’s of performance?? 100Mb maybe a little more, but Gigs?? I’m talking gig’s into a cloud, not highspeed metro-links where WAN acceleration shouldn’t be used.

    Regards

    Adam

  3. I’ve been having a conversation with Adam off-line but here are some salient points:

    1. Cisco didn’t provide him with enough documentation. There is a wonderful test guide that Cisco has, be sure to ask for it if you’re going to be testing WAAS. It’s a step-by-step guide, easy to follow, and probably all you’ll ever need (it’s also a mini-manual).

    2. Inline works fantastically on the Cisco boxes. If one wants the same kind of simplicity as Riverbed, just deploy inline. Performance is great. WCCP is fine if you know how to use it and/or you want to use more than 2 boxes at the core (inline “spillover” clustering stops at 2 boxes, WCCP can do 32). WCCP also has some strict requirements Re IOS versions in order to work well.

    3. WAAS boxes come from the factory optimized for a T1 with about 80ms of latency. Adam has been testing on 128Kbit links. It’s important to change the default config to reflect the true operating conditions. I’d like to see Cisco auto-configure all this, maybe it will come soon.

    4. Make sure you are up-to-date with WAAS code. It’s 4.0.13 as of this writing, but Cisco is updating it VERY quickly (which may cause concern for some). There have been 5 releases at the very least since the the boxes became public last year. Cisco are responding to criticisms at a rapid pace, 4.0.13 already has better reporting than before (Cisco were lambasted about this).

    5. Whether we like it or not, Cisco gear is typically aimed at the higher end of the marketplace. The smallest WAAS that’s stand-alone is the 512, and it’s more money than the smallest Riverbed (but it’s also more capable). I’ve worked for companies that had MULTIPLE gig links to the outside world. Not many out there, but they exist and can make use of high scalability. Cisco actually has options (ACE) that can enable thousands of core WAAS boxes to be clustered. 16K WAAS boxes, 4M concurrent TCP connections, 16Gbps throughput. Can’t think of anyone ever needing ALL that but it’s there…

    D

  4. “5. Whether we like it or not, Cisco gear is typically aimed at the higher end of the marketplace.”

    Cisco WAAS has a stated hard limit of 50 peers. It will not support more than 9 peer sites in a full mesh environment. How can that target the higher end of the marketplace? Additionally, the storage method that Cisco uses segments the disk cache by peer, so available cache decreases by the nth peer. These are contrasted by Riverbed’s architecture, which we found to be more sound.

    As far as the transparency you mention above, it only works with Cisco firewalls. Other vendors need to disable stateful protection which is less secure.

  5. Jeff,

    The 50 peers are guidelines PER box at the core (7326, the smaller boxes have less, the bigger, newer boxes, more, but let’s stay with the number you provided). With 4 core boxes, you can have 200 peers, and so on, up to 32 core boxes with WCCP (1,600 peers) or 16,000 core boxes with ACE for 800,000 peers. Maybe that’s still not enough? If it’s not enough, I’d very much like to sell to the organization that has such needs 🙂

    What do you mean by “full mesh”? Who would need this? Please support your argument.

    When you centralize your servers, per box you can serve 50 peers.

    Each edge site does not need to talk to other edge sites as a peer for CIFS, the idea is that you’re going to the core.

    The segmentation of the cache is a mixed blessing and I have mixed feelings about it – it’s probably the thing that irks me most. Again, it’s geared more towards one having plenty of core boxes and sizing the core so that the relationships make sense. If you have, for whatever reason, 7326 units at 4 edge sites (maybe the sites are large), you better make damn sure you have 4 7326 core boxes for max performance!

    Typically, that’s not the case, most edge sites will either be the network modules that slot in the routers or the WAE-512 or 612, that have much less capacity.

    Re transparency: WAAS is really geared towards all-Cisco shops. That’s where I’ve seen it work best. There are many such shops anyway, so it’s not like there’s a dearth of potential WAAS customers…

    If you have mixed gear, you can get excellent results from Riverbed, Juniper, Expand etc.

    Your mileage may vary. Which is why I insist that anyone that wants to try the WAN optimizers does a pilot for all the solutions and picks whichever works best, functionally, fiscally and, dare I say it, politically.

    D

  6. Riverbed limits concurrent session and optimized speed. For instance 520 is 300 sessions and 1Mbps. Does Cisco WAAS has such limit? Sorry, I am helping my company to choose the right gear.

  7. Cisco has guidelines (they provide a spreadsheet with macros that will calculate what you need and also show you limits). It’s a function of memory and CPU speed. Mostly RAM.

    For instance, a 512 can do about 8Mbits and 750 connections with 1GB, but 20Mbits and 1500 connections with 2GB.

    At the opposite end of the spectrum, a 7371 can go full gigabit and do 50,000 connections. Since one can cluster up to 32 boxes with WCCP, the solution scales.

  8. Yeah, in our experience, Riverbed wins if there is a bake off and the customer understands the long term value of a solution that can address all users, including mobile workers and traveling execs. Cisco is selling on price and tries to fix customer’s pain point rather than addressing the long term needs of the business. It’s the first time I have ever seen Cisco sell on price and not technology. I agree with Dimitris, test multiple vendors in your production environment. This will ensure you choose the right vendor for your network.

    Justin Lofton
    Systems Engineer
    justinl@tredent.com
    Tredent Data Systems, Inc.
    WAN Optimization

  9. 1) Can someone explain how Riverbed do not tunnel ? My understanding is that they change the source and destination IP addresses and by default tunnel everything using port 7800. Looks like a tunnel to me. I don’t understand the claims they are the most transparent !

    2) In my opinion inline does not scale for a large enterprise data centre. Fine for a branch office. WCCP provides much more flexibility and scaleability. However as WCCP is owned by Cisco what is going to happen when they bring out WCCP v3 ? Other vendors already can’t support certain features of version 2.

    3) I hear Juniper will be 100% transparent next year and will operate in both tunnel and transparent mode. Anyone else heard this ?

  10. It is interesting how each partner is biased one way or another. I have a report I can share that shows the newer WAAS code and models UTTERLY wiping the floor with Riverbed’s BIGGEST box. So what report is right? They were all done in a lab.

    The new 4.0.15 WAAS code is even faster than before and Cisco is adding improvements at a rate that’s faster than Riverbed’s.

    And beware of bakeoffs: They’re next to impossible to do right unless you’re willing to PROPERLY AND FULLY implement each solution in your environments. You can never know how the products scale if you don’t, despite vendor claims.

    Testing a couple of sites will almost always show products from ANYONE in a positive light – after all, they all pretty much work. But a limited test may mask future scalability issues.

    It’s more about who you want to align yourselves with than anything else.

    And if you have a substantial Cisco investment (like most), and especially if you’re using Cisco firewalls and VoIP, then it just makes sense to get more Cisco and avoid the fingerpointing in case of problems. The WAAS stuff works.

    It’s funny how certain vendors will focus on something small and blow it out of proportion. “our product was 3.8% faster than WAAS!”, “our product takes 5 minutes less to install than WAAS!”, “our graphs are nicer than Riverbed’s!” etc.

    Whoop-dee-doody.

    It’s also funny how Riverbed never mentions how their stuff actually causes HIGHER server and network utilization than not using anything at all! (it’s also the reason it’s faster in some benchmarks). At least WAAS seriously helps with server load and WAN traffic reduction. Which I thought were pretty important points 🙂

    D

  11. Hi

    Really interresting discussion. Does anyone have any measurements on how much WAN bandwith you can gain? Is it possible to “downsize” existing WAN capacity when implementin WAAS?

    /M

  12. To laughingboy:

    Ad.1: Riverbed does not tunnel, but proxies every single connection, so you have the correct SYN packets going over the WAN, to allow your access lists etc to be handled by any router between the two accelerators. After the first SYN – SYN/ACK you are (were) right, all traffic defaults to be sent to destination port 7800. Since Riverbed released v.5 recently, you have the option of transparency.

    Ad.2: Cisco does not “own” WCCP. There are already subsets of WCCPv2 that may or may not be implemented in different Cisco products or IOS versions, specifically regarding GRE/L2 forwarding or the “mask-based” WCCP variant, i don’t think WAAS competitors will have to do much coding to work with a V3 implementation, as WCCP is a well documented protocol.

    To Dimitris regarding post 11: Yes, it’s funny to see the occasional higher number of bytes transferred when using Riverbed, since it does subdirectory crawling etc., but the result in the remote office is highly beneficial.

    Also, the fact that you don’t see reduction in the server traffic volume when using Riverbed is completely by design, since Riverbed is not a caching device, they will always get the complete data stream from the client to the server. If Cisco doesn’t do that, it sort of invalidates their claim of complete transparency, doesn’t it?

    Disclaimer: I work for a company that sells Riverbed, among other things.

  13. Dimitris,

    Nobody wants to manage 32 WAAS boxes let alone 16000. Since WAAS doesn’t properly understand how to sync configs across a WAAS WCCP cluster, customers of Cisco will be spending their weekends managing any cluster.

    Also, using WCCP is a valid option for Cisco customers that have the newer Cisco routers and have an onsite Cisco SE. Otherwise, we all know that in most cases WCCP is neither easy nor scalable for even medium deployments.

    WCCP is an unfortunate burden on any organization where core router management is important. Most core router admins let me know that WCCP will never run on their routers.

    Good luck to anyone who deploys Cisco WAAS or to anyone who believes that the high management opex of WAAS is trivial.

    Dark Horse

  14. Dimitris,

    I forgot to mention the absurdity of using three or four completely different Cisco products with different CLIs and UIs to try to deploy WAAS with any scale. WAAS and ACE are two completely different products from two different acquisitions. They are managed completely diffent. Even the ACE product has two different products inside of it (ACE and AVS) with two different UIs. To implement WCCP, you will need to make sure that you configure it properly on the Cisco router (different product and UI). If you decide to try to scale using the ISR, you can add a different product to the mix with a different UI yet again.

    Cisco may be one company, but the products are from very different companies. Their integration is worse than if you bought the best of breed products from different companies. Cisco products are “Islands of Disfunctionality”

    Dark Horse

  15. Mr. Dark Horse,

    You may be missing the point. It’s all a pissing match. In the situations where WCCP is NEEDED, then ALL WAN accelerators WILL NEED WCCP!

    In addition, I’ve set up several WCCP clusters and things seemed to work OK, maybe you can tell us what to look for and how to fix it?

    You can get away with doing PBR and of course WAAS (and all other accelerators) also do PBR.

    Or you can do inline (with limitations that exist no matter the WAN accelerator vendor) and not worry about things if your environment is simple enough.

    I’m just trying to illustrate that all the major acceleration vendors do things similarly, nobody FORCES you to do WCCP, but if the situation warrants it the support is there.

    Cisco has multiple technologies because they’re huge. EMC, IBM, Sun, HP are the same way.

    Juniper bought their WXCs from another company.

    F5 the same.

    Riverbed makes ONE product, effectively.

    Silverpeak, bluecoat and a few other smaller ones are similar to riverbed, the companies are tiny and make only one product.

    It’s insane to compare the tiny companies to the multi-billion dollar ones that cater to all kinds of interests.

    And yes, quite often those products came from different companies and will have a different codebase, look, feel etc. At the end of the day though you’re still buying from Cisco etc. and not some mom-and-pop shop. It’s a double-edged sword either way.

    D

  16. Hi Dimitris,

    In the Miercom document, there is an comparative of the WXC 250, which by default has the 128 Kbps WAN limit. On the other hand, NISTnet was set to simulate an T1/1.544 Mbps WAN. Do you know if they used the 2 Mbps upgrade for the testings?

    Best Regards,

    Igor Sotelo.

  17. Cisco is a very well established brand and they should demand rights to their intellectual property.

    This device was so useful and well-appreciated to people.Cisco is a huge company and their products carry a much larger impact than all of the apple products combined.

Leave a comment for posterity...