In-path vs. Out-of-path deployment considerations

IT managers and network engineers who are new to Riverbed and WAN optimization in general are often apprehensive about placing new products and devices in the critical network path.  After all, if anything breaks or goes wrong in the WDS device, then all traffic to the WAN is potentially disrupted.

On the other hand deploying the new WAN optimization device in an out-of-path deployment, where it is configured as any application server or proxy would be configured, can create additional configuration complexity and hinder performance gains.  That is because the WAN router--or some other device that IS in the network path--becomes responsible for re-directing traffic to the WAN optimization device.

I decided in this blog to explore a few of the many considerations concerning in-path vs. out-of-path deployment of your WDS solution.  This blog is not to be a comprehensive evaluation of all issues, but hopefully, it will provide enough insights and understanding for those who are new to WDS, who are also wrestling with questions that others have waded through before.  Note that most of these considerations are vendor-neutral; they apply as much to Cisco WAAS, Blue Coat SGOS, or any other vendor's WDS products as they do to Riverbed's.

I can state unequivocally that out-of-path WDS deployments are significantly more difficult to implement than in-path deployments.  The complexity comes not so much from configuring the WAN optimization device as it does from configuring WCCP or PBR rules directing a router or switch to forward the traffic to the out-of-path WAN optimization device.  In other words, it doesn't matter which WDS vendor you choose--an out-of-path deployment is much more difficult not because of the specific WDS product, but because of the configuration and testing necessary in the Cisco router or switch that is needed to re-direct the traffic to the WAN optimization.  That Cisco router or switch is a common element in all out-of-path deployments, regardless of the WDS vendor selected.

A simple global policy to redirect all traffic to the WAN optimization device can be implemented in a single rule statement, but such an approach is only possible in very small networks.  In more typical production networks, heavy traffic loads and a wide diversity of application traffic types make a global redirection rule infeasible, because a single WAN optimization device may not be large or scalable enough to handle all of the network traffic.  Furthermore, some traffic types may not benefit from WAN optimization, and it is important to make sure these traffic types are exluded from the redirection so that they are not unnecessarily re-directed.  The end-result for large enterprise networks is an unavoidably large ACL list specifying hundreds or thousands of subnets, application ports, IP addresses, etc... are to be included in the redirection lists for optimizing traffic, and which application ports, subnets, etc... are to be excluded and not optimized.

Another important consideration specifically when using WCCP as the redirection method is that not all Cisco IOS software releases are equivalent when it comes to their abilities to support WCCP.  Many IOS releases are notoriously buggy in their WCCP implementations, and it is vitally important to check whether the IOS release in your production use is safe to use for WCCP.  Check with Cisco or your WDS vendor to verify that WCCP is stable for the IOS being used by your routers or switches, and be prepared to change IOS versions if necessary.

In addition, if you are using an older router, it is likely that packet forwarding is processed in software.  Note that in an out-of-path configuration, the amount of traffic processed by the router is going to be significantly increased.  Prior to WAN optimization, the router may have only had to handle 1.5Mbps of throughput for the T1 WAN link; after optimization, traffic throughput through a T1 can increase to as much as 60Mbps, or a ~45X+ increase in traffic workloads that the same router has to worry about.  Many older software-switched routers are not capable of handling these traffic throughput levels.  If you have older software-based routers in your production infrastructure, then the best alternatives to implement WDS solutions would be to upgrade to a new hardware-switched router if you are committed to an out-of-path configuration, or to use an in-path deployment instead.

It follows that in-path deployments are significantly easier to implement. There are no ACL's, redirection lists, WCCP service groups, etc... that have to be configured.  A WAN optimization device that is deployed in-path is immediately able to access the traffic and perform its WAN optimization functions without configuration of any neighboring devices.

In the event of failure in the WDS device, a hardware-based fail-to-wire mechanism creates a physical connection directly through the failed device, preserving connectivity to the WAN.  While traffic may not be optimized by the failed WDS device, at least end-users can still access their data through the WAN.  Those new to WDS solutions may still be apprehensive about the reliability of this mechanism, but at this point there are thousands of enterprises who have deployed tens-of-thousands of WDS devices in the in-path configuration, all leveraging the fail-to-wire capabilit of their WAN optimization devices.

In-path deployments are particularly well-suited for networks with older software-based routers that cannot handle high traffic throughputs.  Specifically, for in-path deployments the older WAN router is not exposed increased traffic loads, including the optimized LAN-side throughputs achieved through the WDS device.  The WAN optimization solution can thus extend the lifetime of legacy router equipment, delivering significantly-increased performance without upgrading WAN infrastructure.

Surprisingly, the simplicity of in-path deployment also leads to more scalability.  It is no coincidence that Riverbed's largest customers--including those who have deployed hundreds of Steelhead devices--tend to use in-path deployment approaches, particularly in the data center site.  Many of these customers have found that the out-of-path configuration approach is too inflexible, and requires too much work to configure and manage.  On the other hand, some Riverbed customers have implemented out-of-path in the branch office only, where traffic workloads are relatively light; at the core data center, an in-path configuration allows the solution to scale to the heavy traffic loads generated by hundreds-of-thousands of remote users.

The appropriate deployment approach (in-path vs. out-of-path) requires that one go beyond the initial prejudicial aversion to anything in-path.  Certainly, in some cases the out-of-path deployment approach may be the most appropriate for a given environment.  And sure, there have been examples of in-path deployments that have failed and caused problems (although not as many as examples of out-of-path deployments that have failed).  However, at this point there are now thousands of examples of successful in-path deployments that are in production operation, including deployment examples with more than 500 Steelhead appliances all interconnected and communicating through in-path configurations.