Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Application Quality of Experience

Application Quality of Experience (AppQoE)

This topic includes following sections:

Introduction to Application Quality of Experience

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.

Supported SRX Series Devices

AppQoE is supported on vSRX instances, SRX300 line of devices, SRX550M, SRX1500, SRX4100, SRX4200, and SRX4600 devices.

You can configure an AppQoE SLA service between two SRX Series device endpoints (book-ended) and both SRX Series devices must have the same version of the Junos OS image.

You can configure vSRX instances, SRX300 line devices, SRX550M as spoke devices and SRX1500, SRX4100 and SRX4200 as hub devices.

Starting in Junos OS Release 15.1X49-D160 and in Junos OS 19.1R1, AppQoE is supported on SRX4100 and SRX4200 device when the device is operating in chassis cluster mode. You can configure the device to operate both in active/active and in active/passive modes and deploy the device as spoke device in SD-WAN deployments.

Note:

When the device is operating in chassis cluster mode, if the secondary node (node 1), through which traffic is forwarded, is rebooted, multiple switching of the application traffic between the links across secondary node links occurs. This happens when the available links on primary node(node 0) are having less active probe SLA path score compared to the secondary node links. This behavior continues until AppQoE active probe SLA path score results are available to indicate that there is 100% packet loss on all the links on secondary node.

Benefits of Application Quality of Experience

  • 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 security devices at the branch offices and remote offices connect directly to a specific SRX 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 security device at the branch office or remote site is configured to connect directly to any other security device in the network that is also part of mesh.

Limitations

Implementation of AppQoE on security 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 security 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 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.

  • The SRX4600 device has the following limitations:

    • The class of service (CoS) for generic routing encapsulation (GRE) is not supported when AppQoE is configured.

    • Passive probe details might not be available for the each short-lived session.

    • Synchronization of the session states might not happen on secondary node in Z-line mode traffic processing when device is operating in chassis cluster mode.

Understanding Application Quality of Experience 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 Application Quality of Experience 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 Application Quality of Experience 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 SRX Series 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.

    Note:

    Starting in Junos OS Release 18.3R1 and in Junos OS Release 15.1X49-D150, on all supported SRX Series devices and vSRX instances, in order to detect if a link or path is down by passive probes, a minimum of three probe requests and 100% packet loss must occur in a sampling period for a given session to trigger SLA violation.

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 security 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

  • Supported SRX Series device with Junos OS Release 18.2 and Junos OS Release 15.1X49-D150 or later. This configuration example is tested for Junos OS Release 18.2.

  • Valid application identification feature license installed on an SRX Series 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.

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 ConfigurationTopology 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.2

  • Remote IP addresses- 1.1.1.1

Probe

  • Local IP addresses- 1.1.1.2

  • Remote IP addresses- 1.1.1.1

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- 2.1.1.2

  • Remote IP addresses-2.1.1.1

Probe

  • Local IP addresses- 2.1.1.2

  • Remote IP addresses- 2.1.1.1

path3

Tunnel

  • Local IP addresses- 3.1.1.2

  • Remote IP addresses- 3.1.1.1

Probe

  • Local IP addresses- 3.1.1.2

  • Remote IP addresses- 3.1.1.1

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 security 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. See also destination-path-group.

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.

    Note:

    Starting in Junos OS Release 19.2 onwards, you can configure the violation-count and the sla-export-factor parameters in [edit security advance-policy-based-routing sla-rule rule-name] hierarchy.

    You can configure the violation-count for both active probe parameters and passive probe parameters. The violation-count option configured in [edit security advance-policy-based-routing sla-rule rule-name passive-probe-params] hierarchy is overridden by [edit security advance-policy-based-routing sla-rule rule-name violation-count] option. The violation count configured for passive probe parameter will be ignored and violation count default value is used. A warning message is also displayed when you attempt to commit the configuration.

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.

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.

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.

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.

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.

Meaning

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

Understanding AppQoE Configuration Limits

Starting in Junos OS Release 15.1X49-D160 and in Junos OS Release 19.1R1, AppQoE enforces the configuration limit for overlay paths, metric profiles, probe parameters, and SLA rules per profile when you configure application-specific SLA rules and associates the SLA rules to an APBR profile.

