SteelHead appliances typically work in pairs to accelerate network traffic between them. In a common setup, client-side appliances are placed at remote sites or branch offices, while server-side appliances are in the data center. The client-side appliances establish trusted connections with the server-side appliances. In cloud or SaaS deployments, client-side appliances peer with server-side appliances in the cloud or with the SaaS Accelerator service. These appliances optimize traffic between client systems and data centers, cloud services, or SaaS platforms.

Higher-capacity SteelHead models can support up to 20,000 peers per appliance. If you have more than 4,000 peers, we recommend you enable the extended peer table. After enabling this, you'll need to clear the appliance’s data store and restart the service.

Peering can be managed manually through peering rules, but autodiscovery offers an automated method. Peering rules (usually set on server-side appliances) work alongside in-path rules (typically set on client-side appliances).

In an in-path deployment, appliances are placed directly between client systems and data center resources. In-path rules control the appliance’s behavior when it receives initial connection requests (TCP SYN packets), allowing detailed management of traffic across in-path links.

Peering rules are used in complex networks to configure peering connections based on various factors. While the default peering rules are sufficient for typical setups like in-path configurations, custom peering rules may be needed for more complex networks.

We recommend using in-path rules to optimize SSL connections on destination ports other than 443.

Peering rules control how the appliance responds to probe queries from other appliances. The appliance evaluates incoming SYN packets against rules based on fields like subnet, IP address, port, and peer relationship. Rules are applied in numerical order, starting with rule 1. If a rule matches, it is applied, and the appliance does not evaluate further rules. If a rule doesn't match, the appliance moves to the next rule. The type of rule determines the action taken on the connection.

Default peering rule number 1, with the SSL incapable flag, applies to any SSL connection with an IP address and port listed in the appliance's bypass list. The bypass list includes SSL servers that the appliance bypasses due to certificate issues or SSL handshake failures. Any subsequent connections to these IP addresses and ports will match rule number 1.

Default peering rule number 2, with the SSL capable flag, applies to SSL connections on port 443 that didn't match rule number 1. The appliance attempts to discover certificate matches and performs SSL acceleration and enhanced autodiscovery for these connections.

Peering rules settings are under Optimization > Network Services: Peering Rules.

Determines the action the appliance takes on the connection:

Determines the order in which the system evaluates the rule.

Specify IP addresses and subnet masks for traffic sources and destinations. Wildcards are supported.

Specifies the destination port number, port label, or All.

Specifies the in-path IP address of the probing appliance. If more than one in-path interface is present on the probing appliance, apply multiple peering rules, one for each in-path interface. You can also specify wildcards.

Enables an SSL capability flag, which specifies criteria for matching an incoming connection with one of the rules in the peering rules table. This flag is typically set on a server-side appliance.

Determines which connections from a client-side appliance (with the Legacy SteelHead Cloud enabled but with redirect disabled) should be optimized with the Legacy SteelHead Cloud. Use cloud acceleration in peering rules on a server-side SteelHead in a back-hauled deployment.

If the client-side SteelHead doesn’t have cloud acceleration enabled or isn’t trying to optimize cloud connections, the value of this setting on the server-side SteelHead doesn't matter.

Enter a description to help you identify the peering relationship.

By default, enhanced autodiscovery is enabled. It automatically finds the furthest peer appliance in the network and establishes a trust relationship with it. For example, if you have four appliances (A, B, C, D), appliance A will automatically find D (the furthest from A) and peer with it. This simplifies configuration and scales deployments.

When enhanced autodiscovery is disabled, regular autodiscovery is used. With regular autodiscovery, the appliance peers with its nearest peer appliance. Using the example above, appliance A in this case peers with appliance B.

We recommend enhanced autodiscovery for the following kinds of deployments:

For environments using MAPI or FTP, consider using primary and backup redundancy instead of serial clusters. For large environments, SteelHead Interceptors offer scalability and high availability by creating multi-appliance clusters. For details, see the SteelHead Interceptor Deployment Guide and the SteelHead Interceptor User Guide.

