Configuring Network Integration Features

This chapter describes how to configure advanced features such as asymmetric routing, connection forwarding, encryption, flow export, joining a Windows domain, simplified routing, and WCCP.

This chapter includes these topics:

•Configuring asymmetric routing features

•Configuring connection forwarding features

•Configuring IPSec encryption

•Configuring subnet side rules

•Configuring flow statistics

•Joining a Windows domain or workgroup

•Configuring simplified routing features

•Configuring WCCP

•Configuring hardware-assist rules

For details about basic and advanced deployment types, see the SteelHead Deployment Guide.

Configuring asymmetric routing features

You enable asymmetric route detection in the Networking > Networking Integration: Asymmetric Routing page.

Asymmetric route detection automatically detects and reports asymmetric routing conditions and caches this information to avoid losing connectivity between a client and a server.

Asymmetric routing is when a packet takes one path to the destination and takes another path when returning to the source. Asymmetric routing is common within most networks; the larger the network, the more likely there’s asymmetric routing in the network.

The asymmetric routing feature is compatible with IPv6.

Asymmetric routing is undesirable for many network devices, including firewalls, VPNs, and SteelHeads. These devices all rely on seeing every packet to function properly. When SteelHeads are deployed in a network, all TCP traffic must flow through the same SteelHeads in the forward and reverse directions. If traffic flows through a SteelHead in one direction and not the other, then TCP clients are unable to make connections to TCP servers. When deploying SteelHeads into redundant networks, there’s a possibility of traffic taking different forward and return paths so that traffic in one direction goes through SteelHeads but traffic in the reverse direction doesn’t.

Asymmetric automatic detection enables SteelHeads to detect the presence of asymmetry within the network. Asymmetry is detected by the client-side SteelHeads. Once detected, the SteelHead passes through asymmetric traffic unoptimized allowing the TCP connections to continue to work. The first TCP connection for a pair of addresses might be dropped because during the detection process the SteelHeads have no way of knowing that the connection is asymmetric.

If asymmetric routing is detected, an entry is placed in the asymmetric routing table and any subsequent connections from that IP-address pair is passed through unoptimized. Further connections between these hosts aren’t optimized until that particular asymmetric routing cache entry times out.

The Networking > Network Integration: Asymmetric Routing page displays the asymmetric routing table. This table describes the different types of asymmetry.

Type	Description	Asymmetric routing table and log entries
Complete Asymmetry	Packets traverse both SteelHeads going from the client to the server but bypass both SteelHeads on the return path.	•Asymmetric Routing Table: bad RST •Log: Sep 5 11:16:38 gen-sh102 kernel: [intercept.WARN] asymmetric routing between 10.11.111.19 and 10.11.25.23 detected (bad RST)
Server-Side Asymmetry	Packets traverse both SteelHeads going from the client to the server but bypass the server-side SteelHead on the return path.	•Asymmetric Routing Table: bad SYN/ACK •Log: Sep 7 16:17:25 gen-sh102 kernel: [intercept.WARN] asymmetric routing between 10.11.25.23:5001 and 10.11.111.19:33261 detected (bad SYN/ACK)
Client-Side Asymmetry	Packets traverse both SteelHeads going from the client to the server but bypass the client-side SteelHead on the return path.	•Asymmetric Routing Table: no SYN/ACK •Log: Sep 7 16:41:45 gen-sh102 kernel: [intercept.WARN] asymmetric routing between 10.11.111.19:33262 and 10.11.25.23:5001 detected (no SYN/ACK)
multiSYN Retransmit	The types of multi-SYN retransmits are: •Probe-filtered occurs when the client-side SteelHead sends out multiple SYN+ frames and doesn’t get a response. •SYN-remit occurs when the client-side SteelHead receives multiple SYN retransmits from a client and doesn’t see a SYN/ACK packet from the destination server.	•Asymmetric Routing Table: probe-filtered (not-AR) •Log: Sep 13 20:59:16 gen-sh102 kernel: [intercept.WARN] it appears as though probes from 10.11.111.19 to 10.11.25.23 are being filtered. Passing through connections between these two hosts.

Detecting and caching asymmetric routes doesn’t optimize these packets. If you want to optimize asymmetric routed packets you must make sure that packets going to the WAN always go through a SteelHead either by using a multiport SteelHead, connection forwarding, or using external ways to redirect packets, such as WCCP or PBR.

For details, see Configuring connection forwarding features or the SteelHead Deployment Guide.

Troubleshooting asymmetric routes

You can use these tools to detect and analyze asymmetric routes:

•TCP Dump - Run a TCP dump diagnostic report on the client-side SteelHead to verify the packet sequence that is causing the asymmetric route detection. You can take traces on the LAN and WAN ports of the SteelHead and, based on the packet maps, look for the packet sequence that is expected for the type of warning message that was in the log.

As an example, to obtain information about all packets on the WAN interface sourced from or destined to 10.0.0.1, and with a source and destination TCP port of 80:

1. Choose Reports > Diagnostics: TCP Dumps to display the TCP Dumps page.

2. Click Add a New TCP Dump.

3. Select the WAN interface.

4. Specify 10.0.0.1 as the source and destination address.

5. Specify TCP port 80 as the source and destination port.

6. Select the Schedule Dump check box and specify the date and time to initiate the dump.

7. Specify any other options such as the capture filename or duration.

8. Click Add.

For details, see Capturing and uploading TCP dump files.

•Trace Route - From the CLI, run the traceroute tool to discover what path a packet is taking from the client to the server and from the server to the client. You access the client and run the traceroute command with the IP address of the server, then run the traceroute command from the server with the IP address of the client: for example, for a Cisco router:

#Client’s Address: 10.1.0.2

#Server’s Address: 10.0.0.4

client# traceroute 10.0.0.4 Type escape sequence to abort.

Tracing the route to 10.0.0.4

1 10.1.0.1 4 msec 0 msec 4 msec

2 10.0.0.2 4 msec 4 msec 0 msec

3 10.0.0.3 4 msec 4 msec 0 msec

4 10.0.0.4 4 msec 4 msec 0 msec

server# traceroute 10.1.0.2 Type escape sequence to abort.

Tracing the route to 10.1.0.2

1 10.0.0.6 4 msec 0 msec 4 msec

2 10.0.0.5 4 msec 4 msec 0 msec

3 10.1.0.1 4 msec 4 msec 0 msec

4 10.1.0.2 4 msec 4 msec 0 msec

For details, see the Riverbed Command-Line Interface Reference Manual or the SteelHead Deployment Guide.

To automatically detect asymmetric routing

1. Choose Networking > Network Integration: Asymmetric Routing to display the Asymmetric Routing page.

2. Under Asymmetric Routing Settings, complete the configuration as described in this table.

Control	Description
Enable Asymmetric Routing Detection	Detects asymmetric routes in your network.
Enable Asymmetric Routing Pass-Through	Enables pass-through traffic if asymmetric routing is detected. If asymmetric routing is detected, the pair of IP addresses, defined by the client and server addresses of this connection, is cached on the SteelHead. Further connections between these hosts are passed through unoptimized until that particular asymmetric routing cache entry times out. Detecting and caching asymmetric routes doesn’t optimize these packets. If you want to optimize asymmetric routed packets you must make sure that the packets going to the WAN always go through a SteelHead either by using a multiport SteelHead, connection forwarding, or using external ways to redirect packets, such as WCCP or PBR. For details, see the SteelHead Deployment Guide.
Remove Selected	Select the check box next to the name and click Remove Selected.

3. Click Save to Disk to save your settings permanently.

•Generating system dumps

•Viewing process dumps

Configuring connection forwarding features

You configure connection forwarding for a network with multiple paths from the server in the Networking > Network Integration: Connection Forwarding page.

The AWS SteelHead-c doesn’t support connection forwarding; however, the ESX SteelHead-c supports it.

You enable connection forwarding only in asymmetric networks; that is, networks in which a client request traverses a different network path than the server response. The default port for connection forwarding is 7850.

For virtual in-path deployments with multiple SteelHeads, including WCCP clusters and connection forwarding, you must always allow in-path neighbor failure. Allowing in-path neighbor failure is necessary because certain events, such as network failures, and router or SteelHead cluster changes, can cause routers to change the destination SteelHead for TCP connection packets. When this happens, SteelHeads must be able to redirect traffic to each other to ensure that optimization continues.

