Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Application Quality of Experience on NFX Devices

 

Application Quality of Experience (AppQoE)

This topic includes following sections:

Introduction to AppQoE

The relentless growth of cloud computing, mobility, and Web-based applications, requires that the network identify and control the traffic at the application level, and handle each application type separately to provide quality of experience (QoE) for users. To ensure application-specific QoE (AppQoE), you need to effectively prioritize, segregate, and route application traffic without compromising performance or availability.

AppQoE utilizes (or employs) the capabilities of two application security services - application identification (AppID) and advanced policy-based routing (APBR). It uses AppID to identify specific applications in your network and advanced policy-based routing (APBR) to specify a path for certain traffic by associating SLA profiles to a routing instance on which the application traffic is sent as per APBR rules.

AppQoE monitors the performance of business- critical applications, and based on the score, selects the best possible link for that application traffic in order to meet performance requirements specified as in SLA (service-level agreement).

The presence of an SLA rule in the APBR configuration triggers the AppQoE functionality; If there are no SLA profiles available, the APBR functions without triggering AppQoE.

Benefits of AppQoE

  • Enables cost-effective QoE by providing real-time monitoring of application traffic to provide a consistent and predictable level of service.

  • Increases customer retention and satisfaction by providing a guaranteed SLA for the delivery of the certain traffic (such as video traffic). AppQoE ensures that the approved traffic receives the appropriate priority, and bandwidth required to ensure the best quality of experience to the user.

Supported Use Cases

AppQoE finds use in the following network scenarios, among others:

  • Networks with hub-and-spoke topology—In a hub-and-spoke configuration, the devices at the branch offices and remote offices connect directly to a specific device and do not form tunnels to other devices in the network. Communication between branch sites or remote offices is enabled through the configured VPN hubs.

  • Mesh networks—In a mesh configuration, a device at the branch office or remote site is configured to connect directly to any other device in the network that is also part of mesh.

Limitations

Implementation of AppQoE on Juniper devices has the following limitations:

  • All the different routes to the destination through different interfaces must have the same preference, weight, and metrics configured. All routes must be added as ECMP paths for the destination and must also be part of the same forwarding table.

  • AppQoE SLA service only between two devices endpoints (book-ended) are supported. End-to-end AppQoE SLA service is not supported.

  • AppQoE can be applied only if all interfaces are part of the same zone.

  • AppQoE cannot be applied for reverse traffic.

  • AppQoE does not influence in change in the destination for a session.

  • AppQoE does not support IPv6/UDP probe encapsulation, GRES, chassis cluster (ISSU, high-availability, dual CPE high availability, Z-mode high availability), and logical systems.

  • AppQoE is not supported in multihoming scenarios.

  • AppQoE does not support preferred path selection and transit virtual routing and forwarding (VRF) are not supported.

  • AppQoE does not support passive probing on IPv6 data packets.

  • An input firewall filter is required at the non-WAN interfaces to discard UDP packets with UDP destination port 36000.

Understanding AppQoE Terminology

This section includes some of the terminologies used in understanding about how AppQoE works.

  • SLA rule—An SLA rule includes all required information to measure SLA and to identify whether any SLA violation has occurred or not. It contains the complete probe profiles, period at which profile need to be sent, preferred SLA configuration and so on.

  • SLA options—By using SLA options, you can specify that applications be seamlessly diverted to the alternate path if the performance of the primary link is below acceptable levels as specified by the SLA.

  • SLA metrics profile — Defines the SLA metrics requirements parameters, which are used by AppQoE to evaluate the SLA of the link. The metric profile includes parameters such as jitter, jitter type, packet loss, round trip delay and so on.

  • SLA violations—To accomplish an SLA, AppQoE monitors the network for sources of failures or congestion. If the performance of a link is below acceptable levels as specified by the SLA, the situation is considered as an SLA violation and an alternate path is determined to select the best link that satisfies the SLA.

  • Active and passive probes—Active and passive probe measurements are used for an end-to-end analysis of the network. The data collected by active and passive probing is used for monitoring the network for sources of failures or congestion. If there is a violation detected for any application, the synthetic probe metrics are evaluated to determine the best link that satisfies the SLA.

  • Overlay path—an overlay path includes the overlay links that are used to send the application traffic. Application or application groups are assigned to a particular overlay link based on the SLA metrics of that overlay link.

  • Destination groups—A destination group is a group of multiple overlay paths terminating at a destination.

