This chapter describes features that maximize performance of networks and hybrid networks across branch offices. Hybrid network architecture typically combines private assets such as MPLS-based WAN networks with public services such as the internet. RiOS provides application-level Quality of Service (QoS) and WAN path selection to control network consumption and prioritize critical and latency sensitive applications, while minimizing use by noncritical applications.

This chapter includes these topics:

For details about QoS and path selection, see the SteelHead Deployment Guide.

Network topology and application properties form the reusable building blocks that allow you to inspect and direct network traffic using the QoS, path selection, and web proxy features. On an SCC, you can protect network traffic by reusing these building blocks with the secure transport feature. In addition, the application statistics collector in the SCC provides visibility into the throughput data for optimized and pass-through traffic flowing in and out of the SteelHeads in your network. For details, see the SteelCentral Controller for SteelHead User Guide.

This table provides the suggested workflow for configuring QoS.

This table provides the suggested workflow for configuring path selection.

You define the network connectivity view in the Networking > Topology: Sites & Networks page.

RiOS 9.0 and later provide a way to define a static network topology to a configuration that is shareable between SteelHeads. The network topology definition becomes a building block that simplifies SteelHead feature configuration for path selection and QoS. You define a topology once and then reuse it as needed. The topology provides the network point-of-view to all other possible sites, including each remote site’s networks and a remotely pingable IP address.

RiOS uses the topology definition to:

We strongly recommend that you define topologies, push topology definitions, and distribute updates to an existing topology from a SteelCentral Controller for SteelHead to the SteelHead appliances, particularly with large scale deployments. For details, see the SteelCentral Controller for SteelHead Deployment Guide.

A network topology includes these WAN topology properties:

The Sites & Networks page is central to defining networks and sites, viewing sites with which a network is associated, changing or deleting sites, and assigning uplinks to a site.

Networks represent the WAN networks that sites use to communicate with each other, such as MLPS, VSAT, or internet.

You can optionally add sites to the network. A site is a logical grouping of subnets. Sites represent the physical and logical topology of a site type. You can classify traffic for each site using network addresses. Site types are typically data center, small, medium and large branch office, and so on. Sites provide the SteelHead with the IP addresses of all subnets existing within a site (this applies to non-SteelHead sites as well).

You must define local and remote sites. The site definitions include a list of IP subnets that path selection or QoS will use to identify the site. Every subnet must be globally unique, although they can overlap.

You also need to define the default site that provides a catch all for traffic not assigned to another site.

SteelHeads running RiOS 9.0 and later determine the destination site using a longest-prefix match on the site subnets. For example, if you define site 1 with 10.0.0.0/8 and site 2 with 10.1.0.0/16, then traffic to 10.1.1.1 matches site 2, not site 1. Consequently, the default site defined as 0.0.0.0 only matches traffic that doesn’t match any other site subnets. This is in contrast to RiOS 8.6 and earlier, where you configured sites in an explicit order and the first-matching subnet indicated a match for that site.

You can associate an inbound or outbound QoS profile with a site to fine-tune the QoS behavior for each site. For details, see Viewing and editing the default QoS classes and Adding QoS profiles.

The maximum number of QoS sites is 200. For details about the maximum number of rules and sites for a SteelHead CX model, see QoS recommendations.

The default site is a catch-all for traffic not assigned to another site that has a subnet of 0.0.0.0/0. You don’t need to add a remote site if you only have one remote site and the default site is suitable.

Configuring a network topology involves specifying uplinks. An uplink is the last network segment connecting the local site to a network. At a high level, you can define multiple uplinks to a given network. The SteelHead monitors the state of the uplink and, based on this, selects the appropriate uplink for a packet. Selecting appropriate uplinks for packets provides more control over network link use.

Remote uplinks are also important for QoS because they define the available bandwidth for remote sites. RiOS uses the specified bandwidth to compute the end-to-end bottleneck bandwidth for QoS.

You can define an uplink based on an egress interface and, optionally, the next-hop gateway IP address. You can specify different DSCP marks per uplink for a given flow, allowing an upstream router to steer packets based on the observed marking.

