• DNS Settings—We recommend you use DNS resolution. For details, see DNS settings.

• Hosts—If you don’t use DNS resolution, or if the host doesn’t have a DNS entry, you can create a host-IP address resolution map. For details, see Hosts.

• Proxies—Configure proxy addresses for network and FTP proxy access to the appliance. For details, see Web/FTP Proxy.

• Username—Specify a username.

• Password—Specify a password.

• Authentication Type—Select an authentication method from the drop-down list:

• Either uses Layer 2 first; if Layer 2 is not supported, GRE is used. This is the default value.

• GRE uses Generic Routing Encapsulation. The GRE encapsulation method appends a GRE header to a packet before it’s forwarded. This method can cause fragmentation and imposes a performance penalty on the router and switch, especially during the GRE packet deencapsulation process. This performance penalty can be too great for production deployments.

• L2 uses Layer-2 redirection. The L2 method is generally preferred from a performance standpoint because it requires fewer resources from the router or switch than the GRE does. The L2 method modifies only the destination Ethernet address. However, not all combinations of Cisco hardware and IOS revisions support the L2 method. Also, the L2 method requires the absence of L3 hops between the router or switch and the SteelHead.

• Either uses Hash assignment unless the router doesn’t support it. When the router doesn’t support Hash, it uses Mask. This is the default setting.

• Hash redirects traffic based on a hashing scheme and the Weight of the SteelHead interface, providing load balancing and failover support. This scheme uses the CPU to process the first packet of each connection, resulting in slightly lower performance. However, this method generally achieves better load distribution. We recommend Hash assignment for most SteelHeads if the router supports it. The Cisco switches that don’t support Hash assignment are the 3750, 4000, and 4500 series, among others.

• Mask redirects traffic operations to the SteelHeads, significantly reducing the load on the redirecting router. Mask assignment processes the first packet in the router hardware, using less CPU cycles and resulting in better performance.

• IP Mask specifies the service group source IP mask. The default value is 0x1741.

• Port Mask specifies the service group source port mask.

• IP Hash specifies that the router hash the source IP address to determine traffic to redirect.

• Port Hash specifies that the router hash the source port to determine traffic to redirect.

• IP Mask specifies the service group destination IP mask.

• Port Mask specifies the service group destination port mask.

• IP Hash specifies that the router hash the destination IP address to determine traffic to redirect.

• Port Hash specifies that the router hash the destination port to determine traffic to redirect.

• Ports Disabled disables the ports.

• Use Source Ports indicates the router determines traffic to redirect based on source ports.

• Use Destination Ports indicates the router determines traffic to redirect based on destination ports.

• Two-Port LR4 Fiber 40 Gigabit-Ethernet PCI-E

• Two-Port SR4 Fiber 40 Gigabit-Ethernet PCI-E

• Four-Port SR Multimode Fiber 10 Gigabit-Ethernet PCI-E

• Two-Port LR Single Mode Fiber 10 Gigabit-Ethernet PCI-E

• Two-Port SR Multimode Fiber 10 Gigabit-Ethernet PCI-E

• Accept—Accepts rules matching the Subnet A or Subnet B IP address and mask pattern for the optimized connection.

• Pass-Through—Identifies traffic to be passed through the network unoptimized.

• RiOS applies the same rule to both LAN and WAN interfaces.

• Every 10-G card has the same rule set.

• WCCP can’t be enabled.

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

• None—Don’t collect mappings.

• Destination Only—Collects destination MAC data. Use this option in connection-forwarding deployments. This is the default setting.

• Destination and Source—Collects mappings from destination and source MAC data. Use this option in connection-forwarding deployments.

• All—Collects mappings for destination, source, and inner MAC data. Also collect data for connections that are unNATed (that is, connections that aren’t translated using NAT).

• 24-hour Report Period—For a five-minute granularity (the default setting).

• 48-hour Report Period—For a ten-minute granularity.

• NetFlow 9 extensions for round-trip time measurements that enable you to understand volumes of traffic across your WAN and end-to-end response time.

• Extensions that enable a SteelCentral NetExpress to properly measure and report on the benefits of optimization.

• Analyze overall WAN use, such as traffic generated by application, most active sites, and so on.

• Troubleshoot a particular application by viewing how much bandwidth it received, checking for any retransmissions, interference from other applications, and so on.

• Compare actual application use against your outbound QoS policy configuration to analyze whether your policies are effective. For example, if your QoS policy determines that Citrix should get a minimum of 10 percent of the link, and the application statistics reveal that Citrix performance is unreliable and always stuck at 10 percent, you may want to increase that minimum guarantee.

• NetFlow 9

• SteelFlow 9.1/SteelFlow

• SteelFlow—Use with Cascade Profiler 8.4 or later.

• SteelFlow-compatible—Use with Cascade Profiler 8.3.2 or earlier, and select the LAN Address check box.

• NetFlow V5—Enables ingress flow records.

• NetFlow V9—Enables both ingress and egress flow records.

• All—Exports both optimized and nonoptimized traffic.

• Optimized—Exports optimized traffic.

• Optimized—Exports optimized LAN or WAN traffic when WCCP is enabled.

• Passthrough—Exports pass-through traffic.

• None—Disables traffic flow statistics.

• Realtime—Specifies real-time traffic class. Give this value to your highest priority traffic: for example, VoIP or video conferences.

• Interactive—Specifies an interactive traffic class: for example, Citrix, RDP, Telnet, and SSH.

• Business Critical—Specifies the high priority traffic class: for example, Thick Client Applications, ERPs, and CRMs.

• Normal Priority—Specifies a normal priority traffic class: for example, internet browsing, file sharing, and email.

• Low Priority—Specifies a low priority traffic class: for example, FTP, backup, other high-throughput data transfers, and recreational applications such as audio file sharing.

• Best Effort—Specifies the lowest priority.

• Specify a numeric VLAN tag identification number from 0 to 4094.

• Specify all to specify the rule applies to all VLANs.

• Specify none to specify the rule applies to untagged connections.

• Realtime—Specifies real-time traffic class. Give this value to your highest priority traffic: for example, VoIP or video conferences.

• Interactive—Specifies an interactive traffic class: for example, Citrix, RDP, Telnet, and SSH.

• Business Critical—Specifies the high priority traffic class: for example, Thick Client Applications, ERPs, and CRMs.

• Normal Priority—Specifies a normal priority traffic class: for example, internet browsing, file sharing, and email.

• Low Priority—Specifies a low priority traffic class: for example, FTP, backup, other high-throughput data transfers, and recreational applications such as audio file sharing.

• Best Effort—Specifies the lowest priority.

• If you’re configuring QoS for the first time, you need to migrate from basic to advanced QoS.

• If you’re upgrading a SteelHead with an existing QoS configuration running RiOS 6.1.x or earlier, the system automatically upgrades to advanced QoS.

• segregate traffic based on flow source or destination and apply different shaping rules and priorities to each leaf-class.

• effectively manage and support remote sites with different bandwidth characteristics.

• Realtime—Specifies real-time traffic class. Give this value to your highest priority traffic: for example, VoIP or video conference.

• Interactive—Specifies an interactive traffic class: for example, Citrix, RDP, Telnet and SSH.

• Business Critical—Specifies the high priority traffic class: for example, Thick Client Applications, ERPs, and CRMs.

• Normal Priority—Specifies a normal priority traffic class: for example, internet browsing, file sharing, and email.

• Low Priority—Specifies a low priority traffic class for all traffic that doesn’t fall into any other service class: for example, FTP, backup, other high-throughput data transfers, and recreational applications such as audio file sharing.

• Best Effort—Specifies the lowest priority.

• SFQ—Shared Fair Queuing (SFQ) is the default queue for all classes. Determines SteelHead behavior when the number of packets in a QoS class outbound queue exceeds the configured queue length. When SFQ is used, packets are dropped from within the queue in a round-robin fashion, among the present traffic flows. SFQ ensures that each flow within the QoS class receives a fair share of output bandwidth relative to each other, preventing bursty flows from starving other flows within the QoS class.

• FIFO—Transmits all flows in the order that they’re received (first in, first out). Bursty sources can cause long delays in delivering time-sensitive application traffic and potentially to network control and signaling messages.

• MX-TCP—Has very different use cases than the other queue parameters. MX-TCP also has secondary effects that you must understand before configuring:

• The QoS rule for MX-TCP is at the top of QoS rules list.

• The rule doesn’t use AFE identification.

• You only use MX-TCP for optimized traffic. MX-TCP doesn’t work for unoptimized traffic.

• Specify a numeric VLAN tag identification number from 0 to 4094.