To optimize connections in asymmetric networks, packets traveling in both directions must pass through the same client-side and server-side SteelHead. If you have one path from the client to the server and a different path from the server to the client, you must enable in-path connection forwarding and configure the SteelHeads to communicate with each other. These SteelHeads are called neighbors and exchange connection information to redirect packets to each other.

When you define a neighbor, specify the SteelHead in-path IP address, not the primary IP address.

In RiOS 9.6 and later, you can use IPv6 addresses when you configure SteelHead neighbors. Specify either all-IPv4 addresses or all-IPv6 addresses; mixed IPv4 and IPv6 addresses aren’t allowed.

You can use connection forwarding in mixed IPv4 and IPv6 networks. The protocol and neighbors you specify for connection forwarding (either IPv4 or IPv6) determine the control channel to use, but IPv4 and IPv6 traffic to those neighbors is sent unchanged.

When RiOS determines an IPv6 incompatibility between connection-forwarding neighbors, it triggers an alarm indicating that a peer SteelHead is incompatible. For details, see Configuring alarm settings and Viewing Alarm Status reports.

You must enable connection forwarding in a WCCP cluster. With connection forwarding enabled, the WCCP load-balancing algorithm considers the total number of in-path interfaces of all neighbors in the service group when balancing the load across the interfaces. If you don’t enable connection forwarding, the SteelHead with the lowest IP address assigns all traffic flows to itself. For details, see the SteelHead Deployment Guide.

While WCCP doesn’t support IPv6, you can use connection forwarding in a WCCP cluster with a mixed IPv4 and IPv6 network, as long as all SteelHeads in the cluster are running RiOS 8.5 or later.

Asymmetric network

You can place neighbors in the same physical site or in different sites, but the latency between them must be short because the packets traveling between them aren’t optimized.

If there are more than two possible paths, additional SteelHeads must be installed on each path and configured as neighbors. Neighbors are notified in parallel so that the delay introduced at the connection setup is equal to the time it takes to get an acknowledgment from the furthest neighbor.

Connection-forwarding neighbors must use the same WAN visibility mode. For details, see Configuring in-path rules.

For details about connection forwarding, see the SteelHead Deployment Guide.

To enable connection forwarding

1. Choose Networking > Network Integration: Connection Forwarding to display the Connection Forwarding page.

2. In the Connection Forwarding Settings pane, complete the configuration as described in this table.

Control	Description
Enable Connection Forwarding	Enables connection forwarding by default on all neighbors added to the peer list.
Port	Specify the port number to use as the default for the neighbor SteelHead in-path port. The default value is 7850.
Keep-Alive Interval	Specify the number of seconds to use as the default interval for ping commands between neighbor SteelHeads. The default value is 1 second.
Keep-Alive Count	Specify the number of tries to use as the default number of failed ping attempts before an appliance terminates a connection with a neighbor. The default value is 3.
In-Path Neighbor Failure	Uses the neighbor appliance to optimize new connections if the appliance fails. For in-path deployments that use connection forwarding with WCCP, enabling this option ensures that if one appliance fails, the neighbor appliance continues to optimize new connections. For in-path deployments that use connection forwarding without WCCP, enabling this option ensures that a SteelHead attempts to optimize new connections that are symmetrically routed, even after all of the neighbor SteelHeads on another network path failed. New asymmetrically routed connections aren’t optimized but passed through.
Multiple Interface Support	Enables high availability on SteelHead appliances configured with multiple in-path interfaces and using connection forwarding with another multiport SteelHead. This option makes all neighbor in-path interface IP addresses visible to each peer to ensure proper neighbor communication if the in-path0_0 interface fails. RiOS 6.5 and later require connection forwarding in a WCCP cluster. You must enable multiple interface support for a connection-forwarding neighbor to work with IPv6.
IPv6 Connection Forwarding	Allows IPv6 addresses to be entered in the Neighbor Table area of this page, in the In-Path IP Address and Additional IP Addresses fields. Selecting this check box disallows the use of IPv4 addresses for neighbors; clearing this box disallows the use of IPv6 addresses for neighbors.

3. Click Apply to apply your settings.

4. Click Save to Disk to save your settings permanently.

To add a new neighbor

1. Under Neighbor Table, complete the configuration as described in this table.

Control	Description
Add a New Neighbor	Displays the controls to add a new neighbor.
Hostname	Specify a hostname.
In-Path IP Address	Specify the in-path IP address for the neighbor SteelHead. When you define a neighbor, you must specify the appliance in-path IP address, not the primary IP address. You can use connection forwarding with IPv6 addresses if the following conditions are met: •Both SteelHeads must be running RiOS 9.6 or later. •Multiple interface support must be selected. •The IPv6 Connection Forwarding check box must be selected in the Connection Forwarding Settings area of this page.
Port	Specify the in-path port for the neighbor SteelHead. The default port is 7850.
Additional IP Addresses	Adds a neighbor SteelHead to the neighbor list. IPv6 addresses are allowed if this SteelHead and the neighbor SteelHeads are running RiOS 9.6 or later and the IPv6 Connection Forwarding check box is selected.
Add	Adds a new neighbor.
Remove Selected	Select the check box next to the name and click Remove Selected.

2. Click Apply to apply your settings.

3. Click Save to Disk to save your settings permanently.

To modify the neighbor properties, select the IP address of the neighbor and complete the configuration.

Related topics

•Configuring general service settings

•Configuring asymmetric routing features

Configuring IPSec encryption

You configure IPSec encryption to allow data to be communicated securely between peer SteelHeads in the Optimization > SSL: Secure Peering (IPSEC) page.

Enabling IPSec encryption makes it difficult for a third party to view your data or pose as a computer you expect to receive data from. To enable IPSec, you must specify at least one encryption and authentication algorithm. Only optimized data is protected, pass-through traffic isn’t.

Enabling IPSec support is optional.

RiOS doesn’t support IPSec over IPv6.

In RiOS 9.0 and later, IPSec secure peering and the secure transport service are mutually exclusive. The secure transport service is enabled by default. Before you enable IPSec secure peering, you must disable the secure transport service by entering the no stp-client enable command at the system prompt.

RiOS provides support for SSL peering beyond traditional HTTPS traffic. For details, see Configuring secure peers.

You must set IPSec support on each peer SteelHead in your network for which you want to establish a secure connection. You must also specify a shared secret on each peer SteelHead.

If you NAT traffic between SteelHeads, you can’t use the IPSec channel between the SteelHeads because the NAT changes the packet headers, causing IPSec to reject them.

To enable IPSec encryption

1. Choose Optimization > SSL: Secure Peering IPsec to display the Secure Peering IPsec page.

2. Under General Settings, complete the configuration as described in this table.

Control	Description
Enable Authentication and Encryption	Enables authentication between SteelHeads. By default, this option is disabled.
Enable Perfect Forward Secrecy	Enables additional security by renegotiating keys at specified intervals. If one key is compromised, subsequent keys are secure because they’re not derived from previous keys. By default, this option is enabled.
Encryption Policy	Select one of these encryption methods from the drop-down list: •DES - Encrypts data using the Data Encryption Standard algorithm. DES is the default value. •NULL - Specifies the null encryption algorithm. •None - Doesn’t apply an encryption policy. •3DES - Appears when a valid Enhanced Cryptography License Key is installed on the appliance. Encrypts data using the Triple Digital Encryption Standard with a 168-bit key length. This standard is supported for environments where AES has not been approved, but is both slower and less secure than AES. •AES - Appears when a valid Enhanced Cryptography License Key is installed on the appliance. Encrypts data using the Advanced Encryption Standard (AES) cryptographic key length of 128 bits. •AES256 - Appears when a valid Enhanced Cryptography License Key is installed. Encrypts data using the Advanced Encryption Standard (AES) cryptographic key length of 256 bits. Provides the highest security. Optionally, select an algorithm from the method 2, 3, 4, or 5 drop-down lists to create a prioritized list of encryption policies for negotiating between peers. Note: Peer SteelHeads must both have a valid Enhanced Cryptography License Key installed to use 3DES, AES, or AES256. When a SteelHead has the valid Enhanced Cryptography License Key installed and an IPSec encryption level is set to 3DES or AES, and a peer SteelHead doesn’t have a valid Enhanced Cryptography License Key installed, the appliances uses the highest encryption level set on the appliance without the key.
Authentication Policy	Select one of these authentication methods from the drop-down list: •MD5 - Specifies the Message-Digest 5 algorithm, a widely used cryptographic hash function with a 128-bit hash value. This is the default value. •SHA-1 - Specifies the Secure Hash Algorithm, a set of related cryptographic hash functions. SHA-1 is considered to be the successor to MD5. Optionally, select an algorithm from the method 2 drop-down list to create a secondary policy for negotiating the authentication method to use between peers. If the first authentication policy negotiation fails, the peer SteelHeads use the secondary policy to negotiate authentication.
Time Between Key Renegotiations	Specify the number of minutes between quick-mode renegotiation of keys using the Internet Key Exchange (IKE) protocol. IKE uses public key cryptography to provide the secure transmission of a secret key to a recipient so that the encrypted data can be decrypted at the other end. The default value is 240 minutes.
Enter the Shared Secret/Confirm the Shared Secret	Specify and confirm the shared secret. All the SteelHeads in a network for which you want to use IPSec must have the same shared secret.
Add a New Secure Peer	Displays the controls to add a new secure peer. •Peer IP Address - Specify the IP address for the peer SteelHead (in-path interface) for which you want to make a secure connection.
Add	Adds the peer specified in the Peer IP Address text box. If a connection has not been established between the two SteelHeads that are configured to use IPSec security, the peers list doesn’t display the peer SteelHead status as mature. Note: Adding a peer causes a short service disruption (3 to 4 seconds) to the peer that is configured to use IPSec security.
Remove Selected	Select the check box next to the name and click Remove Selected.