To monitor uplink availability, you configure the latency of the uplink (timeout) and the loss observed (threshold). Path selection uses ICMP pings to monitor the uplink state dynamically, on a regular schedule (the default is 2 seconds). If the ping responses don’t make it back within the probe timeout period, the probe is considered lost. If the system loses the number of packets defined by the probe threshold, it considers the uplink to be down and triggers an alarm, indicating that the uplink is unavailable.

If one uplink fails, the SteelHead directs traffic through another available uplink. When the original uplink comes back up, the SteelHead redirects the traffic back to it.

You can configure up to 1024 direct uplinks.

RiOS 8.6 and later include a tunnel mode to provide IPv4 generic routing encapsulation (GRE) for direct uplinks. Direct uplinks using GRE become direct tunneled uplinks. You must create direct tunneled uplinks to steer traffic over any uplink that traverses a stateful firewall between the server-side SteelHead and the client-side SteelHead.

Without GRE, traffic attempting to switch midstream to an uplink that traverses a stateful firewall might be blocked. The firewall needs to track the TCP connection state and sequence numbers for security reasons. Because the firewall has not logged the initial connection handshake, and has partial or no packet sequence numbers, it blocks the attempt to switch to the secondary uplink and might drop these packets. To traverse the firewall, path selection can encapsulate that traffic into a GRE tunnel. The most common examples of midstream uplink switching occur when:

The GRE tunnel starts with a SteelHead and ends at the remote SteelHead. Both SteelHeads must be running RiOS 8.6.x or later. The tunnel configuration is local. The remote IP address must be a remote SteelHead in-path interface and the remote SteelHead must have path selection enabled. ICMP responses from the remote SteelHead use the same tunnel from which the ping is received. The remote SteelHead must also have GRE tunnel mode enabled if the user wants return traffic to go through a GRE as well.

The sites appear in a table.

The default site matches all of the traffic that doesn’t match another site.

To edit a site, click Edit Site next to a site name, modify the definition, and click Save.

Starting with RiOS 9.7, Generic Routing Encapsulation (GRE) between two SteelHead appliances can be inspected and optimized. Enable the GRE tunnel optimization features with the in-path peering-gre command.

GRE optimization supports hub-and-spoke and spoke-to-spoke topologies. A maximum of 100 tunnels is supported on a hub-and-spoke topology or a spoke-to-spoke topology.

The GRE tunnel must be started and terminated between two routers. In addition, the default route for the client-side SteelHead and server-side SteelHeads should be directed to the WAN. Multiple SteelHead appliances can be used in a point-to-point GRE tunnel, as long as all of the SteelHeads are inside the tunnel.

This figure shows a sample supported topology for GRE optimization.

This figure shows a spoke-to-spoke topology with two GRE tunnels. Two client-side SteelHeads and a single server-side SteelHead terminate the optimized connections.

The following SteelHead appliances support GRE tunnel optimization:

The following features are supported with GRE tunnel optimization:

The following traffic is not optimized with GRE tunnel optimization:

The following features are not supported:

You define applications in the Networking > App Definitions: Applications page.

Application definitions enable you to attach a business relevancy to all traffic that goes through your network. To simplify SteelHead configuration, the definition of an application is a separate task in RiOS 9.0 and later. A separate application definition allows you to configure multiple rules using the same application without having to repeat the application definition for each rule.

Application definitions also enable you to use application groups so that you can configure and reuse a single rule for multiple applications. Using application groups in a rule can reduce the number of rules significantly.

RiOS 9.0 and later separates application definition from the QoS rules. For more information about QoS rules, see Configuring QoS.

We strongly recommend that you define applications and push application definitions from a SteelCentral Controller for SteelHead to the SteelHead appliances. For details, see the SteelCentral Controller for SteelHead Deployment Guide.

To view a list of predefined applications, see Application Signatures for AFE.

Defining an application means that you group together a set of criteria to match certain traffic. After you define the criteria, you can use an application to configure QoS and path selection rules.

You apply Riverbed QoS policies in the Networking > Network Services: Quality of Service page. This section describes how SteelHeads use Riverbed QoS policies to allocate bandwidth and latency priorities.

