Controlling Optimization Configuration Examples
The following examples show common deployment configurations:
Configuring High-Bandwidth, Low-Latency EnvironmentConfiguring Pass-Through Transit TrafficConfiguring High-Bandwidth, Low-Latency Environment
To show how in-path and peering rules might be used when designing SteelHead deployments, consider a network that has high bandwidth, low latency, and a large number of users.
Figure 1‑7 shows this scenario occurring between two buildings at the same site. In this situation, you want to select SteelHead models to optimize traffic going to and from the WAN. However, you do not want to optimize traffic flowing between SteelHead A and SteelHead B.
Figure 1‑7. High Bandwidth Utilization, Low Latency, and Many Connections Between SteelHeads
You can achieve this result as follows:
In-path Rules - You can configure in-path rules on each of the SteelHeads (in Building A and Building B) so that the SteelHeads do not perform auto-discovery on any of the subnets in Building A and Building B. This option requires knowledge of all subnets within the two buildings, and also requires that you update the list of subnets as the network is modified.Peering Rules - You can configure peering rules on SteelHead A and SteelHead B that pass through probe packets with in-path IP addresses of the other SteelHead (SteelHead A passes through probe packets with in-path IP addresses of SteelHead B, and vice versa). Using peering rules would require:less initial configuration.less ongoing maintenance, because you do not need to update the list of subnets in the list of peering rules for each of the SteelHeads.Figure 1‑8 shows how to use peering rules to prevent optimization from occurring between two SteelHeads and still allow optimization for traffic going to and from the WAN.
Figure 1‑8. Peering Rules for High Utilization Between SteelHeads
Figure 1‑8 shows the following:
SteelHead A has a Pass peering rule for all traffic coming from the SteelHead B in-path interface. When this happens, SteelHead A allows connections from SteelHead B to pass through it unoptimized.SteelHead B has a Pass peering rule for all traffic coming from the SteelHead A in-path interface. When this happens, SteelHead B allows connections from SteelHead A to pass through it unoptimized.To configure a high-bandwidth, low-latency environment
On SteelHead A, connect to the CLI and enter the following commands:
enable
configure terminal
in-path peering rule pass peer 10.11.2.25 rulenum end
On SteelHead B, connect to the CLI and enter the following commands:
enable
configure terminal
in-path peering rule pass peer 14.102.11.5 rulenum end
If a packet does not apply to any of the configured peering rules, the auto-peering rule is used.
Configuring Pass-Through Transit Traffic
Transit traffic is data that is flowing through a SteelHead whose source or destination is not local to the SteelHead.
A SteelHead must optimize only traffic that is initiated or terminated at the site where it resides—any extra WAN hops between the SteelHead and the client or server greatly reduces the optimization benefits seen by those connections.
Figure 1‑9 shows the SteelHead at the Chicago site detects transit traffic to and from San Francisco and New York (traffic that is not initiated or terminated in Chicago). You want the initiating SteelHead (San Francisco) and the terminating SteelHead (New York) to optimize the connection. You do not want the SteelHead in Chicago to optimize the connection.
Figure 1‑9. Transit Traffic
Figure 1‑9 shows the possible solutions to resolve this transit traffic issue. These points do not include the configuration for features such as duplex, alarms, and DNS. Also assume that the default in-path rules are configured on all three SteelHeads. Because the default action for in-path rules and peering rules is to use auto-discovery, two in-path and two peering rules must be configured on the Chicago SteelHead.
The following scenarios are possible solutions:
Manual peering and in-path rules - Configure in-path and peering rules on the Chicago SteelHead to ignore transit traffic. You can configure peering rules for transit traffic by using the following CLI commands:enable
configure terminal
in-path rule auto srcaddr 10.0.0.0/24 rulenum end
in-path rule pass rulenum end
in-path peering rule auto dest 10.0.0.0/24 rulenum end
in-path peering rule pass rulenum end
Figure 1‑10. Peering Rules for Transit Traffic
Figure 1‑11. Resolving Transit Traffic by Adjusting Network Infrastructure
Figure 1‑12. Resolving Transit Traffic by Adjusting Traffic Flow