If you configure the parameters more than the allowed limit, error messages are displayed when you commit the configuration.

Examples of error messages:

Note:

The following sample error messages are from the SRX4100 and SRX4200 device. The value of the configuration limit might not reflect exact number supported; the numbers might differ between the supported devices.

Example: Configuring Link Preference and Priority for AppQoE

This example shows how to configure AppQoE to select the link based on the link priority and the link type when multiple links that meet the SLA requirements are available.

Requirements

  • Supported SRX Series device with Junos OS Release 18.4 and Junos OS Release 15.1X49-D160 or later. This configuration example is tested for Junos OS Release 18.4.

  • Valid application identification feature license installed on an SRX Series 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.

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

Overview

Before you begin:

You configure AppQoE to select the link based on the link priority and the link type. You can configure the link type either as IP or MPLS and set the priority for the underlay links. You can also configure the link-type affinity as strict for the preferred link type.

You can define the link type and priority for the underlay links in the SLA rule. The SLA rule is assigned to an APBR profile. Because the APBR rule is defined for an application or a group of applications, you can enforce the link preference at the application or application group level. The link preference configuration is applied for the application traffic matching the APBR rule.

Figure 2 shows the topology used in this example.

Figure 2: Topology for Configuring Link Type and Link Priority for Application PathTopology for Configuring Link Type and Link Priority for Application Path

Table 3 and Table 4 provide the details of the parameters used in this example.

Table 3: 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

rule1

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

SLA rule

sla1

Individual applications and application group must have an SLA rule attached.

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

Link-type affinity

Strict

For strict affinity, AppQoE ensures that the path selected is always of the preferred link type.

Table 4: Link Preference Parameters for Underlay Interfaces

SLA Rule

Underlay Interfaces

Link Type

Priority

sla1

ge-0/0/1

MPLS

1

ge-0/0/2

MPLS

2

ge-0/0/3

IP

3

In this example, you configure the link ge-0/0/1 with link type as MPLS and priority as 1, ge-0/0/2 with link type as MPLS with priority 2, and ge-0/0/3 with link type as IP with priority 3. All the links have same the SLA score as defined in the SLA rule (sla1). For the SLA rule (sla1), configure the link type preference as MPLS.

The following examples show how the path selection mechanism selects the link based on preferred link and the link-type affinity. The topology used in this example is shown in Figure 3 and the configured link type and link-type affinity is shown inTable 5 .

Figure 3: Path Section Mechanism ExamplePath Section Mechanism Example
Table 5: Link Type and Priority Details

Links

Link Type

Priority

ge-0/0/1

MPLS

1

ge-0/0/2

MPLS

2

ge-0/0/3

IP

3

  • Case 1: When preferred link type is configured as MPLS and link-type affinity is configured as loose (default option), the path selection mechanism details are provided in Table 6.

    Table 6: Case 1: Preferred Link Type is MPLS and Link-Type Affinity is Default (Loose)

    Link Selected For Traffic

    Change in Situation

    Which Links are Eligible

    Traffic Switched To

    Explanation

    ge-0/0/1

    An SLA violation is reported in ge-0/0/1

    ge-0/0/2 and ge-0/0/3

    ge-0/0/2

    Link ge-0/0/2 is selected because it has higher priority.

    ge-0/0/2

    An SLA violation is reported in ge-0/0/2

    ge-0/0/3

    ge-0/0/3

    Link ge-0/0/3 is selected because it is only remaining eligible link meeting SLA requirements.

    ge-0/0/3

    SLA violation is cleared in ge-0/0/1

    ge-0/0/3 and ge-0/0/1

    ge-0/0/1

    Traffic is switched back to preferred link ge-0/0/1 (MPLS) from the link ge-0/0/3 (IP).

  • Case 2: When the preferred link type is MPLS and link-type affinity configured as strict, the path selection mechanism details are provided in Table 7.

    Table 7: Case 2: Preferred Link Type is MPLS and Link-Type Affinity is Strict

    Link Selected For Traffic

    Change in Situation

    Which Links are Eligible

    Traffic Switched To

    Explanation

    ge-0/0/1

    An SLA violation is reported in ge-0/0/1

    ge-0/0/2 and ge-0/0/3

    ge-0/0/2

    Link ge-0/0/2 is selected because it is matching the link type preference MPLS.

    ge-0/0/2

    An SLA violation is reported in ge-0/0/2

    ge-0/0/3

    ge-0/0/2

    Link ge-0/0/2 remains as the selected path. Because of the strict affinity, ge-0/0/3 (which has link type configured as IP) is not selected.

    Note:

    When there are multiple interfaces meeting the SLA requirements are available, the path is selected based on link-type preference , and then link priority. If all links have the same link-type preference and priority, then a random selection of the link is done.

