Best Practices for SteelHead Deployments
The following list represents best practices for deploying your SteelHeads. These best practices are not requirements, but Riverbed recommends that you follow these suggestions because they lead to designs that require the least amount of initial and ongoing configuration:
Use in-path designs - Whenever possible, use a physical in-path deployment—the most common type of SteelHead deployment. Physical in-path deployments are easier to manage and configure than WCCP, PBR, and Layer-4 designs. In-path designs generally require no extra configuration on the connected routers or switches. If desired, you can limit traffic to be optimized on the SteelHead. Use the correct cables - To ensure that traffic flows not only when the SteelHead is optimizing traffic, but also when the SteelHead transitions to fail-to-wire mode, use the appropriate crossover or straight-through cable to connect the SteelHead to a router or switch. Verify the cable selection by removing power from the SteelHead and then test connectivity through it. Set matching duplex speeds - The most common cause of performance issues is duplex mismatch on the SteelHead WAN or LAN interfaces, or on the interface of a device connected to the SteelHead. Most commonly, the issue is with the interface of a network device deployed prior to the SteelHead. Minimize the effect of link state transition - Use the Cisco spanning-tree portfast command on Cisco switches, or similar configuration options on your routers and switches, to minimize the amount of time an interface stops forwarding traffic when the SteelHead transitions to failure mode. Use serial rather than parallel designs - Parallel designs are physical in-path designs in which a SteelHead has some, but not all, of the WAN links passing through it, and other SteelHeads have the remaining WAN links passing through them. Connection forwarding must be configured for parallel designs. In general, it is easier to use physical in-path designs where one SteelHead has all of the links to the WAN passing through it. Do not optimize transit traffic - Ideally, SteelHeads optimize only traffic that is initiated or terminated at its local site. To avoid optimizing transit traffic, deploy the SteelHeads where the LAN connects to the WAN and not where LAN-to-LAN or WAN-to-WAN traffic can pass through (or be redirected to) the SteelHead. Position your SteelHeads close to your network endpoints - For optimal performance, minimize latency between SteelHeads and their respective clients and servers. By deploying SteelHeads as close as possible to your network endpoints (that is, place client-side SteelHeads as close to your clients as possible, and place server-side SteelHeads as close to your servers as possible).Use WAN visibility modes that interoperate with monitoring, QoS, and security infrastructure - RiOS currently supports four different WAN visibility modes, including granular control for their usage. This ensures that the most appropriate mode is used. Use RiOS data store synchronization - Regardless of the deployment type or clustering used at a site, RiOS data store synchronization can allow significant bandwidth optimization, even after a SteelHead or hard drive failure. Use connection forwarding and allow-failure in a WCCP cluster - In a WCCP cluster, use connection forwarding and the allow-failure CLI option between SteelHeads. For details, see Connection Forwarding.Avoid using fixed-target in-path rules - Use the auto-discovery feature whenever possible, thus avoiding the need to define fixed-target, in-path rules. Understand in-path rules versus peering rules - Use in-path rules to modify SteelHead behavior when a connection is initiated. Use peering rules to modify SteelHead behavior when it detects auto-discovery tagged packets. Use Riverbed Professional Services or an authorized Riverbed Partner - Training (both standard and custom) and consultation are available for small to large, and extra-large, deployments.