This chapter describes how to enable and configure optimization features. It includes these topics:

You configure general optimization service settings in the Optimization > Network Services: General Service Settings page.

General Service Settings include controls to enable or disable in-path, out-of-path, failover support, and to set connection limits and the maximum connection pooling size.

If you have a SteelHead that contains multiple bypass cards, the Management Console displays options to enable in-path support for these ports. The number of these interface options depends on the number of pairs of LAN and WAN ports that you have enabled in your SteelHead.

The properties and values you set in this page depend on your deployment. For example, these deployment types would require different choices:

For an overview of in-path and out-of-path deployment options, see the SteelHead Deployment Guide.

In the event of appliance failure, the SteelHead enters bypass mode to avoid becoming a single point of failure in your network. If you want optimization to continue in the event of appliance failure, you can deploy redundant appliances as failover buddies.

For details about failover redundancy, see the SteelHead Deployment Guide.

For a physical in-path failover deployment, you configure a pair of SteelHeads: one as a master and the other as a backup. The master SteelHead in the pair (usually the SteelHead closest to the LAN) is active and the backup SteelHead is passive. The master SteelHead is active unless it fails for some reason. The backup is passive while the master is active and becomes active if either the master fails or the master reaches its connection limit and enters admission control status. A backup SteelHead doesn’t intercept traffic while the master appliance is active. It pings the master SteelHead to make sure that it is alive and processing data. If the master SteelHead fails, the backup takes over and starts processing all of the connections. When the master SteelHead comes back up, it sends a message to the backup that it has recovered. The backup SteelHead stops processing new connections (but continues to serve old ones until they end).

For an out-of-path failover deployment, you deploy two server-side SteelHeads and add a fixed-target rule to the client-side SteelHead to define the master and backup target appliances. When both the master and backup SteelHeads are functioning properly, the connections traverse the master appliance. If the master SteelHead fails, subsequent connections traverse the backup SteelHead.

The master SteelHead uses an Out-of-Band (OOB) connection. The OOB connection is a single, unique TCP connection that communicates internal information only; it doesn’t contain optimized data. If the master SteelHead becomes unavailable, it loses this OOB connection and the OOB connection times out in approximately 40 to 45 seconds. After the OOB connection times out, the client-side SteelHead declares the master SteelHead unavailable and connects to the backup SteelHead.

During the 40 to 45 second delay before the client-side SteelHead declares a peer unavailable, it passes through any incoming new connections; they’re not blackholed.

While the client-side SteelHead is using the backup SteelHead for optimization, it attempts to connect to the master SteelHead every 30 seconds. If the connection succeeds, the client-side SteelHead reconnects to the master SteelHead for any new connections. Existing connections remain on the backup SteelHead for their duration. This is the only time (immediately after a recovery from a master failure) that connections are optimized by both the master SteelHead and the backup.

If both the master and backup SteelHeads become unreachable, the client-side SteelHead tries to connect to both appliances every 30 seconds. Any new connections are passed through the network unoptimized.

In addition to enabling failover and configuring buddy peering, you must synchronize the RiOS data stores for the master-backup pairs to ensure optimal use of SDR for warm data transfer. With warm transfers, only new or modified data is sent, dramatically increasing the rate of data transfer over the WAN. For information on synchronizing RiOS data stores for master-backup pairs, see Synchronizing peer RiOS data stores.

In the General Service Settings page, you can also modify default settings for the maximum half-opened connections from a single source IP address and the connection pool size. For details, pay careful attention to the configuration descriptions included in the following procedure.

This section describes how to enable peering and configure peering rules. It includes these topics:

With enhanced automatic discovery, the SteelHead automatically finds the furthest SteelHead peer in a network and optimization occurs there. By default, enhanced autodiscovery is enabled. When enhanced autodiscovery is disabled, the SteelHead uses regular autodiscovery. With regular autodiscovery, the SteelHead finds the next appliance in the group and optimization occurs there.

In some deployments, enhanced autodiscovery can simplify configuration and make your deployments more scalable. When enhanced autodiscovery is enabled, the SteelHead automatically finds the furthest SteelHead in a network and optimization occurs there. For example, if you had a deployment with four SteelHeads (A, B, C, D), where D represents the appliance that is furthest from A, the SteelHead automatically finds D. This feature simplifies configuration and makes your deployment more scalable.

We recommend enhanced autodiscovery for the deployments described in this table.

For details about these deployment types, see the SteelHead Deployment Guide.

RiOS supports a large number of peers (up to 20,000) per SteelHead. This feature is available only on the SteelHead CX5070, CX7070, CX5080, CX7080, and GX10000. We recommend enabling the extended peer table if you have more than 4,000 peers. After enabling extended peer table support, you must clear the RiOS data store and stop and restart the service. See Configuring peering.

You display, add, and modify autodiscovery peering settings in the Optimization > Network Services: Peering Rules page. You can also enable extended peer table support.

Peering rules control SteelHead behavior when it sees probe queries.

Peering rules are an ordered list of fields a SteelHead uses to match with incoming SYN packet fields (for example, source or destination subnet, IP address, VLAN, or TCP port) as well as the IP address of the probing SteelHead. This feature is especially useful in complex networks.

The Peering Rules page displays a list of peering rules. The list contains the default peering rules and any peering rules you add.

The system evaluates the rules in numerical order starting with rule 1. If the conditions set in the rule match, then the rule is applied. If the conditions set in the rule don’t match, then the rule isn’t 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.

The Rule Type of a matching rule determines which action the SteelHead takes on the connection.

The default peering rules are adequate for typical network configurations, such as in-path configurations. However, you might need to add peering rules for complex network configurations. For details about deployment cases requiring peering rules, see the SteelHead Deployment Guide.

Enhanced autodiscovery greatly reduces the complexities and time it takes to deploy SteelHeads. It works so seamlessly that occasionally it has the undesirable effect of peering with SteelHeads on the Internet that aren’t in your organization's management domain or your corporate business unit. When an unknown (or unwanted) SteelHead appears connected to your network, you can create a peering rule to prevent it from peering and remove it from your list of peers. The peering rule defines what to do when a SteelHead receives an autodiscovery probe from the unknown SteelHead.

After you add the peering rule, the unknown SteelHead appears in the Current Connections report as a Connected Appliance until the connection times out. After the connection becomes inactive, it appears dimmed. To remove the unknown appliance completely, restart the optimization service.

You configure NAT IP address mapping for the SteelHead (in the cloud) in the Optimization > Cloud: NAT IP Address Mapping page.

You configure the discovery service in the Optimization > Cloud: Discovery Service page. The discovery service enables the SteelHead (in the cloud) or SteelHead (virtual edition) appliance to find and propagate the public and private IP address of the SteelHead (in the cloud) or SteelHead (virtual edition) appliance.

The system displays the following discovery service information: node ID, node key, discovery type, polling interval, and portal URL.

The Optimization Groups table displays the group name and the load balancing policy of the optimization groups that you configured in the Riverbed Cloud Portal. Click the group name to display more information about the list of nodes in each group. Click the node to display more information about the node, such as the load balancing policy, node ID, public interfaces, and local interfaces.

This section describes how to configure RiOS data store settings. It includes these topics:

You display and modify RiOS data store settings in the Optimization > Data Replication: Data Store page. This page is typically used to enable RiOS data store encryption and synchronization.