• Specify all to specify the rule applies to all VLANs.

• Specify none to specify the rule applies to untagged connections.

• Realtime—Specifies real-time traffic class. Give this value to your highest priority traffic: for example, VoIP or video conferences.

• Interactive—Specifies an interactive traffic class: for example, Citrix, RDP, Telnet, and SSH.

• Business Critical—Specifies the high priority traffic class: for example, Thick Client Applications, ERPs, and CRMs.

• Normal Priority—Specifies a normal priority traffic class: for example, internet browsing, file sharing, and email.

• Low Priority—Specifies a low priority traffic class: for example, FTP, backup, other high-throughput data transfers, and recreational applications such as audio file sharing.

• Best Effort—Specifies the lowest priority.

• Realtime—Specifies real-time traffic class. Give this value to your highest priority traffic: for example, VoIP or video conferences.

• Interactive—Specifies an interactive traffic class: for example, Citrix, RDP, Telnet, and SSH.

• Business Critical—Specifies the high priority traffic class: for example, Thick Client Applications, ERPs, and CRMs.

• Normal Priority—Specifies a normal priority traffic class: for example, internet browsing, file sharing, and email.

• Low Priority—Specifies a low priority traffic class: for example, FTP, backup, other high-throughput data transfers, and recreational applications such as audio file sharing.

• Best Effort—Specifies the lowest priority.

• Realtime—Specifies real-time traffic class. Give this value to your highest priority traffic: for example, VoIP or video conference.

• Interactive—Specifies an interactive traffic class: for example, Citrix, RDP, Telnet and SSH.

• Business Critical—Specifies the high priority traffic class: for example, Thick Client Applications, ERPs, and CRMs.

• Normal Priority—Specifies a normal priority traffic class: for example, internet browsing, file sharing, and email.

• Low Priority—Specifies a low priority traffic class for all traffic that doesn’t fall into any other service class: for example, FTP, backup, other high-throughput data transfers, and recreational applications such as audio file sharing.

• Best Effort—Specifies the lowest priority.

• Port labels aren’t case sensitive and can be any string consisting of letters, the underscore, or the hyphen. There can’t be spaces in port labels.

• The fields in the various rule pages of the SCC that take a physical port number also take a port label.

• To avoid confusion, don’t use a number for a port label.

• Port labels that are used in in-path and other rules, such as QoS and peering rules, can’t be deleted.

• Port label changes (that is, adding and removing ports inside a label) are applied immediately by the rules that use the port labels that you have modified.

• List multiple dedicated application servers by hostname in a single rule and apply a policy

• List multiple business websites and servers to protect

• List recreational websites to restrict

• Host label names are case sensitive and can be any string consisting of letters, numbers, the underscore (_), or the hyphen (-). There can’t be spaces in host labels.

• We suggest starting the name with a letter or underscore.

• To avoid confusion, don’t use a number for a host label.

• You can’t delete host labels that a QoS or in-path rule is using.

• create a logical set of domain names. Apply an in-path rule to the entire set instead of creating individual rules for each domain name. One rule replaces many rules. For example, you can define a set of services in a domain label, use that domain label in an in-path rule, and apply an optimization policy based on the application or service being accessed.

• match a specific set of services. Domain labels can be especially useful when an IP address and subnet hosts many services and you don’t need your in-path rule to match them all.

• replace a fixed IP address for a server. Some SaaS providers and the O365 VNext architecture that serve multiple O365 applications such as SharePoint, Lync, and Exchange no longer provide a fixed IP address for the server. With many IP addresses on the same server, a single address is no longer enough to match with an in-path rule. Let’s suppose you need to select and optimize a specific SaaS service. Create a domain label and then use it with a host label and an in-path rule to intercept and optimize the traffic.

• They’re compatible with autodiscovery, pass-through, and fixed-target (not packet mode) in-path rules.

• They don’t replace the destination IP address. The in-path rule still sets the destination using IP/subnet (or uses a host label or port). The in-path rule matches the IP address and port first, and then matches the domain label second. The rule must match both the destination and the domain label.

• RiOS 9.16.0 and later support IPv6 for domain labels.

• The client-side and server-side SteelHeads must be running RiOS 9.2 or later.

• A fixed-target rule with a domain label match followed by an auto-discover rule will not use autodiscovery but will instead pass through the traffic. This happens because the matching SYN packet for a fixed-target rule with a domain-label isn’t sent with a probe.

• Domain labels and cloud acceleration are mutually exclusive. When you add a domain label to an in-path rule that has cloud acceleration enabled, the system automatically sets cloud acceleration to Pass Through and connections to the subscribed SaaS platform are no longer optimized by the SteelHead SaaS. To use cloud acceleration with domain labels, place the domain label rules lower than cloud acceleration rules in your rule list so the cloud rules match before the domain label rules.

• We recommend adding domain label rules last in the list, so RiOS matches all previous rules before matching the domain label rule.

• When you add a domain label to an in-path rule with the ports set to All, the in-path rule defaults to ports HTTP (80) and HTTPS (443) for optimization. A warning states that only HTTP and HTTPS ports are in use. When you choose a specific port number or port range, the in-path rule matches those ports.

• They’re not compatible with connection forwarding.

• You can’t use domain labels with QoS rules.

• A domain label name can be up to 64 characters long.

• Domain label names are case sensitive and can be any string consisting of letters, numbers, the underscore (_), or the hyphen (-). There can’t be spaces in domain label names.

• We suggest starting the name with a letter or underscore, although the first letter can be a number.

• To avoid confusion, don’t use a number for a domain label.

• Matching is case insensitive.

• You must include a top-level domain: for example, .com. You can’t include a wildcard in a top-level domain.

• You must specify second-level domains: for example, *.outlook.com, but not *.com.

• You can also separate domains with spaces or new lines.

• A domain name can be up to 64 characters long.

• Characters must be alphanumeric (0-9, a-z, A-Z), periods, underscores, wildcards, and hyphens.

• Don’t use consecutive periods.

• Don’t use consecutive wildcards.

• Don’t use IP addresses.

• Reset Existing Client Connections on Start Up—(Not recommended for production environments).

• Enable L4/PBR/WCCP/Interceptor Support—Enables optional, virtual in-path support on all the interfaces for networks that use Layer-4 switches, PBR, WCCP, and Interceptor. External traffic redirection is supported only on the first in-path interface. These redirection methods are available:

• Interface <inpathx_y> Present—Specify the interface upon which you want to enable optimization support.

• Interface <inpathx_y> Present—Specify the interface upon which you want to enable optimization support.

• TCP SYN packet arrives on the LAN interface of physical in-path deployments.

• TCP SYN packet arrives on the WAN0_0 interface of virtual in-path deployments.

• Auto-Discover—Uses the autodiscovery process to determine if a remote SteelHead is able to optimize the connection attempting to be created by this SYN packet. By default, Auto-Discover is applied to all IP addresses and ports that aren’t secure, interactive, or default Riverbed ports. Defining in-path rules modifies this default setting.

• Fixed-Target—Skips the autodiscovery process and uses a specified remote SteelHead as an optimization peer.

• Fixed-Target (Packet Mode Optimization)—Skips the autodiscovery process and uses a specified remote SteelHead as an optimization peer to perform bandwidth optimization on TCPv4, TCPv6, UDPv4, or UDPv6 connections.

• Pass-Through—Allows the SYN packet to pass through the SteelHead unoptimized. No optimization is performed on the TCP connection initiated by this SYN packet. You define pass-through rules to exclude subnets from optimization. Traffic is also passed through when the SteelHead is in bypass mode. (Pass through of traffic might occur because of in-path rules or because the connection was established before the SteelHead was put in place or before the optimization service was enabled.)

• Discard—Drops the SYN packets silently. The SteelHead filters out traffic that matches the discard rules. This process is similar to how routers and firewalls drop disallowed packets: the connection-initiating device has no knowledge that its packets were dropped until the connection times out.

• Deny—Drops the SYN packets, sends a message back to its source, and resets the TCP connection being attempted. Using an active reset process rather than a silent discard allows the connection initiator to know that its connection is disallowed.

• Select the Report Events via Email check box and specify an email address.

• Select the Send Reminder of Pass-through Rules via Email option.

• None—Don’t direct traffic through the Web Proxy.

• Force—Select with a pass-through rule to direct any private or intranet IP address and port matching this rule through the Web Proxy. You can also specify port labels to proxy. When enabled, the full and port transparency WAN visibility modes have no impact.

• Auto—Automatically directs all internet-bound traffic destined to public IP addresses on port 80 and 443 through the Web Proxy. This is the default setting. Only IPv4 traffic is supported.