3. Click Save to Disk to save your settings permanently.

4. If you have changed an IPSec encryption setting, you must restart the optimization service. For details, see Starting and stopping the optimization service.

The peered SteelHeads don’t establish the IPSec channel until they’re optimizing traffic.

About the Secure Peers list

The Secure Peers list displays the peers with the encryption and authentication policies and one of these states:

•Mature - The IPSec connection is established and usable.

•Larval - The IPSec connection is being established.

•Disconnected - The IPSec connection isn’t yet established or isn’t usable.

Configuring subnet side rules

You configure subnet side rules in the Networking > Network Services: Subnet Side Rules page.

Subnet side rules are used in a virtual in-path deployment to support Flow Export, to support a client-side SteelHead with Riverbed Services Platform (RSP) enabled, or to exempt certain subnets from QoS enforcement or path selection.

Subnet side rules let you configure subnets as LAN-side subnets or WAN-Side subnets for a virtual in-path SteelHead. The subnet side rules determine whether traffic originated from the LAN or the WAN-Side of the SteelHead based on the source subnet. You must configure subnets on each SteelHead in a virtual in-path configuration when RSP is enabled, as the subnets for each will likely be unique.

With subnet side rules in place:

•LAN-bound traffic that traverses the WAN interface of the SteelHead is exempt from QoS enforcement. For details, see Bypassing LAN traffic.

•client-side SteelHeads configured for virtual in-path deployment and RSP enabled can optimize traffic from client-side connections. Otherwise, the appliance does not optimize traffic from client-side connections. In virtual in-path configurations, all traffic flows in and out of one physical interface, and the default subnet side rule causes all traffic to appear to originate from the WAN side of the device.

•flow export collectors such as NetFlow analyze nonoptimized or passed through traffic correctly. Otherwise, the SteelHead can’t discern whether the traffic is traveling from the LAN to the WAN or in the opposite direction. Without subnet side rules, the SteelHead can over-report traffic in a particular direction or for a particular interface.

The Fake index feature is necessary for correct optimized traffic reporting. The fake index feature is enabled by default if you enable the Flow Export option on the Networking > Network Services: Flow Statistics page For details, see the SteelHead Deployment Guide.

To add subnet side rules

1. Choose Networking > Network Services: Subnet Side Rules to display the Subnet Side Rules page.

2. Complete the configuration as described in this table.

Control	Description
Add a Subnet Side Rule	Displays the controls to create a subnet side rule.
Insert Rule At	Select Start, End, or a rule number from the drop-down list. SteelHeads evaluate rules in numerical order starting with rule 1. If the conditions set in the rule match, then the rule is applied, and the system moves on to the next packet. If the conditions set in the rule don’t match, the system consults the next rule. For example, if the conditions of rule 1 don’t match, rule 2 is consulted. If rule 2 matches the conditions, it is applied, and no further rules are consulted.
Subnet	Specify the subnet. The subnet can be either an IPv4 or an IPv6 address. Use the following format: <ip address>/<subnet mask> xxx.xxx.xxx.xxx/xx (IPv4) x:x:x:x/xxx (IPv6)
Subnet is on the LAN side of this appliance	In virtual in-path configurations, all traffic is flowing in and out of one physical interface. Select to specify that the subnet is on the LAN side of the device.
Subnet is on the WAN side of this appliance	In virtual in-path configurations, all traffic is flowing in and out of one physical interface. Select to specify that the subnet is on the WAN side of the device.
Add	Adds the rule to the subnet map table. The Management Console redisplays the subnet map table and applies your changes to the running configuration, which is stored in memory.
Remove Subnet Rules	Select the check box next to the name and click Remove Subnet Rules.
Move Subnet Rules	Moves the selected rules. Click the arrow next to the desired rule position; the rule moves to the new position.

You can’t delete the default rule that optimizes all remaining WAN side traffic that has not been selected by another rule. This rule is always listed last.

Related topics

•Configuring flow statistics

Configuring flow statistics

You enable and configure flow statistic settings in the Networking > Network Services: Flow Statistics page. You can also enable flow export to an external collector and to a CascadeFlow collector. CascadeFlow collectors can aggregate information about QoS configuration and other application statistics to send to a SteelCentral NetProfiler. The Enterprise NetProfiler summarizes and displays the QoS configuration statistics.

By default, flow export is disabled.

You can’t export data flowing through a secure transport tunnel to a flow collector. Secure transport provides security by creating tunnels between the peers through which the traffic flows. IPSec is used to provide authentication and encryption to the packets that flow through the tunnels. Specifically, secure transport uses the ESP mode of IPSec. Flow statistic collectors can’t collect ESP packet data flow information.

External collectors use information about network data flows to report trends such as the top users, peak usage times, traffic accounting, security, and traffic routing. You can export preoptimization and post-optimization data to an external collector.

The Top Talkers feature enables a report that details the hosts, applications, and host and application pairs that are either sending or receiving the most data on the network. Top Talkers doesn’t use a NetFlow Collector.

Enabling flow export

SteelHeads support NetFlow v5.0, CascadeFlow, NetFlow v9, and CascadeFlow-compatible. Flow export requires these components:

•Exporter - When you enable flow export support, the SteelHead exports data about the individual flows that it sees as they traverse the network.

•Collector - A server or appliance designed to aggregate data sent to it by the SteelHead and other exporters.

•Analyzer - A collection of tools used to analyze the data and provide relevant data summaries and graphs. NetFlow analyzers are available for free or from commercial sources. Analyzers are often provided in conjunction with the collectors.

Before you enable flow export in your network, consider the following:

•Flow data typically consumes less than 1 percent of link bandwidth. Take care with low bandwidth links to ensure that flow export doesn’t consume too much bandwidth and thereby impacting application performance.

•You can reduce the amount of bandwidth consumption by applying filters that only export the most critical information needed for your reports.

Flow export in virtual in-path deployments

In virtual in-path deployments, such as WCCP or PBR, traffic arrives and leaves from the same WAN interface. When data is exported to a flow export collector, all traffic has the WAN interface index. This behavior is correct because the input interface is the same as the output interface.

For details about configuring flow export in a virtual in-path deployment, see Configuring subnet side rules.

To distinguish between LAN-to-WAN and WAN-to-LAN traffic in virtual in-path deployments, see the SteelHead Deployment Guide.

To enable flow statistic settings

1. Choose Networking > Network Services: Flow Statistics to display the Flow Statistics page.

2. Under Flow Statistics Settings, complete the configuration as described in this table.