SteelHeads transparently intercept and analyze all of your WAN traffic. TCP traffic is segmented, indexed, and stored as segments of data, and the references representing that data are stored on the RiOS data store within SteelHeads on both sides of your WAN. After the data has been indexed, it is compared to data already on the disk. Segments of data that have been seen before aren’t transferred across the WAN again; instead a reference is sent in its place that can index arbitrarily large amounts of data, thereby massively reducing the amount of data that needs to be transmitted. One small reference can refer to megabytes of existing data that has been transferred over the WAN before.

You enable RiOS data store encryption in the Optimization > Data Replication: Data Store page.

Encrypting the RiOS data store significantly limits the exposure of sensitive data in the event an appliance is compromised by loss, theft, or a security violation. The secure data is difficult for a third party to retrieve.

Before you encrypt the RiOS data store, you must unlock the secure vault. The secure vault stores the encryption key. For details, see Unlocking the secure vault.

Encrypting the RiOS data store can have performance implications; generally, higher security means less performance. Several encryption strengths are available to provide the right amount of security while maintaining the desired performance level. When selecting an encryption type, you must evaluate the network structure, the type of data that travels over it, and how much of a performance trade-off is worth the extra security.

The SteelHead can’t use an encrypted RiOS data store with an earlier RiOS software version, unless the version is an update (8.0.x). For example, an encrypted RiOS data store created in 8.0.2 would work with 8.0.3, but not with 8.5.

Before downgrading to an earlier version, you must select none as the encryption type, clear the RiOS data store, and restart the service. After you clear the RiOS data store, the data is removed from persistent storage and can’t be recovered.

If you return to a previous software version and there’s a mismatch with the encrypted RiOS data store, the status bar indicates that the RiOS data store is corrupt. You can either:

For deployments requiring the highest levels of redundancy and performance, RiOS supports warm standby between designated master and backup devices. RiOS data store synchronization enables pairs of local SteelHeads to synchronize their data stores with each other, even while they’re optimizing connections. RiOS data store synchronization is typically used to ensure that if a SteelHead fails, no loss of potential bandwidth savings occurs, because the data segments and references are on the other SteelHead.

You can use RiOS data store synchronization for physical in-path, virtual in-path, or out-of-path deployments. You enable synchronization on two SteelHeads, one as the synchronization master, and the other as the synchronization backup.

The traffic for RiOS data store synchronization is transferred through either the SteelHead primary or auxiliary network interfaces, not the in-path interfaces.

RiOS data store synchronization is a bidirectional operation between two SteelHeads, regardless of which deployment model you use. The SteelHead master and backup designation is only relevant in the initial configuration, when the master SteelHead RiOS data store essentially overwrites the backup SteelHead RiOS data store.

The synchronization master and its backup:

When you have configured the master and backup appliances, you must restart the optimization service on the backup SteelHead. The master restarts automatically.

After you have enabled and configured synchronization, the RiOS data stores are actively kept synchronized. For details about how synchronized appliances replicate data and how RiOS data store synchronization is commonly used in high-availability designs, see the SteelHead Deployment Guide.

The appliance continues to write data references to the RiOS data store until it reaches capacity. In certain situations, you must clear the RiOS data store. For example, you must clear the RiOS data store:

For details about clearing the RiOS data store, see Rebooting and shutting down the SteelHead.

You enable branch warming for SteelHead Mobiles in the Optimization > Data Replication: Data Store page. By default, branch warming is enabled.

Branch warming keeps track of data segments created while a SteelCentral Controller for SteelHead Mobile user is in a SteelHead-enabled branch office and sends the new data back to the SteelCentral Controller for SteelHead Mobile user’s laptop. When the user leaves the branch office, the SteelCentral Controller for SteelHead Mobile client provides warm performance.

Branch warming cooperates with and optimizes transfers for a server-side SteelHead. New data transfers between the client and server are populated in the SteelCentral Controller for SteelHead Mobile RiOS data store, the branch SteelHead RiOS data store, and the server-side SteelHead RiOS data store.

When the server downloads data, the server-side SteelHead checks if either the SteelHead Mobile or the branch SteelHead has the data in their RiOS data store. If either device already has the data segments, the server-side SteelHead sends only references to the data. The SteelHead Mobile and the branch SteelHead communicate with each other to resolve the references.

Other clients at a branch office benefit from branch warming as well, because data transferred by one client at a branch also populates the branch SteelHead RiOS data store. Performance improves with all clients at the branch because they receive warm performance for that data. For details, see the SteelHead Deployment Guide.

These requirements must be met for branch warming to work:

Branch warming doesn’t improve performance for configurations using:

You enable RiOS data store wrap notifications in the Optimization > Data Replication: Data Store page. By default, data store wrap notifications are enabled.

This feature triggers an SNMP trap and sends an email when data in the RiOS data store is replaced with new data before the time period specified.

You enable settings to improve network and RiOS data store performance in the Optimization > Data Replication: Performance page. This section describes the default settings and the cases in which you might consider changing the default values.

The RiOS data store segment replacement policy selects the technique used to replace the data in the RiOS data store. While the default setting works best for most SteelHeads, occasionally we recommend changing the policy to improve performance.

You optimize the RiOS data store for high-throughput Data Replication (DR) or data center workloads in the Optimization > Data Replication: Performance page.

You might benefit from changing the performance settings if your environment uses a high-bandwidth WAN. DR and Storage Area Network (SAN) replication workloads at these high throughputs might benefit from the settings that enhance RiOS data store performance while still receiving data reduction benefits from SDR.

To maintain consistent levels of performance, we recommend using separate SteelHeads for DR workloads than for optimization of other application traffic.

The adaptive data streamlining mode monitors and controls the different resources available on the SteelHead and adapts the utilization of these system resources to optimize LAN throughput. Changing the default setting is optional; we recommend you select another setting only with guidance from Riverbed Support or the Riverbed Sales Team.

Generally, the default setting provides the most data reduction. When choosing an adaptive streamlining mode for your network, contact Riverbed Support to help you evaluate the setting based on:

Use the CPU settings to balance throughput with the amount of data reduction and balance the connection load. The CPU settings are useful with high-traffic loads to scale back compression, increase throughput, and maximize Long Fat Network (LFN) utilization.

You can accelerate SaaS application traffic by registering a SteelHead with a SteelConnect Manager (SCM) that is set up for SaaS acceleration.

When you set up SaaS acceleration on SCM, SCM deploys and manages a SaaS service cluster in the cloud. Once registered, SteelHeads (and SteelHead Mobile clients) peer with the SaaS service cluster to accelerate the SaaS traffic.

The SaaS Accelerator feature also includes proxy certificate management to simplify the deployment process.

Before you can set up the SteelHead and accelerate SaaS traffic, you need to perform these steps on the SteelConnect Manager:

See the SteelConnect Manager User Guide and the SaaS Accelerator User Guide for detailed configuration information.

When you have configured SteelConnect Manager for SaaS acceleration, you can configure SteelHead as a client.

We strongly recommend that you configure and push SaaS acceleration policies from a SteelCentral Controller for SteelHead to the SteelHeads, particularly with large scale deployments and production networks with multiple SteelHeads. For details, see “Configuring SaaS acceleration on multiple SteelHeads using SCC” on page 91.

In SCC 9.9.1 and later, you can configure SaaS acceleration on managed SteelHeads. SaaS Accelerator requires an additional license, but the license is not installed on the SCC and SteelHeads; it is installed on SCM.

To accelerate SaaS application traffic using your managed SteelHeads, register your SCC with an SCM that is set up for SaaS acceleration. After registering the SCC with SCM, register selected SteelHeads or a group of SteelHeads with SCM. Once registered, SteelHeads peer with the SaaS service cluster to accelerate the SaaS traffic. Make sure you move the registered SCC and SteelHead appliances to the whitelist on SCM.