• Fixed-target

• Fixed-target packet mode optimization

• Discard

• Deny

• All IP (IPv4 + IPv6)—Maps to all IPv4 and IPv6 networks.

• All IPv4—Maps to 0.0.0.0/0.

• All IPv6—Maps to ::/0.

• IPv4—Prompts you for a specific IPv4 address. Use this format for an individual subnet IP address and netmask: xxx.xxx.xxx.xxx/xx (IPv4)

• IPv6—Prompts you for a specific IPv6 address. Use this format for an individual subnet IP address and netmask: x:x:x::x/xxx (IPv6)

• All IP (IPv4 + IPv6)—Maps to all IPv4 and IPv6 networks.

• All IPv4—Maps to 0.0.0.0/0.

• All IPv6—Maps to ::/0.

• IPv4—Prompts you for a specific IPv4 address. Use this format for an individual subnet IP address and netmask: xxx.xxx.xxx.xxx/xx (IPv4)

• IPv6—Prompts you for a specific IPv6 address. Use this format for an individual subnet IP address and netmask: x:x:x::x/xxx (IPv6)

• Host Label—Specify the destination host label in the text box to selectively optimize connections to specific services: for example, *.sharepoint.com or *.outlook.com. A host label includes a hostname or a set of IP addresses and subnets, allowing you to select specific hosts to optimize. Host labels are useful because some SaaS providers and the O365 VNext architecture serve multiple O365 applications (for example, SharePoint, Lync, and Exchange) through the same dynamic virtual IP address. Choose a host label as a destination to provide flexible hostname-based interception.

• RiOS 9.16.0 and later support IPv6 for host labels.

• You can use both host labels and domain labels within a single in-path rule.

• The rules table shows any host label, domain label, and/or port label name in use in the Destination column.

• RiOS 9.16.0 and later support IPv6 for domain labels.

• Both the server-side and the client-side SteelHeads must be running RiOS 9.2 or later.

• We recommend that you position rules using a domain label below others. A fixed-target rule with a domain label match followed by an auto-discover rule will not use auto discovery but will instead pass through the traffic. This happens because the matching SYN packet isn’t sent with a probe.

• Domain labels and cloud acceleration are mutually exclusive. When you use a domain label with an in-path rule that has cloud acceleration enabled, the system automatically sets cloud acceleration to Pass Through and connections to the subscribed SaaS platform are no longer optimized by the SteelHead SaaS. Setting domain label back to n/a doesn’t reset the cloud acceleration setting back to the original setting after it has been changed to Pass Through.

• When you add a domain label to an in-path rule with the ports set to All Ports, the system interprets the request as all ports that match the domain label and uses ports HTTP (80) and HTTPS (443) for optimization. A warning states that only the HTTP and HTTPS ports are in use. When you choose a specific port number, the in-path rule honors the port.

• Port—Specify the target port number for a fixed-target rule.

• Port—Specify the backup destination port number for a fixed-target rule.

• TCP—Specifies the TCP protocol. Supports TCP-over-IPv6 only.

• UDP—Specifies the UDP protocol. Supports UDP-over-IPv4 only.

• Any—Specifies all TCP-based and UDP-based protocols. This is the default setting.

• None—If the Oracle Forms, SSL, or Oracle Forms-over-SSL preoptimization policy is enabled and you want to disable it for a port, select None. This is the default setting.

• Oracle Forms—Enables preoptimization processing for Oracle Forms. This policy isn’t compatible with IPv6.

• Oracle Forms over SSL—Enables preoptimization processing for both the Oracle Forms and SSL encrypted traffic through SSL secure ports on the client-side SteelHead. You must also set the Latency Optimization Policy to HTTP. This policy isn’t compatible with IPv6.

• SSL—Enables preoptimization processing for SSL encrypted traffic through SSL secure ports on the client-side SteelHead.

• Normal—Performs all latency optimizations (HTTP is activated for ports 80 and 8080). This is the default setting.

• HTTP—Activates HTTP optimization on connections matching this rule.

• Outlook Anywhere—Activates RPC over HTTP(S) optimization for Outlook Anywhere on connections matching this rule. To automatically detect Outlook Anywhere or HTTP on a connection, on the SteelHead, select the Normal latency optimization policy and enable the Auto-Detect Outlook Anywhere Connections option in the Optimization > Protocols: MAPI page. The auto-detect option in the MAPI page is best for simple SteelHead configurations with only a single SteelHead at each site and when the Internet Information Services (IIS) server is also handling websites. If the IIS server is only used as RPC Proxy, and for configurations with asymmetric routing, connection forwarding, or Interceptor installations, add in-path rules that identify the RPC Proxy server IP addresses and select this latency optimization policy. After adding the in-path rule, disable the auto-detect option in the Optimization > Protocols: MAPI page.

• Citrix—Activates Citrix-over-SSL optimization on connections matching this rule. This policy isn’t compatible with IPv6. Add an in-path rule to the client-side SteelHead that specifies the Citrix Access Gateway IP address, select this latency optimization policy on both the client-side and server-side SteelHeads, and set the preoptimization policy to SSL. Both the client-side and the server-side SteelHeads must be running RiOS 7.0 or later. The preoptimization policy must be set to SSL.

• Exchange Autodetect—Automatically detects MAPI transport protocols (Autodiscover, Outlook Anywhere, and MAPI over HTTP) and HTTP traffic. For MAPI transport protocol optimization, enable SSL and install the SSL server certificate for the Exchange Server on the server-side SteelHead. To activate MAPI over HTTP bandwidth and latency optimization, on the client-side SteelHead, you must also choose Optimization > Protocols: MAPI and select Enable MAPI over HTTP optimization. Both the client-side and server-side SteelHeads must be running RiOS 9.2 or later for MAPI over HTTP bandwidth and latency optimization.

• None—Don’t activate latency optimization on connections matching this rule. For Oracle Forms-over-SSL encrypted traffic, you must set the Latency Optimization Policy to HTTP. Setting the Latency Optimization Policy to None excludes all latency optimizations, such as HTTP, MAPI, and SMB.

• Normal—Perform LZ compression and SDR.

• SDR-Only—Perform SDR; don’t perform LZ compression.

• SDR-M—Performs data reduction entirely in memory, which prevents the SteelHead from reading and writing to and from the disk. Enabling this option can yield high LAN-side throughput because it eliminates all disk latency. This data reduction policy is useful for:

• Compression-Only—Perform LZ compression; don’t perform SDR.

• None—Don’t perform SDR or LZ compression.

• Auto—If the in-path rule matches, the connection is optimized by the SteelHead SaaS connection.

• Pass Through—If the in-path rule matches, the connection isn’t optimized by the SteelHead SaaS, but it follows the other rule parameters so that the connection might be optimized by this SteelHead with other SteelHeads in the network, or it might be passed through.

• Globally for all existing connections in the Optimization > Network Services: General Service Settings page.

• For a single pass-through or optimized connection in the Current Connections report, one connection at a time.

• For all existing connections that match an in-path rule and the rule has kickoff enabled.

• Never—Don’t use the Nagle algorithm. The Nagle algorithm is a means of improving the efficiency of TCP/IP networks by reducing the number of packets that need to be sent over the network. It works by combining a number of small outgoing messages and sending them all at once. All the data is immediately encoded without waiting for timers to fire or application buffers to fill past a specified threshold. Neural heuristics are computed in this mode but aren’t used. In general, this setting works well with time-sensitive and chatty or real-time traffic.

• Always—Use the Nagle algorithm. This is the default setting. All data is passed to the codec, which attempts to coalesce consume calls (if needed) to achieve better fingerprinting. A timer (6 ms) backs up the codec and causes leftover data to be consumed. Neural heuristics are computed in this mode but aren’t used. This mode isn’t compatible with IPv6.

• TCP Hints—If data is received from a partial frame packet or a packet with the TCP PUSH flag set, the encoder encodes the data instead of immediately coalescing it. Neural heuristics are computed in this mode but aren’t used. This mode isn’t compatible with IPv6.

• Dynamic—Dynamically adjust the Nagle parameters. In this option, the system discerns the optimum algorithm for a particular type of traffic and switches to the best algorithm based on traffic characteristic changes. This mode isn’t compatible with IPv6.

• Correct Addressing—Disables WAN visibility. Correct addressing uses SteelHead IP addresses and port numbers in the TCP/IP packet header fields for optimized traffic in both directions across the WAN. This is the default setting.