How AppQoE Works?

AppQoE utilizes AppID and APBR capabilities to identify specific applications/application groups and specify a path for certain traffic by associating SLA profiles to a routing instance on which the application traffic is sent as per APBR rules.

AppQoE monitors the performance of applications, and based on the score, selects the best possible link for that application traffic in order to meet performance requirements specified as in SLA (service-level agreement).

Identifying Applications or Application Groups

Following steps are involved in identifying applications or application groups:

  1. Junos OS application identification identifies applications and once an application is identified, its information is saved in the application system cache (ASC).

  2. APBR evaluates the packets based to determine if the session is candidate for application-based routing (advance policy-based routing). If this is first packet of the new session and traffic is not flagged for application-based routing, it undergoes normal processing (non-APBR route) to destination.

  3. If the session needs application-based routing, APBR queries the ASC module to get the application attributes (IP address, destination port, protocol type, and service).

    • If the application in ASC is found, traffic is further processed for a matching rule in the APBR profile.

      • If a matching rule is found, the traffic is redirected to the specified routing instance for the route lookup.

        • AppQoE checks whether an SLA is enabled for a session. If the session is a candidate for an SLA measurement, AppQoE initiates active and passive probes for performance measurements.

        • If SLA is not enabled for the session in the APBR rule, the AppQoE ignores that session and the default behavior of APBR is applied to those sessions—that is, traffic is routed through the specified routing instance for the destination.

      • If a matching rule is not found, traffic traverses through a default route (non-APBR route) to the destination.

    • If the application in is not found in ASC, APBR requests for deep inspection of the flow. that is, application signature package is installed and application identification for the session is enabled, so that ASC can be populated for use by subsequent sessions for APBR processing (see step 2).

Specifying Path for Applications or Application Groups

The following steps summarize how AppQoE specifies a path for the application traffic according to the SLA rules.

  1. APBR uses the application details to look for a matching rule in the APBR profile (application profile). Traffic matching the applications and application groups, are forwarded to the static route and the next-hop address as specified in the routing instance.

  2. An SLA rule attached to the APBR profile specifies parameters, that are required to measure the SLA and to identify whether any SLA violation has occurred or not.

  3. The applications traffic is assigned to a particular overlay link based on the SLA metrics of that overlay link measured using active probing.

  4. The SLA violation is determined through passive probing of live application/application group traffic. The best path/overlay link for the application/application group is determined through the path selection algorithm.

Application Traffic Path Selection

The following steps take place for routing data traffic from source to destination, specifically, to select the best path,

  • For the first data packet of a flow (first path), if the application is already known (from the ASC lookup), then the best path for the application is searched in the database. If the application is not known or is new (from ASC lookup), then a random path or the default path is chosen. This path continues for the entire session. Later, after the application is detected by the DPI, the database is updated with the best path for the application.

  • For the remaining data packet of a flow (fast path), if the application is not known initially, then the particular session continues on the same path. If the application is known initially, then AppQoE selects the best path for the application traffic.

When a new application is detected, the path selection mechanism attempts to find a path that satisfies all the SLA metrics. If no such path exists, then the next best path (based on number of metrics satisfied) is used. If there are more than one path that satisfies the metrics, a random path among the available paths is selected. The SLA violation is detected when any one of the metric is violated or none of the metrics meets the requirement, based on the profile configuration.

How AppQoE Measures Application Performance

Application performance is determined by the following indicators:

  • Latency—The amount of time physically required for media to travel depending on media length and distance that need to be covered

  • RTT— A round-trip time required to travel from source to destination and vice versa.

  • Packet loss—Packet loss reflects the number of packets lost per 100 of packets sent by a host.

  • Jitter—Jitter is the difference in the latency from packet to packet. Ingress jitter, egress jitter, and two-way jitter can be specified for evaluating the performance of the link.

AppQoE monitors RTT, jitter, and packet loss on each link, and based on the score, seamlessly diverts applications to the alternate path if performance of the primary link is below acceptable levels as specified by SLA. Measurement and monitoring of application performance is done using active and passive probes to detect SLA violations and to select an alternate path for that particular application.

AppQoE collects real-time data by continuously monitoring application traffic and identifying network or device issues by:

  • Monitoring the performance on all configured overlay links.

  • Using passive probes (inline with the application datapath) and active probes (synthetic probes for specific application) to monitor the traffic performance for application or application group.

  • Sending all collected performance metrics or metadata for analysis to a log collector.

  • Comparing specified application against a specific performance metric and changing the path for the application traffic dynamically in case of an SLA violation.

  • Supporting flexible SLA metric configuration for a given application or application group.