Configuration

Configure Link Preference and Priority

Step-by-Step Procedure

Configure AppQoE to select the link based on the link priority and the link type:

  1. Create an APBR profile with three rules matching application HTTP and SSH with link type and preference for interfaces.

    Prior to Junos OS Release 21.2R1, create an APBR profile with three rules matching application HTTP and SSH with link type and preference for underlay interfaces.

  2. Configure the SLA rule (sla1) with preferred link tag as ISP1 and affinity as strict.

    Prior to Junos OS Release 21.2R1, configure the SLA rule (sla1) with preferred link type as MPLS and link-type affinity as strict.

  3. Associate an SLA rule with the APBR profile.

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.

Prior to Junos OS Release 21.2R1:

Verify AppQoE Configuration

Displaying SLA Statistics

Purpose

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

Action

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

Meaning

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

Understanding System log Messages for AppQoE

Starting in Junos OS Release 19.2R1, the support for the application-level logging is available for AppQoE on SRX Series devices. This feature is introduced to reduce the impact on CSO or log collector device while processing large number of system log messages generated at the session-level. The security device maintains session-level information and provides system log messages for the session level. With application-level logging replacing session-level logging, the overhead on security device decreases and AppQoE log throughput increases.

AppQoE sends following system log messages:

  • APPQOE_SLA_METRIC_VIOLATION: When a violation is detected for a session and when a session’s path is resolved as a result of moving to a new link.

  • APPQOE_BEST_PATH_SELECTED: When a session switches the path for its data traffic.

With application-level logging, all session-level logs are supported at the application-level. The AppQoE functionality of sending real-time probes, measuring the SLA metrics, violation detection, and path-switch continues at the session-level. However, as part of application-level summarization feature, datapath sessions notify the SLA metrics, violation information, and path switch to AppQoE database. The information thus received from datapath is aggregated at the application-level, and then sent in the form of system logs to collector device.

Table 8 provides details of new application-level logs are supported from Junos OS Release 19.2R1 onwards.

Table 8: Application-Level Log Messages

system log Message

Description

APPQOE_APP_SLA_METRIC_VIOLATION

  • This system log message is generated the first time the application is in violation.

  • The SLA metrics are measured for each application session in the data path. The SLA violation metrics continue to be measured at the session-level only. However, the metrics or data pertaining to the SLA violation are sent to the AppQoE database by all data sessions of that application when their SLA is violated.

  • In the case of dual CPE, the node which is active for the application generates the APPQOE_APP_SLA_METRIC_VIOLATION report.

APPQOE_APP_BEST_PATH_SELECTED

  • This system log message is generated when an application goes through a path switch. This log report is also generated to clear the violation happened because of self heal (when the SLA violation is cleared by itself before any change in the link)

  • For application-level logging, Once an application or a link switches to an alternate path, AppQoE sends the log message APPQOE_APP_BEST_PATH_SELECTED to the collector device.

APPQOE_APP_PASSIVE_SLA_METRIC_REPORT

  • This system log message is generated for passive probe SLA metrics data. This message is generated once the number of samples collected meet with the SLA export factor.

  • With the support of application-level logging, each probe candidate session sends information to AppQoE where the metrics are aggregated and averaged out before it is sent to the collector. Therefore the passive SLA report thus aggregated at the application level includes the averaged data from all of those application data sessions.

