SteelHead™ Deployment Guide : Path Selection : Design Considerations
  
Design Considerations
Consider the following when you use path selection:
  • Path selection does not require dual-ended SteelHead deployments, but Riverbed highly recommends that you maintain return-traffic symmetry.
  • You cannot use AFE for Internet-bound applications to select paths with different Internet egress points. Using AFE implies that packets prior to identification traverse one path, but that after identification, the connection can switch midstream to a different path. If these two paths use different egress points to the Internet, the packets on each path use different NAT public Internet IP addresses and appear as two different sources to the Internet server. These are examples in which multiple Internet egress can exist:
  • Direct-to-Internet at the branch office and Internet at the data center - You cannot use AFE to decide that some Internet applications exit directly from the branch office and others from the data center.
    • For example, the default path that directly reaches the Internet is at the branch, but you configure AFE for Facebook traffic to traverse a path to the data center. The beginning packets of the connection exit from the branch with a externally translated address from the branch Internet provider. After identified, path selection switches midstream to the path to the data center, where the traffic is translated to a different Internet address.
  • Dual data centers, each with Internet egress - You cannot use AFE to determine what path Internet-bound applications traverse.
  • Be mindful of WAN-side routing, because it always takes precedence over path selection. Routers on the WAN side of a SteelHead can always override and reroute traffic according to their configuration. Be aware of upstream router configuration, so you that avoid unintended traffic redirection. Placing the SteelHead closer to the edge of a WAN helps to avoid this scenario. Some examples of this scenario include but are not limited to:
  • WAN-aggregation layer - All routers consolidate into a pair of Layer-3 switches. Path selection must occur on the WAN side of this layer. This is more common in data centers.
  • WAN-side router with multiple circuits - The router decides on which circuit to send traffic. You cannot use path selection effectively in this scenario.
  • Path selection is not effective in any environment in which independent routing decisions are made at the site after the SteelHead path selection decision has already occurred.
  • Path selection in virtual in-path environments have additional considerations. For details, see Path Selection and Virtual In-Path Deployment.
  • Subnet side rules exclude subnets from changing paths.
  • The SteelHead does not apply path selection configuration for traffic destined onto the same IP segment as the in-path interface. This is useful for routing updates if you have deployed the SteelHead in the direct path of that traffic.
  • The SteelHead never takes on the role of the router or of a default gateway. Because the path selection solution is transparent, you do not have to make network design changes to accommodate path selection design.
  • The primary and auxiliary interfaces of a SteelHead do not support path selection.
  • Path selection is compatible with all virtual and physical SteelHead models running RiOS v8.5 or later.
  • You must disable RSP to enable path selection. Current virtualization capabilities, including VSP on SteelHead EX v2.0 and later, are compatible with path selection.
  • A SteelHead with path selection enabled has no enforcement on the return path.
    • If you want to influence the return path of traffic and override the original traffic path, you must deploy a SteelHead near the return traffic WAN junction point. Traffic returning on a different path is commonly known as asymmetric routing. Typically, networks are not designed in this way; however if this traffic pattern exists, it might not be completely detrimental, because the SteelHead can rely on existing features and complete the optimization.
    For more information about asymmetric routing, see the SteelHead Management Console User’s Guide.
  • A single SteelHead can maintain optimization even if traffic is received on a different in-path interface from the original sending in-path interface. Because the SteelHead shares internal flow table with itself, it can complete the optimization process with no asymmetric alarm generation.
    • The following are not supported by path selection:
  • Packet-mode optimization
  • IPv6 optimization
  • WCCP designs with Layer-2 redirection
  • Designs requiring specific LAN-side redirection
  • Layer-2 WAN
  • Single-ended SCPS connections
  • Maintaining VLAN transparency
    • For example, network designs in which the in-path interface is sitting on a VLAN trunk connection and you want to switch a flow onto another VLAN, results in discarded packets, because the VLAN ID field is not reflected upon steering.
    Path Selection using GRE encapsulation has the following additional restrictions:
  • Virtual in-path deployment is not supported.
  • Inbound QoS is not applicable to inner or encapsulated incoming traffic.
  • Simplified routing does not learn from tunneled packets. If the default gateway is pointed to the WAN, make sure that you have configured the proper static routes for networks that reside in the LAN.
  • Flow export or reports reliant on flow show GRE traffic on the WAN interface. Visibility tools that coalesce or stitch LAN and WAN flows together can be affected adversely.
  • The downstream SteelHeads in serial deployments cannot intercept and take over new TCP connections when an upstream SteelHead sends GRE traffic. Even in the event of admission control, a SteelHead continues to perform path selection and tunneling, preventing proper connection spillover to a downstream SteelHead.
    •