AppQoE measures the application SLA across multiple WAN links, and maps the application traffic to a path among the available links, that is, to the path that best serves the SLA requirement.

Application Performance Measurement by Using Active and Passive Probes

Active and passive probe measurements are the two approaches used for end-to-end analysis of the network.

  • Active probe—Active probes measure the service quality of the application to provide an end-to-end measurement of the network performance.

    In active probing, custom packets are sent between spoke and hub points on all the multiple routes and the RTT, latency, jitter, and packet-loss are measured between the installed probe points. The active probes are sent periodically on all the active and passive links. A configured number of samples is collected and a running average for each such application’s probe path is measured. If there is a violation detected for any application traffic, the probe metrics are evaluated to determine the best link that satisfies the SLA.

  • Passive probe—Passive probes are installed on links within the network, and they monitor all the traffic that flows through those links.

    Passive probing monitors links for SLA violations on live data traffic. In a passive probe, the actual data packets are encapsulated in an IP/UDP probe header in the live traffic between the device book-ended points, and RTT, jitter and packet loss between the points of installation of the probes are measured to compute the service quality.

    If there is a violation detected for any application, the synthetic probe metrics are evaluated to determine the best link that satisfies the SLA.

You can configure an SLA rule with active and passive probe parameters and associate the SLA rule with APBR profile. The APBR profile also includes a APBR rule. Rules are associated with one or more than one application or application groups and the traffic matching the rule is redirected to the routing instance

AppQoE triggers the probe requests to all probe paths of the application. Active and passive probes monitor the network for areas or points of failures or congestion.

AppQoE collects traffic class statistics for learned applications using active and passive probes and takes following actions:

  1. Measure performance for SLA—The real-time metrics provided by probes are used to score service quality according to the SLA for an application and determine whether the application path does not meet SLA requirements. That is, if there is a violation detected for any application, the synthetic probe metrics are evaluated to determine the best alternate link for the application traffic that satisfies the SLA.

  2. Reroute traffic—Switch the application traffic between the two links, that is, when one link has performance issues, the traffic is routed to the other link during the same session.

Note

If the application’s traffic can be reachable through multiple links, you must configure all the reachable paths as overlay paths and attach the overlay paths to application’s SLA rule.

Switching Application Traffic to An Alternate Path

You can enable or disable switching of the application traffic to another route (local to the device) during an SLA violation. When local route switching is enabled, switching of the application traffic to an alternate route is enabled and the SLA monitoring and reporting functionality is also available. Even when the option for switching of the application traffic to an alternate path is disabled in the SLA rule configuration, AppQoE resolves SLA violations---for example, by switching the application traffic to a new path

When local route switching is disabled, only SLA monitoring and reporting functionality is available and switching of the application traffic to the different route because of an SLA violation is tuned off.

When an application traffic switches to an alternative path, there will be a short time period during which the application traffic cannot be switched again to another path in case of SLA violation. This time period helps to avoid flapping of the traffic across links.

Example: Application Quality of Experience (AppQoE)

This example shows how to configure AppQoE to provide quality of experience (QoE) by enabling real- time monitoring of the application traffic according to the specified SLA..

This example provides step-by-step procedures required for Juniper devices to provide the quality-of-experience (QoE) service using AppQoE. In this configuration, devices in the network prioritize certain application traffic to enhance the user experience based on service-level agreement (SLA).

Requirements

  • Valid application identification feature license installed on a Juniper device.

  • Appropriate security policies to enforce rules for the transit traffic, in terms of what traffic can pass through the device, and the actions that need to take place on the traffic as it passes through the device.

  • Enable application tracking support enabled for the zone. See Application Tracking.

  • Supported NFX device with Junos OS Release 18.2R1 or later. This configuration example is tested for Junos OS Release 15.1X49-D130 on an SRX Series device.

Overview

AppQoE monitors the performance of business-critical applications, and based on the score, selects the best possible link for that application traffic in order to meet performance requirements that are specified as in the SLA. To achieve this goal, AppQoE creates application-specific SLA rules and associates the SLA rules to an APBR profile and to a routing instance on which the application traffic will be sent.

AppQoE measures the application performance across multiple links by collecting real-time data by continuously monitoring application traffic and identifying any network or device issues by active and passive probing. Measured application data is used to determine whether the application path meets SLA requirements and whether an alternate path can be used to reroute the traffic to meet the SLA requirements.

Figure 1 shows the topology used in this configuration example.

Figure 1: Topology for AppQoE Configuration
Topology
for AppQoE Configuration

Table 1 provides the details of the parameters used in this example.

Table 1: AppQoE Configuration Parameters

Parameter

Name

Description

APBR profile

apbr1

Name of the APBR profile. This profile matches applications and application groups and redirects the matching traffic to the specified routing instance for route lookup. The profile includes multiple rules.

APBR rule

rule-app1

rule-app2

rule-app2

Define the rules for the APBR profile. Associate the rule with one or more than one application (example: for HTTP, FTP, and SSH) or application groups.

Routing Instance

appqoe-vrf

Instance type as routing and forwarding (VRF) instance

RIB group

lanvrf

Name of the routing information base (RIB) (also known as routing table) group.

Define AppQoE as service

system-services=appqoe

Enable AppQoE as an individual service to allow host-inbound custom probe traffic that can reach the device for all the interfaces in a zone.

SLA rule

  • sla1

  • sla2

Individual applications and application group must have an SLA rule attached. The SLA rule includes all required information to measure the SLA and to identify whether any SLA violation has occurred or not. It contains the complete probe profiles, time period at which profile need to be sent, preferred SLA configuration and so on.

An SLA rule is associated with an APBR rule, which is matched to the application or application group.

SLA options

local-route-switch = enabled

Specify local route switch option. This option enables switching of application traffic to an alternate path if an SLA violation occurs.

SLA metrics profile

  • metric1

  • metric 2

Defines the performance metrics for delay round trip, one-way jitter or two-way jitter, and packet loss. AppQoE uses metrics profile to evaluate the SLA of the link.

Active probes

  • probe1

  • probe2

An active probe parameter configures the probe data information such as probe’s data size, intervals between individual probes, and so on.

Active probe will be initiated from the spoke device to the hub device on each of the overlay path.

Overlay path

overlay-path1

Tunnel

  • Local IP addresses- 1.1.1.1

  • Remote IP addresses- 2.1.1.1

Probe

  • Local IP addresses- 125.1.1.1

  • Remote IP addresses- 125.1.1.10

Configuring an overlay path allows you to specify the destinations to which the active probe data needs to be sent. Overlay paths are configured for all overlay endpoints. Overlay path configuration includes two set of IP addresses:

  • Tunnel IP addresses–In this example, T1, T2, T3 are used as tunnels. Tunnel’s start and end IP addresses must be mentioned. Tunnel IP addresses must be unique across individual overlay paths. end points

  • Probe IP addresses—Probe IP addresses are used as probes’ start and end addresses to send over the corresponding tunnel paths. Probe IP addresses must be unique across individual overlay paths.

path2

Tunnel

  • Local IP addresses- 100.0.0.1

  • Remote IP addresses- 150.1.1.1

Probe

  • Local IP addresses- 25.1.1.1

  • Remote IP addresses- 25.1.1.10

path3

Tunnel

  • Local IP addresses- 200.1.1.1

  • Remote IP addresses- 250.1.1.1

Probe

  • Local IP addresses- 225.1.1.1

  • Remote IP addresses-

Destination Grouping

destination-path-group-1

You can group all the overlay paths terminating at the same destination under a destination group. In this example, you have a single destination—that is, hub device. So, all paths are configured under the same destination group and all the paths must be available in the routing instance specific for active probing.

Before you begin:

  • When a traffic is identified for AppQoE, that traffic could be fragmented when the packet size exceeds the supported MTU value with the additional encapsulation of the probe header.

    To manage the fragmentation, we recommend you to configure the maximum segment size for TCP sessions for SRX Series devices using the following commands:

  • The passive probe packet carries actual source and destination IP address of the client packets. To allow the passive probe packets through the system, you must complete the following configuration:

    • Configure address-based custom applications signatures for UDP (port 36000). This configuration helps in identifying the application by AppID.

    • You must create an appropriate security policy and application firewall policy to support the above configuration.

Note

Passive probes generate application tracking log messages for session create and session delete. Once the custom signature identifies these packets, the message reports application as jun-appqoe.

Configuring AppQoE

Configure Advanced Policy-Based Routing (APBR)

Step-by-Step Procedure

Configure APBR profiles for HTTP, FTP, and SSH applications traffic.

  1. Create routing instances.
  2. Group one or more routing tables to form a RIB group and import routes into the routing tables.
  3. Create the APBR profile and define the rules.
  4. Configure AppQoE as system service.
  5. Apply the APBR profile to the security zone.

Configuring Metrics Profile

Step-by-Step Procedure

  1. Create the set of metrics which AppQoE uses to evaluate the SLA of the link.

Configure Active Probe Parameters

Step-by-Step Procedure

Configure active probing to send custom packets between spoke device and hub device on all routes to measure RTT, jitter, and packet loss between the points.

  1. Configure active probe parameter (probe1).
  2. Configuring active probe parameter (probe2).

Configuring Overlay and Probe Paths

Step-by-Step Procedure

Configure an overlay setup, which includes setting up both tunnel path and probe path, between local and remote endpoint on both ends of the overlay (spoke device and hub devices).

  1. Create overlay paths for the tunnel and probe (overlay-path1).
  2. Create overlay paths for the tunnel and probe (overlay-path2).
  3. Create overlay paths for the tunnel and probe (overlay-path3).
  4. Group all the overlay paths terminating at a destination. Because there is a single destination available—that is, the hub device— all paths must be configured under the same destination group. All paths must be available in the routing instance specific for active probing.

Configure SLA Rule

Step-by-Step Procedure

Configure an SLA rule to measure the SLA and to identify any SLA violation has occurred or not.

  1. Configure the SLA rule, associate metrics profile, active probe parameter, and define passive probe parameters.
  2. Define switch idle time for the SLA rule.
  3. Associate active probe parameter (probe1) to the SLA rule.
  4. Define passive probe parameters.

Configure SLA Rule Setting with APBR

Step-by-Step Procedure

Associate an SLA rule to with the APBR profile.

  1. Enable local route switching. This option enables switching of application traffic to an alternate path if an SLA violation occurs.
  2. Configure SLA rule setting with APBR.

Configure AppQoE on Device Acting as Hub

Step-by-Step Procedure

  1. Configure AppQoE as service. You must configure AppQoE as service for host inbound traffic for a desired zone.
  2. Configure the percentage of sessions selected for book-ended measurement (passive probing).

Results

From configuration mode, confirm your configuration by entering the show commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

Verify AppQoE Configuration

Verifying SLA Profile

Purpose

Display the SLA version.

Action

From operational mode, enter the show security advance-policy-based-routing sla version command.

user@host>show security advance-policy-based-routing sla version

Meaning

The command output displays the version of AppQoE. This information helps verify that the SLA version on both hub device and spoke device is same.

Verifying SLA Profile Status

Purpose

Verify that the SLA is enabled on your device.

Action

From operational mode, enter the show security advance-policy-based-routing sla status command.

user@host>show security advance-policy-based-routing sla status

Meaning

The command output confirms that local switching is enabled. That is, switching of the application traffic to another route (local to the device) during an SLA violations, is enabled.

When local route switching is enabled, switching of application traffic to other route is enabled and also SLA monitoring and reporting functionality is available. This configuration selects the best possible link for that application traffic in order to meet performance requirements as in the SLA.

Displaying SLA Statistics

Purpose

Display the details of the SLA statistics based on APBR profile.

Action

From operational mode, enter the show security advance-policy-based-routing sla statistics command.

user@host>show security advance-policy-based-routing sla statistics

Meaning

The command output displays the session details subjected to passive probe and active probe.

Display SLA Statistics for An Application

Purpose

Display the details of the application traffic.

Action

From operational mode, enter the show security advance-policy-based-routing sla command.

user@host> show security advance-policy-based-routing sla profile apbr-1 destination-group-name d1 status apbr1 application junos:HTTP
user@host> show security advance-policy-based-routing sla profile apbr-1 application junos:HTTP destination-group-name d1

Meaning

The command output samples help in understanding application details, APBR profile, SLA rule, application status, SLA violations occurred, number of times application traffic has switched route path, and monitored sessions.

Display Active Probe Statistics

Purpose

Display active probe statistics.

Action

From operational mode, enter the show security advance-policy-based-routing sla active-probe-statistics active-probe-params-name command.

user@host> show security advance-policy-based-routing sla active-probe-statistics active-probe-params-name probe1

Meaning

The output shows RTT, jitter and packet-loss measured between the installed probe points.