• Port Transparency—Port address transparency preserves your server port numbers in the TCP/IP header fields for optimized traffic in both directions across the WAN. Traffic is optimized while the server port number in the TCP/IP header field appears to be unchanged. Routers and network monitoring devices deployed in the WAN segment between the communicating SteelHeads can view these preserved fields. Port transparency is supported for IPv4 and IPv6 modes.

• Full Transparency—Full address transparency preserves your client and server IP addresses and port numbers in the TCP/IP header fields for optimized traffic in both directions across the WAN. It also preserves VLAN tags. Traffic is optimized while these TCP/IP header fields appear to be unchanged. Routers and network monitoring devices deployed in the WAN segment between the communicating SteelHeads can view these preserved fields.

• Full Transparency with Reset—Enables full address and port transparency and also sends a forward reset between receiving the probe response and sending the transparent inner channel SYN. This mode ensures the firewall doesn’t block inner transparent connections because of information stored in the probe connection. The forward reset is necessary because the probe connection and inner connection use the same IP addresses and ports and both map to the same firewall connection. The reset clears the probe connection created by the SteelHead and allows for the full transparent inner connection to traverse the firewall. Both the client-side and server-side SteelHeads must be running RiOS 6.0 or later. Full transparency with reset is supported on IPv6 RiOS 9.7 or later.

• For details on configuring WAN visibility and its implications, see the SteelHead Deployment Guide.

• WAN visibility works with autodiscover in-path rules only. It doesn’t work with fixed-target rules or server-side out-of-path SteelHead configurations.

• To enable full transparency globally by default, create an in-path autodiscover rule, select Full, and place it above the default in-path rule and after the Secure, Interactive, and RBT-Proto rules.

• You can configure a SteelHead for WAN visibility even if the server-side SteelHead doesn’t support it, but the connection isn’t transparent.

• You can enable full transparency for servers in a specific IP address range and you can enable port transparency on a specific server. For details, see the SteelHead Deployment Guide.

• The Top Talkers report displays statistics on the most active, heaviest users of WAN bandwidth, providing some WAN visibility without enabling a WAN Visibility Mode.

• Policy-based routing (PBR)—PBR allows you to define policies to route packets instead of relying on routing protocols. You enable PBR to redirect traffic that you want optimized by an Interceptor that’s not in the direct physical path between the client and server.

• Web Cache Communication Protocol (WCCP)—If your network design requires you to use WCCP, a packet redirection mechanism, it directs packets to RiOS appliances that aren’t in the direct physical path to ensure that they’re optimized.

• CDP Hold Time—Specify the CDP message hold time, in seconds. The default value is 180 seconds.

• CDP Interval—Specify the CDP message polling interval, in seconds. The default value is 10 seconds.

• Auto—Allows built-in functionality to determine the response for peering requests (performs the best peering possible). If the receiving SteelHead isn’t using automatic autodiscovery, this has the same effect as the Accept peering rule action. If automatic autodiscovery is enabled, the SteelHead only becomes the optimization peer if it is the last SteelHead in the path to the server.

• Accept—Accepts peering requests that match the source-destination-port pattern. The receiving SteelHead responds to the probing SteelHead and becomes the remote-side SteelHead (that is, the peer SteelHead) for the optimized connection.

• Passthrough—Allows pass-through peering requests that match the source and destination port pattern. The receiving SteelHead doesn’t respond to the probing SteelHead, and allows the SYN+probe packet to continue through the network.

• All-IPv4 is the wildcard for single-stack IPv4 networks.

• All-IPv6 is the wildcard for single-stack IPv6 networks.

• All-IP is the wildcard for all IPv4 and IPv6 networks.

• All-IPv4 is the wildcard for single-stack IPv4 networks.

• All-IPv6 is the wildcard for single-stack IPv6 networks.

• All-IP is the wildcard for all IPv4 and IPv6 networks.

• Port—Specify the destination port number, port label, or all.

• All-IPv4 is the wildcard for single-stack IPv4 networks.

• All-IPv6 is the wildcard for single-stack IPv6 networks.

• All-IP is the wildcard for all IPv4 and IPv6 networks.

• No Check—The peering rule doesn’t determine whether the server SteelHead is present for the particular destination IP address and port combination.

• Capable—The peering rule determines that the connection is SSL-capable if the destination port is 443 (irrespective of the destination port value on the rule), and the destination IP and port don’t appear on the bypassed servers list. The SteelHead accepts the condition and, assuming all other proper configurations and that the peering rule is the best match for the incoming connection, optimizes SSL.

• Incapable—The peering rule determines that the connection is SSL-incapable if the destination IP and port appear in the bypassed servers list. The service adds a server to the bypassed servers list when there is no SSL certificate for the server or for any other SSL handshake failure. The SteelHead passes the connection through unoptimized without affecting connection counts.

• Auto—If the in-path rule matches, the connection is optimized by the SteelHead SaaS connection.

• Pass Through—If the in-path rule matches, the connection isn’t optimized by the SteelHead SaaS, but it follows the other rule parameters so that the connection might be optimized by this SteelHead with other SteelHeads in the network, or it might be passed through.

• Standard (RFC-Compliant)—Optimizes non-SCPS TCP connections by applying data and transport streamlining for TCP traffic over the WAN. This control forces peers to use standard TCP as well. For details on data and transport streamlining, see the SteelHead Deployment Guide. This option clears any advanced bandwidth congestion control that was previously set.

• HighSpeed—Enables high-speed TCP optimization for more complete use of long fat pipes (high-bandwidth, high-delay networks). Don’t enable for satellite networks.

• Bandwidth Estimation—Uses an intelligent bandwidth estimation algorithm along with a modified slow-start algorithm to optimize performance in long lossy networks. These networks typically include satellite and other wireless environments, such as cellular networks, longer microwave, or Wi-Max networks.

• SkipWare Error-Tolerant—Enables SkipWare optimization with the error-rate detection and recovery mechanism on the SteelHead. This method is compatible with IPv6.

• Congestion loss while exiting the slow start phase. The slow-start phase is an important part of the TCP congestion-control mechanisms that starts slowly increasing its window size as it gains confidence about the network throughput.

• Congestion collapse.

• Packet bursts.

• Enable Auto-Detect TCP Optimization on the server-side SteelHead to negotiate the configuration with the client-side SteelHead.

• Configure an MX-TCP QoS rule to set the appropriate rate cap. If an MX-TCP QoS rule isn’t in place, rate pacing isn’t applied and the congestion-control method takes effect. You can’t delete the MX-TCP QoS rule when rate pacing is enabled.

• This feature isn’t compatible with IPv6.

• Packets with a compressed TCP header use IP protocol 105 in the encapsulating IP header; this might require changes to intervening firewalls to permit protocol 105 packets to pass.

• This feature supports a maximum of 255 connections between any pair of end-host IP addresses. The connection limit for legacy SkipWare connections is the same as the appliance-connection limit.

• QoS limits for the SteelHead apply to the legacy SkipWare connections.

• All-IPv4 is the wildcard for single-stack IPv4 networks.

• All-IPv6 is the wildcard for single-stack IPv6 networks.

• All-IP is the wildcard for all IPv4 and IPv6 networks.

• a VLAN identification number from 1 to 4094

• all to specify that the rule applies to all VLANs

• untagged to specify the rule applies to untagged connections.

• Ignore—Ignores web proxy settings for this rule.

• Disabled—Disables web proxy settings for this rule.

• Enabled—Enables web proxy settings for this rule.

• SCPS Discover—Turns on SCPS and turns off TCP proxy.

• TCP Proxy—Turns off SCPS and turns on TCP proxy.

• Standard (RFC-Compliant)—Optimizes non-SCPS TCP connections by applying data and transport streamlining for TCP traffic over the WAN. This control forces peers to use standard TCP as well. For details on data and transport streamlining, see the SteelHead Deployment Guide. This option clears any advanced bandwidth congestion control that was previously set.

• Bandwidth Estimation—Uses an intelligent bandwidth estimation algorithm along with a modified slow-start algorithm to optimize performance in long lossy networks. These networks typically include satellite and other wireless environments, such as cellular networks, longer microwave, or Wi-Max networks.

• a pipe algorithm that gates when a packet should be sent after receipt of an ACK.

• the NewReno algorithm, which includes the sender's congestion window, slow start, and congestion avoidance.

• time stamps, window scaling, appropriate byte counting, and loss detection.

• Congestion loss while exiting the slow start phase. The slow-start phase is an important part of the TCP congestion-control mechanisms that starts slowly increasing its window size as it gains confidence about the network throughput.

• Congestion collapse.

• Packet bursts.

• Enable Auto-Detect TCP Optimization on the server-side SteelHead to negotiate the configuration with the client-side SteelHead.