Application-level logging introduces the following AppQoE functionality changes:

  • Active probe maintains and uses only real-time RTT and jitter values. For packet loss, it refers the previous session’s cause because packet loss can be calculated only at the end of the window.

  • During configuration commit, active probe sets RTT and jitter values to highest 32-bit value for all entries.

  • Active probe retains previous session’s values until the a proper real-time value of the metrics are available.

  • When a 100% packet loss is experienced in active probing, all other metrics are set to highest 32-bit value.

Reporting of Invalid Values for RTT and Jitter

When the data for RTT and Jitter is not available, log messages sent with an invalid value of 0xFFFFFFFF and it can be ignored by the log collector. Table 9 provides some possible scenarios when the invalid RTT and Jitter is sent.

Table 9: Application-Level Log Messages Affected by Invalid Data for RTT and Jitter

Scenario

Affected System Logs

100% packet loss:

APPQOE_APP_PASSIVE_SLA_METRIC_REPORT

APPQOE_APP_SLA_METRIC_VIOLATION

Packet-loss greater than 0 and less than 100%:

APPQOE_APP_PASSIVE_SLA_METRIC_REPORT

APPQOE_APP_SLA_METRIC_VIOLATION

No Packet-loss

APPQOE_APP_SLA_METRIC_VIOLATION

APPQOE_APP_PASSIVE_SLA_METRIC_REPORT

Disable AppQoE Logging

By default AppQoE log-type is set as system log. If you want to disable AppQoE, then configure the log-type as disabled in the following configuration:

  1. Disable AppQoE logging
  2. Enable AppQoE logging

Configure SLA Export Factor

You can configure the SLA export factor to report probe metrics at the application level.

Configure SLA export factor at SLA rule level.

Example:

When you configure the sla-export-factor as 5, passive probe results are exported once at the end of the 5th, 10th, and 15th probe interval. You can use a passive probe report to report any data that remains unreported in the probe interval at the end of a session.

With application level summarization, each probe candidate session must send data to central location where the metrics are aggregated. The data thus aggregated is sent out once the configured SLA export factor is met.

Configure Violation Count

You can configure the violation count to report probe metrics at the application level. Violation count indicates the number of violations that must occur in a sampling-period for a given session before a link is marked as having violated the SLA.

Configure violation count at SLA rule level.

Example:

In this example, when you configure the violation count as 5, then the link is marked as violated SLA after 5 consecutive times the violation has occurred.

Application Quality of Experience (AppQoE) Based on the DSCP Bits of Incoming Traffic

AppQoE depends on application identification to associate an SLA with the incoming traffic. AppQoE utilizes APBR to select the best possible link for the application traffic in order to meet performance requirements specified as in SLA.

Application identification techniques rely on deep packet inspection (DPI). There are some cases where DPI engine might not be able to identify the application, for example—encrypted traffic. As a result, AppQoE might not be able to identify the application and associate any SLA to the incoming traffic. Because of this, you might not be able to provide quality of experience (QoE) for the traffic.

To overcome this scenario, Starting in Junos OS Release 19.4R1, AppQoE supports SLA-based path selection for the incoming traffic on the basis of DSCP value.

Starting from Junos OS Release 19.3R1, SRX Series devices introduced APBR functionality on the DSCP-tagged traffic. You can configure an APBR rule with dynamic-application or application group, DSCP value or combination of both dynamic-application and DSCP value. Using this enhancement, AppQoE selects the best possible link for the application traffic based on the application signature or DSCP value or combination of both application identification and DSCP value.

DSCP Support in APBR

In a APBR rule, you can configure a DSCP value or dynamic applications or combination of both.

When you configure both DSCP and dynamic application in a APBR rule, the rule is considered as match if the traffic matches all the criteria specified in the rule. When there are multiple DSCP values present in the APBR rule, then if any one criteria matches, it is considered as match.

A APBR profile can contain multiple rules, each rule with a variety of match conditions.

In case of multiple APBR rules in a APBR profile, the rule lookup uses the following priority order:

  1. Rule with DSCP + dynamic application

  2. Rule with dynamic application

  3. Rule with DSCP value

To understand how the APBR performs rule lookup and applies the rules, see Using DSCP as Match Criteria in APBR Rules.

AppQoE Functionality for the Traffic based on the DSCP Value

