Best Practices for Interceptor Deployments
This chapter includes best practice information for Interceptor deployments. We recommend that you use the following guidelines in Interceptor deployments to achieve designs that require the least amount of initial and ongoing configuration and maintenance. This chapter includes the following sections:
General best practices
n Use one of the three standard cluster types - The series, parallel with fail-to-block, and quad deployment designs represent the majority of Interceptor deployments.
n Place SteelHeads on the LAN side of the Interceptor - Connect SteelHeads to the network infrastructure on the LAN side of the Interceptor. This configuration typically minimizes the amount of traffic that traverses the Interceptor.
n Avoid designs with security or monitoring devices between Interceptors and cluster SteelHeads - Security or monitoring devices don’t interoperate with the redirection protocol used between the Interceptor and SteelHead. Place these devices on the LAN or WAN side of the entire cluster for security or monitoring functions.
n Don’t redirect transit traffic - Ideally, SteelHeads optimize connections that are initiated or terminated at the location of the SteelHead. Place the Interceptors where the amount of LAN-to-LAN or WAN-to-WAN traffic passing through it is minimal. If necessary, use the Interceptor controls, such as the load-balancing rules, to ensure that traffic moving through the deployment site isn’t redirected to SteelHead clusters.
n Enable multi-interface on each cluster member - Even in Interceptor deployments where you use a single in-path interface on the Interceptor or SteelHead, enable multi-interface support on all the Interceptors and clustered SteelHeads.
n Use the debug validate deployment CLI command and other configuration verification procedures - You must carefully plan and implement Interceptor deployments. Use the debug validate deployment command to ensure that the configured failover and neighbor Interceptors and the clustered SteelHead relationships are consistent throughout the cluster.
n Use hardware-assisted pass-through on traffic that isn’t optimized - Use hardware-assisted pass-through (HAP), available with some network bypass cards, to minimize Interceptor resource usage. Example traffic types for HAP include UDP traffic, TCP traffic to or from remote sites without SteelHeads, and LAN-to-LAN and WAN-to-WAN transit traffic.
n Use the right cables and duplex configuration - You must use the correct cables and duplex settings on the Interceptors and the attached network devices to avoid performance loss due to duplex mismatches and to ensure that traffic flows through the Interceptor during failures. Duplex configuration is important on SteelHead clusters because duplex mismatches severely limit optimized connection performance, possibly to levels below nonoptimized performance.
n Minimize the effect of link state transition - Use the Cisco CLI command spanning-tree portfast on Cisco switches (or similar configuration options on other routers and switches) to minimize the amount of time an interface stops forwarding traffic when the SteelHead transitions to failure mode.
n Redirect a test subset of traffic before redirecting all traffic - Begin redirection with a small subset of traffic to remote sites with and without deployed SteelHeads. Verify that the optimized and pass-through traffic operates as expected.
n If you use port scanners in your network, use one of the following settings - If you aren’t using fair peering version 2 and you are using Interceptor 1.1.2j or later, use the CLI command no clidistmap use-port enable. If you are using fair peering version 2, the Interceptors use a different client map synchronization algorithm. Note that in Interceptor 4.5.1 and later there is a new alarm if a port scanner is in use.
n Use Riverbed Professional Services or an authorized Riverbed Services Partner - You can design and implement Interceptor deployments with the help of Riverbed Professional Services. Riverbed Professional Services has deployed Interceptors in large and complex networks.
n For routing, use the WAN-side SteelHead gateway for the Interceptor in-path interface to account for the Interceptor’s role during autodiscovery - Add static routes on each in-path interface through a LAN-side gateway to reach peer Interceptors and SteelHeads. For the SteelHeads, because simplified routing isn’t enabled, We recommend that you use a separate Layer-3 segment so that the SteelHeads can leverage the underlay network devices routing information to reach a remote SteelHead or local host.
If you point your SteelHead gateway on the other side of the Interceptor, you overload the Interceptor with unnecessary traffic, which impacts performance.
VLAN segregation best practices
We recommend the following best practices for VLAN segregation:
n Dedicate SteelHeads to each instance, and size the SteelHeads according to the needs of traffic within the instance.
n Use the same deployment cluster type for each instance.
n Use the same instance names on all Interceptors.
n Use the same VLANs with an instance on all Interceptors.
You must use unique IP addresses for the Interceptor and SteelHeads within and across instances even though IP address overlap is supported for clients and servers.
We strongly recommend that you configure each instance as the same cluster type.
Installation and verification best practices
This section describes best practices for installation and configuration verification. It includes the following topics:
In an Interceptor deployment, you must first install and power on the Interceptors and SteelHeads in the network without redirecting or optimizing traffic. You can verify the configuration before the system attempts optimization.
A typical Interceptor deployment installation is as follows:
1. Rack the SteelHeads and Interceptors.
2. Apply the configuration.
3. Cable the appliances into the network and data path.
4. Verify the configuration.
We recommend that you have the following information and configurations before you begin:
n The primary and in-path IP addresses, subnet masks, and default gateways for all SteelHeads and Interceptors
n The duplex configuration of the LAN and WAN devices that the Interceptor and SteelHeads connect to
n Straight-through or crossover cables as needed (we recommend cable labels)
n Any additional network interface cards for the SteelHead and Interceptors
n The in-path IP addresses of remote SteelHeads to optimize connections to the Interceptor deployment location
n The IP addresses for a few remote hosts at locations without SteelHeads
n An application optimization test plan that details procedures to verify correct and optimized application behavior
n Expert personnel or resources needed to execute the application optimization test plan
n A network diagram that illustrates where all appliances are to be logically placed in the network
n The clustered Interceptor and SteelHead configuration
Installing an Interceptor
The following procedure is a general outline of how to install and test an Interceptor.
To install an Interceptor
1. Insert any required additional network interface cards to the SteelHeads and Interceptors.
2. Rack and power on the SteelHeads and Interceptors. Connect only the primary interface to the network. Don’t cable any WAN or LAN interfaces.
3. Using the serial console, configure the management (primary) interface configuration and default gateway on all Interceptors and SteelHeads. As a result, all appliances are reachable through the network, and further configuration can be performed using SSH for the CLI or https for the Interceptor Management Console.
4. Apply and save the remaining configuration on each SteelHead and Interceptor—including in-path IP addresses, in-path default gateway and routing information, connection forwarding, failover, and neighbor Interceptor relationships—as required by the design.
5. Configure each Interceptor with a load-balancing rule that matches all traffic and has an action of type pass. Make this rule the last rule in the load-balancing rule list, so that traffic isn’t redirected. Save this configuration.
6. Label both ends of the cables with the installation target device and interface identifier on all cables involved in the installation, both existing and new. This practice eliminates potential errors during cable plugging and swapping activities. Labeling is especially necessary for deployments involving numerous in-path interfaces.
7. Plan a change window. During that time, cable the WAN interfaces of the SteelHeads and the Interceptor WAN and LAN interfaces by performing the following steps:
n Power off the Interceptor. Verify that local hosts can continue to reach the WAN. Power on the Interceptor. After the Interceptor has restarted and the interfaces are up, verify that local hosts can continue to reach the WAN.
n Configure a load-balancing rule of type redirect that matches a small subset of traffic to and from sites with remote SteelHeads. (This load-balancing rule must be placed logically before the pass all rule.) This rule must match connections required for the application optimization test plan, and it must also include connections that aren’t optimized.
n Verify that the connections from the host to remote SteelHeads sites are optimized, both by looking at the SteelHeads Current Connections report and by verifying that performance for the applications have improved.
n Verify that existing and new nonoptimized connections matched by the load-balance redirect rule continue to function normally.
n At the end of the change window, you can leave the redirect load-balancing rule in place to allow only the subset of traffic to be optimized, or you can remove both the redirect and the pass all rule. This configuration allows the Interceptor to forward traffic as needed to the SteelHead for autodiscovery and potentially optimize all traffic to remote locations with SteelHeads.
Verifying the configuration
After you apply the configurations to the Interceptors and SteelHeads in a cluster, you can verify that the cluster interfaces and relationships are reachable and consistent.
To verify that the cluster interfaces and relationships are reachable and consistent, use the following techniques:
n Use the debug validate deployment command to verify all cluster relationships among the local SteelHeads and Interceptors.
n Use the ping command to verify reachability between all in-path interfaces on all SteelHeads and Interceptors. Measure the round-trip latency reported to make sure the latency is low. Investigate and correct high latencies. High latency might indicate that the path between the cluster members crosses the WAN.
n Use the show steelhead name all command on the clustered Interceptors to ensure that they have connected to all the clustered SteelHeads. You can also use this command in VLAN segregation mode.
n Use the show redirect peers command on the clustered Interceptors to ensure that they have connected to all other cluster Interceptors. If you are in VLAN segregation mode, this command is show Interceptor name all.
n Use the ping command to verify reachability between the clustered SteelHeads in-path IP addresses and remote SteelHeads in-path IP addresses.
n Use the ping command to verify reachability between the clustered SteelHeads in-path IP addresses and local hosts.
n Use the ping command to verify reachability between the Interceptor in-path IP addresses and remote locations.