• Configure an MX-TCP QoS rule to set the appropriate rate cap. If an MX-TCP QoS rule isn’t in place, rate pacing isn’t applied and the congestion-control method takes effect. You can’t delete the MX-TCP QoS rule when rate pacing is enabled.

• None—Turns off data encryption.

• AES_128—Encrypts data using the AES cryptographic key length of 128 bits.

• AES_192—Encrypts data using the AES cryptographic key length of 192 bits.

• AES_256—Encrypts data using the AES cryptographic key length of 256 bits.

• Riverbed LRU—Replaces the least recently used data in the RiOS data store, which improves hit rates when the data in the RiOS data store aren’t equally used. This is the default setting.

• FIFO—Replaces data in the order received (first in, first out).

• the amount of data replication your SteelHead is processing.

• the type of data being processed and its effects on disk throughput on the SteelHeads.

• your primary goal for the project, which could be maximum data reduction or maximum throughput. Even when your primary goal is maximum throughput you can still achieve high data reduction.

• Provides the most data reduction.

• Reduces random disk seeks and improves disk throughput by discarding very small data margin segments that are no longer necessary. This margin segment elimination (MSE) process provides network-based disk defragmentation.

• Writes large page clusters.

• Monitors the disk write I/O response time to provide more throughput.

• Legacy—Includes the default settings and also:

• Advanced—Maximizes LAN-side throughput dynamically under different data workloads. This switching mechanism is governed with a throughput and bandwidth reduction goal using the available WAN bandwidth. Both SteelHeads must be running RiOS 6.0.x or later.

• SMB2/SMB3 signing set to required. SMB3 signing is enabled by default.

• SMB3 secure dialect negotiation (enabled by default on the Windows 8 client).

• SMB3 encryption.

• Windows domain integration, including domain join and domain-level support.

• Authentication using transparent mode and delegation mode. Delegation mode is the default for SMB2. Transparent mode works out of the box with Windows Vista (but not Windows 7). To use transparent mode with Windows 7, you must join the server-side SteelHead as an Active Directory integrated (Windows 2003) or an Active Directory integrated (Windows 2008 and later).

• Secure inner-channel SSL support.

• Windows 2000

• Windows 2003 R2

• Windows 2008

• Windows 2008 R2

• a basic parent and child domain relationship. Users from the child domain access CIFS/MAPI servers in the parent domain. For example, users in ENG.RVBD.COM accessing servers in RVBD.COM.

• a grandparent and child domain relationship. Users from grandparent domain access resources from the child domain. For example, users from RVBD.COM accessing resources in DEV.ENG.RVBD.COM.

• a sibling domain relationship. For example, users from ENG.RVBD.COM access resources in MARKETING.RVBD.COM.

• NTLM transparent mode—Uses NTLM authentication end to end between the client-side and server-side SteelHeads and the server-side SteelHead and the server. This is the default mode for SMB1 and SMB2/3 signing starting with RiOS 9.6. Transparent mode in RiOS 6.1 and later supports all Windows servers, including Windows 2008 R2, that have NTLM enabled. We recommend using this mode.

• NTLM delegation mode—Uses Kerberos delegation architecture to authenticate signed packets between the server-side SteelHead and any configured servers participating in the signed session. NTLM is used between the client-side and server-side SteelHead. SMB2 delegation mode in RiOS 6.5 and later supports Windows 7 and Samba 4 clients. Delegation mode requires additional configuration of Windows domain authentication.

• Kerberos authentication support—Uses Kerberos authentication end to end between the client-side and server-side SteelHead and the server-side SteelHead and the server. Kerberos authentication requires additional configuration of Windows domain authentication.

• Windows 7 clients. RiOS 7.0 and later support transparent mode when you join the server-side SteelHead as an Active Directory integrated (Windows 2008) or an Active Directory integrated (Windows 2008).

• Windows 2008 R2 domains that have NTLM disabled.

• Windows servers that are in domains with NTLM disabled.

• Windows 7 clients that have NTLM disabled.

• If the client-side machine has Required signing, enabling this feature prevents the client from connecting to the server.

• If the server-side machine has Required signing, the client and the server connect but you can’t perform full latency optimization with the SteelHead. Domain Controllers default to Required.

• Encryption—The SMB 3.1.1 encryption ciphers are negotiated per-connection through the negotiate context. Windows 10 now supports the AES-128-CCM cipher in addition to AES-128-GCM for encryption. SMB 3.1.1 can negotiate to AES-128-CCM to support older configurations.

• Preauthentication Integrity—Provides integrity checks for negotiate and session setup phases. The client and server maintain a running hash on all of the messages received until there’s a final session setup response. The hash is used as input to the key derivation function (KDF) for deriving the session secret keys.

• Extensible Negotiation—Detects man-in-the-middle attempts to downgrade the SMB2/3 protocol dialect or capabilities that the SMB client and server negotiate. SMB 3.1.1 dialect extends negotiate request/response through negotiate context to negotiate complex connection capabilities such as the preauthentication hash algorithms and the encryption algorithm.

• Encryption—If the server and client negotiate SMB3 and the server is configured for encryption, all SMB3 packets following the session setup are encrypted on the wire, except for when share-level encryption is configured. Share-level encryption marks a specific share on the server as being encrypted; if a client opens a connection to the server and tries to access the share, the system encrypts the data that goes to that share. The system doesn’t encrypt the data that goes to other shares on the same server.

• New Signing Algorithm—SMB3 uses the AES-CMAC algorithm instead of the HMAC-SHA256 algorithm used by SMB2 and enables signing by default.

• Secure Dialect Negotiation—Detects man-in-the-middle attempts to downgrade the SMB2/3 protocol dialect or capabilities that the SMB client and server negotiate. Secure dialect negotiation is enabled by default in Windows 8 and Server 2012. You can use secure dialect negotiation with SMB2 when you are setting up a connection to a server running Server 2008-R2.

• a vastly reduced set of opcodes (a total of only 18); in contrast, SMB1 has over 70 separate opcodes. Note that use of SMB2 doesn’t result in lost functionality (most of the SMB1 opcodes were redundant).

• general mechanisms for data pipelining and lease-based flow control.

• request compounding, which allows multiple SMB requests to be sent as a single network request.

• larger reads and writes, which provide for more efficient use of networks with high latency.

• caching of folder and file properties, where clients keep local copies of folders and files.

• improved scalability for file sharing (number of users, shares, and open files per server greatly increased).

• Sync Schedule Date, Time—Sets date (yyyy/mm/dd) and time (hh:mm:ss) for synchronizing the appliance with the server.

• Sync Interval—Set number and select Minutes, Hours, Days, or Disabled from the drop-down list.

• Static—Displays only the static subnet or hostname configurations in the subnet and hostname list. You create a static configuration manually to fine-tune HTTP optimization for a particular host or server subnet. By default, RiOS displays both automatic and static configurations.

• Auto—Displays only the automatic subnet or hostname configurations in the subnet and hostname list. RiOS creates automatic configurations when you select Enable Per-Host Auto Configuration, based on an application profile. Automatic configurations define the optimal combination of URL learning, Parse and Prefetch, and Object Prefetch Table for the host or subnet. By default, RiOS displays both automatic and static configurations.

• Auto (Eval)—Displays the automatic hostname configurations currently under evaluation. By default, the evaluation period is 1000 transactions.

• When using HTTP, Outlook can only use NTLM proxy authentication.

• When using HTTPS, Outlook can use NTLM or Basic proxy authentication.

• When using encrypted MAPI with HTTP or HTTPS, you must enable and configure encrypted MAPI in addition to this feature.

• When autodetect is enabled and the in-path rule doesn’t match, RiOS optimizes Outlook Anywhere if it detects the RPC over HTTPS protocol.

• When autodetect isn’t enabled and the in-path rule doesn’t match, RiOS doesn’t optimize Outlook Anywhere.

• When autodetect is enabled and the in-path rule matches with HTTP only, RiOS doesn’t optimize Outlook Anywhere (even if it detects the RPC over HTTPS protocol).

• When autodetect isn’t enabled and the in-path rule doesn’t match with HTTP only, RiOS doesn’t optimize Outlook Anywhere.

• When autodetect is enabled and the in-path rule matches with an Outlook Anywhere latency optimization policy, RiOS optimizes Outlook Anywhere (even if it doesn’t detect the RPC over HTTPS protocol).

• When autodetect isn’t enabled and the in-path rule matches with Outlook Anywhere, RiOS optimizes Outlook Anywhere.

• Custom—Specifies a custom policy for the NFS server.