Network Service Orchestrator can map application to DSCP value at external service function and the same is provisioned at the gateway router to map the DSCP to desired SLA profile.

Figure 4 shows a scenario where AppQoE performs SLA-based path selection for the incoming traffic on the basis of DSCP value and application signature in a gateway router use case.

Figure 4: Path Selection for the Traffic Based on DSCP Value and ApplicationPath Selection for the Traffic Based on DSCP Value and Application

For the traffic based on the DSCP value, AppQoE works as follows:

  • All the traffic entering the gateway router from LAN undergoes application identification. Until DPI identifies an application, the system forwards the traffic stream to a default forwarding virtual routing and forwarding (VRF) instance. VRF includes an outgoing interface associated to it.

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

  • The system continues to check if any application information available either from DPI classification or ASC.

  • The APBR mechanism classifies sessions based on well-known applications signatures and DSCP values and uses policy to identify the best possible route for the application. The APBR policy maps application traffic to a specific VRF.

  • The presence of an SLA rule in the APBR configuration triggers the AppQoE functionality; AppQoE performs SLA-based path selection for the traffic based on the application or DSCP value.

For more information on configuring APBR with DSCP as match criteria, see Advanced Policy-Based Routing.

DSCP-Based SLA Rule and Passive Probes

A single DSCP includes multiple application categories bundled into it. Different application categories have their individual traffic pattern. In such a scenario, detection of violation using passive probes and applying it to all the sessions might cause false negative and false positive. As a workaround, avoid using passive probing when you have configured DSCP-based SLA rule. You can use active probes for the destination path group to which the traffic is forwarded.

Limitations

AppQoE deployments with DSCP-based rules on the device is chassis cluster mode have the following limitations:

  • If the rule match is completed before the application identification is done, and AppQoE moves the session to the other node, then application identification does not complete. This condition occurs when the DSCP-based rule is configured.

  • If you have configured two APBR rules—1) with DSCP value 2) with both DSCP and dynamic application, and assigned a same DSCP value in both the rules, on receiving the first packet, APBR matches with the DSCP rule. In case the best path is identified on the other node, then the session is moved to the other node. In this scenario, the application sessions are matched against the DSCP rule and not with the APP+DSCP rule.

AppQoE Support for Granular APBR Rules

Starting in Junos OS Release 20.1R1, AppQoE utilizes the granular rule matching functionality provided by APBR to provide the quality of experience (QoE) based on the application traffic.

AppQoE utilizes AppID and APBR capabilities to identify specific applications and application groups and specifies a path for certain traffic by associating SLA (service-level agreement) profiles to a routing instance on which the application traffic is sent as per APBR rules.

In Junos OS Release 18.2R1, APBR supported configuring policies by defining source addresses, destination addresses, and applications as match conditions. After a successful match, the configured APBR profile is applied as an application services for the session. In Junos OS Release 20.1R1, AppQoE leverages the APBR enhancement and selects the best possible link for the application traffic as sent by APBR to meet performance requirements specified in SLA.

Lets understand the new enhancement with a workflow and a sample configuration.

Workflow for AppQoE

You can define APBR policies for a security zone. APBR uses the following sequences to match the traffic by a policy and apply rule to forward the traffic:

  1. APBR policy rules match the traffic at the ingress zone. The policy match conditions include the source address, destination address, source identity (optional), and application.

  2. APBR policy action specifies the APBR profile for the matching traffic.

  3. The APBR profile configuration incudes the set of rules that contains set of dynamic applications, or dynamic applications group or DSCP value as match condition. The action part of the rules defines:

    • The routing instance to forward the traffic and then transit traffic to a specific device or interface.

    • SLA rule to trigger AppQoE functionality.

  4. AppQoE initiates active and passive probes for performance measurements.

  5. AppQoE specifies a path for the application traffic according to the SLA rules.

Sample Configuration

In this example, you want to forward Telnet and HTTPS traffic arriving at the trust zone to a specific device or interface through a best available link. When traffic arrives at the trust zone, APBR matches the traffic with matching criteria source address, destination address and applications defined in policies POLICY-1 and POLICY-2. If traffic matches the policy, corresponding APBR profiles PROFILE-1 or PROFILE-2 are applied.