Control	Description
Enable Application Visibility	Continuously collects detailed application-level statistics for both pass-through and optimized traffic. The Application Visibility and Application Statistics reports display these statistics. This statistic collection is disabled by default. To view the reports, choose Reports > Networking: Application Statistics or Application Visibility. Enabling application visibility also improves connection reporting on the Current Connections report. For example, HTTP-SharePoint is displayed as the WebDAV or FPSE protocols and Office 365 appears as MS-Office-365 instead of HTTP.
Enable WAN Throughput Statistics	Continuously collects WAN throughput statistics, which the WAN Throughput report displays. This statistic collection is enabled by default; however, you can disable the collection to save processing power. To view the WAN throughput statistics, choose Reports > Networking: WAN Throughput.
Enable Top Talkers	Continuously collects statistics for the most active traffic flows. A traffic flow consists of data sent and received from a single source IP address and port number to a single destination IP address and port number over the same protocol. The most active, heaviest users of WAN bandwidth are called the Top Talkers. A flow collector identifies the top consumers of the available WAN capacity (the top 50 by default) and displays them in the Top Talkers report. Collecting statistics on the Top Talkers provides visibility into WAN traffic without applying an in-path rule to enable a WAN visibility mode. You can analyze the Top Talkers for accounting, security, troubleshooting, and capacity planning purposes. You can also export the complete list in CSV format. The collector gathers statistics on the Top Talkers based on the proportion of WAN bandwidth consumed by the top hosts, applications, and host and application pair conversations. The statistics track pass-through or optimized traffic, or both. Data includes TCP or UDP traffic, or both (configurable in the Top Talkers report page). A NetFlow collector is not required for this feature. Optionally, select a time period to adjust the collection interval: •24-hour Report Period - For a five-minute granularity (the default setting). •48-hour Report Period - For a ten-minute granularity. The system also uses the time period to collect SNMP Top Talker statistics. For top talkers displayed in the Top Talker report and SNMP Top Talker statistics, the system updates the Top Talker data ranks either every 300 seconds (for a 24- hour reporting period), or 600 seconds (for a 48-hour reporting period). The system saves a maximum of 300 Top Talker data snapshots, and aggregates these to calculate the top talkers for the 24-hour or 48-hour reporting period. The system never clears top talker data at the time of polling; however, every 300 or 600 seconds, it replaces the oldest Top Talker data snapshot of the 300 with the new data snapshot. After you change the reporting period, it takes the system one day to update the Top Talker rankings to reflect the new reporting period. In the interim, the data used to calculate the Top Talkers still includes data snapshots from the original reporting period. This delay applies to Top Talker report queries and SNMP Top Talker statistics.

3. Click Save to Disk to save your settings permanently.

To enable flow export settings

1. Choose Networking > Network Services: Flow Statistics to display the Flow Statistics page.

2. Under Flow Export Settings, complete the configuration as described in this table.

Control	Description
Enable Flow Export	Enables the SteelHead to export network statistics about the individual flows that it sees as they traverse the network. By default, this setting is disabled.
Export QoS and Application Statistics to CascadeFlow Collectors	Sends application-level statistics from all sites to a SteelCentral collector on a SteelCentral appliance. SteelCentral appliances provide central reporting capabilities. The collector aggregates QoS and application statistics to provide visibility using detailed records specific to flows traversing the SteelHead. The SteelHead sends SteelCentral an enhanced version of NetFlow called CascadeFlow. CascadeFlow includes: •NetFlow v9 extensions for round-trip time measurements that enable you to understand volumes of traffic across your WAN and end-to-end response time. •extensions that enable a SteelCentral NetExpress to properly measure and report on the benefits of optimization. After the statistics are aggregated on a Cascade appliance, you can use its central reporting capabilities to: •analyze overall WAN use, such as traffic generated by application, most active sites, and so on. •troubleshoot a particular application by viewing how much bandwidth it received, checking for any retransmissions, interference from other applications, and so on. •compare actual application use against your outbound QoS policy configuration to analyze whether your policies are effective. For example, if your QoS policy determines that Citrix should get a minimum of 10 percent of the link, and the application statistics reveal that Citrix performance is unreliable and always stuck at 10 percent, you might want to increase that minimum guarantee. You must enable outbound QoS on the SteelHead, add a CascadeFlow collector, and enable REST API access before sending QoS configuration statistics to an SteelCentral NetProfiler. To enable QoS, choose Networking > Network Services: Outbound QoS. You can’t export statistics for inbound QoS. The collectors appear in the Flow Collector list at the bottom of the Configure > Networking: Flow Statistics page. To enable REST API access, choose Administration > Security: REST API Access. The CascadeFlow collector collects read-only statistics on both pass-through and optimized traffic. When you use CascadeFlow, the SteelHead sends four flow records for each optimized TCP session: ingress and egress for the inner-channel connection, and ingress and egress for the outer-channel connection. A pass-through connection still sends four flow records, even though there are no separate inner- and outer-channel connections. In either case, the SteelCentral NetExpress merges these flow records together with flow data collected for the same flow from other devices. For details, see the SteelCentral Network Performance Management Deployment Guide.
Enable IPv6	Enables support for IPv6 addresses for flow exports.
Active Flow Timeout	Optionally, specify the amount of time, in seconds, the collector retains the list of active traffic flows. The default value is 1800 seconds. You can set the time-out period even if the Top Talkers option is enabled.
Inactive Flow Timeout	Optionally, specify the amount of time, in seconds, the collector retains the list of inactive traffic flows. The default value is 15 seconds.

3. Click Apply to apply your settings.

4. Click Save to Disk to save your settings permanently.

Related topics

•Configuring subnet side rules

•Viewing Top Talkers reports

•Viewing Application Statistics reports

To add a flow collector

1. Under Flow Collectors, complete the configuration as described in this table.

Control	Description
Add a New Flow Collector	Displays the controls to add a Flow collector.
Collector Hostname or IP Address	Specify the IP address or (in RiOS 9.7 and later) a hostname for the Flow collector.
Port	Specify the UDP port the Flow collector is listening on. The default value is 2055.
Version	Select one of these versions from the drop-down list: •CascadeFlow - Use with Cascade Profiler 8.4 or later. •CascadeFlow-compatible - Use with Cascade Profiler 8.3.2 or earlier, and select the LAN Address check box. •NetFlow v9 - Enables both ingress and egress flow records. •NetFlow v5 - Enables ingress flow records. For details on using NetFlow records with Cascade, see the SteelCentral Network Performance Management Deployment Guide. CascadeFlow and CascadeFlow-compatible are enhanced versions of flow export to the SteelCentral. These versions allow automatic discovery and interface grouping for SteelHeads in a Riverbed SteelCentral NetProfiler or a SteelCentral Flow Gateway and support WAN and optimization reports in SteelCentral. For details, see the SteelCentral NetProfiler and NetExpress User Guide and the SteelCentral Flow Gateway User Guide.
Packet Source Interface	Select the interface to use as the source IP address of the flow packets (Primary, Aux, or MIP) from the drop-down list. NetFlow records sent from the SteelHead appear to be sent from the IP address of the selected interface.
LAN Address	Causes the TCP/IP addresses and ports reported for optimized flows to contain the original client and server IP addresses and not those of the SteelHead. The default setting displays the IP addresses of the original client and server without the IP address of the SteelHeads. This setting is unavailable with NetFlow v9, because the optimized flows are always sent out with both the original client server IP addresses and the IP addresses used by the SteelHead.
Capture Interface/Type	Specify the traffic type to export to the flow collector. Select one of these types from the drop-down list: •All - Exports both optimized and nonoptimized traffic. •Optimized - Exports optimized traffic. •Optimized - Exports optimized LAN or WAN traffic when WCCP is enabled. •Passthrough - Exports pass-through traffic. •None - Disables traffic flow export. The default is All for LAN and WAN interfaces, for all four collectors. The default for the other interfaces (Primary, rios_lan, and rios_wan) is None. You can’t select a MIP interface.
Enable Filter	(CascadeFlow and NetFlow v9 only) Filter flow reports by IP and subnets or IP:ports included in the Filter list. When disabled, reports include all IP addresses and subnets.
Filter	(CascadeFlow and NetFlow v9 only) Specify the IP and subnet or IP:port to include in the report, one entry per line, up to 25 filters maximum. This field supports both IPv4 and IPv6 subnets.
Add	Adds the collector to the Collector list.
Remove Selected	Select the check box next to the name and click Remove Selected.

2. Click Apply to apply your settings.

3. Click Save to Disk to save your settings permanently.

Troubleshooting

To troubleshoot your flow export settings:

•Make sure the port configuration matches on the SteelHead and the listening port of the collector.

•Ensure that you can reach the collector from the SteelHead (for example, –i aux 1.1.1.1 where 1.1.1.1 is the NetFlow collector and aux is the Packet Source Interface).

•Verify that your capture settings are on the correct interface and that traffic is flowing through it.