On the SCC policies that include SaaS acceleration, make sure you perform these configurations:

For more details about configuring SaaS acceleration on managed SteelHeads, see the SteelCentral Controller for SteelHead User Guide.

Once configured, you can use the SaaS Acceleration Status panel to monitor activity. This panel shows all SaaS applications configured for acceleration and shows the status of their in-path rules.

The SteelHead gets data from the SteelConnect Manager every five minutes and shows the time for the displayed data. Click Refresh Data to get the latest information.

To cancel the acceleration, click Deregister. This action also removes all related in-path rules.

Configure the cloud acceleration service for Software as a Service (SaaS) applications such as Office 365 and Salesforce.com in the Optimization > SaaS: Legacy Cloud Accelerator page. The SteelHead Legacy Cloud Accelerator combines RiOS with the Akamai internet route optimization technology to accelerate SaaS application performance.

To enable SaaS applications for use with SteelHeads, follow the steps in Activating SaaS applications.

Before you configure the SteelHead Cloud Accelerator on the SteelHead, be sure to configure the following:

Enabling optimization for SaaS applications on SteelHead appliances requires configuration on both the Riverbed Cloud Portal and the SteelHead. Enabling a SaaS application on the Riverbed Cloud Portal makes that application available to all registered SteelHeads, while enabling a SaaS application on the SteelHead activates optimization for that application on that SteelHead.

After you enable optimization, you can run reports to view optimization statistics.

You enable prepopulation and add, modify, and delete prepopulation shares in the Optimization > Protocols: CIFS Prepopulation page.

The prepopulation operation effectively performs the first SteelHead read of the data on the prepopulation share. Later, the SteelHead handles read and write requests as effectively as with a warm data store. With a warm data store, RiOS sends data references along with new or modified data, dramatically increasing the rate of data transfer over the WAN.

The first synchronization, or the initial copy, retrieves data from the origin file server and copies it to the RiOS data store on the SteelHead. Subsequent synchronizations are based on the synchronization interval.

The RiOS 8.5 and later Management Consoles include policies and rules to provide more control over which files the system transfers to warm the RiOS data store. A policy is a group of rules that select particular files to prepopulate. For example, you can create a policy that selects all PDF files larger than 300 MB created since January 1, 2017.

CIFS Prepopulation is disabled by default.

After you add a share, the CIFS prepopulation page includes the share in the Share table. The Share table provides an editable list of shares along with each share’s remote pathname, the date and time the next synchronizations will occur, the status, and any comments about the share.

When the status reports that the share has an error, mouse over the error to reveal details about the error.

After adding a CIFS prepopulation share, you can edit it from the Configuration tab. You can create a policy (group of rules) to apply to the share, and you can schedule a date and time for share synchronization.

After adding a CIFS prepopulation share, you can synchronize the share or perform a dry run of what would be synchronized.

After adding a CIFS prepopulation share, you can view CIFS prepopulation share logs to see more detail regarding recent synchronizations, the initial copy of the share, or the last share synchronization.

To print the report, choose File > Print in your web browser to open the Print dialog box.

This section describes how to configure TCP, satellite optimization, and high-speed TCP settings. It includes these topics:

You configure TCP, high-speed TCP, and satellite optimization settings in the Optimization > Network Services: Transport Settings page.

Riverbed provides satellite WAN optimization to overcome the common sources of performance loss associated with space networking. Satellite optimization allows for more effective use of satellite channels, while providing improved user experiences and increased productivity.

SkipWare, an exclusive technology in the Riverbed product family, senses increases and decreases in bandwidth allocation and automatically adjusts its transmission window in response, without requiring user intervention.

RiOS includes compatibility settings for the Space Communications Protocol Standards (SCPS) protocol suite. SCPS is designed to allow communication over challenging environments. Originally, it was developed jointly by NASA and DOD’s USSPACECOM to meet their various needs and requirements. Through a collaborative, multiyear R&D effort, the partnership created the Space Communications Protocol Standards-Transport Protocol (SCPS-TP, commonly referred to as “skips”). This protocol now meets the needs of the satellite and wireless communities.

Unlike TCP, the SCPS protocol was designed to operate in an environment of high latency and limited bandwidth. The first commercial implementation of the SCPS protocol was released under the brand name SkipWare.

To use the SkipWare discovery mechanisms, you must have a SCPS license.

SkipWare is enabled automatically when the license is installed, regardless of which transport optimization method is selected (for example, standard TCP, high-speed TCP, or bandwidth estimation). After installing the SkipWare license, you must restart the optimization service.

The basic RiOS license includes non-SkipWare options such as bandwidth estimation and standard TCP.

To change SkipWare settings, you must have role-based permission to use the Optimization Service role. For details, see Managing user permissions.

For details and example satellite deployments, see the SteelHead Deployment Guide.

You configure satellite optimization settings depending on the connection type. This section describes the connection types. For details about the SCPS discovery process used in various device scenarios, see the SteelHead Deployment Guide.

A RiOS and SCPS connection is established between two SteelHeads. Because both SteelHeads are SCPS compatible, this is a double-ended connection that benefits from traditional RiOS optimization (SDR and LZ). A RiOS and SCPS connection works with all RiOS features.

A single-ended interception (SEI) connection is established between a single SteelHead paired with a third-party device running TCP-PEP (Performance Enhancing Proxy). Both the SteelHead and the TCP-PEP device are using the SCPS protocol to speed up the data transfer on a satellite link or other high-latency links. In the following figure, the SteelHead replaces a third-party device running TCP-PEP in the data center, but the SteelHead can also reside in the branch office. Because there’s only one SteelHead that intercepts the connection, this is called a single-ended interception.

Because a single-ended interception connection communicates with only one SteelHead, it:

To configure satellite optimization for an SEI, you define SEI connection rules. The SteelHead uses SEI connection rules to determine whether to enable or pass-through SCPS connections.

We recommend that for SEI configurations in which the SteelHead initiates the SCPS connection on the WAN, you add an in-path pass-through rule from the client to the server. While the pass-through rule is optional, without it the SteelHead probes for another SteelHead, and when it doesn’t locate one, will failover. Adding the in-path pass-through rule speeds up setup by eliminating the autodiscovery probe and subsequent failover.

The in-path pass-through rule isn’t necessary on SEI configurations in which the SteelHead terminates the SCPS connection on the WAN, because in this configuration the SteelHead evaluates only the SEI connection rules table and ignores the in-path rules table.

SEI connections count toward the connection count limit on the SteelHead.

To properly configure transport settings for your environment, you must understand its characteristics. For information on gathering performance characteristics for your environment, see the SteelHead Deployment Guide.

The buffer settings in the Transport Settings page support high-speed TCP and are also used in data protection scenarios to improve performance. For details about data protection deployments, see the SteelHead Deployment Guide.

To properly configure buffer settings for a satellite environment, you must understand its characteristics. For information on gathering performance characteristics for your environment, see the SteelHead Deployment Guide.

You can optionally add rules to control single-ended SCPS connections. The SteelHead uses these rules to determine whether to enable or pass through SCPS connections.

A SteelHead receiving a SCPS connection on the WAN evaluates only the single-ended connection rules table.

To pass through a SCPS connection, we recommend setting both an in-path rule and a single-ended connection rule.