APBR uses the application details to look for a matching rule in the profile. If a matching rule is found, the traffic is redirected to the specified routing instance as defined in the rule.

AppQoE checks whether an SLA is enabled for this session. If the session is a candidate for an SLA measurement, AppQoE initiates active and passive probes for performance measurements. AppQoE measures the application SLA across multiple WAN links, and maps the application traffic to a path among the available links.

The output sample is truncated to display configuration details for APBR policy and APBR profile. For more information, see following topics:

AppQoE Multi-homing with Active-Active Deployment

Starting In Junos OS Release 20.2R1, AppQoE is enhanced to support multi-homing with active-active deployment. Previously, AppQoE supported multihoming with active-standby deployment.

In active-active deployment, the spoke device connects to multiple hub devices. Application traffic can transit through any of the hub devices if the link to the hub device meets SLA requirements. Application traffic can seamlessly switch between the hub devices in case of SLA violation or the active hub device is not responding

Figure 1 shows a mesh topology. In this topology, an end point is reachable through more than one node.

Figure 5: A Sample Mesh TopologyA Sample Mesh Topology

To enable multihoming in active-active mode, you must configure the BGP multipath to allow the device to select multiple equal-cost BGP paths to reach a given destination.

When you enable BGP multipath, the device selects multiple equal-cost BGP paths to reach a given destination, and all these paths are installed in the forwarding table. AppQoE completes the route lookup and gets the next-hop route details along with the corresponding overlay-links. AppQoE obtains the overlay-link property from the configured destination path group.

Based on the application’s SLA requirements and link preferences, AppQoE determines the best link among all the links in that destination-path-group. In case of SLA violation, based on the SLA score and link preferences, AppQoE selects alternate links across all the configured destination-path-group if the end-point is reachable through those links.

For more information on BGP multipath configuration, see Examples: Configuring BGP Multipath.

Limitation

In certain scenario when next-hop ID for the route changes, the existing sessions remain on the SLA-violated link even though another link that meets SLA requirements is available. However, the new sessions are not impacted in this case and they are routed through the links that meet SLA requirements.

Support for SaaS Applications

Starting in Junos OS Release 20.4R1, we’ve extended application quality of experience (AppQoE) support for Software as a Service (SaaS) applications.

AppQoE performs service-level agreement (SLA) measurements across the available WAN links such as underlay, GRE, IPsec or MPLS over GRE. It then sends SaaS application data over the most SLA-compliant link to provide a consistent service.

To configure AppQoE for SaaS applications:

  1. Define the SLA rule type as SaaS (set security advance-policy-based-routing sla-rule sla1 type saas ).

  2. Include SaaS server details in the address book (set security address-book global address address-book dns-name saas-server-url ipv4-only).

  3. Attach the SLA rule to the policy-based APBR profile.

Support for IPv6 Traffic

  • Starting in Junos OS Release 21.3R1, you can use IPv6 addresses in AppQoE configurations. The support includes:

    • IPv6 address in overlay path configuration
    • Active probing sessions using IPv6 addresses as source and destination address.
    • IPv4 and IPv6 traffic from the client side
    • Dual stacking of IPv4 and IPv6 on the LAN side
    • IPv6 address on the LAN side for SaaS (software as a service) probing.

      For SaaS probing, ensure that you configure both IPv4 and IPv6 addresses for the incoming interface for IPv4 and IPv6 interoperability.

Release History Table
Release
Description
19.4R1
Starting in Junos OS Release 19.4R1, AppQoE supports SLA-based path selection for the incoming traffic on the basis of DSCP value
19.2R1
Starting in Junos OS Release 19.2R1, the support for the application-level logging is available for AppQoE on SRX Series devices.
19.1R1
Starting in Junos OS Release 15.1X49-D160 and in Junos OS 19.1R1, AppQoE is supported on SRX4100 and SRX4200 device when the device is operating in chassis cluster mode
19.1R1
Starting in Junos OS Release 15.1X49-D160 and in Junos OS Release 19.1R1, AppQoE enforces the configuration limit for overlay paths, metric profiles, probe parameters, and SLA rules per profile when you configure application-specific SLA rules and associates the SLA rules to an APBR profile.