• Global Read-Write—Specifies a policy that provides data consistency rather than performance. All of the data can be accessed from any client, including LAN-based NFS clients (which don’t go through the SteelHeads) and clients using other file protocols such as CIFS. This option severely restricts the optimization that can be applied without introducing consistency problems. This is the default configuration.

• Read-only—Specifies that the clients can read the data from the NFS server or volume but can’t make changes.

• Custom—Specifies a custom policy for the NFS volume.

• Global Read-Write—Specifies a policy that provides data consistency rather than performance. All of the data can be accessed from any client, including LAN-based NFS clients (which don’t go through the SteelHeads) and clients using other file protocols such as CIFS. This option severely restricts the optimization that can be applied without introducing consistency problems. This is the default configuration.

• Read-only—Specifies that the clients can read the data from the NFS server or volume but can’t make changes.

• Microsoft Windows file servers using signed SMB for file sharing to Microsoft Windows clients.

• Microsoft Exchange Servers providing an encrypted MAPI communication to Microsoft Outlook clients.

• Microsoft Internet Information Services (IIS) web servers running HTTP or HTTP-based web applications.

• SMB signing

• SMB2 signing

• Encrypted MAPI and encrypted Outlook Anywhere

• HTTP or HTTP-based traffic

• Off disables OCSP. Disabled by default.

• Strict bypasses the connection is the origin server does not support OCSP.

• Strict AIA bypasses the connection if the certificate included an Authority Information Access (AIA) field but the origin server failed to send an OCSP response. If the certificate did not include an AIA field and the origin server failed to send an OCSP response, the connection is not dropped because the server-side appliance does not expect an OCSP response.

• Loose does not bypass the connection if the origin server does not support OCSP.

• Upload—Browse to the local file in PKCS-12, PEM, or DER formats.

• Paste it here (PEM only)—Copy and then paste the contents of a PEM file.

• The Private Key is in a separate file (see below)—You can either upload it or copy and paste it.

• This file includes the Certificate and Private Key

• The Private Key for this Certificate was created with a CSR generated on this appliance.

• Upload (PEM or DER formats)—Browse to the local file in PEM or DER formats.

• Paste it here (PEM only)—Paste the contents of a PEM file.

• Common name—Specify the common name (hostname) of the peer.

• Organization Name—Specify the organization name (for example, the company).

• Organization Unit Name—Specify the organization unit name (for example, the section or department).

• Locality—Specify the city.

• State (no abbreviations)—Specify the state.

• Country (2-letter code)—Specify the country (2-letter code only).

• Email Address—Specify the email address of the contact person.

• Validity Period (Days)—Specify how many days the certificate is valid. The default value is 730.

• Common Name (required)—Specify the common name (hostname) of the peer.

• Organization Name—Specify the organization name (for example, the company).

• Organization Unit Name—Specify the organization unit name (for example, the section or department).

• Locality—Specify the city.

• State—Specify the state. Don’t abbreviate.

• Country (2-letter code)—Specify the country (2-letter code only).

• Email Address—Specify the email address of the contact person.

• Validity Period (Days)—Specify how many days the certificate is valid. The default value is 730.

• MAPI-encrypted, SMB1, and SMB2-signed traffic.

• Citrix traffic (RiOS 7.0 and later).

• all other traffic that inherently doesn’t require a secure connection.

• SSL Only—The peer client-side appliance and the server-side SCC authenticate each other and then encrypt and optimize all SSL traffic: for example, HTTPS traffic on port 443. This is the default setting.

• SSL and Secure Protocols—The peer client-side appliance and the server-side appliance authenticate each other and then encrypt and optimize all traffic traveling over these secure protocols: SSL, SMB signed, and encrypted MAPI. When you select this traffic type, SMB-signing and MAPI encryption must be enabled. Enabling this option requires an optimization service restart.

• All—The peer client-side appliance and the server-side appliance authenticate each other and then encrypt and optimize all traffic. Only the optimized traffic is secure; pass-through traffic isn’t. Enabling this option requires an optimization service restart.

• Certificates of trusted peers.

• Certificates of trusted Certificate Authorities (CAs) that may sign certificates for peers.

• Your organization has an internal CA that signs the certificates or peering certificates for the back-end server.

• The server certificates are signed by an intermediate or root CA unknown to the appliance (perhaps external to the organization).

• The CA certificate included in the trusted list of the appliance has expired or has been revoked and needs replacing.

• Optional Local Name—Specify the local filename.

• Local File—Browse to the local certificate authority file.

• Cert Text—Paste the certificate authority into the text box and click Add.

• conventional CAs, which are listed in the Certificate Authorities page.

• peering CAs, which are listed in the Trusted Entities list in the Secure Peering page.

• High Security Mode—Enforces the advanced SSL protocol on the Client Accelerators for increased security.

• Mixed Security Mode—Allows Client Accelerator Controller clients to run in any SSL mode. This mode is required to optimize with mobile clients running on VMware Fusion.

• Timeout—Specify the amount of time the client can reuse a session with an SSL server after the initial connection ends. The range is from 6 minutes to 24 hours. The default value is 10 hours.

• Off—By default, client certificate support is off and the SSL handshake relies only on a server certificate.

• On—This mode relies on passive key derivation.

• Enable client certificate support on the server-side SteelHead.

• The server-side SteelHead must have access to the exact private key used by the SSL server.

• The SSL server must be configured to ask for client certificates.

• The SteelHead must have a compatible cipher chosen by the server.

• SSL sessions that reuse previous secrets that are unknown to the SteelHead can’t be decrypted.

• Client-side certificates with renegotiation handshakes aren’t supported.

• Client certificate supports the RSA key exchange only. It doesn’t support the Diffie-Hellman key exchange.

• Peering—In peering mode, the SteelHead needs a proxy certificate for the connection, but it does not need the origin server’s private key. This mode lets the SteelHead respond to client authentication requests by using its peering certificate.

• create an in-path rule on the client-side SteelHead to identify the proxy server IP address and port number. Select the SSL preoptimization policy for the rule.

• enable SSL optimization on both the client-side and server-side SteelHeads.

• ensure both the client-side and server-side SteelHeads are running RiOS 7.0 or later.

• restart the optimization service on both SteelHeads.

• Both the client-side and server-side SteelHeads must be running RiOS 7.0 or later.

• The SSL client must be the same as the TCP client.

• SSL messages can’t be wrapped with any other non-SSL or non-TCP protocol headers or footers.

• SSL optimization must be enabled on both the client-side and server-side SteelHeads.

• Adds the SNI extension from the client Hello to the server-side SteelHead client Hello.

• Uses the SNI extension to match and select the proxy certificate to return to the client.

• DES—The Data Encryption Standard. This is the default value.

• 3DES—Triple DES encryption algorithm.

• AES—The AES 128-bit encryption algorithm.

• AES256—The AES 256-bit encryption algorithm.

• MD5—Enables MD5 security protocol.

• SHA-1—Enables SHA security protocol.

• SHA-256—Enables the SHA-256 cryptographic hash function.

• SHA-384—Enables the SHA-384 cryptographic hash function.

• SHA-512—Enables the SHA-512 cryptographic hash function.

• DES—Encrypts data using the Data Encryption Standard algorithm. DES is the default value.

• NULL—Specifies the null encryption algorithm.

• None—Doesn’t apply an encryption policy.

• 3DES—Appears when a valid Enhanced Cryptography License Key is installed on the appliance. Encrypts data using the Triple Digital Encryption Standard with a 168-bit key length. This standard is supported for environments where AES hasn’t been approved, but is both slower and less secure than AES.

• AES—Appears when a valid Enhanced Cryptography License Key is installed on the appliance. Encrypts data using the Advanced Encryption Standard (AES) cryptographic key length of 128 bits.

• AES256—Appears when a valid Enhanced Cryptography License Key is installed. Encrypts data using the Advanced Encryption Standard (AES) cryptographic key length of 256 bits. Provides the highest security.

• MD5—Specifies the Message-Digest 5 algorithm, a widely-used cryptographic hash function with a 128-bit hash value. This is the default value.

• SHA-1—Specifies the Secure Hash Algorithm, a set of related cryptographic hash functions. SHA-1 is considered to be the successor to MD5.

• SHA-256—Enables the SHA-256 cryptographic hash function.

• SHA-384—Enables the SHA-384 cryptographic hash function.

• SHA-512—Enables the SHA-512 cryptographic hash function.

• shared-secret—Enables shared secret mode. All the SteelHeads in a network for which you want to use IPsec must have the same shared secret.

• certificate—Enables certificate mode.

• Improved performance for applications by saving the round trips previously needed to resolve names. Whenever the name server receives address information for another host or domain, it stores that information for a specified period of time. That way, if it receives another name resolution request for that host or domain, the name server has the address information ready, and doesn’t need to send another request across the WAN.