The high-speed TCP (HS-TCP) feature provides acceleration and high throughput for high-bandwidth links (also known as long fat networks, or LFNs) for which the WAN pipe is large but latency is high. HS-TCP is activated for all connections that have a BDP larger than 100 packets.

This table describes the basic steps needed to configure high-speed TCP.

You configure service port settings in the Optimization > Network Services: Service Ports page.

Service ports are the ports used for inner connections between SteelHeads.

You can configure multiple service ports on the server-side of the network for multiple QoS mappings. You define a new service port and then map destination ports to that port, so that QoS configuration settings on the router are applied to that service port.

Configuring service port settings is optional.

You create domain labels in the Networking > App Definitions: Domain Labels page.

Domain labels are names given to a group of domains to streamline configuration. You can specify an internet domain with wildcards to define a wider group. For example, you can create a domain label called Office365 and add *.microsoftonline.com, *.office365.com, or *.office.com.

Domain labels provide flexible domain and hostname-based interception through a dynamic IP address to accommodate network environments that are changing from static to dynamic IP addresses.

Domain labels are optional.

Use domain labels to:

Domain labels have these dependencies:

You add or delete domains in the Domain Labels page.

You create host labels in the Networking > App Definitions: Host Labels page.

Host labels are names given to sets of hostnames and subnets to streamline configuration. Host labels provide flexibility because you can create a logical set of hostnames to use in place of a destination IP/subnet and then apply a rule, such as a QoS rule or an in-path rule, to the entire set instead of creating individual rules for each hostname or IP subnet.

When you define hostnames in host labels (as opposed to subnets), RiOS performs a DNS query and retrieves a set of IP addresses that correspond to that fully qualified domain name (hostname). It uses these IP addresses to match the destination IP addresses for a rule using the host label. You can also specify a set of IP subnets in a host label to use as the destination IP addresses for a rule using the host label.

Host labels are compatible with autodiscover, passthrough, and fixed-target (not packet mode) in-path rules. Host labels aren’t compatible with IPv6.

Host labels are optional.

RiOS includes a predefined host label, _cloud-accel-saas_, that detects any IP addresses that carry Legacy Cloud Accelerator-enabled SaaS traffic automatically. As SaaS applications are added or deleted, the host label is automatically updated with the list of associated IP addresses. This host label removes the requirement that domain rules and Cloud Acceleration be mutually exclusive.

Use the _cloud-accel-saas_ host label with an Auto Discover in-path rule, and set Cloud Acceleration to Auto.

You can also use the _cloud-accel-saas_ host label with the in-path rule auto-discover CLI command, specifying cloud-accel as auto and including the dst-host _cloud-accel-saas_ parameter. See the Riverbed Command-Line Interface Reference Manual for details.

You can define a set of file servers in a host label, use that host label in a single QoS or in-path rule, and apply a policy limiting all IP traffic to and from the servers (independent of what protocol or application is in use).

Other ways to use host labels:

RiOS resolves hostnames through a DNS server immediately after you add a new host label or after you edit an existing host label. RiOS also automatically re-resolves hostnames once daily. If any problems arise during the automatic or manual hostname resolution, the summary section of the host labels page alerts you quickly that there’s a problem.

RiOS relays any changes in IP addresses to QoS or in-path rules after resolving them; you don’t need to update the host label in QoS or in-path rules.

When you know that the IP addresses associated with a hostname have been updated in the DNS server, and you don’t want to wait until the next scheduled resolution, you can resolve the hostnames manually. After you resolve the hostname cache manually, RiOS schedules the next resolve time to be 24 hours in the future.

When the system resolves a hostname, the elapsed time appears next to the Resolved label.

The summary section displays this information:

You add or delete hostnames or subnets associated with a host label in the Host Labels page.

You create port labels in the Networking > App Definitions: Port Labels page.

Port labels are names given to sets of port numbers. You use port labels when configuring in-path rules in place of individual port numbers. For example, you can use port labels to define a set of ports for which the same in-path, peering, QoS classification, and QoS marking rules apply.

This table summarizes the port labels that are provided by default.

If you don’t want to automatically forward traffic on interactive, RBT-Proto, secure ports or FTP, you must delete the Interactive, RBT-Proto, Secure, and FTP in-path rules. For details, see In-path rules overview.

For information on common port assignments, see SteelHead Ports.

This feature is optional.

You add or delete ports associated with a port label in the Port Label: <Port Label Name> page.

This section describes how to optimize CIFS. It includes these topics:

You display and modify CIFS optimization and SMB signing settings in the Optimization > Protocols: CIFS (SMB1) page and the Optimization > Protocols: SMB2/3 pages.

This section lists and describes new CIFS and SMB features and enhancements by RiOS version.

For all SteelHead models except CX580, CX780, and CX3080, CIFS latency optimization doesn’t require a separate license. The CX580, CX780, and CX3080 models require the Standard licensing tier or better.

SMB1 is enabled by default. Typically, you disable CIFS optimizations only to troubleshoot the system.

CIFS SMB1 optimization performs latency and SDR optimizations on SMB1 traffic. Without this feature, SteelHeads perform only SDR optimization without improving CIFS latency.

This section describes the SMB support changes with recent versions of RiOS.

Enabling SMB3 on a SteelHead also enables support for SMB 3.1.1 to accelerate file sharing among Windows 10 clients to Windows Server 16 or Windows VNext (server). RiOS supports latency and bandwidth optimization for SMB 3.1.1 when SMB2/3 and SMB2 signing is enabled and configured. SMB 3.1.1 adds these encryption and security improvements:

The server-side SteelHeads must be joined to the domain in Active Directory Integrated Windows 2008 or later.

With the exception of service accounts configuration, you can complete all of the above settings on the server-side SteelHead by using the Configure Domain Auth widget. See Easy domain authentication configuration.

In RiOS 9.0 and later, enabling SMB3 on a SteelHead also enables support for the SMB 3.02 dialect introduced by Microsoft in Windows 8.1 and Windows Server 2012 R2. SMB 3.02 is only negotiated when systems of these operating system versions are directly connected. SMB 3.02 is qualified with SMB3.02 signed and unsigned traffic over IPv4 and IPv6, and encrypted connections over IPv4 and IPv6. Authenticated connections between a server-side SteelHead and a domain controller are only supported over IPv4.

RiOS 8.5 and later include support for SMB3 traffic latency and bandwidth optimization for native SMB3 clients and servers.

Windows 8 clients and Windows 2012 servers feature SMB3, an upgrade to the CIFS communication protocol. SMB3 adds features for greater resiliency, scalability, and improved security. SMB3 supports these features:

To optimize signed SMB3 traffic, you must run RiOS 8.5 or later and enable SMB3 optimization on the client-side and server-side SteelHeads.

For additional details on SMB 3.0 specifications, go to

RiOS supports for SMB2 traffic latency optimization for native SMB2 clients and servers. SMB2 allows more efficient access across disparate networks. It is the default mode of communication between Windows Vista and Windows Server 2008. Microsoft modified SMB2 again (to SMB 2.1) for Windows 7 and Windows Server 2008 R2.

SMB2 brought a number of improvements, including but not limited to:

You display and modify SMB signing settings in the Optimization > Protocols: CIFS (SMB1) and (SMB2/3) pages.

When sharing files, Windows provides the ability to sign CIFS messages to prevent man-in-the-middle attacks. Each CIFS message has a unique signature that prevents the message from being tampered with. This security feature is called SMB signing.