QoS is a reservation system for network traffic. In its most basic form, QoS allows organizations to allocate scarce network resources across multiple traffic types of varying importance. QoS implementations allow organizations to accurately control their applications by the amount of bandwidth they have access to and by their sensitivity to delay.

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

RiOS 9.5 introduced major changes to the Networking > Network Services: Quality of Service page:

RiOS 9.1 provides these enhancements:

RiOS 9.0 provides these enhancements:

RiOS 8.6 provides these enhancements:

RiOS 8.5 provides these enhancements:

QoS classes are based on traffic importance, bandwidth needs, and delay-sensitivity. You allocate network resources to each of the classes. Traffic flows according to the network resources allocated to its class.

You configure QoS on client-side and server-side SteelHeads to control the prioritization of different types of network traffic and to ensure that SteelHeads give certain network traffic (for example, Voice over IP (VoIP) higher priority over other network traffic.

QoS allows you to specify priorities for particular classes of traffic and properly distribute excess bandwidth among classes. The QoS classification algorithm provides mechanisms for link sharing and priority services while decoupling delay and bandwidth allocation.

Many QoS implementations use some form of Packet Fair Queueing (PFQ), such as Weighted Fair Queueing or Class-Based Weighted Fair Queueing. As long as high-bandwidth traffic requires a high priority (or vice-versa), PFQ systems perform adequately. However, problems arise for PFQ systems when the traffic mix includes high-priority, low-bandwidth traffic, or high-bandwidth traffic that doesn’t require a high priority, particularly when both of these traffic types occur together. Features such as low-latency queueing (LLQ) attempt to address these concerns by introducing a separate system of strict priority queueing that is used for high-priority traffic. However, LLQ isn’t an effective way of handling bandwidth and latency trade-offs. LLQ is a separate queueing mechanism meant as a workaround for PFQ limitations.

The Riverbed QoS system isn’t based on PFQ, but rather on Hierarchical Fair Service Curve (HFSC). HFSC delivers low latency to traffic without wasting bandwidth and delivers high bandwidth to delay-insensitive traffic without disrupting delay-sensitive traffic. The Riverbed QoS system achieves the benefits of LLQ without the complexity and potential configuration errors of a separate queueing mechanism.

The SteelHead HFSC-based QoS enforcement system provides the flexibility needed to simultaneously support varying degrees of delay requirements and bandwidth usage. For example, you can enforce a mix of high-priority, low-bandwidth traffic patterns (for example, SSH, Telnet, Citrix, RDP, and CRM systems) with lower priority, high-bandwidth traffic (for example, FTP, backup, and replication). RiOS QoS allows you to protect delay-sensitive traffic such as VoIP, as well as other delay-sensitive traffic such as RDP and Citrix. You can do this without having to reserve large amounts of bandwidth for their traffic classes.

QoS classification occurs during connection setup for optimized traffic, before optimization and compression. QoS shaping and enforcement occurs after optimization and compression.

By design, QoS is applied to both pass-through and optimized traffic; however, you can choose to classify either pass-through or optimized traffic. QoS is implemented in the operating system; it’s not a part of the optimization service. When the optimization service is disabled, all the traffic is pass-through and is still shaped by QoS.

We recommend the maximum classes, rules, and sites shown in this table for optimal performance and to avoid delays while changing the QoS configuration.

The QoS bandwidth limits are global across all WAN interfaces and the primary interface.

Traffic that passes through a SteelHead but isn’t destined to the WAN isn’t subject to the QoS bandwidth limit. Examples of traffic that isn’t subject to the bandwidth limits include routing updates, DHCP requests, and default gateways on the WAN-side of the SteelHead that redirect traffic back to other LAN-side subnets.

For the following appliance models, the network services flows and WAN capacity replace the maximum configurable QoS root bandwidth in previous RiOS versions. Network services include these features: path selection, secure transport, SteelFlow, and the Application Flow Engine (AFE).

For the GX10000, the total recommended number of classes and rules cannot exceed 4,000.

We recommend a maximum limit on the configurable root bandwidth for the WAN interface. The hardware platform determines the recommended limit. For details, see QoS recommendations.

Certain virtual in-path network topologies where the LAN-bound traffic traverses the WAN interface might require that the SteelHead bypass LAN-bound traffic so that it’s not included in the rate limit determined by the recommended maximum root bandwidth. Some deployment examples are WCCP or a WAN-side default gateway.

In-path configuration where default LAN gateway is accessible over the SteelHead WAN interface and WCCP configuration where default LAN gateway is accessible over the SteelHead WAN interface illustrate topologies where the default LAN gateway or router is accessible over the WAN interface of the SteelHead. If there are two clients in the local subnet, traffic between the two clients is routable after reaching the LAN gateway. As a result, this traffic traverses the WAN interface of the SteelHead.

 

In a QoS configuration for these topologies, suppose you have several QoS classes created and the root class is configured with the WAN interface rate. The remainder of the classes use a percentage of the root class. In this scenario, the LAN traffic is rate limited because RiOS classifies it into one of the classes under the root class.

You can use the LAN bypass feature to exempt certain subnets from QoS enforcement, bypassing the rate limit. The LAN bypass feature is enabled by default and comes into effect when subnet side rules are configured.

To verify the traffic classification, choose Reports > Networking: Inbound QoS or Outbound QoS.

When configuring QoS classification for FTP, the QoS rules differ depending on whether the FTP data channel is using active or passive FTP. Active versus passive FTP determines whether the FTP client or the FTP server select the port connection for use with the data channel, which has implications for QoS classification.

The AFE doesn’t support passive FTP. Because passive FTP uses random high TCP port numbers to set up its data channel from the FTP server to the FTP client, the FTP data traffic can’t be classified on the TCP port numbers. To classify passive FTP traffic, you can add an application rule where the application is FTP and matches the IP address of the FTP server.

With active FTP, the FTP client logs in and enters the PORT command, informing the server which port it must use to connect to the client for the FTP data channel. Next, the FTP server initiates the connection toward the client. From a TCP perspective, the server and the client swap roles. The FTP server becomes the client because it sends the SYN packet, and the FTP client becomes the server because it receives the SYN packet.

Although not defined in the RFC, most FTP servers use source port 20 for the active FTP data channel.

For active FTP, configure a QoS rule on the server-side SteelHead to match source port 20. On the client-side SteelHead, configure a QoS rule to match destination port 20.

You can also use AFE to classify active FTP traffic.

With passive FTP, the FTP client initiates both connections to the server. First, it requests passive mode by entering the PASV command after logging in. Next, it requests a port number for use with the data channel from the FTP server. The server agrees to this mode, selects a random port number, and returns it to the client. Once the client has this information, it initiates a new TCP connection for the data channel to the server-assigned port. Unlike active FTP, there’s no role swapping and the FTP client initiates the SYN packet for the data channel.

The FTP client receives a random port number from the FTP server. Because the FTP server can’t return a consistent port number to use with the FTP data channel, RiOS doesn’t support QoS Classification for passive FTP in versions earlier than RiOS 4.1.8, 5.0.6, or 5.5.1. Later RiOS releases support passive FTP and the QoS Classification configuration for passive FTP is the same as active FTP.

When configuring QoS Classification for passive FTP, port 20 on both the server-side and client-side SteelHeads indicates the port number used by the data channel for passive FTP, as opposed to the literal meaning of source or destination port 20.

RiOS 9.x doesn’t support packet-order queueing or latency priorities with Citrix traffic. We recommend using either the Autonegotiation of Multi-Stream ICA feature or the Multi-Port feature to classify Citrix traffic types for QoS. For details, see Configuring Citrix optimization.

RiOS 8.6.x and earlier provide a way to classify Citrix traffic using QoS to differentiate between different traffic types within a Citrix session. QoS classification for Citrix traffic is beneficial in mixed-use environments where Citrix users perform printing and use drive-mapping features. Using QoS to classify Citrix traffic in a mixed-use environment provides optimal network performance for end users.

Citrix QoS classification provides support for Presentation Server 4.5, XenApp 5.0 and 6.0, and 10.x, 11.x, and 12.x clients.

The essential RiOS capabilities that ensure optimal delivery of Citrix traffic over the network are:

The default ports for the Citrix service are 1494 (native ICA traffic) and 2598 (session reliability). To use session reliability, you must enable Citrix optimization on the SteelHead in order to classify the traffic correctly. You can enable and modify Citrix optimization settings in the Optimization > Protocols: Citrix page. For details, see Configuring Citrix optimization.

You can use session reliability with optimized traffic only. Session reliability with RiOS QoS doesn’t support pass-through traffic. For details about disabling session reliability, go to
http://support.citrix.com/proddocs/index.jsp?topic=/xenapp5fp-w2k8/ps-sessions-sess-rel.html.

This section describes how to configure QoS. It contains these topics:

QoS configuration identifies business applications and classifies traffic according to priorities. The SteelHead uses this information to control the amount of WAN resources that each application can use. QoS ensures that your important applications are prioritized and removes the guesswork from protecting performance of key applications. In addition, QoS can prevent recreational applications from interfering with business applications.

We strongly recommend that you configure QoS on and push QoS policies from a SteelCentral Controller for SteelHead to the SteelHead appliances, particularly with large scale deployments. For details, see the SteelCentral Controller for SteelHead Deployment Guide.

Every SteelHead has predefined classes that categorize network traffic. For more information, see Viewing and editing the default QoS classes. You can keep the default classes, or modify them by adding subclasses and rules. See Adding QoS profiles and Adding and editing QoS rules for more information.

A useful way to configure QoS is to add a subclass or rule and use group applications and application signatures that come predefined with RiOS. To find applications available in your version of the software, see Application Signatures for AFE. For the list of application groups, and to create a custom application, see Defining applications.

Before configuring QoS, we recommend that you define any applications that are not already defined. See Defining applications for more information.

And all in-path interfaces are enabled for inbound and outbound QoS with the same link rate.

Starting with RiOS 9.5, there is no default profile in the QoS Profiles pane. Instead, SteelHeads display a set of default QoS classes in the Default QoS Classes pane. These classes take the place of the default QoS profile. To view the classes, choose Networking > Network Services: Quality of Service.

The default classes represent the following types of traffic:

RealTime - Specifies real-time traffic class. Give this value to the highest-priority traffic: for example, VoIP or video conferencing.

Interactive - Specifies an interactive traffic class: for example, Citrix, RDP, telnet, and SSH.

BusinessCritical - Specifies the high-priority traffic class: for example, Thick Client Applications, ERPs, and CRMs.

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

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

BestEffort - Specifies the lowest priority.

The QoS class indicates how delay-sensitive a traffic class is to the QoS scheduler. These are minimum service class guarantees; if better service is available, it’s provided. For example, if a class is specified as low priority and the higher-priority classes aren’t active, then the low-priority class receives the highest possible available priority for the current traffic conditions. This parameter controls the priority of the class relative to the other classes.

Classes are organized in a hierarchical tree structure. You can use the default classes in rules as part of a profile by choosing Any (Default Rule) in the QoS Rules pane, which inherits the default classes.

You can create additional profiles to set QoS classes and rules for multiple sites. For details about sites, see Defining a site. For details about QoS, see the SteelHead Deployment Guide and the QoS on SteelHeads Feature Module.

A QoS profile contains a set of QoS classes and rules.

QoS profiles in RiOS 9.0 and later replace QoS service policies in previous versions.

In RiOS 9.0 and later, QoS rules assign traffic to a particular QoS class. Prior to RiOS 9.0, QoS rules defined an application; however, applications are now defined separately, and you can add application groups, application signatures, or custom applications as part of a rule. To learn how to find applications supported in the software, see Application Signatures for AFE. For the list of application groups, and to create a custom application, see Defining applications.

You can create multiple QoS rules for a profile. When multiple QoS rules are created for a profile, the rules are followed in the order in which they’re shown in the QoS Profile page and only the first matching rule is applied to the profile.

SteelHeads support up to 2000 rules and up to 500 sites. When a port label is used to add a QoS rule, the range of ports can’t be more than 2000 ports.

If a QoS rule is based on an application group, it counts as a single rule. Using application groups can significantly reduce the number of rules in a profile.

In RiOS 9.0 and later, QoS rules assign traffic to a particular QoS class. Prior to RiOS 9.0 QoS rules defined an application; now you use application properties. For more information, see Defining applications.

Including the QoS rule in the profile prevents the repetitive configuration of QoS rules, because you can assign a QoS profile to multiple sites.

For more information about QoS profiles, see Adding QoS profiles.

After you apply your settings, you can verify whether the traffic is categorized in the correct class by choosing Reports > Networking: Outbound QoS and viewing the report. For example, if you have configured VoIP traffic as real-time, check the real-time class and verify that existing classes aren’t receiving VoIP traffic.

You can verify whether the configuration is honoring the bandwidth allocations by reviewing the Outbound QoS and Inbound QoS reports.

When you have verified appropriate changes, you can write the active configuration that is stored in memory to the active configuration file (or you can save it as any filename you choose). For details about saving configurations, see Managing configuration files.

When you define a QoS class, you can enable a maximum speed TCP (MX-TCP) queue policy, which prioritizes TCP/IP traffic to provide more throughput for high loss links or links that have large bandwidth and high latency LFNs. Some use case examples are:

After enabling the MX-TCP queue to forward TCP traffic regardless of congestion or packet loss, you can assign QoS rules that incorporate this policy only to links where TCP is of exclusive importance.

These exceptions to QoS classes apply to MX-TCP queues:

When enabling MX-TCP, ensure that the QoS rule is at the top of QoS rules list.

This table describes the basic steps to configure MX-TCP. Enabling this feature is optional.

You can modify the profile name, QoS class properties, and QoS rule properties in the Networking > Network Services: QoS Profiles page. You can rename a profile name, class, or rule seamlessly without the need to manually update the associated resources. For example, if you rename a profile associated with a site, the system updates the profile name and the profile name within the site definition automatically.

For details on creating a profile, see Adding QoS profiles.

When two SteelHeads see each other for the first time, either through autodiscovery or a fixed-target rule, they set up an out-of-band (OOB) splice. This is a control TCP session between the two SteelHeads that the system uses to test the connectivity between the two appliances.

After the setup of the OOB splice, the two SteelHeads exchange information about each other such as the hostname, licensing information, RiOS versions, capabilities, and so on. This information is included in the Riverbed control channel traffic.

By default, the control channel traffic isn’t marked with a DSCP value. By marking the control channel traffic with a DSCP or ToS IP value, you can prevent dropped packets and other undesired effects on a lossy or congested network link.

In RiOS 9.0 and earlier, the qos dscp-marking enable command enables global DSCP marking, which tags inner channel setup packets and OOB packets with a DSCP value. RiOS 9.1 and later let you use the management console to separate the inner channel setup packets from the OOB packets and mark the OOB control channel traffic with a unique DSCP value.

Before marking OOB traffic with a DSCP value, ensure that the global DSCP setting isn’t in use. Global DSCP marking includes both inner channel setup packets and OOB control channel traffic. This procedure separates the OOB traffic from the inner channel setup traffic. For details on disabling global DSCP marking, see the [no] qos dscp-marking enable command in the Riverbed Command-Line Interface Reference Manual.

The new QoS rule appears in the QoS Rules table.

You configure inbound QoS in the Networking > Network Services: Quality of Service page. RiOS 9.0 and later provide feature parity between outbound and inbound QoS.

Inbound QoS allocates bandwidth and prioritizes traffic flowing into the LAN network behind the SteelHead. Inbound QoS provides the benefits of QoS for environments that can’t meet their QoS requirements with outbound QoS.

Some examples of environments that can benefit from inbound QoS are:

Configuring inbound QoS focuses on prioritizing types of traffic using rules and classes just like outbound QoS. The inbound configuration is separate from the outbound configuration. You define the applications on the local network and then create their corresponding shaping policies.

Inbound QoS applies the HFSC shaping policies to the ingress traffic. Applying policies to the ingress traffic addresses environments in which bandwidth constraints exist at the downstream location. When this condition occurs, the downstream SteelHead (where inbound QoS is enabled) dynamically communicates the bandwidth constraints to the client transmitting the traffic. The client slows down the throughput and the traffic adheres to the configured inbound QoS rule. Inbound QoS, just like outbound QoS, isn’t a dual-ended SteelHead solution. A single SteelHead performing traffic shaping as needed to avoid network congestion controls inbound WAN traffic on its own.

For details about the HFSC queueing technology, see Traffic classification and the SteelHead Deployment Guide.

QoS rules define the types of traffic flowing into the branch office. As with outbound QoS, the rule can match the traffic based on VLAN, IP header values, TCP/UDP ports, and AFE information. As an example, you can ensure that the voice traffic on the WAN is reserved a fixed bandwidth and this traffic has a higher priority over the recreational internet traffic.

Inbound classes shape the inbound traffic. The class configuration resembles an outbound QoS class configuration. An outbound QoS configuration describes remote sites and applications. Inbound QoS describes the local services and applications and how to shape the inbound traffic.

The inbound traffic shaping configuration includes a default shaping class. The QoS scheduler applies the built-in inbound default class constraints and parameters on traffic not placed in any other class by the configured QoS rules. The default shaping class has a 10 percent minimum bandwidth allocation and a 100 percent maximum bandwidth allocation. You can’t delete the default class; however, you can change its bandwidth allocations.

These limitations apply to inbound QoS traffic shaping.

For outbound QoS limit recommendations, see the SteelHead Deployment Guide.

You configure path selection in the Networking > Network Services: Path Selection page.

Path selection ensures the right traffic travels the right path, by choosing a predefined WAN gateway for certain traffic flows in real time, based on availability. You define a path, called an uplink, by specifying a WAN egress point and providing a direction for the egressing packets to take. This granular path manipulation enables you to better use and more accurately control traffic flow across multiple WAN circuits.

A common use of path selection is to route voice and video over an expensive, high-quality, multiprotocol label switching (MPLS) link, while offloading less time-sensitive business traffic over a less expensive internet VPN or direct internet link. Enabling internet paths makes efficient use of existing resources by taking advantage of both private and public links. Using path selection provides the right performance levels for your applications and saves on bandwidth costs by optimizing the use of available bandwidth.

The path selection WAN egress control:

To configure path selection, you define path selection rules to direct any application to any site.

Path selection rules direct matching traffic onto specific uplinks. Traffic is matched by a combination of application and destination site.

You can create multiple rules for a site. When multiple rules are created for a site, the rules are followed in the order in which they’re shown in the Path Selection page and only the first matching rule is applied to the site.

The network topology definition includes direct uplinks on a SteelHead. A SteelHead uses a direct uplink to steer packets to a specific gateway. The SteelHead can reach the gateway over Layer 2, so it can send packets directly to that gateway.

You configure a direct uplink using a SteelHead in-path IP address and a gateway IP address pair. For details, see Defining a hybrid network topology. When you define path selection rules, you specify the uplink preferences for certain traffic.

You must deploy two SteelHeads using path selection to enforce the return uplink. To define the return uplink for traffic and override the original traffic uplink, you must deploy a SteelHead near the return traffic WAN junction point.

For more information, see Path selection limitations and Path selection use cases.

For more details on path selection, see the SteelHead Deployment Guide.

You don’t need to restart the SteelHead to enable path selection. At this point, path selection is enabled. Path selection processes new flows after you enable it, but it doesn’t process preexisting flows.

If the primary uplink assigned to a connection becomes unavailable, the SteelHead directs traffic through the next available uplink and triggers the Path Selection Path Down alarm. When the original uplink comes back up, the SteelHead redirects the traffic back to it.

For details on the Path Selection Path Down alarm, see Configuring alarm settings and SNMP traps.

Use these pages to validate your design:

To troubleshoot, we recommend taking TCP dump traces on all WAN and LAN interfaces.

This section describes several different ways to configure path selection. For more use cases, see the SteelHead Deployment Guide.

In this configuration, you have multiple uplinks from the SteelHead to the remote data center. The SteelHead selects which uplink to use. For each application, you define the primary uplink as a combination of the outgoing interface (wan0_0 or wan0_1) and the next hop IP address. The system must send the probe packets over the exact uplink that the data packets take.

You can define this type of configuration in one of these ways:

In this configuration, you define a primary uplink by specifying the wan0_0 interface and the secondary uplink as the wan0_1 interface. Suppose that the SteelHead selects the primary uplink for the application. In this case, it doesn’t matter whether it sends the packet to path 1 or path 2. In both cases, the SteelHead selects the MPLS uplink.

While probing for the remote IP address from wan0_0, the probe packets use either R1 or R2. The SteelHead can’t monitor both uplinks because it doesn’t know about them. Because it monitors only one uplink, it ensures that all data packets are also sent over that uplink. Assuming that the probe packets are being sent to the remote IP through R1, it can’t use uplink 2 to send data packets toward the server, because this uplink might be down. The SteelHead doesn’t route data packets, but simply uses the next hop learned by probing.

In the case of the secondary uplink, all packets are sent through uplink 2 so there’s no confusion.

In this configuration, you specify the next hop as well as the relay interface to use for a given uplink. This is the simplest case, because the SteelHead doesn’t need to learn anything during probing. The SteelHead doesn’t need to route data packets, because they use the next hop specified in the configuration. The SteelHead sends the packets out of the configured relay.

You can use path selection in SteelHead Interceptor deployments using the SCC to manage all Interceptors in one centralized location. You can manage Interceptors as:

RiOS 9.1 extended path selection to operate in SteelHead Interceptor cluster deployments, providing high-scale and high-availability deployment options. A SteelHead Interceptor cluster is one or more SteelHead Interceptors collaborating with one or more SteelHeads to select uplinks dynamically.

SteelHeads select uplinks based on path selection rules and network conditions and instruct a SteelHead Interceptor to steer the WAN-bound packets to the chosen uplink. A SteelHead Interceptor redirects all connections that need to be path selected to the SteelHead for the lifetime of the connection, including UDPv4 and TCPv4 optimized and unoptimized connections.

For details on using an SCC to configure SteelHead Interceptors, see the SteelCentral Controller for SteelHead User Guide.

You can use path selection in Interceptor cluster deployments by configuring an Interceptor neighbor on a SteelHead. In RiOS 9.1 and later, you can use the SCC to manage all Interceptor configurations in one centralized location. We recommend that you use the SCC to configure Interceptor and SteelHead clusters instead of individually configuring each appliance for these reasons:

For details on using the SCC to configure path selection on Interceptors, see the SteelCentral Controller for SteelHead User Guide, the SteelHead Interceptor Deployment Guide, and the SteelHead Interceptor User Guide.

When configuring uplinks on the SteelHead for path selection in an Interceptor cluster, the uplink gateway need not be a Layer 2 hop away from the SteelHead, but it must be a Layer 2 hop away from one or more Interceptors in the cluster.

Each SteelHead must be aware of which Interceptor it can use to reach a particular uplink. This is accomplished by configuring a channel that acts as an overlay tunnel between the SteelHead and the Interceptor and allows the SteelHead to reach an uplink. One or more channels must be configured for every uplink. After the SteelHead has this information, RiOS uses the Riverbed encapsulation protocol (RBEP) when communicating with an Interceptor neighbor.

Path selection with Interceptor cluster deployments assumes that:

Adding an Interceptor as a SteelHead neighbor requires an optimization service restart, and enabling path selection on a SteelHead also requires an optimization service restart. You can avoid the second optimization service restart on the SteelHead by configuring path selection on all Interceptors in the cluster and then following the procedures in this section. All Interceptors in the cluster must be running version 5.0 or later.

For path selection limitations, see Path selection limitations for SteelHeads in an Interceptor cluster.

Path selection requires compatible configurations on all appliances in the cluster. When path selection is enabled on an appliance in the cluster while not enabled on another, the system considers the cluster to be incompatible and raises the Cluster Neighbor Incompatible alarm. This alarm provides the reason for the incompatibility and lists the incompatible Interceptors.

The incompatible appliances are also disconnected from each other, resulting in the Multiple Interface Connection Forwarding alarm. This alarm lists the disconnected appliances.

These limitations apply to SteelHead path selection in an Interceptor cluster:

For information on the Interceptor path selection limitations, see the SteelHead Interceptor Deployment Guide.