SteelCentral Appliance Deployment Considerations

This section provides recommendations on how to improve the accuracy of the exported flow data when you deploy SteelCentral in specific SteelHead deployment scenarios, and it describes certain SteelHead features. It includes the following sections:

The Flow Gateway appliance uses SNMPv3 to poll the SteelHead. This polling requires the SteelHead access control list (ACL) to allow the Flow Gateway to poll OID 1.3.6.1.2. One of the steps in creating an ACL on the SteelHead is creating a View that lists OIDs that are included or excluded from access. If OID 1.3.6.1.2 is not in the included section, the Flow Gateway cannot retrieve data when it polls the SteelHead.

In an in-path configuration, you deploy SteelHeads in the physical path of the client and server, where they detect all traffic. You can source flow export from either the SteelHead primary or auxiliary interface to the Flow Gateway or the NetExpress. Enable flow export for all traffic on all SteelHead interfaces that have traffic traversing them: for example, lan0_0 and wan0_0 for a single in-path SteelHead deployment.

Riverbed recommends that you enable simplified routing when using SteelCentral and SteelHead in-path configurations. Simplified routing avoids situations where traffic can potentially run through the SteelHead more than once—commonly known as ricochet. When packet ricochet occurs, the same traffic is reported by the SteelHead multiple times, which causes an unexpected increase in bandwidth, packets, and other traffic statistics in various NetProfiler reports. Ricochet can happen when you install the SteelHead in a different subnet from the client or server and you do not configure the appropriate static routes to avoid traffic passing through the SteelHead multiple times on the way to and from the default gateway.

For more details about simplified routing and in-path deployments, see the SteelHead Management Console User’s Guide and the SteelHead Deployment Guide.

This section describes SteelHead virtual in-path deployments. It contains the following topics:

In a virtual in-path deployment, the SteelHeads are placed physically out of the path but virtually in the path between the clients and servers. This deployment differs from a physical in-path deployment in that a packet redirection mechanism is used to direct packets to the SteelHead.

Redirection mechanisms include policy-based routing (PBR), Web Cache Communication Protocol (WCCP), the Interceptor, and a Layer-4 load balancer.

In a virtual in-path deployment the SteelHead most likely detects only the traffic that has been redirected to it based on the configured ACL on the router, and not all the destined for the WAN. As a result, you cannot report on the actual WAN-link use based on the SteelHeads reports only. Therefore, you must enable NetFlow export on the router to capture information about the traffic that is not redirected to the SteelHead.

Enabling NetFlow on the router enables reporting traffic on the actual WAN link. If the SteelHead is using correct addressing, the optimized connections are reported showing the SteelHeads IP addresses as the end points of the flow and not the original client/server IP addresses. This can cause some double counting in reports under certain circumstances. However, you must not include the WAN interface of the router in the WAN optimized group, as it is not an endpoint in optimization.

In a virtual in-path configuration, the SteelHeads are connected with their WAN interface only, so that they do not have sufficient information to determine the flow direction of pass-through traffic. Therefore the IP addresses of the subnets passing through the SteelHead need to be manually configured belong to either the WAN or LAN side of the network from a SteelHead perspective. You can specify this configuration in the subnet side rules table.

For more information about configuring subnet side rules, Subnet Side Rules and the SteelHead Deployment Guide.

As a best practice in virtual in-path deployments, enable NetFlow on the primary and auxiliary interfaces and export flow data for the optimized traffic only from the SteelHead. Use the router to export the pass-through flow data. Additionally, configure LAN- and WAN-side subnets in the subnet side rules table.

Prior to RiOS 6.0, you must run the following commands on the SteelHead that is running virtually in-path to enable the SteelHead to determine the direction of flows of optimized traffic on the WAN interface:

In RiOS 6.0 and later, the fake index feature is enabled automatically, and the direction of flows of optimized traffic is determined automatically by the SteelHead. Subnet Side Rules still must be configured.

If reports are showing abnormally large bandwidth on the SteelHead WAN interface, it is an indication that either fakeindex was not enabled or LAN subnets were not properly configured. A flow list on such traffic would show flows with both the ingress and egress interfaces of the SteelHead as the WAN, such as wan0_0.

To get information about only the nonoptimized traffic, create a report using a host subnet (or host address) with the SteelHead client IP address.

For more details about virtual in-path deployments, see the SteelHead Deployment Guide.

When you deploy SteelHeads virtually in-path and load-balanced by an Interceptor, in addition to ensuring that you have fake index enabled, make sure that you avoid capturing inner-channel traffic. When you deploy a NetShark or NetExpress, do not place either appliance so it captures traffic between the SteelHeads and Interceptor, because this configuration does not detect any information about the nonoptimized network traffic. You only detect communication between the SteelHeads and Interceptor.

If you configure the SteelHead with full-transparency, you must exclude traffic between the SteelHeads and Interceptor when you configure port mirroring for collection by the NetShark or NetExpress; otherwise, you might detect excessive retransmission and incorrect or missing round-trip-time (RTT) metrics.

In virtual in-path deployments, the SteelHeads are connected with their WAN interfaces only, so that they do not have sufficient information to determine the flow direction of pass-through traffic. Therefore, you must manually configure the IP addresses of the subnets passing through the SteelHead to belong to either the WAN or LAN side of the network (from a SteelHead perspective).

If you do not have any LAN subnets configured, the SteelHead does not discern whether the traffic is passing from the WAN to the LAN or in the opposite direction. This lack of configuration can result in over reporting traffic in a particular direction or for a particular interface.

An out-of-path deployment is a network configuration in which the SteelHead is not in the direct physical path between the client and the server. In an out-of-path deployment, the SteelHead acts as a proxy. This configuration is suitable for data center locations in which physical in-path or virtual in-path configurations are not possible. The out-of-path solution uses Network Address Translation (NAT); therefore there is no direct correlation between the client and server conversation and the traffic over the WAN. You can still create valuable reports with this configuration. However, you cannot view the benefit of optimization.

In a server-side out-of-path (SSOOP) deployment, you enable NetFlow on the primary and auxiliary interface and export flow data for only the optimized traffic from the SteelHead. Similar to the virtual in-path deployment, you configure the router to export the pass-through flow data, as the SteelHead detects only optimized data in this configuration.

Prior to RiOS 6.0, and similar to the virtual in-path deployment, you must enable fake index to properly report on the direction of the optimized traffic through the SteelHead. You do not need to configure subnet side rules because the out-of-path SteelHead detects only optimized traffic and never passes traffic.