A serial cluster’s bandwidth matches the appliance model in use; it does not increase with multiple appliances in the cluster. For example, a serial cluster that is made up of two 570-M model appliances with a bandwidth specification of 20 Mbps has a cluster bandwidth of 20 Mbps.

If the active appliance in the cluster experiences high CPU load and enters a degraded state, it will still continue to accept new connections.

Make sure the autodiscovery settings on both the peered server-side and client-side appliances are the same. If they don't match, optimization may not work correctly.

Enables enhanced autodiscovery for IPv4 and mixed IPv4/IPv6 networks. This option relies on an IPv4 connection to the peer appliance over TCP, and your network must support IPv4 for the inner channels for this feature to function.

Enables enhanced auto-discovery for IPv6 networks. Enabling this option is required for IPv6 single-stack networks. This can be enabled for both single-stack IPv6 and dual-stack IPv4 + IPv6 networks. Enhanced IPv6 Auto-discovery is disabled is by default.

Supports up to 20,000 peers on high-end server-side SteelHeads The appliance’s data store organizes peers in groups of 1,024 in the global peer table. If you have more than 4,000 peers, we recommend enabling the extended peer table. By default, this option is disabled (the option is unavailable on models that don’t support it).

Before enabling, ensure you understand the performance and scaling implications. You should compare this with a serial cluster deployment for scalability.For details, see SteelHead Deployment Guide. After enabling, you must clear the RiOS data store and restart the service.

Enables peer appliances to pass traffic without optimization when the latency between them is below a set threshold. The default threshold is 10 milliseconds, but you can adjust it. The client-side SteelHead calculates the latency. When latency is low, sending unoptimized traffic can be faster than optimizing it. You can also use the Ignore Latency Detection option in peer in-path rules, if needed.

SteelHead's enhanced auto-discovery feature makes deployment easy but can sometimes cause unwanted appliances (not part of your organization) to connect. To prevent this, you can create a pass-through peering rule to block these appliances and remove them from your peer list. Create a pass-through rule for the unwanted appliance by specifying its subnet as the source and your local network subnet as the destination.

Alternatively, create a rule that only allows peering from your organization's subnet and denies others. Place this rule at the top of the list. Add a second rule to allow all other traffic to pass through. With these rules, your local SteelHead will either peer with an appliance (if it matches the accept rule) or ignore it (if it matches the pass-through rule).

Any unknown appliances will appear in the Current Connections report as "Connected Appliances" until their connection times out. Once inactive, they’ll appear dimmed, and you can restart the service to remove them completely.

When a client-side appliance receives a new SYN packet, it checks the packet’s fields (such as source or destination subnet, IP address, VLAN tag, and TCP port) against its in-path rules. If a match is found, the appliance follows the settings in the rule. In-path rules apply only when SYN packets are received on the LAN (physical in-path) or WAN (virtual in-path) interface.

By default, appliances use autodiscovery to connect to peer appliances for any connections that aren't secure, interactive, or default Riverbed ports. The appliance will automatically find and connect to a peer server-side appliance if available.

In-path rules do not affect established connections. To apply new rules, you must reset the connections.

The appliance checks incoming connection requests in order, starting with rule 1. If rule 1 matches, it is applied, and the system moves on to the next packet. If rule 1 doesn’t match, the appliance checks rule 2, and so on.

Rules are listed in order of their specified priority. Expand a rule to access its settings. In general, list rules in this order, placing rules that use domain labels below others:

The default rule accelerates all traffic that doesn't match any other rules. It cannot be removed and is always listed last. It applies to all IPv4 and IPv6 addresses, using autodiscovery for WAN visibility.

Auto Discovery rules use autodiscovery to check if a remote SteelHead can optimize the connection initiated by the SYN packet.