You can enable the RiOS SMB signing feature on a server-side SteelHead to alleviate latency in file access with CIFS acceleration while maintaining message security signatures. With SMB signing on, the SteelHead optimizes CIFS traffic by providing bandwidth optimizations (SDR and LZ), TCP optimizations, and CIFS latency optimizations—even when the CIFS messages are signed.

RiOS 8.5 and later include support for optimizing SMB3-signed traffic for native SMB3 clients and servers. You must enable SMB3 signing if the client or server uses any of these settings:

SteelHeads include support for optimizing SMB2-signed traffic for native SMB2 clients and servers. SMB2 signing support includes:

The RiOS SMB signing feature works with Windows domain security and is fully compliant with the Microsoft SMB signing version 1, version 2, and version 3 protocols. RiOS supports domain security in both native and mixed modes for:

The server-side SteelHead in the path of the signed CIFS traffic becomes part of the Windows trust domain. The Windows domain is either the same as the domain of the user or has a trust relationship with the domain of the user. The trust relationship can be either a parent-child relationship or an unrelated trust relationship.

RiOS optimizes signed CIFS traffic even when the logged-in user or client machine and the target server belong to different domains, provided these domains have a trust relationship with the domain the SteelHead has joined. RiOS supports delegation for users that are in domains trusted by the server's domain. The trust relationships include:

The process RiOS uses to authenticate domain users depends upon its version.

RiOS features these authentication modes:

Transparent mode doesn’t support the following configurations; instead, use Kerberos authentication support mode:

You can enable extra security using the secure inner channel. The peer SteelHeads using the secure channel encrypt signed CIFS traffic over the WAN. For details, see Configuring secure peers.

This section describes prerequisites and recommendations for using SMB signing.

This section describes how to verify the domain and DNS settings before joining the Windows domain and enabling SMB signing.

After you have joined a Windows domain, you can enable SMB signing.

The RiOS Optimize Connections with Security Signatures feature can lead to unintended consequences when SMB signing is required on the client but set to Enabled on the server. With this feature enabled, the client concludes that the server doesn’t support signing and might terminate the connection with the server as a result. You can prevent this condition by performing one of these actions before enabling this feature:

If the SMB server and client negotiate SMB3 and the server is configured for encryption, you can configure share-level encryption. Share-level encryption marks a specific share on the server as encrypted so that if a client opens a connection to the server and tries to access the share, RiOS encrypts the data that goes to that share. RiOS doesn’t encrypt the data that goes to other shares on the same server.

RiOS 9.5 and later support the SMB 3.1.1 dialect when SMB3 is enabled. RiOS 9.0 and later support the SMB 3.0.2 dialect when SMB3 is enabled.

The Current Connections report displays the SMB traffic using these labels:

For details, see Viewing Connection History reports.

This section describes how to configure HTTP optimization features. HTTP optimization works for most HTTP and HTTPS applications, including SAP, customer relationship management, enterprise resource planning, financial, document management, and intranet portals.

It includes these topics:

This table summarizes the basic steps for configuring HTTP optimization, followed by detailed procedures.

You display and modify HTTP optimization feature settings in the Optimization > Protocols: HTTP page. For an overview of the HTTP optimization features and basic deployment considerations, see Configuring HTTP optimization.

Configuring HTTP optimization can be a complex task. There are many different options and it isn’t always easy to determine what settings are required for a particular application without extensive testing. HTTP automatic configuration creates an ideal HTTP optimization scheme based on a collection of comprehensive statistics per host. The host statistics create an application profile, used to configure HTTP automatically and assist with any troubleshooting.

You can easily change an automatically configured server subnet to override settings.

Use one of the following methods to enable SaaS identity. The second method requires the Riverbed Cloud Portal and the SteelHead SaaS service. If your network uses the SteelHead SaaS service, you can use either method.

Under Settings, you can enable URL Learning, Parse and Prefetch, and Object Prefetch Table in any combination for any host server or server subnet. You can also enable authorization optimization to tune a particular subnet dynamically, with no service restart required.

The default settings are URL Learning, Object Prefetch Table, and Strip Compression for all traffic with automatic configuration disabled. The default setting applies when HTTP optimization is enabled, regardless of whether there’s an entry in the Subnet or Host list. In the case of overlapping subnets, specific list entries override any default settings.

In RiOS 8.5 and later, the default rule is applied if any other rule (that is, the subnet rule or host-based rule) doesn’t match.

Suppose the majority of your web servers have dynamic content applications but you also have several static content application servers. You could configure your entire server subnet to disable URL Learning and enable Parse and Prefetch and Object Prefetch Table, optimizing HTTP for the majority of your web servers. Next, you could configure your static content servers to use URL Learning only, disabling Parse and Prefetch and Object Prefetch Table.

To modify subnet configuration properties, use the drop-down lists in the table row for the configuration.

To modify server properties, use the drop-down list in the table row for the server.

You can display and modify Oracle Forms optimization settings in the Optimization > Protocols: Oracle Forms page.

Oracle Forms is a platform for developing user interface applications to interact with an Oracle database. It uses a Java applet to interact with the database in either native, HTTP, or HTTPS mode. The SteelHead decrypts, optimizes, and then reencrypts the Oracle Forms traffic.

You can configure Oracle Forms optimization in these modes:

Use Oracle Forms optimization to improve Oracle Forms traffic performance. RiOS supports 6i, which comes with Oracle Applications 11i, and 10gR2, which comes with Oracle E-Business Suite R12.

This feature doesn’t need a separate license and is enabled by default. However, you must also set an in-path rule to enable this feature.

Before enabling Oracle Forms optimization, you must know the mode in which Oracle Forms is running at your organization.

This section describes how to enable Oracle Forms optimization for the deployment mode your organization uses.

You display and modify MAPI optimization settings in the Optimization > Protocols: MAPI page. This feature is enabled by default.

RiOS uses the SteelHead secure inner channel to ensure all MAPI traffic sent between the client-side and the server-side SteelHeads is secure. You must set the secure peering traffic type to All. For details, see Enabling secure peers.

You must enable MAPI optimization on all SteelHeads optimizing MAPI in your network, not just the client-side SteelHead.

In out-of-path deployments, if you want to optimize MAPI Exchange by destination port, you must define a fixed-target in-path rule that specifies these ports on the client-side appliance:

For details about defining in-path rules, see Configuring In-Path Rules.

You can configure SteelHeads to operate with Exchange Server clusters that use load balancers (such as CAS) to provide dynamic MAPI port mappings for clients.

In these environments, you must configure one of the following transparency modes or disable port remapping on the client-side SteelHead:

You display and modify NFS optimization settings in the Optimization > Protocols: NFS page.

NFS optimization provides latency optimization improvements for NFS operations by prefetching data, storing it on the client SteelHead for a short amount of time, and using it to respond to client requests. You enable NFS optimization in high-latency environments.

You can configure NFS settings globally for all servers and volumes or you can configure NFS settings that are specific to particular servers or volumes. When you configure NFS settings for a server, the settings are applied to all volumes on that server unless you override settings for specific volumes.

You can add server configurations to override your default settings. You can also modify or remove these configuration overrides. If you don’t override settings for a server or volume, the SteelHead uses the global NFS settings.

After you add a server, the NFS page includes options to configure volume policies. The Available Volumes table provides an uneditable list of NFS volumes that are available for the current NFS server. You can use the NFS volume information listed in this table to facilitate adding new NFS volumes.

You can enable and modify Lotus Notes optimization settings in the Optimization > Protocols: Lotus Notes page.

