Path Selection and Virtual In-Path Deployment
Riverbed recommends that you not use virtual in-path deployments for path selection, but always use physical in-path deployments. Virtual in-path deployments often have caveats that limit path selection effectiveness, including but not limited to the following:
Typically, only traffic that is optimized is redirected to the SteelHead, and therefore the SteelHead is limited to identifying and acting on only that subset of total traffic. Although you can configure devices to redirect all traffic, this is often undesirable due to adding increased load and complexity.Additional routing devices often exist after the SteelHead makes the path selection decision.For example, consider an environment with dual Layer-3 switches and dual routers connected to different service providers. Policy-based routing (PBR) is configured on the Layer-3 switches, and the SteelHeads make the path selection decision about which Layer-3 switch to send traffic to. The Layer-3 switches then make an independent routing decision to send traffic to a router, and therefore provider, rendering the SteelHead path selection decision meaningless.
Considering additional routing devices is important in physical in-path deployments, but holds additional weight in virtual in-path deployments because of the added restriction of only certain devices being capable of redirection. For example, many firewall devices have limited functionality when supporting virtual in-path mechanisms.
Path selection next-hop functionality is not supported with WCCP. The SteelHead cannot choose to redirect packets using a different in-path interface or to send traffic to a configured gateway. Only limited functionality is available, enabling the SteelHead to mark packets with DCSP with different criteria depending on path availability.