The Riverbed Blog (testing)

A blog in search of a tagline

Eating our own dogfood, part 3

Posted by riverbedtest on November 5, 2009

"Cisco has approximately 300 global offices that have less than 45Mbps bandwidth.  Cisco partner IBM will deploy Cisco WAAS in these offices during the remainder of 2008 and part of fiscal year 2009. Configuring the WAN gateway at each office to intercept certain requests and forward them to the Cisco WAE will take only a few minutes…"

— from Cisco IT Deployment in Progress, Wide Area Application Services document (dated 2008)

Several months ago I posted my first dogfood blog (  In response to that blog, Cisco has been evasive and unclear about whether or not they really use WAAS internally, all while promising that an internal WAAS rollout will be taking place in the future (see also Feng Meng's WAN Optimization and Application Acceleration Case Study blog, dated June 2009).

Now that more than four months have passed, I think it's time to revisit the question again.  My contacts within Cisco IT continue to indicate there is still no signficant WAAS deployment in their production network. Why has Cisco still not executed a world-wide deployment of WAAS in their own network?  Why won't they eat their own dogfood?  Cisco certainly has had more than enough time to complete a worldwide rollout (each WAAS device takes only a few minutes to configure, right?).  Furthermore, Cisco has sold the WAAS product for more than five years at this point, and it seems rather disingenuous for them to sell it to their customers while not using it themselves internally.

Perhaps the real problem is that WAAS faces fundamental issues when deployed in large networks.  One well-known issue is that WAAS uses a per-peer data store.  If you are not familiar with this issue, details about the per-peer data store can be found in my previous blog:

Because of its per-peer data store architecture, the core data center WAAS device has dedicated data stores that each match the data store of each remote WAAS device.  For example, a Cisco WAVE-574 appliance has 120GB of DRE storage capacity, and is roughly equivalent to a mid-range Steelhead 1050L.  A core WAAS device in the data center must allocate 120GB of its DRE storage capacity to communicate with and fully utilize the DRE resources of each remote WAVE-574 device at each branch office.  But if Cisco were to deploy a WAVE-574 appliances to each of their 300 branch offices, that would mean a total of 36 TB of DRE storage will be needed in Cisco's core data center.  Since the largest WAAS appliance, the WAE-7371, has 1TB of DRE storage capacity each, this would mean that 36 WAE-7371 appliances would have to be deployed in Cisco's core data center!

Having to deploying 36 WAE-7371 is quite problematic, because they're not cheap at a list price of $129,000 each.  In contrast, Riverbed uses a universal data store architecture, and consequently there is no artificial edge-to-core fan-out ratio driven by data store sizing for the Riverbed solution.  In fact, only about three core Steelhead 6050's would provide a fully-redundant clustered solution for Cisco's internal network, assuming they have about about 18,000 remote users (an average 60 employees distributed to each of Cisco's 300 sites).  Having to deploy 36 (thirty-six) WAE-7371 vs. Riverbed's alternative of just three Steelhead 6050 leads to a huge difference in the price of the overall solution.

But even if Cisco's IT organization was given 36 large WAE-7371 applicances at no cost, and ordered by Cisco management to deploy WAAS, they still face some daunting challenges.  For example, it would be unrealistic for them to serially-chain those 36 appliances in an in-path/in-line configuration.  Using WCCP would be problematic too, because the maximum number of devices in a WCCP cluster is only 32.  The ACE load balancer isn't a good solution either, because it can't address the asymmetrically-routed network traffic that likely exists in Cisco's data centers.

So if the above analysis is correct, it seems that the real reason why Cisco hasn't deployed WAAS is simply that it just wont' scale for Cisco's internal network.  Cisco's dogfood is simply too much to swallow, even for Cisco themselves.  It is a pity that Cisco's internal IT can't use Riverbed, because Riverbed has successfully deployed Steelheads throughout a number of network environments that are far larger than Cisco's.  Here's an example of one happy Riverbed customer who has deployed 700 Steelheads:

One Response to “Eating our own dogfood, part 3”

  1. Josh Tseng said

    A number of you have emailed me asking if Cisco has responded to this blog. Well, it’s been a week now since I posted the blog, and I am not aware of any Cisco response to this blog. Perhaps they have no response.
    If anyone has any additional sources of information about the current status of Cisco’s internal deployment of WAAS, please post that information here (or post a link to it).
    Josh Tseng
    Riverbed Technology

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: