Application Definitions
  
Application Definitions
Application definitions is a grouping of related configuration pages in RiOS 9.0. This chapter describes how to define applications and application groups. Additionally it describes how to create host and port labels. To see the application definitions menu items, select Networking > App Definitions.
Important: If you are using a release previous to RiOS 9.0, the features described in the chapter are not applicable. For information about applications before RiOS 9.0, see earlier versions of the SteelHead Deployment Guide on the Riverbed Support site at https://support.riverbed.com.
This chapter includes the following sections:
•  Applications
•  Application Flow Engine
•  Creating Host Labels
•  Creating Port Labels
•  Creating Domain Labels
This chapter requires you be familiar with QoS Configuration and Integration and Path Selection.
For more information about configuring applications for QoS, see Configuring Applications.
Applications
This section describes how to define applications and work with application groups. Additionally, it describes the concept of application properties. This section includes the following topics:
•  Defining an Application
•  Application Properties
To simplify the SteelHead configuration, the definition of an application is a separate task in RiOS 9.0 and later. A separate application definition allows for the configuration of multiple rules, using the same application without having to repeat the application definition for each rule.
Note: In RiOS versions prior to version 9.0, the configuration of an application was tightly coupled with QoS rules.
Application definitions also enable you to group applications, so that you can configure and reuse a single rule for multiple applications. Using an application group in a rule can reduce the number of rules significantly.
For more information about QoS rules, see QoS Rules. For more information about grouping applications, see Application Properties.
Defining an Application
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.
Note: Custom-defined applications are not displayed in the Application Statistics or Application Visibility reports.
To define an application
1. Choose Networking > App Definitions: Applications.
The custom applications group is empty until you add application groups. For more information about application groups, see Application Properties.
2. Select Custom Applications from the drop-down menu and select Add (Figure: Add an Application).
Figure: Add an Application
3. Specify a name and a description for the new application.
Figure: Add an Application shows the example new application, MyApp.
4. Specify its traffic characteristics (Figure: Facebook Application).
You can use host labels instead of local and remote subnets, and you can use port labels instead of TCP/UDP port numbers.
For more information about traffic characteristics, see the SteelHead Management Console User’s Guide.
In addition to criteria matching on the IP-header based characteristics or the VLAN ID, you can use the Riverbed Application Flow Engine (AFE) to let RiOS automatically detect the application by typing the first letters of the application into the Application Layer Protocol field. For example, if you want to create specific criteria to identify Facebook traffic, type in the first three or four letters and a drop down menu opens, which lets you choose from Facebook applications.
Figure: Facebook Application
You can also create a QoS or path selection rule using the AFE directly in the rule. For more information about AFE, see Overview of Application Flow Engine.
5. Click Save to save the application to the list.
Figure: New Application shows MyApp in the custom application list.
Figure: New Application
Application Properties
Application properties provide a way to group applications based on the following criteria:
•  Application group
•  Category
•  Business criticality
The grouping of applications enables you to create path selection or QoS rules based on your users intent instead of single applications. For example, to configure all business critical applications for a QoS class, you can configure a single rule in a QoS profile based on the application group Business Critical. Without the application group you need to configure as many rules as there are business critical applications.
Note: Currently, the application properties Category and Business Criticality are not supported to configure path selection or QoS rules, nor can you create additional application groups.
Select the drop-down menu next to the application group on the Networking > App Definitions: Applications page to display all available groups (Figure: Application Groups).
Figure: Application Groups
Select an application group in the drop-down menu to view the application list associated with that group.
You can also add a new application to a group by selecting the group from the Application Group drop-down menu in the Application Properties section of the configuration page (Figure: Assigning the New Application a Group).
Figure: Assigning the New Application a Group
You can also change the membership of an application in an application group by editing the application.
For example, the application Facebook is preconfigured in the Recreational application group, but your company is using Facebook as a business productivity tool.
To move the Facebook application into the Business Productivity group, choose Networking > App Definitions > Applications and select the Recreational application group. Next, select Facebook and change the application group (Figure: Change Application Group Membership).
Figure: Change Application Group Membership
Application Flow Engine
This section includes the following topics:
•  Overview of Application Flow Engine
•  AFE and Microsoft Lync 2010 and 2013
Overview of Application Flow Engine
The Riverbed Application Flow Engine (AFE), QoS can identify applications accurately using a variety of technologies. It is a powerful engine that you can use to automatically detect applications on the network. You can also use AFE in QoS and path selection rules, in application definitions, and the application visibility reporting. In RiOS 9.1 and later, AFE can identify over 1300 applications and protocols.
Examples of technologies the AFE uses are:
•   Application signature/Pattern matching
–  Match well-known byte patterns in a flow and across multiple packets
–  Match the URL within HTTP
•  Protocol dissection/Protocol awareness
–  Layer-7 fluency to following the conversation
•  Behavioral classification/Heuristic classification
–  Analyses packet size, packet inter-arrival time, packet rate, data rate, and calculates entropy (randomness) to detect an application (for example, Skype)
•  Dynamic decode
–  Undoing obfuscation techniques (for example, base64)
If the AFE fails to identify the application based on the above technologies, it falls back to a TCP/UDP port-based classification.
To view a completed global application list, see the SteelHead Management Console User’s Guide.
In addition to the AFE supporting many well-known applications, you can add rules to identify custom applications. For example, you can identify a new HTTP application based on specific domain name or relative path (Figure: Rules to Identify Applications).
Figure: Rules to Identify Applications
With RiOS 8.6 or later, you can use the AFE to classify unoptimized SSL traffic based on the TLS/SSL server common name in the server certificate. To do this, add an application, type SSL in the Application Layer Protocol text box, and type the common name of the server certificate (for example, www.yoursite.com/*) in the Common Name field. To make the configuration easier, you can use wildcards in the name (Figure: SSL Common Name Matching Configuration).
Figure: SSL Common Name Matching Configuration
You cannot classify SSL optimized traffic using the common name control. For optimized or decrypted SSL traffic, the AFE uses the same techniques as nonencrypted traffic to classify the traffic.
For information about defining an application using the AFE, see Applications. For more information about SSL, see the SteelHead Deployment Guide - Protocols.
AFE and Microsoft Lync 2010 and 2013
RiOS 9.1 and later enhance support for Microsoft Lync. Lync is a multiple-feature communication suite that carries traffic over an extensive selection of protocols. The AFE classification of Lync traffic covers the majority of traffic generated between Lync clients and Lync servers.
The following table summarizes the types of traffic Lync generates and the classification the AFE provides for them:
Workload
Classified As
Client login
LYNC, LYNCCTRL
Chat message
LYNC, LYNCCTRL
File transfer
LYNC, LYNCSHRE
Group voice chat
LYNC, LYNCMDIA
Video call
LYNC, LYNCMDIA
Application screen sharing
LYNC, LYNCSHRE
Desktop sharing
LYNC, LYNCSHRE
Voice call
LYNC, LYNCMDIA
Presentation sharing
SSL, SIP
White-board session
SSL, SIP
Note: A Lync server uses the default SIP port of TCP 5061. You can use this information to build a custom rule to classify Lync SIP traffic.
Creating Host Labels
Use host labels to group multiple subnets or hostnames into one label. You create host labels on the Networking > App Definitions > Host Labels page (Figure: Host Labels Page).
Figure: Host Labels Page
The host label option covers a group of server IP addresses, subnets, and fully qualified domain name (FQDN) entries. FQDNs require that you configure a DNS server on the SteelHead so that it can resolve the host label of the FQDN.
After you create the host label, you can use the host label:
•  to define an application instead of using an IP addresse in the local and remote subnet fields of the New Application box (Figure: Adding the Host Label to an Application).
•  in the in-path rule list (Figure: Adding the Host Label to the In-Path Rule).
An application or an in-path rule defined using a host label can match traffic coming from multiple hostnames or IP addresses with a single rule definition.
For information about how to define an application, see Defining an Application.
Figure: Adding the Host Label to an Application
Figure: Adding the Host Label to the In-Path Rule
Use the following guidelines when creating a host label:
•  If hostnames in a host label are not resolved by DNS, traffic does not match.
•  You cannot use host labels to define sites.
•  Host labels only support IPv4.
•  All configured hostnames are automatically resolved by DNS every 24 hours by default. You can change the interval with the following CLI command:
host label refresh intvl <minutes>
•  Click Resolve Hostnames to immediately resolve hostnames through DNS.
•  Any changes in IP addresses that a hostname resolves are relayed to the rule using the host label.
•  You can configure a maximum of 100 unique hostnames (across all host labels combined).
•  There is a maximum of 64 subnets and hostnames per host label.
•  There is no limit on the number of host labels that you can configure.
•  Host labels are not supported on the source subnet field of an in-path rule.
•  Riverbed recommends that you use caution when using a host label in an in-path rule when you have cloud acceleration configured if the IP addresses or FQDNs in the host labels coincide with the cloud acceleration IP addresses.
The following table shows host label usage supportability with various deployment options:
SteelHead Deployment Options
Host label In-Path Rule Destination
Client-side and server-side inline
Yes. Host-label rule only configured on the client-side SteelHead.
Client-side virtual in-path
Yes
Server-side out-of-path
Yes, when using a fixed-target rule on the client-side SteelHead with a host label.
Connection forwarding
Client-side: Yes
Server-side: N/A
Agent-intercept mode (with discovery agent)
Client-side: Yes
Server-side: N/A
SteelHead Mobile
No
For more information about host labels, see the SteelHead Management Console User’s Guide.
Creating Port Labels
A port label is a name given to a set of TCP/UDP port numbers. You use port labels when you configure in-path rules, peering rules, or applications.
RiOS uses predefined port labels and in-path rules to pass-through certain traffic types, like encrypted or already optimized traffic.
Note: If you are optimizing SSL encrypted HTTP traffic make sure to remove port 443 from the Secure port label.
To edit or create a port label, choose Networking > App Definitions: Port Labels (Figure: Port Label Page).
Figure: Port Label Page
For more information about port labels, see the SteelHead Management Console User’s Guide.
Creating Domain Labels
A domain label is an augmentation for further refining an in-path rule by using the domain name field. For example, rather than specifying multiple IP addresses or FQDNs in the destination field, you can use *.ABC.com to intercept only destination hosts matching these criteria. A domain label field can also lessen the number of hosts to optimize, or exclude from optimization, in case the field does not match the domain label and the other source or destination fields.
Note: Riverbed recommends that you read the knowledge base article at https://supportkb.riverbed.com/support/index?page=content&id=S28159&actp=search before implementing domain labels.
Note: Domain labels are not supported on SteelHead SaaS.
The domain label field does not replace the destination IP address parameter. The in-path rule needs to match the destination IP address or host label field, and next match the domain label entry. If the connection matches the source and destination list, the client-side SteelHead begins to process subsequent data packets looking to match the domain in the host field if HTTP or the SNI field in HTTPS.
With a domain label you can selectively perform:
•  dual-ended optimization of individual services on an on-premises server running multiple applications.
•  web-proxy optimization of individual domain of HTTP/HTTPS web proxy traffic in single-ended deployment.
Use the following guidelines when creating a domain label:
•  Riverbed recommends that you configure a domain label as the last rule in the listing.
•  For optimized traffic, both the client-side and server-side SteelHeads must be running RiOS 9.2 or later.
•  Domain labels are not compatible with packet mode optimization.
•  Domain label names are alphanumeric.
•  Domain label names cannot be more than 64 characters long.
•  You can create a maximum of 63 domain labels.
•  The default destination ports are 80 and 443 unless manually specified in the in-path rule.
•  Domain labels are compatible with IPv4 only.
•  Place an in-path rule using a domain label and destination address set to All at the end of the rule list.
•  Domain labels are not supported on the source subnet field.
•  The web proxy feature is compatible with domain label rule lists. For more information about web proxy, see SteelCentral Controller for SteelHead Deployment Guide.
•  Domain labels allow you to specify an internet domain with wildcards to define a wider group, such as *.ABC.com.
•  By default, domain labels support only HTTP-based and HTTPS-based traffic (ports 80 and 443). For HTTP, the domain label feature looks at the Host field in the GET request to find a match with the configured domains. For HTTPS, the domain label looks at the SNI field of the Client Hello.
•  SteelHead SaaS optimization is bypassed in the presence of a rule defined with a domain label and destination set to All.
•  SteelHead SaaS optimization and domain labels in the same rule is not supported.
To edit or create a domain label, choose Networking > App Definitions: Domain Labels (Figure: Domain Label Page).
Figure: Domain Label Page
Note: Domain labels require both SteelHeads to be running RiOS 9.2 and later.