Joining a Windows domain or workgroup

A server-side SteelHead can join a Windows domain or workgroup in the Optimization > Active Directory: Domain Join page. This page provides a central place for a SteelHead to join a Windows domain or workgroup.

The SteelHead can join a single Windows domain to use these features:

•SMB signing trust for CIFS optimizations. For details, see Configuring SMB signing.

•MAPI 2007 encrypted traffic optimization authentication. For details, see Configuring MAPI optimization.

•MAPI Exchange as a hosted service using Active Directory integrated mode for Windows 2003 and 2008 or later.

RiOS 8.5 and later include an automatic way to join the domain and deploy the server-side SteelHead in Active Directory integrated mode for Windows 2003 and 2008. For details, see Configuring domain authentication automatically.

Domain and local workgroup settings

You can choose between two user authentication modes: domain or local workgroup. Creating a local workgroup eliminates the need to join a Windows domain and simplifies the configuration process, but a workgroup doesn’t support SMB signing, MAPI 2007 encrypted traffic optimization authentication, or MAPI Exchange as a hosted service.

You can join a SteelHead to a domain in Active Directory 2008 integrated mode without administrator privileges. For details, go to the Riverbed Knowledge Base article S18097.

Domain mode

In Domain mode, you configure the SteelHead to join a Windows domain (typically, the domain of your company). When you configure the SteelHead to join a Windows domain, you don’t have to manage local accounts in the branch office, as you do in Local Workgroup mode.

Domain mode allows a domain controller (DC) to authenticate users accessing its file shares. The DC can be located at the remote site or over the WAN at the main data center. The SteelHead must be configured as a Member Server or Active Directory integrated in the Windows 2000 or later Active Directory Services (ADS) domain. Domain users are allowed to use the Kerberos delegation trust facility and NTLM environments for MAPI 2007 encryption or SMB signing based on the access permission settings provided for each user.

Support for one-way trusts include Windows 7 clients without requiring a registry change on the Windows 7 client. You must join the server-side SteelHead to the domain using the Active Directory integrated (Windows 2008 and later) mode. This mode allows the SteelHead to use authentication within the Active Directory environment on the Exchange Servers that provide Microsoft Exchange online services. The domain that the server-side SteelHead joins must be either the same as the client user or any domain that trusts the domain of the client user.

For more information about configuring and joining a domain, see Preconfiguration checklist for joining a SteelHead to a Windows domain.

Local Workgroup mode

In Local Workgroup mode, you define a workgroup and add individual users that have access to the SteelHead. The SteelHead doesn’t join a Windows domain.

Use Local Workgroup mode in environments where you don’t want the SteelHead to be a part of a Windows domain. Creating a workgroup eliminates the need to join a Windows domain and simplifies the configuration process.

If you use Local Workgroup mode you must manage the accounts and permissions for the branch office on the SteelHead. The Local Workgroup account permissions might not match the permissions on the origin-file server.

To configure a Windows domain in Local Workgroup mode

1. Select Optimization > Active Directory: Domain Join to display the Domain Join page.

2. Under Domain/Local, select Local Workgroup Settings, click Select, and then click OK when a dialog asks if you really want to change the setting or reminds you to leave the domain before changing the setting.

3. Complete the configuration as described in this table.

Control	Description
Workgroup Name	Specify a local workgroup name. If you configure in local workgroup mode, the SteelHead doesn’t need to join a domain. Local workgroup accounts are used by clients when they connect to the SteelHead. Starting with RiOS 9.5, this name is not case sensitive.
Add a New User	Displays the controls to add a new user to the local workgroup.
User	Specify the login to create a local workgroup account so that users can connect to the SteelHead.
Password/Password Confirm	Specify and confirm the user account password.
Add	Adds users to the local workgroup.
Remove Selected	Removes the selected names.

4. Click Apply to apply your settings to the running configuration.

5. Click Save to Disk to save your settings permanently.

Preconfiguration checklist for joining a SteelHead to a Windows domain

Follow these guidelines when joining a Windows domain server to a SteelHead. For more information, see the Riverbed Knowledge Base document “Optimization in a Secure Windows Environment” at https://supportkb.riverbed.com/support/index?page=content&id=S25759.

•Make sure that the SteelHead time is synchronized with the domain time and is in the same time zone (for example, Americas/Denver). The time on the SteelHead should be within a few seconds of the domain time; synchronizing the time to an NTP server sets the time on the SteelHead to within a few milliseconds of the Windows domain time. The SteelHead time must be within 5 minutes of the Windows server’s time if using NTLM, and within 30 seconds for Kerberos. See Configuring the date and time to configure an NTP server.

•Ensure that the Primary (management) interface of the SteelHead is connected to your LAN and has connectivity to DNS, NTP, and the Active Directory domain. All domain join and delegation features use the Primary interface.

In addition, check these DNS settings:

–Verify that there is an A record and reverse look-up record present on the DNS server for the primary interface of the SteelHead (which itself must be connected to the LAN).

–Make sure that an Active Directory DNS server is configured that allows the SteelHead to perform lookups. The DNS service must also be able to return domain controller names for each domain. Set or verify the DNS server in the DNS Settings area of the Networking > Networking: Host Settings page. See Modifying general host settings for details.

–Verify that the Active Directory domain suffix (for example, domain.riverbed.com) is added to the DNS Settings area of the Networking > Networking: Host Settings page. See Modifying general host settings for details.

–Make sure that all Windows client computers point to the DNS server that you configure on the SteelHead. To use SMB signing, the server-side SteelHead must be in the DNS. For details, see To specify DNS settings.

If you have issues with SteelHeads attempting to join domains that were not requested or authorized, configure the server-side SteelHead to ignore all trusted domains, and then specify the domains to join. See the Riverbed Knowledge Base article S27002 for details.

•Be sure that the SteelHead hostname is no more than 15 characters. Windows does not allow computer names that exceed 15 characters in Active Directory.

•Verify that the SteelHead hostname does not currently exist in the Computers container from the Active Directory Users and Computers snap-in (adsc.msc). If the SteelHead computer hostname has been retargeted from the default Computers container into an Organizational Unit (OU), verify that container for an existing SteelHead account.

•Be sure to specify a fully qualified domain name (FQDN). This FQDN must be the configured domain name for all Windows desktop computers.

•For RiOS release 9.5 and earlier, make sure that SMB1 (CIFS) is enabled on the domain controller. Starting with RiOS release 9.6, SMB2/3 is supported for the SteelHead domain join operation. See the Riverbed Knowledge Base article S30252 for more information.

•If you configure a SteelHead in Active Directory integrated (Windows 2003) or Active Directory integrated (Windows 2008 and later) mode, specify a Windows user with the ability to add a domain controller to the domain. Typically, any account belonging to the Domain Administrators group can be used.

Do not use an account that’s only able to join a workstation to a domain; these accounts can’t place the SteelHead’s account in the proper group or OU and can’t modify the userAccountControl account attribute in Active Directory for the SteelHead machine account. See the Riverbed Knowledge Base article S22468 for details.

The SteelHead deletes the domain administrator credentials after the domain join is compete; no Windows username or password is retained on the SteelHead.

Do not prepend the domain with the domain name; for example, for a domain of username, specify username not DOMAIN\username.

To use a Windows username without administrative privileges, first create a workstation (computer) account for the SteelHead and assign it additional privileges. See the Riverbed Knowledge Base article S18097 for details.

•If you use Kerberos to join a domain, use these guidelines:

–To verify or add a Kerberos replication user on the server-side SteelHead, display the Service Accounts page and check the field for the Kerberos replication user. See To add Kerberos replication users on the SteelHead for details.

–To enable Kerberos authentication for restricted trust environments, use a one-way trust configuration. For details, see the “One-way trust configuration” chapter in the SteelHead Deployment Guide - Protocols. This configuration is typically required for environments with restricted security: for example, for a trust model that has split resource and management Active Directory domains such as Office 365 or other managed service providers.

•Be sure that the following ports are open to all domain controllers.

Protocol	Port
SMB1, SMB2/3	TCP 139 (legacy Windows implementations) 445 (more recent Windows implementations)
LDAP	TCP/UDP 389
Kerberos	TCP/UDP 88
DNS	UDP 53
SMB1-Named-Pipes, SMB2/3-Named-Pipes	TCP 445
EPM/RPC	TCP 135

To configure a Windows domain in Domain mode