Lotus Notes is a client/server collaborative application that provides email, instant messaging, calendar, resource, and file sharing. RiOS provides latency and bandwidth optimization for Lotus Notes 6.0 and later traffic across the WAN, accelerating email attachment transfers and server-to-server or client-to-server replications.

RiOS saves bandwidth by automatically disabling socket compression, which makes SDR more effective. It also saves bandwidth by decompressing Huffman-compressed attachments and LZ-compressed attachments when they’re sent or received and recompressing them on the other side. Lotus Notes optimization allows SDR to recognize attachments that have previously been sent in other ways (such as over CIFS, HTTP, or other protocols), and also allows SDR to optimize the sending and receiving of attachments that are slightly changed from previous sends and receives.

Enabling Lotus Notes provides latency optimization regardless of the compression type (Huffman, LZ, or none).

Before enabling Lotus Notes optimization, be aware that it automatically disables socket-level compression for connections going through SteelHeads that have this feature enabled.

The Encryption Optimization Servers table displays all of the servers for which server ID files were imported and optimization of encrypted connections is occurring.

If the secure vault is locked, this table doesn’t appear. Instead, a dialog box asks you to unlock the secure vault. After you type the password to unlock the secure vault, the Encrypted Optimization Server table appears.

A successful connection appears as NOTES-ENCRYPT in the Current Connections report.

New connections to or from an IP address on this list don’t receive Lotus Notes encryption optimization.

If RiOS encounters a problem during client authentication that prevents the SteelHead from optimizing the encrypted traffic, it must drop the connection, because in the partially authenticated session the client expects encryption but the server doesn’t. (Note that the client transparently tries to reconnect with the server after the connection drops.) Whenever there’s a risk that the problem might reoccur when the client reconnects, the client IP address or server IP address or both appear on the unoptimized IP address table on the server-side SteelHead. The system disables Lotus Notes encryption optimization in future connections to or from these IP addresses, which in turn prevents the SteelHead from repeatedly dropping connections, which could block the client from ever connecting to the server.

The Unoptimized IP Address table displays the reason that the client or server isn’t receiving Lotus Notes encrypted optimization.

This section explains how to configure a Domino server to accept unencrypted connections on an alternative TCP port in addition to accepting connections on the standard TCP port 1352.

You enable and modify Citrix optimization settings in the Optimization > Protocols: Citrix page.

Citrix optimization has the following features:

RiOS 9.0.x has enhancements to QoS that classify Citrix ICA traffic based on its ICA priority group using Multi-Stream with Multi-Port.

RiOS 9.1 and later include an autonegotiation of Multi-Stream ICA feature which classifies Citrix ICA traffic based on its ICA priority group.

Support is provided for the following Citrix software components.

Citrix Receiver or ICA client versions:

Citrix XenDesktop:

Citrix XenApp:

In addition, RiOS supports encrypted and compressed Citrix ICA traffic optimization.

For more information about Citrix optimization, see the SteelHead Deployment Guide - Protocols, the Riverbed Command-Line Interface Reference Manual, and the white paper Optimizing Citrix ICA Traffic.

This table describes how the SteelHeads handle Citrix traffic as a secure protocol after a secure inner channel setup failure.

You can enable and modify Fibre Channel over TCP/IP (FCIP) storage optimization module settings in the Optimization > Data Replication: FCIP page.

FCIP is a transparent Fibre Channel (FC) tunneling protocol that transmits FC information between FC storage facilities over IP networks. FCIP is designed to overcome the distance limitations of FC.

FCIP storage optimization provides support for environments using storage technology that originates traffic as FC and then uses either a Cisco Multilayer Director Switch (MDS) or a Brocade 7500 FCIP gateway.

To increase the data reduction LAN-to-WAN ratio with either equal or greater data throughput in environments with FCIP traffic, RiOS separates the FCIP headers from the application data workload written to storage. The FCIP headers contain changing protocol state information, such as sequence numbers. These headers interrupt the network stream and reduce the ability of SDR to match large, contiguous data patterns. After isolating the header data, the SteelHead performs SDR network deduplication on the larger, uninterrupted storage data workload and LZ compression on the headers. RiOS then optimizes, reassembles, and delivers the data to the TCP consumer without compromising data integrity.

You configure the RiOS FCIP storage optimization module on the SteelHead closest to the FCIP gateway that opens the FCIP TCP connection by sending the initial SYN packet. The SteelHead location can vary by environment. If you are unsure which gateway initiates the SYN, enable FCIP on both the client-side and server-side SteelHeads.

By default, FCIP optimization is disabled.

For details about data replication deployments, see the SteelHead Deployment Guide.

After completing the FCIP configuration on both SteelHeads and restarting the optimization service, you can view the FCIP connections in the Current Connections report. Choose Reports > Networking: Current Connections. In the list of optimized connections, look for the FCIP connection in the Application column. Verify that the FCIP connection appears in the list without a red protocol error icon:

For details, see Viewing Connection History reports.

You can view combined throughput and reduction statistics for two or more FCIP tunnel ports by entering this command from the command-line interface:

For details, see the Riverbed Command-Line Interface Reference Manual.

Environments with GigE-based (RF port) originated SRDF traffic between VMAX arrays must isolate DIF headers within the data stream. These DIF headers interrupt the data stream. When the R1 Symmetrix array is running Enginuity microcode version 5875 or newer, manual FCIP rules aren’t necessary. In 5875+ environments, RiOS automatically detects the presence of DIF headers and DIF blocksize for GigE-based (RF port) SRDF traffic. To manually isolate the DIF headers when the R1 Symmetrix array is running Enginuity microcode version 5874 or older, you add FCIP rules by defining a match for source or destination IP traffic.

Automatically detected FCIP settings in Enginuity 5875 and later environments override any manually configured FCIP rules.

The default rule optimizes all remaining traffic that has not been selected by another rule. It always appears as the last in the list. You can’t remove the default rule; however, you can change its DIF setting. The default rule uses 0.0.0.0 in the source and destination IP address fields, specifying all IP addresses. You can’t specify 0.0.0.0 as the source or destination IP address for any other rule.

Suppose your environment consists mostly of regular FCIP traffic without DIF headers that has some RF-originated SRDF between a pair of VMAX arrays. A pair of FCIP gateways uses a tunnel to carry the traffic between these VMAX arrays. The source IP address of the tunnel is 10.0.0.1 and the destination IP is 10.5.5.1. The preexisting default rule doesn’t look for DIF headers on FCIP traffic. It handles all of the non-VMAX FCIP traffic. To isolate the DIF headers on the FCIP tunnel carrying the VMAX-to-VMAX SRDF traffic, add this rule.

You can enable and modify Symmetrix Remote Data Facility (SRDF) storage module optimization settings in the Optimization > Data Replication: SRDF page.

EMC’s Symmetrix Remote Data Facility/Asynchronous (SRDF/A) is a SAN replication product. It performs the data replication over GigE (instead of the Fibre Channel), using gateways that implement the SRDF protocol.

SRDF storage optimization provides support for environments using storage technology that originates traffic through Symmetrix GigE ports. For details on storage technologies that originate traffic through GigE RE ports, see the SteelHead Deployment Guide.

To increase the data reduction LAN-to-WAN ratio with either equal or greater data throughput in environments with SRDF traffic, RiOS separates the SRDF headers from the application data workload written to storage. The SRDF headers contain changing protocol state information, such as sequence numbers. These headers interrupt the network stream and reduce the ability of scalable data replication (SDR) to match large, contiguous data patterns. After isolating the header data, the SteelHead performs SDR network deduplication on the larger, uninterrupted storage data workload and LZ compression on the headers. RiOS then optimizes, reassembles, and delivers the data to the TCP consumer as originally presented to the SteelHead network.