• Improved performance for services by saving round trips previously required for updates.

• Continuous DNS service locally when the WAN is disconnected, with no local administration needed, eliminating the need for DNS servers at branch offices.

• Enabled—Forwards name resolution requests to a DNS name server, then stores the address information locally in the SCC. By default, the requests go to the root name server, unless you specify another name server.

• Disabled—Stops the SCC from acting as the DNS name server.

• Enabled—Enables the name server to listen for name resolution requests on the primary interface.

• Disabled—Stops the name server from using the primary interface

• Enabled—Enables the name server to listen for name resolution requests on the auxiliary interface.

• Disabled—Stops the name server from using the auxiliary interface.

• Connection Limit—Indicates the system connection limit has been reached. Additional connections are passed through unoptimized. The alarm clears when the appliance moves out of this condition.

• CPU—The appliance has entered admission control due to high CPU use. During this event, the appliance continues to optimize existing connections, but new connections are passed through without optimization. The alarm clears automatically when the CPU usage has decreased.

• MAPI—The total number of MAPI optimized connections have exceeded the maximum admission control threshold. By default, the maximum admission control threshold is 85 percent of the total maximum optimized connection count for the client-side appliance. The appliance reserves the remaining 15 percent so that the MAPI admission control doesn’t affect the other protocols. The 85 percent threshold is applied only to MAPI connections. RiOS is now passing through MAPI connections from new clients but continues to intercept and optimize MAPI connections from existing clients (including new MAPI connections from these clients). RiOS continues optimizing non-MAPI connections from all clients. The alarm clears automatically when the MAPI traffic has decreased; however, it can take one minute for the alarm to clear.

• Memory—The appliance has entered admission control due to memory consumption. The appliance is optimizing traffic beyond its rated capability and is unable to handle the amount of traffic passing through the WAN link. During this event, the appliance continues to optimize existing connections, but new connections are passed through without optimization. No other action is necessary; the alarm clears automatically when the traffic has decreased.

• TCP—The appliance has entered admission control due to high TCP memory use. During this event, the appliance continues to optimize existing connections, but new connections are passed through without optimization. The alarm clears automatically when the TCP memory pressure has decreased.

• Cluster IPv6 Incompatible

• Cluster Neighbor Incompatible

• Connection Forwarding Ack Timeout

• Connection Forwarding Connection Failure

• Connection Forwarding Keepalive Timeout

• Connection Forwarding Latency Exceeded

• Connection Forwarding Lost Connection Error

• Connection Forwarding Lost Due To End Of Stream

• Connection Forwarding Read Information Timeout

• Multiple Interface Connection Forwarding

• Single Interface Connection Forwarding

• Rising Threshold—Specify the rising threshold. When an alarm reaches the rising threshold, it is activated. The default value is 90 percent.

• Reset Threshold—Specify the reset threshold. When an alarm reaches the lowest or reset threshold, it is reset. After an alarm is triggered, it isn’t triggered again until it has fallen below the reset threshold. The default value is 80 percent.

• Corruption—Enables an alarm and sends an email notification if the RiOS data store is corrupt or has become incompatible with the current configuration. To clear the RiOS data store of data, restart the optimization service and click Clear the Data Store.

• Data Store Clean Required—Enables an alarm and sends an email notification if you need to clear the RiOS data store.

• Encryption Level Mismatch—Enables an alarm and sends an email notification if a data store error, such as an encryption, header, or format error occurs.

• Synchronization Error—Enables an alarm if RiOS data store synchronization has failed. The RiOS data store synchronization between two SteelHeads has been disrupted and the RiOS data stores are no longer synchronized.

• Disk Error—Enables an alarm when one or more disks is offline. To see that disk is offline, enter this CLI command from the system prompt:

• Fan Error—Enables an alarm and sends an email notification if a fan is failing or has failed and needs to be replaced. By default, this alarm is enabled.

• Flash Error—Enables an alarm when the system detects an error with the flash drive hardware. By default, this alarm is enabled.

• IPMI—Enables an alarm and sends an email notification if an Intelligent Platform Management Interface (IPMI) event is detected. (Not supported on all appliance models.)

• Memory Error—Enables an alarm and sends an email notification if a memory error is detected. For example, when a system memory stick fails.

• Other Hardware Error—Enables an alarm if a hardware error is detected. These issues trigger the hardware error alarm:

• Power Supply—Enables an alarm and sends an email notification if an inserted power supply cord doesn’t have power, as opposed to a power supply slot with no power supply cord inserted. By default, this alarm is enabled.

• RAID—Enables an alarm and sends an email notification if the system encounters an error with the RAID array (for example, missing drives, pulled drives, drive failures, and drive rebuilds). An audible alarm can also sound. To see if a disk has failed, enter this CLI command from the system prompt:

• SSD Write Cycle Level Exceeded—Enables an alarm if the accumulated SSD write cycles exceed a predefined write cycle 95 percent level on appliance models 7050L and 7050M. If the alarm is triggered, the administrator can swap out the disk before any problems arise. By default, this alarm is enabled.

• Appliance Unlicensed—This alarm triggers if the SCC has no BASE or MSPEC license installed for its currently configured model.

• Autolicense critical event—This alarm triggers if the SCC autolicense has a critical event.

• Autolicense information event—This alarm triggers if the SCC autolicense has event information.

• Licenses Expired—This alarm triggers if one or more features has at least one license installed, but all of them are expired.

• Licenses Expiring—This alarm triggers if the license for one or more features is going to expire within two weeks.

• Load Balance Service—Indicates whether the load-balancing service is properly configured.

• Oversubscription Alert—Indicates when the total capacity of the remote SteelHeads is much greater than the total capacity of the local SteelHeads (oversubscription).

• Local SteelHead Interceptor Disconnection Alert—If a local Interceptor is disconnected from the cluster.

• SteelHead Admission Control Alert—If a local appliance is under admission control.

• SteelHead Capacity Alert—If a local appliance is near to or has reached capacity.

• SteelHead Permanent Capacity Adjustment Alert—If capacity reduction has been triggered for a local appliance.

• Version Incompatibility Alert—If version incompatibility exists among cluster appliances.

• Internal Error—Enables an alarm and sends an email notification if the RiOS optimization service encounters a condition that can degrade optimization performance. By default, this alarm is enabled.

• Service Status—Enables an alarm and sends an email notification if the RiOS optimization service encounters a service condition. By default, this alarm is enabled. The message indicates the reason for the condition.

• Unexpected Halt—Enables an alarm and sends an email notification if the RiOS optimization service halts due to a serious software error. By default, this alarm is enabled.

• Proxy File Service Configuration—Indicates that a configuration attempt has failed. If the system detects a configuration failure, attempt the configuration again.

• Proxy File Service Operation—Indicates that a synchronization operation has failed. If the system detects an operation failure, attempt the operation again.

• Secure Vault Locked—Indicates that the secure vault is locked. To optimize SSL connections or to use RiOS data store encryption, the secure vault must be unlocked.

• Secure Vault New Password Recommended—Indicates that the secure vault requires a new, nondefault password. Reenter the password.

• Secure Vault Not Initialized—Indicates that an error has occurred while initializing the secure vault. When the vault is locked, SSL traffic isn’t optimized and you can’t encrypt the RiOS data store.

• Non-443 SSL Servers—Indicates that during a RiOS upgrade (for example, from 5.5 to 6.0), the system has detected a preexisting SSL server certificate configuration on a port other than the default SSL port 443. SSL traffic can’t be optimized. To restore SSL optimization, you can add an in-path rule to the client-side SCC to intercept the connection and optimize the SSL traffic on the nondefault SSL server port.

• SSL Certificates Error (SSL CAs)—Indicates that an SSL peering certificate has failed to reenroll automatically within the Simple Certificate Enrollment Protocol (SCEP) polling interval.

• SSL Certificates Error (SSL Peering CAs)—Indicates that an SSL peering certificate has failed to reenroll automatically within the Simple Certificate Enrollment Protocol (SCEP) polling interval.

• SSL Certificates Expiring—Indicates that an SSL certificate is about to expire.

• SSL Certificates SCEP—Indicates that an SSL certificate has failed to reenroll automatically within the SCEP polling interval.

• The blockstore is running out of space.

• The blockstore is out of space.

• The blockstore is running out of memory.

• The blockstore couldn’t read data that was already replicated to the DC.

• The blockstore couldn’t read data that’s not yet replicated to the DC.

• The blockstore fails to start due to disk errors or an incorrect configuration.