1. Select Optimization > Active Directory: Domain Join to display the Domain Join page.

2. Under Domain/Local, click Domain Settings, click Select, and then click OK when a dialog asks if you really want to change the setting.

3. Complete the configuration as described in this table.

Control	Description
Active Directory Domain Name/Realm	Specify the domain in which to make the SteelHead a member. Typically, this is your company domain name. RiOS supports Windows 2000 or later domains. RiOS doesn’t support nondomain accounts other than administrator accounts. If you create Local mode shares on a nonadministrator account, your security permissions for the share aren’t preserved on the origin-file server.
Primary DNS IP Address	By default, this field displays the primary DNS IP set in the DNS Settings page. To modify this entry, click the IP address.
Join Account Type	Specifies which account type the server-side SteelHead uses to join the domain controller. You can optimize the traffic to and from hosted Exchange servers. You must configure the server-side SteelHead in the Active Directory integrated mode for Windows 2003 or Windows 2008. This allows the SteelHead to use authentication on the Exchange servers that provide Microsoft Exchange online services. The domain that the server-side SteelHead joins must be either the same as the client user or any domain that trusts the domain of the client user. Be aware that when you integrate the server-side SteelHead in the Active Directory, it doesn’t provide any Windows domain controller functionality to any other machines in the domain and doesn’t advertise itself as a domain controller or register any SRV records (service records). In addition, the SteelHead doesn’t perform any replication nor hold any Active Directory objects. The server-side SteelHead has just enough privileges so that it can have a legitimate conversation with the domain controller and then use transparent mode for NTLM authentication. The Active Directory integration provides a way to optimize NTLM authentication from Windows 7/2008 R2 and newer clients when using transparent mode. This scenario is only successful for servers and clients that can make use of NTLM authentication. The server-side SteelHead joins a domain with DC privileges and then uses NTLM pass-through authentication to perform the authentication. Using transparent mode simplifies the configuration. Select one of these options from the drop‑down list: •Active Directory integrated (Windows 2008 and later) - Configures the server-side SteelHead to integrate with the Active Directory domain. This option supports Windows 2008 DCs and higher, supports authentication across domains, and is the default setting for RiOS 9.6 and later. If the network contains any domain controllers running Windows 2003 or older operating system versions, you must explicitly specify a list of Windows 2008 DCs in the Domain Controller Names field; see the instructions under “Domain Controller Name(s)” in this table for details. •Workstation - Joins the server-side SteelHead to the domain with workstation privilege. You can join the domain to this account type using any ordinary user account that has the permission to join a machine to the domain. This is the default setting for RiOS releases earlier than 9.6. •Active Directory integrated (Windows 2003) - Configures the server-side SteelHead to integrate with the Active Directory domain. If the account for the server-side SteelHead was not already present, it’s created in organizational unit (OU) domain controllers. If the account existed previously as a domain computer then its location doesn’t change. You can move the account to a different OU later. When you select Active Directory integrated (Windows 2003), you must specify one or more domain controller name(s), separated by commas. You must have Administrator privileges to join the domain with active directory integration. Active Directory integration doesn’t support cross-domain authentication where the user is from a domain trusted by the domain to which the server-side SteelHead is joined.
	You must have Administrator privileges. Additionally, if the user account is in a domain that is different from the domain to which the join is being performed, specify the user account in the format domain\username. Do not specify the user account in the format username@realmname. In this case, domain is the short domain name of the domain to which the user belongs. Even though the SteelHead is integrated with Active Directory, it doesn’t provide any Windows domain controller functionality to any other machines in the domain.
Domain Login	Specify the login name, which must have domain join privileges. Domain administrator credentials aren’t strictly required, except when you join the domain as an Active Directory integration. RiOS deletes domain administrator credentials after the join.
Password	Specify the password. This control is case sensitive.
Domain Controller Name(s)	Specify the hosts that provide user login service in the domain, separated by commas. (Typically, with Windows 2000 Active Directory Service domains, given a domain name, the system automatically retrieves the DC name.) Specifying domain controller names is required if you are joining the domain in Active Directory integrated mode 2008 and higher, and the network contains domain controllers running Windows 2003 or older operating system versions. We recommend specifying the domain controller names in environments where there’s varying latency between the SteelHead and the domain controllers.
Short Domain Name	Specify the short domain (NetBIOS) name if it doesn’t match the first portion of the Active Directory domain name. Case matters; NBTTECH is not the same as nbttech.
Join/Leave	Joins the domain or leaves the domain. Note: If you are in domain mode and have joined a domain, you can’t change to local workgroup mode until you leave the domain.
Rejoin	Rejoins the domain.
Cancel	Cancels any current domain action that is in progress, such as joining or leaving a domain.

4. Click Apply to apply your settings to the running configuration.

5. Click Save to Disk to save your settings permanently.

When you have successfully joined the domain, the status updates to In a Domain.

The next step is to enable protocol optimization for CIFS (SMB) or encrypted MAPI. See Configuring CIFS optimization and Configuring MAPI optimization.

Troubleshooting a domain join failure

This section describes common problems that can occur when joining a Windows domain.

RiOS 8.5 and later feature a domain health tool to identify, diagnose, and report possible problems with a SteelHead within a Windows domain environment. For details, see Checking domain health.

System time mismatch

The number one cause of failing to join a domain is a significant difference in the system time on the Windows domain controller and the SteelHead. When the time on the domain controller and the SteelHead don’t match, this error message appears:

lt-kinit: krb5_get_init_creds: Clock skew too great

We recommend using NTP time synchronization to synchronize the client and server clocks. It is critical that the SteelHead time is the same as on the Active Directory controller. Sometimes an NTP server is down or inaccessible, in which case there can be a time difference. You can also disable NTP if it isn’t being used and manually set the time. You must also verify that the time zone is correct. For details, see Configuring the date and time.

Select the primary DNS IP address to view the Networking: Host Settings page.

Invalid domain controller IP

A domain join can fail when the DNS server returns an invalid IP address for the Domain Controller. When a DNS misconfiguration occurs during an attempt to join a domain, these error messages appear:

Failed to join domain: failed to find DC for domain <domain name>

Failed to join domain: No Logon Servers

Additionally, the Domain Join alarm triggers and messages similar to these appear in the logs:

Oct 13 14:47:06 bravo-sh81 rcud[10014]: [rcud/main/.ERR] - {- -} Lookup for bravo-sh81.GEN-VCS78DOM.COM Failed

Oct 13 14:47:06 bravo-sh81 rcud[10014]: [rcud/main/.ERR] - {- -} Failed to join domain: failed to find DC for domain GEN-VCS78DOM.COM

When you encounter this error, choose Networking > Networking > Host Settings and verify that the DNS settings are correct.

Related topics

•Configuring SMB signing

•Configuring MAPI optimization

Configuring simplified routing features

You can enable simplified routing in the Networking > Network Integration: Simplified Routing page.

Simplified routing collects the IP address for the next hop MAC address from each packet it receives to address traffic. With simplified routing, you can use either the WAN or LAN side device as a default gateway. The SteelHead learns the right gateway to use by watching where the switch or router sends the traffic, and associating the next-hop Ethernet addresses with IP addresses. Enabling simplified routing eliminates the need to add static routes when the SteelHead is in a different subnet from the client and the server.

Without simplified routing, if a SteelHead is installed in a different subnet from the client or server, you must define one router as the default gateway and static routes for the other routers so that traffic isn’t redirected back through the SteelHead. In some cases, even with the static routes defined, the ACL on the default gateway can still drop traffic that should have gone through the other router. Enabling simplified routing eliminates this issue.

Simplified routing has these constraints:

•WCCP can’t be enabled.

•The default route must exist on each SteelHead in your network.

For detailed configuration information, see the SteelHead Deployment Guide.

The SteelHead (in the cloud) isn’t deployed in-path, but in its unique out-of-path method, using one interface. Simplified routing doesn’t apply.

The simplified routing feature in RiOS 8.5 and later is compatible with IPv6.

To enable simplified routing

1. Choose Networking > Network Integration: Simplified Routing to display the Simplified Routing page.

2. Under Mapping Data Collection Setting, complete the configuration as described in this table.