You configure the SRDF storage optimization module on the SteelHead closest to the Symmetrix array that opens the SRDF TCP connection by sending the initial SYN packet. The SteelHead location can vary by environment. If you are unsure which array initiates the SYN, configure SRDF on both the client-side and server-side SteelHeads.

By default, SRDF optimization is disabled.

For details about data replication deployments, see the SteelHead Deployment Guide.

After completing the SRDF configuration on both SteelHeads and restarting the optimization service, you can view the SRDF connections in the Current Connections report.

For details, see Viewing Connection History reports.

This section describes how to apply custom data reduction levels to remote data facility (RDF) groups.

You can base the data reduction level on the compression characteristics of the data associated with an RDF group to provide SRDF selective optimization. Selective optimization enables you to find the best optimization setting for each RDF group, maximizing the SteelHead use. Selective optimization depends on an R1 Symmetrix array running VMAX Enginuity microcode levels newer than 5874.

For example, you can customize the data reduction level for applications associated with an RDF group when excess WAN bandwidth is available and the application data associated with the group isn’t reducible. For applications with reducible data, getting maximum reduction might be more important, requiring a more aggressive data reduction level.

You can configure the optimization level from no compression to full scalable data replication (SDR). SDR optimization is the default, and includes LZ compression on the cold, first-pass of the data. You can also configure LZ-compression alone with no SDR.

Consider an example with these types of data:

In this example, you can assign LZ-only compression to the Oracle logs, no optimization to the encrypted check images, and default SDR to the virtual machine images. To assign these levels of optimization, you configure the SteelHead to associate specific RE port IP addresses with specific Symmetrix arrays, and then assign a group policy to specific RDF groups to apply different optimization policies.

The data reduction level within a group policy overrides the current default data reduction setting for the storage resources an RDF group represents. This override is distinct per Symmetrix ID.

Environments with GigE-based (RE port) originated SRDF traffic between VMAX arrays must isolate data integrity field (DIF) headers within the data stream. These DIF headers interrupt the data stream. When the R1 Symmetrix array is running Enginuity microcode version 5875 or newer, manual SRDF rules aren’t necessary. In 5875+ environments, RiOS automatically detects the presence of DIF headers and DIF blocksize for GigE-based (RE port) SRDF traffic. To manually isolate the DIF headers when the R1 Symmetrix array is running Enginuity microcode version 5874 or older, you add SRDF rules by defining a match for source or destination IP traffic.

Automatically detected SRDF settings in Enginuity 5875 and later environments override any manually configured SRDF rules.

The default rule optimizes all remaining traffic that has not been selected by another rule. It always appears as the last in the list. You can’t remove the default rule; however, you can change the DIF setting of the default rule. The default rule uses 0.0.0.0 in the source and destination IP address fields, specifying all IP addresses. You can’t specify 0.0.0.0 as the source or destination IP address for any other rule.

You manage SnapMirror storage optimization settings in the Configure > Optimization: SnapMirror page.

SnapMirror is used mainly for disaster recovery and replication. To provide maximum protection and ease of management, many enterprises choose to perform SnapMirror operations across the wide-area network. However, WAN links are often costly, and the limited bandwidth and high-network latency they provide often severely degrade SnapMirror operations.

SteelHead improves the performance of the WAN for NetApp SnapMirror traffic by overcoming limited bandwidth restrictions, high latency, and poor network quality commonly associated with wide-area networks.

RiOS also improves WAN performance, visibility, and control of NetApp SnapMirror traffic with features that allow you to:

SteelHead supports SnapMirror optimization for environments using NetApp ONTAP 9 (Clustered Data ONTAP or cDOT) and legacy 7-mode environments in NetApp ONTAP 7 or Data ONTAP 8.

By default, SnapMirror optimization is enabled for clustered configurations.

In Clustered Data ONTAP, the SnapMirror replication works at the Storage Virtual Machine (SVM, formerly known as Vservers) level. Each SVM can have one or more volumes and, to perform replication, multiple network connections are established between the source and destination SVM. A single network connection is not dedicated to a single volume replication; instead a network connection can carry data belonging to different volumes and a single volume replication can span multiple connections. With this design, the SteelHead cannot uniquely identify volumes for a SnapMirror replication, but SteelHead can perform bandwidth and QoS optimization at the SVM level.

For details about data replication deployments, see the SteelHead Deployment Guide.

SteelHead provides the following optimization for SnapMirror replications between 7-mode Data ONTAP controllers:

Data ONTAP 7-mode creates a single dedicated network connection to replicate a SnapMirror volume. This behavior lets the SteelHead SnapMirror optimization work at volume level.

By default, SnapMirror optimization is disabled for legacy 7-mode configurations.

To benefit from SnapMirror optimization, both SteelHeads must be running RiOS 8.5 or later.

For details about data replication deployments, see the SteelHead Deployment Guide.

This section describes how to create a new filer or make changes to an existing filer. You must add a filer before you can add a volume. SnapMirror needs both a source and a destination IP address for each filer.

You can view the SnapMirror connections by choosing Reports > Optimization: SnapMirror. For details, see Viewing SnapMirror reports.

This section describes how to configure a SteelHead to optimize in an environment where there are:

Optimization in a secure Windows environment has changed with each software version of RiOS.

For details, go to the Riverbed Knowledge Base article Optimization in a Secure Windows Environment at https://supportkb.riverbed.com/support/index?page=content&id=S25759.

RiOS 8.5 and later support:

This table shows the different combinations of Windows clients and authentication methods with the required minimum version of RiOS and Windows configuration (delegation, Kerberos, Active Directory integrated) for the server-side SteelHead.

For Windows 8 clients behavior, use Windows 7 information in the above table, and RiOS 8.5 or later. For Windows 8.1 and Windows 10 clients, use RiOS 9.0 or later.

SteelHeads support end-to-end Kerberos authentication for these secure protocols:

When you configure the server-side SteelHead to support end-to-end Kerberos authentication, you can join it to the domain in Active Directory integrated mode to support other clients that might be using NTLM authentication. This configuration can provide flexible and broad support for multiple combinations of Windows authentication types in use within the Active Directory environment.

SteelHeads protect authentication credentials for delegate and replication users by storing them in the SteelHead secure vault. The secure vault contains sensitive information about your SteelHead configuration.

You must unlock the secure vault to view, add, remove, or edit any replication or delegate user configuration details that are stored on the SteelHeads. The system initially locks the secure vault on a new SteelHead with a default password known only to RiOS. This lock allows the SteelHead to automatically unlock the vault during system start up. You can change the password, but the secure vault doesn’t automatically unlock on start up.

For details, see Unlocking the secure vault.

To migrate previously configured authentication credentials to the secure vault after upgrading from a RiOS version of 6.5.x or earlier, unlock the secure vault and then enter this CLI command at the system prompt:

For details, see the Riverbed Command-Line Interface Reference Manual.

Windows 7 clients can use Kerberos authentication for maximum security. Kerberos authentication doesn’t require delegation mode configuration, but you must configure both NTLM authentication (either transparent mode or delegation mode) along with Kerberos authentication (if desired).

RiOS 8.5 and later simplify the SteelHead configuration necessary to optimize traffic in an environment where there are:

This section describes how to simplify configuration using these operations:

Domain authentication automatic configuration simplifies the server-side SteelHead configuration for enabling latency optimizations in a secure environment. Using this widget automates the majority of the required configuration tasks, avoiding the need to perform step-by-step operations in different configuration tools and using the command line on the Windows AD platforms.

Use this widget to configure the server-side SteelHead in integrated Active Directory mode for Windows 2003 or 2008 and later, and enable secure protocol optimization for CIFS SMB1, SMB2, and SMB3 for all clients and servers. To enable secure protocol optimization for MAPI and encrypted MAPI, you need to enable MAPI protocol optimization on all clients after running the widget.

Domain Authentication Automatic Configuration performs these tasks:

If any of the steps fail during the configuration, the system automatically rolls back to the previous configuration.

You don’t necessarily need to use the replication user or delegate user facility to optimize secure Windows traffic if you deploy the server-side SteelHead so that it joins a domain in the Active Directory environment. To integrate the server-side SteelHead into Active Directory, you must configure the role when you join the SteelHead to the Windows domain.

When you integrate the server-side SteelHead in this way, 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.

Historically, with earlier Windows releases, the preferred option was to have the server-side SteelHead join the domain as “Workstation” then use a Delegate User account and authenticate using constrained delegation. However, delegation requires the most administrative effort by both the SteelHead and Windows AD administrators. This configuration option has been deprecated. We recommend Active Directory Integrated mode due to its simplicity, ease of configuration, and low administrative maintenance.

Follow the procedures in the Riverbed Knowledge Base article Optimization in a Secure Windows Environment at https://supportkb.riverbed.com/support/index?page=content&id=S25759.

You can assign a restricted set of privileges to a user, known as a replication user. You can configure the replication user on a per-forest basis so that the user assigned to it can retrieve machine credentials from any domain controller in any trusted domain within the forest. Remember that a forest can comprise multiple domains with trusts between them.

Automatic configuration simplifies setting up your SteelHead for delegation or replication. Use these widgets to:

Using delegation mode to optimize SMB-signed or encrypted MAPI traffic requires additional configuration (beyond joining the server-side SteelHead to a domain) because delegation mode uses the Active Directory constrained delegation feature. You must configure both the server-side SteelHead and the Windows domain that it joins.

Constrained delegation is an Active Directory feature that enables configured services to obtain security related information for a user. Configuring constrained delegation requires the creation of a special delegate user account in the Windows domain. The account allows the delegate user the privilege of obtaining security information for use with specific applications (like CIFS and MAPI), and then configuring the delegate user credentials on the server-side SteelHead.

For details, go to the Riverbed Knowledge Base article Optimization in a Secure Windows Environment at https://supportkb.riverbed.com/support/index?page=content&id=S25759.

The configure delegation account widget configures a user with trusted delegation rights for a domain.

The configure replication account widget adds a user with trusted replication rights to a domain.

The add delegation servers widget adds delegation servers from either the CIFS or Exchange MDB service.

The remove delegation servers widget removes delegation servers from either the CIFS or Exchange MDB service.

After you run a widget, the status indicates one of these states:

Last Run displays the amount of time elapsed since the last execution and then the time and date the operation completed. The time is meaningful only if the status is success or failed.

Logging Data displays log output for the operation. You might want to view the log if the status indicates an operation failure. Two log files follow an operation:

You can control the logging data display using the tabs.

Select Hide Log to remove the logs from the display.

Select the Summary and Full Log tabs to view the logging data. The system displays a line count for the number of lines in the logging data. The system omits the tab if the log file is empty.

The following topics describe the manual configuration on the server-side SteelHead for enabling latency optimizations in a secure environment. We recommend using the automatic configuration as described in Configuring domain authentication automatically, because it performs these steps automatically. Use this operation instead of the automatic configuration to set up delegate users in Active Directory. After running this operation, you can enable secure protocol optimization for CIFS SMB1, SMB2, SMB3, and encrypted MAPI for all clients and servers.

For an overview of Windows Domain Authentication, see Viewing SnapMirror connections.

For details about configuring domain authentication manually, see the Riverbed Knowledge Base article Optimization in a Secure Windows Environment at https://supportkb.riverbed.com/support/index?page=content&id=S25759.

Historically, with earlier Windows releases, the preferred option was to have the server-side SteelHead join the domain as “Workstation” then use a Delegate User account and authenticate using constrained delegation. However, delegation requires the most administrative effort by both the SteelHead and Windows AD administrators. This configuration option has been deprecated. We strongly recommend using Active Directory Integrated mode due to its simplicity, ease of configuration, and low administrative maintenance.

Follow the procedures in the Riverbed Knowledge Base article Optimization in a Secure Windows Environment at https://supportkb.riverbed.com/support/index?page=content&id=S25759.

To set up manual delegation (specifying each server allowed to delegate), continue to the next procedure.

To set up automatic server detection, see Autodelegation mode (deprecated).

Historically, with earlier Windows releases, the preferred option was to have the server-side SteelHead join the domain as “Workstation,” use a Delegate User account, and authenticate using constrained delegation. However, delegation requires the most administrative effort by both the SteelHead and Windows AD administrators. This configuration option has been deprecated. We strongly recommend using Active Directory Integrated mode due to its simplicity, ease of configuration, and low administrative maintenance.

Follow the procedures in the Riverbed Knowledge Base article Optimization in a Secure Windows Environment at https://supportkb.riverbed.com/support/index?page=content&id=S25759.

Delegation mode automatically updates the delegate user in Active Directory with delegation rights to servers. The service updates the user in real-time, eliminating the need to grant the user access to delegate on every server. Auto-delegation mode also updates the server IP address if it changes.

The following section describes the configuration on the server-side SteelHead.

This section provides information on troubleshooting the delegate user set up, if necessary.

Kerberos end-to-end authentication relies on Active Directory replication to obtain machine credentials for any servers that require secure protocol optimization. The RiOS replication mechanism requires a domain user with AD replication privileges, and involves the same AD protocols used by Windows domain controllers. These procedures explain how to configure replication to use Kerberos authentication for these features:

Kerberos one-way trust in RiOS 8.5 and later provide an alternative to creating and using a specific Kerberos replication user for trust models with split resource and management Active Directory domains, such as Office 365 or other managed service providers.

To enable Kerberos authentication for restricted trust environments, see To enable one-way trust using Kerberos. To join the server-side SteelHead as an integrated Active Directory, see Easy domain authentication configuration.

For details about restricted trust configurations, see the SteelHead Deployment Guide.

SteelHeads store authentication credentials for delegate and replication users in the secure vault. To unlock the secure vault, choose Administration > Security: Secure Vault and click Unlock Secure Vault.

To migrate previously configured authentication credentials to the secure vault after upgrading from a RiOS version of 6.5.x or earlier, enter this CLI command at the system prompt:

For details, see the Riverbed Command-Line Interface Reference Manual.

The following topics describe additional procedures necessary to configure PRP support.

Verify that the current domain functional level is Windows 2008 or later. See Verifying the domain functional level and host settings. For details on functional level support, see the SteelHead Deployment Guide - Protocols.

The final step in configuring replication users is to add users to either the allowed password replication group or the denied password replication group.

This section describes an alternative to creating and using a specific Kerberos replication user for environments with restricted security. Kerberos restricted trust includes trust models with split resource and management Active Directory domains such as Office 365 or other managed service providers.

For details about restricted trust configurations, see the SteelHead Deployment Guide - Protocols.

Windows XP clients must use TCP for Kerberos in a one-way trust configuration. By default, Kerberos uses UDP. You must change UDP to TCP in a Registry setting.

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.