Fixed target rules skip autodiscovery and use a specified remote appliance for acceleration. At least one remote peer must be configured, and you can specify multiple peers or backup peers. IPv6 is supported.

Fixed-target (packet mode optimization) is similar to fixed target rules, but it supports acceleration for various transport protocols (v4 and v6 TCP and UDP) using SDR and LZ optimization. However, performance is reduced since the appliance doesn’t proxy or predict applications when using this method.

Packet-mode optimization rules are unidirectional, meaning it only accelerates traffic from the client-side appliance to the server-side appliance. For bidirectional traffic, you need to set up two rules: one on the client-side and one on the server-side appliance.

Avoid using the All IP option for source and destination subnets.

Packet-mode optimization works with physical in-path, virtual in-path with WCCP/PBR, and primary-backup deployments. It is not supported in out-of-path, serial cluster, or SteelHead Interceptor deployments.

IPv6 addresses and routes are required for each interface, unless optimizing UDP traffic.

Packet-mode optimization must be enabled under General Service Settings, requiring a service restart. Connections appear in the Current Connections report and Connection History report. Optionally, you can run the show flows command for additional details.

Pass-through rules let traffic pass through the appliance without acceleration. They can be used to exclude specific subnets from acceleration. An appliance in bypass mode will pass all traffic without optimizing it.

Discard rules silently drop SYN packets that match the rule. Similar to how routers or firewalls filter traffic, the connection initiator won't know that the packet was dropped until the connection times out.

Deny rules drop SYN packets and send a message back to the source, resetting the connection. This provides feedback to the initiator that the connection is disallowed. The settings for discard and deny rules are similar.

In-path rule settings are under Optimization > Network Services: In-Path Rules.

Specifies the general behavior of the appliance toward new connections.

Enables the appliance to send email notifications and reminders to specified users. Reminder emails, if enabled, are sent every 15 days. You can adjust the frequency using the notify-timer <notification-time-in-days> command, but this feature is only available for pass-through rules. To use it, email notifications must be enabled in the administration settings.

Deactivates latency detection on matching connections.

These settings determine which client requests the rule applies to, based on their source and destination. The options vary slightly depending on the type of rule.

Specifies the subnet IP address and netmask for the source and destination network:

Specifies a domain label for use in autodiscover, passthrough, or fixed-target rules. For a rule to apply, both the destination and domain label must match. If they don’t, the system checks the next rule. Domain labels only apply to HTTP and HTTPS traffic. If the destination port is set to All, the rule defaults to ports 80 (HTTP) and 443 (HTTPS). You can also set specific ports or use port labels. Domain labels support IPv6 starting in RiOS version 9.16.0.

Enables the appliance to transparently intercept internet-bound traffic using a single-ended web proxy. It is available to autodiscover and pass-through rules. Not available in cloud appliances.

Specifies a numerical ID from 0 to 4094 that identifies a specific VLAN. Enter all to match all VLANs, or enter untagged to match untagged connections. Passed-through traffic maintains existing VLAN tags. The default is 0.

Specifies the IP address for the remote peer appliance. When the protocol is TCP and you don’t specify an IP address, the rule defaults to all IPv6 addresses.

Specifies the target port number.

Settings are similar to those for target appliances.

Specifies a traffic protocol: TCP, UDP, or any.

Specifies a preoptimization policy Oracle Forms or SSL traffic:

Activates latency optimization for the selected traffic type:

Enables the selected optimization method:

Specifies whether the connection is accelerated by the cloud or passed through.

Resets preexisting matched connections to force reconnection.

Optimizes packet framing for Scalable Data Referencing (SDR) by using heuristics to decide the best time to flush TCP buffers. Here are the available modes:

Enables visibility of how packets traversing the WAN are addressed:

Specifies the rule’s hierarchical position in the list. Place rules that use domain labels below others. The default rule can’t be removed.

Specifies a description for the rule to facilitate administration.

Enables or disables the rule.