Control	Description
Collect Mappings From	Select one of these options from the drop‑down list: •None - Does not collect mappings. •Destination Only - Collects mappings from destination IP, destination MAC, and VLAN tag (when deployed on 802.1q trunk). We recommend that you use this setting for most deployments with multiple in-paths or connection forwarding SteelHeads. SteelHeads do not usually learn incorrect mappings unless the network devices themselves are routing incorrectly. This is the default setting. •Destination and Source - Collects mappings from destination and source IP, destination and source MAC, and VLAN tag (when deployed on 802.1q trunk). •All - Collects mappings for destination, source, and inner MAC data. Also collect data for connections that are un-NATted (that is, connections that aren’t translated using NAT).
Enable simplified routing for GRE-tunneled pass-through packets	Enables simplified routing for GRE tunnel pass-through traffic. Enabling this setting avoids packet ricochet between the server-side SteelHead and the server-side SteelHead gateway for pass-through packets from GRE tunnels. This setting applies to TCP and UDP packets.

3. Click Apply to save your settings to the running configuration.

4. Click Save to Disk to save your settings permanently.

Related topics

•In-path rules overview

•Configuring connection forwarding features

Configuring WCCP

You can enable WCCP service groups in the Networking > Network Integration: WCCP page.

WCCP enables you to redirect traffic that isn’t in the direct physical path between the client and the server. To enable WCCP, the SteelHead must join a service group at the router. A service group is a group of routers and SteelHeads that define the traffic to redirect, and the routers and SteelHeads the traffic goes through. You might use one or more service groups to redirect traffic to the SteelHeads for optimization.

RiOS allows each individual SteelHead in-path interface to be configured as a WCCP client. Each configured in-path interface participates in WCCP service groups as an individual WCCP client, providing flexibility to determine load balancing proportions and redundancy.

You must enable connection forwarding in a WCCP cluster. A WCCP cluster refers to two or more SteelHeads participating in the same service group. By default, RiOS provides load balancing across all participating SteelHeads in a WCCP cluster. With connection forwarding enabled, the WCCP load balancing algorithm considers the total number of in-path interfaces of all neighbors in the service group when balancing the traffic load across the interfaces. If you don’t enable connection forwarding, the SteelHead with the lowest IP address assigns all traffic flows to itself.

In virtual in-path configurations, all traffic flows in and out of one physical interface, and the default subnet side rule causes all traffic to appear to originate from the WAN side of the device. For more information, see Configuring subnet side rules.

Enabling WCCP is optional.

WCCP doesn’t support IPv6.

You can also use the CLI to configure WCCP service groups. For detailed configuration information (including configuring the WCCP router), see the SteelHead Deployment Guide.

The AWS SteelHead-c doesn’t support L4/PBR/WCCP configuration. The ESX SteelHead-c supports it.

To enable a WCCP service group

Before configuring your WCCP service group, you must enable L4/PBR/WCCP support in the General Service Settings page. For details, see Configuring general service settings.

1. Choose Networking > Network Integration: WCCP to display the WCCP page.

2. Under WCCP Service Groups, complete the configuration as described in this table.

Control	Description
Enable WCCP v2 Support	Enables WCCPv2 support on all groups added to the Service Group list.
Multicast TTL	Specify the TTL boundary for the WCCP protocol packets. The default value is 16.

3. Click Apply to save your settings to the running configuration.

To add, modify, or remove a service group

1. Under WCCP groups, complete the configuration as described in this table.

Control	Description
Add a New Service Group	Displays the controls for adding a new service group.
Interface	Select a SteelHead interface to participate in a WCCP service group. In virtual in-path configurations, all traffic flows in and out of one physical interface, and the default subnet side rule causes all traffic to appear to originate from the WAN side of the device. RiOS allows multiple SteelHead interfaces to participate in WCCP on one or more routers for redundancy (RiOS 6.0 and earlier allows a single SteelHead interface). If one of the links goes down, the router can still send traffic to the other active links for optimization. You must include an interface with the service group ID. More than one SteelHead in-path interface can participate in the same service group. For WCCP configuration examples, see the SteelHead Deployment Guide. If multiple SteelHeads are used in the topology, they must be configured as neighbors. RiOS 6.5 and later require connection forwarding in a WCCP cluster.
Service Group ID	Enables WCCPv2 support on all groups added to the Service Group list. Specify a number from 0 to 255 to identify the service group on the router. A value of 0 specifies the standard HTTP service group. We recommend that you use WCCP service groups 61 and 62. Note: The service group ID is local to the site where WCCP is used. Note: The service group number is not sent across the WAN.
Protocol	Select a traffic protocol from the drop-down list: TCP, UDP, or ICMP. The default value is TCP.
Password/Password Confirm	Optionally, assign a password to the SteelHead interface. This password must be the same password that is on the router. WCCP requires that all routers in a service group have the same password. Passwords are limited to eight characters.
Priority	Specify the WCCP priority for traffic redirection. If a connection matches multiple service groups on a router, the router chooses the service group with the highest priority. The range is 0 to 255. The default value is 200. The priority value must be consistent across all SteelHeads within a particular service group.
Weight	Specify the percentage of connections that are redirected to a particular SteelHead interface, which is useful for traffic load balancing and failover support. The number of TCP, UDP, or ICMP connections a SteelHead supports determines its weight. The more connections a SteelHead model supports, the heavier the weight of that model. In RiOS 6.1 and later, you can modify the weight for each in-path interface to manually tune the proportion of traffic a SteelHead interface receives. A higher weight redirects more traffic to that SteelHead interface. The ratio of traffic redirected to a SteelHead interface is equal to its weight divided by the sum of the weights of all the SteelHead interfaces in the same service group. For example, if there are two SteelHeads in a service group and one has a weight of 100 and the other has a weight of 200, the one with the weight 100 receives 1/3 of the traffic and the other receives 2/3 of the traffic. However, since it’s generally undesirable for a SteelHead with two WCCP in-path interfaces to receive twice the proportion of traffic, for SteelHeads with multiple in-paths connected, each of the in-path weights is divided by the number of that SteelHead's interfaces participating in the service group. As an example, if there are two SteelHeads in a service group and one has a single interface with weight 100 and the other has two interfaces each with weight 200, the total weight will still equal 300 (100 + 200/2 + 200/2). The one with the weight 100 receives 1/3 of the traffic and each of the other's in-path interfaces receives 1/3 of the traffic. The range is 0 to 65535. The default value corresponds to the number of TCP connections your SteelHead supports. Failover Support To enable single in-path failover support with WCCP groups, define the service group weight to be 0 on the backup SteelHead. If one SteelHead has a weight 0, but another one has a nonzero weight, the SteelHead with weight 0 doesn’t receive any redirected traffic. If all the SteelHeads have a weight 0, the traffic is redirected equally among them. The best way to achieve multiple in-path failover support with WCCP groups is to use the same weight on all interfaces from a given SteelHead for a given service group. For example, suppose you have SteelHead A and SteelHead B with two in-path interfaces each. When you configure SteelHead A with weight 100 from both inpath0_0 and inpath0_1 and SteelHead B with weight 200 from both inpath0_0 and inpath0_1, RiOS distributes traffic to SteelHead A and SteelHead B in the ratio of 1:2 as long as at least one interface is up on both SteelHeads. In a service group, if an interface with a nonzero weight fails, its weight transfers over to the weight 0 interface of the same service group. For details on using the weight parameter to balance traffic loads and provide failover support in WCCP, see the SteelHead Deployment Guide.
Encapsulation Scheme	Specifies the method for transmitting packets between a router or a switch and a SteelHead interface. Select one of these encapsulation schemes from the drop-down list: •Either - Use Layer 2 first; if Layer 2 is not supported, GRE is used. This is the default value. •GRE - Generic Routing Encapsulation. The GRE encapsulation method appends a GRE header to a packet before it’s forwarded. This method can cause fragmentation and imposes a performance penalty on the router and switch, especially during the GRE packet deencapsulation process. This performance penalty can be too great for production deployments. •L2 - Layer-2 redirection. The L2 method is generally preferred from a performance standpoint because it requires fewer resources from the router or switch than the GRE does. The L2 method modifies only the destination Ethernet address. However, not all combinations of Cisco hardware and IOS revisions support the L2 method. Also, the L2 method requires the absence of L3 hops between the router or switch and the SteelHead.
Assignment Scheme	Determines which SteelHead interface in a WCCP service group the router or switch selects to redirect traffic to for each connection. The assignment scheme also determines whether the SteelHead interface or the router processes the first traffic packet. The optimal assignment scheme achieves both load balancing and failover support. Select one of these schemes from the drop-down list: •Either - Uses Hash assignment unless the router doesn’t support it. When the router doesn’t support Hash, it uses Mask. This is the default setting. •Hash - Redirects traffic based on a hashing scheme and the Weight of the SteelHead interface, providing load balancing and failover support. This scheme uses the CPU to process the first packet of each connection, resulting in slightly lower performance. However, this method generally achieves better load distribution. We recommend Hash assignment for most SteelHeads if the router supports it. The Cisco switches that don’t support Hash assignment are the 3750, 4000, and 4500 series, among others. Your hashing scheme can be a combination of the source IP address, destination IP address, source port, or destination port. •Mask - Redirects traffic operations to the SteelHeads, significantly reducing the load on the redirecting router. Mask assignment processes the first packet in the router hardware, using less CPU cycles and resulting in better performance. Mask assignment supports load-balancing across multiple active SteelHead interfaces in the same service group. The default mask scheme uses an IP address mask of 0x1741, which is applicable in most situations. However, you can change the IP mask by clicking the service group ID and changing the service group settings and flags. In multiple SteelHead environments, it’s often desirable to send all users in a subnet range to the same SteelHead. Using mask provides a basic ability to leverage a branch subnet and SteelHead to the same SteelHead in a WCCP cluster. For details and best practices for using assignment schemes, see the SteelHead Deployment Guide. Note: If you use mask assignment you must ensure that packets on every connection and in both directions (client-to-server and server-to-client), are redirected to the same SteelHead. For details, see the SteelHead Deployment Guide.
Source	•IP Mask - Specify the service group source IP mask. The default value is 0x1741. •Port Mask - Specify the service group source port mask. •IP Hash - Specify that the router hash the source IP address to determine traffic to redirect. •Port Hash - Specify that the router hash the source port to determine traffic to redirect.
Destination	•IP Mask - Specify the service group destination IP mask. •Port Mask - Specify the service group destination port mask. •IP Hash - Specify that the router hash the destination IP address to determine traffic to redirect. •Port Hash - Specify that the router hash the destination port to determine traffic to redirect.
Ports Mode	Select one of these modes from the drop-down list: •Ports Disabled - Select to disable the ports. •Use Source Ports - The router determines traffic to redirect based on source ports. •Use Destination Ports - The router determines traffic to redirect based on destination ports.
Ports	Specify a comma-separated list of up to seven ports that the router will redirect. Use this option only after selecting either the Use Source Ports or the Use Destination Ports mode.
Router IP Address(es)	Specify a multicast group IP address or a unicast router IP address. You can specify up to 32 routers.
Add	Adds the service group.
Remove Selected Groups	Select the check box next to the name and click Remove Selected Groups.