• The Granite Edge software version is incompatible with the blockstore version on disk.

• The blockstore couldn’t save data to disk due to a media error.

• The Edge device has connected to a Granite Core that doesn’t recognize the Edge device.

• The Edge doesn’t have an active connection with the Granite Core.

• The data channel between Granite Core and the Edge is down.

• The connection between the Granite Core and the Edge has stalled.

• Critical Temperature—Enables an alarm and sends an email notification if the CPU temperature exceeds the rising threshold. When the CPU returns to the reset threshold, the critical alarm is cleared. The default value for the rising threshold temperature is 70C; the default reset threshold temperature is 67C.

• Warning Temperature—Enables an alarm and sends an email notification if the CPU temperature approaches the rising threshold. When the CPU returns to the reset threshold, the warning alarm is cleared.

• Rising Threshold—Specifies the rising threshold. The alarm activates when the temperature exceeds the rising threshold. The default value is 70 percent.

• Reset Threshold—Specifies the reset threshold. The alarm clears when the temperature falls below the reset threshold. The default value is 67 percent.

• Web Proxy Service - Configuration

• Web Proxy Service - Service Status

• Emergency—Unusable system.

• Alert—Action must be taken immediately.

• Critical—Conditions that affect the functionality of the SCC.

• Error—Conditions that probably affect the functionality of the SCC.

• Warning—Conditions that could affect the functionality of the SCC, such authentication failures.

• Notice—Normal but significant conditions, such as a configuration change. This is the default setting.

• Info—Informational messages that provide general information about system operations.

• Time—Select Day, Week, or Month from the drop-down list.

• Disk Space—Specify how much disk space, in megabytes, the log uses before it rotates. The default value is 16MB.

• Emergency—Unusable system.

• Alert—Action must be taken immediately.

• Critical—Conditions that affect the functionality of the SCC.

• Error—Conditions that probably affect the functionality of the SCC.

• Warning—Conditions that could affect the functionality of the SCC, such authentication failures.

• Notice—Normal but significant conditions, such as a configuration change. This is the default setting.

• Info—Informational messages that provide general information about system operations.

• alarmd—Alarm manager

• cifs—CIFS Optimization

• cmcfc—SCC Auto-registration Utility

• rgp—SCC Connector

• rgpd—SCC Connection Manager

• cli—Command-line interface

• mgmtd—Device Control and Management

• http—HTTP Optimization

• hald—Hardware Abstraction Daemon

• notes—Lotus Notes Optimization

• mapi—MAPI Optimization

• nfs—NFS Optimization

• pm—Process Manager

• qosd—QoS Classification

• sched—Process Scheduler

• ssl—SSL optimization

• statsd—Statistics Collector

• wdt—Watchdog Timer

• webasd—Web Application Process

• domain_auth—Windows Domain Authentication

• Emergency—Unusable system.

• Alert—Action must be taken immediately.

• Critical—Conditions that affect the functionality of the SCC.

• Error—Conditions that probably affect the functionality of the SCC.

• Warning—Conditions that could affect the functionality of the SCC, such authentication failures.

• Notice—Normal but significant conditions, such as a configuration change. This is the default setting.

• Info—Informational messages that provide general information about system operations.

• v1 or v2c displays another drop-down list; select a security name.

• usm displays another drop-down list, select a user.

• No Auth—Doesn’t authenticate packets and doesn’t use privacy. This is the default setting.

• Auth—Authenticates packets but doesn’t use privacy.

• SNMPv1

• SNMPv2

• SNMPv3, which provides authentication through the User-based Security Model (USM).

• View-Based Access Control Mechanism (VACM), which provides richer access control.

• SNMPv3 authentication using AES 128 and DES encryption privacy.

• MD5—Specifies the Message-Digest 5 algorithm, a widely used cryptographic hash function with a 128-bit hash value. This is the default value.

• SHA—Specifies the Secure Hash Algorithm, a set of related cryptographic

• No Auth—Doesn’t authenticate packets and doesn’t use privacy. This is the default setting.

• Auth—Authenticates packets but doesn’t use privacy.

• AuthPriv—Authenticates packets using AES 128 and DES to encrypt messages for privacy.

• MD5—Specifies the Message-Digest 5 algorithm, a widely-used cryptographic hash function with a 128-bit hash value. This is the default value.

• SHA-1—Specifies the Secure Hash Algorithm, a set of related cryptographic hash functions. SHA-1 is considered to be the successor to MD5.

• Privacy Protocol—Select either the AES or DES protocol from the drop-down list. AES uses the AES128 algorithm.

• Privacy—Select same as Authentication, Supply a Password, or Supply a Key to use while authenticating users. The default setting is Same as Authentication.

• is limited to 16 characters or fewer

• can’t include white space or #s

• can’t be empty

• is case sensitive

• Admin—The system administrator user has full privileges. For example, as an administrator you may set and modify configuration settings, add and delete users, restart the optimization service, reboot the SteelHead, and create and view performance and system reports. The system administrator role allows you to add or remove a system administrator role for any other user, but not for yourself.

• Monitor—A monitor user may view reports, view user logs, and change their password. A monitor user can’t make configuration changes, modify private keys, view logs, or manage cryptographic modules in the system.

• Max Web Login Limit—You can configure the maximum number of logins to the web UI for the specified user. The default value is -1 which allows for unlimited logins.

• Max CLI Login Limit—Configure the maximum number of logins to the CLI for this user. The default value is -1 which allows for unlimited logins.

• Enable Account—check this box to enable the specified account.

• Read-only—With read-only privileges you can view current configuration settings but you can’t change them.

• Read/write—With read and write privileges you can view settings and make configuration changes for a feature.

• Deny—With deny privileges you can’t view settings or save configuration changes for a feature.

• has permission to view current configuration settings but not change them (Read-Only).

• has permission to view settings and make configuration changes for a feature (read/write).

• is prevented from viewing or saving settings or configuration changes for a feature (Deny).

• Topology definitions

• Site and network definitions

• Application definitions

• Host interface settings

• Network interface settings

• DNS cache settings

• Hardware assist rules

• Host labels

• Port labels

• Strong—Sets the password policy to more stringent enforcement settings. Selecting this template automatically prepopulates the password policy with stricter settings commonly required by higher security standards such as for the Department of Defense.

• Basic—Reverts the password policy to its predefined settings so you can customize your policy.

• Server Key—Specify the override server key.

• Confirm Server Key—Confirm the override server key.

• Server Key—Specify the override server key.

• Confirm Server Key—Confirm the override server key.

• Sign Authentication Request—Select this option to have SCC sign the SAML authentication request sent to the identity provider. Signing the initial login request sent by SCC allows the identity provider to verify that all login requests originate from a trusted service provider.

• Requires Signed Assertions—Select if SAML assertions must be signed. Some SAML configurations require signed assertions to improve security.

• Requires Encrypted Assertions—Select this option to indicate to the SAML identity provider that SCC requires encrypted SAML assertion responses. When this option is selected, the identity provider encrypts the assertion section of the SAML responses. Even though all SAML traffic to and from SCC is already encrypted by the use of HTTPS, this option adds another layer of encryption.

• User Name Attribute—Enter the name of the IdP variable that carries the username of the user. The user name attribute is mandatory and must be sent by your identify provider in the SAML response to align the login with a configured SteelHead account. Default value is samlNameId.

• Member of Attribute—Enter the name of the IdP variable that carries the role of the user. Default value is memberOf.

• restrict access to certain interfaces or protocols of an appliance.

• restrict inbound IP access to an appliance, protecting it from access by hosts that don’t have permission without using a separate device (such as a router or firewall).

• specify that hosts or groups of hosts can access and manage an appliance by IP address, simplifying the integration of appliances into your network.

• detects the IP address you’re connecting from and displays a warning if you add a rule that denies connections to that address.

• always enables the default appliance ports 7800, 7801, 7810, 7820, and 7850.

• always enables a previously-connected SCC to connect and tracks any changes to the IP address of the SCC to prevent disconnection.

• converts well-known port and protocol combinations, such as SSH, Telnet, HTTP, HTTPS, SNMP, and SOAP into their default management service and protects these services from disconnection. For example, if you specify protocol 6 (TCP) and port 22, the management ACL converts this port and protocol combination into SSH and protects it from denial.

• tracks changes to default service ports and automatically updates any references to changed ports in the access rules.

• Allow—Enables a matching packet access to the SCC. This is the default action.

• Deny—Denies access to any matching packets.

• A SteelCentral NetProfiler communicating with a SteelCentral NetShark.

• A SteelCentral NetProfiler retrieving a QoS configuration from an appliance.