This setting, available for autodiscover and pass-through rules, allows client-side appliances to route internet-bound traffic through a single-ended web proxy. Enabling it boosts performance by caching web content (HTTP/HTTPS) to reduce load times and WAN usage, and decrypting SSL traffic for better optimization and visibility.

Web object caching stores HTTP and HTTPS content. The cache space available depends on the appliance model. Each object stays in the cache for the time set in its cache control header, and once expired, it's removed.

The cache is separate from the data store. If the content is already cached, the appliance serves it locally, skipping connection setup and reducing WAN traffic. The proxy cache is persistent, meaning its contents are preserved even after a restart.

Single-ended and asymmetric topologies are supported, and a server-side peer is not required.

Web proxy connections appear in the Current Connections report.

Cloud acceleration lets you control whether connections to the cloud are optimized. You don’t need an in-path rule unless you want to apply acceleration to specific users only. Choose from these options:

Domain labels and cloud acceleration can’t be used together. If a domain label is selected, the cloud acceleration option will automatically be set to Pass Through. Cloud acceleration can be set to Auto only when no domain label is used (set to n/a).

Neural framing helps optimize the moment to flush TCP buffers by evaluating heuristics to maximize data transmission and minimize idle time. It is available for Auto-Discover or Fixed Target rule types and can be selected for the in-path rule.

The best algorithm depends on traffic type, latency, compression, and SDR performance.

To set up neural framing for FTP or MAPI data channels, define an in-path rule with the respective destination port (FTP: 20, MAPI: 7830) and configure the data reduction policy.

WAN Visibility Mode enables monitoring and management of traffic across the WAN, with different options for transparency:

Full Transparency with a stateful firewall is supported. A stateful firewall examines packet headers, stores information, and then validates subsequent packets against this information. If your system uses a stateful firewall, use Full Transparency with Reset.

Port transparency is generally preferable unless you need full address visibility. Full transparency may lead to connectivity issues if network traffic is asymmetric. To enable full transparency globally by default, create an in-path autodiscover rule. Set the visibility mode to Full Transparency. Place this rule above the default in-path rule, but after the Secure, Interactive, and RBT-Proto rules. You can configure full transparency even if the server-side appliance doesn’t support it; however, in that case, the connection will not be transparent.

WAN visibility works only with autodiscover in-path rules, not with fixed-target rules or server-side out-of-path configurations.

The Top Talkers report provides WAN visibility by showing the most active users of WAN bandwidth, without needing to enable full WAN visibility.

SteelHead appliances come with three default in-path rules that are designed to pass through specific types of traffic unoptimized. These defaults are in place because protocols like Telnet, SSH, and HTTPS are commonly used during appliance deployment and configuration.

These rules allow essential management traffic through without interference. The autodiscover default rule is read-only; you can’t edit or delete it.

We recommend you keep the default in-path rules, as they support essential management protocols. However, if needed, you can override them by creating custom rules with higher priority. Modify the port groups used in the default rules to adjust their behavior.

Commonly excluded ports are 1503, 1720-1727, 2000, 3230-3253, and 5060.

Uncommon ports include 261, 448, 684, 695, 994, 2252, 2478, 2479, 2482, 2484, 2492, 2679, 2762, 2998, 3077, 3078, 3183, 3191, 3220, 3269, 3410, 3424, 3471, 3496, 3509, 3529, 3539, 3660, 3661, 3747, 3864, 3885, 3896, 3897, 3995, 4031, 5007, 5061, 7674, 9802, 11751, and 12109.

Service port settings are under Optimization > Network Services: Service Ports.

Service ports are used for inner connections between SteelHead appliances. For QoS purposes, you can configure multiple service ports on the server-side appliance to support various QoS mappings, and you can create a new service port and map specific destination ports to it. This allows QoS settings on your router to be applied to traffic based on the defined service port.

Specifies ports in a comma-separated list. The default service ports are 7800 and 7810.

Specifies the default service port.

For adding a service port mapping:

Specifies a destination port.

Specifies the service port.