2. Click Apply to save your settings to the running configuration.

3. Click Save to Disk to save your settings permanently.

Verifying a multiple in-path interface configuration

This section describes how to verify that multiple SteelHeads are participating in WCCP with one or more routers using a multiple in-path interface configuration.

1. Because the SteelHeads are configured as neighbors, messages appear in the log at INFO level when the neighbors connect to each other, and the log displays a list of in-path IP addresses.

2. When the weight computation is about to begin, a message appears in the log at INFO level that the SteelHead interface with the lowest IP address is taking over as the lead cache.

3. When the weight computation is complete, a REDIRECT_ASSIGN WCCP message appears from the SteelHead interface with the lowest IP address. This message includes the load balancing information from the hash or mask value table.

For more WCCP troubleshooting, see the SteelHead Deployment Guide.

Modifying WCCP group settings

You modify WCCP service group settings, add additional routers to a service group, and set flags for source and destination ports to redirect traffic (that is, the hash table settings) in the Networking > WCCP Service Group: <group ID> page.

Before you can modify WCCP service group settings, you must create a WCCP service group. For details about creating a WCCP service group, see Configuring WCCP.

When you are modifying service group settings in RiOS 6.1 or later, the service group description includes the interface.

To modify WCCP service group settings

1. Choose Networking > Network Integration: WCCP to display the WCCP page.

2. Select the service group ID in the Groups list to expand the page.

3. Under Editing Service Group <name><interface>, modify the settings.

4. Click Apply to save your settings to the running configuration.

5. Click Save to Disk to save your settings permanently.

Related topics

•Configuring general service settings

•Verifying a multiple in-path interface configuration

Configuring hardware-assist rules

You configure hardware-assist rules in the Networking: Network Services > Hardware Assist Rules page. This feature only appears on a SteelHead equipped with one or more Two-Port SR Multimode Fiber 10 Gigabit-Ethernet or Two-Port LR Single Mode Fiber 10 Gigabit-Ethernet PCI-E cards.

Hardware-assist rules can automatically bypass all UDP (User Datagram Protocol) connections. You can also configure rules for bypassing specific TCP (Transmission Control Protocol) connections. Automatically bypassing these connections decreases the work load on the local SteelHeads because the traffic is immediately sent to the kernel of the host machine or out of the other interface before the SteelHead receives it.

The maximum number of hardware-assist rules is 50.

To be safe, change hardware-assist rules only during a maintenance window, or during light traffic and with a full understanding of the implications. For details and best practices, see the Knowledge Base article Best Practices for Enabling Hardware Assist Passthrough (HAP) Rules http://supportkb.riverbed.com/support/index?page=content&id=S12992.

For a hardware-assist rule to be applied to a specific 10G bypass card, the corresponding in-path interface must be enabled and have an IP address.

To configure hardware-assist rules

1. Choose Networking > Network Services: Hardware Assist Rules to display the Hardware Assist Rules page.

2. Under 10G NIC Hardware Assist Rules Settings, enable pass-through as follows:

–To automatically pass through all UDP traffic, select the Enable Hardware Passthrough of All UDP Traffic check box.

–To pass through TCP traffic based on the configured rules, select the Enable Hardware Passthrough of TCP Traffic Defined in the Rules Below check box. TCP pass-through is controlled by rules. The next step describes how to step up hardware-assist rules.

RiOS ignores all hardware-assist rules unless you select this check box. No TCP traffic is passed through.

3. Under TCP Hardware Assist Rules, complete the configuration as described in this table.

Control	Description
Add a New Rule	Displays the controls for adding a new rule.
Type	Select a rule type: •Accept - Accepts rules matching the Subnet A or Subnet B IP address and mask pattern for the optimized connection. •Pass-Through - Identifies traffic to be passed through the network unoptimized.
Insert Rule At	Determines the order in which the system evaluates the rule. Select Start, End, or a rule number from the drop-down list. The system evaluates rules in numerical order starting with rule 1. If the conditions set in the rule match, then the rule is applied and the system moves on to the next rule: for example, if the conditions of rule 1 don’t match, rule 2 is consulted. If rule 2 matches the conditions, it is applied, and no further rules are consulted. In general, filter traffic that is to be unoptimized, discarded, or denied before processing rules for traffic that is to be optimized.
Subnet A	Specify an IP address and mask for the subnet that can be both source and destination together with Subnet B. Use this format: xxx.xxx.xxx.xxx/xx Note: You can specify all or 0.0.0.0/0 as the wildcard for all traffic.
Subnet B	Specify an IP address and mask for the subnet that can be both source and destination together with Subnet A. Use this format: xxx.xxx.xxx.xxx/xx Note: You can specify all or 0.0.0.0/0 as the wildcard for all traffic.
VLAN Tag ID	Optionally, specify a numeric VLAN tag identification number. Select all to specify the rule applies to all VLANs. Select untagged to specify the rule applies to nontagged connections. Note: Pass-through traffic maintains any preexisting VLAN tagging between the LAN and WAN interfaces. Note: To complete the implementation of VLAN tagging, you must set the VLAN tag IDs for the in-path interfaces that the SteelHead uses to communicate with other SteelHeads. For details about configuring the in-path interface for the SteelHead, see Configuring in-path rules.
Description	Optionally, include a description of the rule.
Add	Adds the new hardware-assist rule to the list. You can add up to a maximum number of 50 rules. •RiOS applies the same rule to both LAN and WAN interfaces. •Every 10G card has the same rule set. The SteelHead refreshes the hardware-assist rules table and applies your modifications to the running configuration, which is stored in memory.
Remove Selected Rules	Select the check box next to the name and click Remove Selected Rules.
Move Selected Rules	Moves the selected rules. Click the arrow next to the desired rule position; the rule moves to the new position.

4. Click Apply to apply your settings to the running configuration.