Link Search Menu Expand Document

AppExpress Summary Tab

Monitoring > Performance > AppExpress Summary

From this tab you can view and monitor information about the AppExpress groups you have configured. There are buttons on this tab that allow quick access to Application Definitions, AppExpress Groups Tab, and Apply AppExpress Groups Tab. For detailed information about this feature including how to configure it, see About AppExpress.

The following table describes the information displayed on the AppExpress Summary tab. You can filter the view by selecting a specific appliance in the appliance tree.

Column Description
Appliance The name of the appliance on which the flow originates.
Application The name of the application being monitored.
Group The name of the AppExpress group that the appliance is part of. The group determines the available transport paths for the application and the frequency that the Ping QoE and User QoE are updated.
Target QoE The quality of experience (QoE) target for the application. This target is what the system assesses the Ping QoE and User QoE against to determine the best path for each application.
User QoE An Apdex score that is based on actual user flows. When users start using an application that is monitored, the EdgeConnect begins measuring the user flows to that application. This is a real-time QoE measure and is the basis for all the AppExpress decisions to redirect flows from one transport to another, for the application.
Current Transport Path The transport path that the application is currently using. Current Transport Paths can include third-party IPSec tunnels, local breakout labels, and SD-WAN peers.
Application Performance trend The trend of how the traffic flow for this application has performed over time.
Status Indicates if the traffic flow for this application on this appliance is meeting the optimal targets set for this application. Possible statuses:

Initial – AppExpress is in provisioning and will soon enter the Learning state.

Learning – AppExpress is in startup and needs time to accumulate Ping QoE scores.

Ping Optimal – No User flows have been observed; however, AppExpress has found at least one Ping path that meets the Target QoE. When a user flow is observed, AppExpress will route the flow to the path shown in the Current Transport Path column.

Ping Suboptimal – No User flows have been observed and there are no paths whose Ping QoE meets the Target QoE. User flows will be routed to the path with the highest Ping QoE.

User Optimal – User flows have been observed and are meeting the Target QoE. New user flows will be routed to the path shown in the Current Transport Path column until the User QoE no longer meets the Target QoE.

User Suboptimal – User flows have been observed; however, they are not meeting the Target QoE over the Current Transport Path. At the next User QoE interval, AppExpress will try the next best transport path sorted by Ping QoE score.

Fallback – No user flows have been observed and pings to all paths are failing. AppExpress will revert to standard BIO handling for new flows.
Ping QoE An Apdex score that is based on synthetic polling. Failed connections count toward the F boundary. Synthetic polling consists of pings that go out from an EdgeConnect appliance through the loopback interface for the appliance across each path. From these pings, the system determines the Ping QoE for each flow.

About AppExpress

For most enterprises, a handful of high-profile, high-impact applications drive the business. AppExpress allows you to optimize the user experience for high-impact applications. With AppExpress you can monitor the traffic flow for up to 50 applications and leverage synthetic polling and real-time user traffic observations to intelligently steer traffic. AppExpress automatically selects the best path for each of the 50 applications. See Determining the Best Flow for an Application Path and Transport Types for more information on how AppExpress does this. AppExpress works for internal and cloud-based applications.

AppExpress sends synthetic probes across all available paths—local breakout, backhaul, and third-party service tunnels—to applications and it determines which path appears to have the best latency and is most robust. AppExpress then places flows for applications on the best paths based on criteria that are set for each application.

The following example shows how AppExpress works for a common application, Zoom, throughout a typical business day.

img

Prerequisites

Before you begin using the AppExpress feature you must:

  • Configure a loopback interface.

    • A loopback interface is required for AppExpress to function because it is the source of the synthetic probes that are sent to applications across backhaul and third-party tunnels. See Interface Labels and navigate to Configuration > Overlays & Security > Interface Labels in Orchestrator to create a LAN-side “LOOPBACK” label.

    • See Loopback Orchestration and navigate to Configuration > Networking > Loopback Orchestration in Orchestrator.

  • Enable AppExpress for each application that you want to monitor and steer.

    • See Application Definitions and navigate to Configuration > Templates & Policies > Applications & SaaS > Application Definitions in Orchestrator.

    • When enabling, select the Monitor and Steer option.

  • Create AppExpress groups and add AppExpress applications to the groups.

    • If AppExpress is enabled for an application, but it isn’t added to an AppExpress group then only monitoring of the application takes place. If you want AppExpress to also steer the application traffic, it must be part of an AppExpress group.

    • See AppExpress Groups Tab, and Apply AppExpress Groups Tab and navigate to Configuration > Templates & Policies > Applications & SaaS > AppExpress Groups in Orchestrator.

Determining the Best Path for an Application Flow

AppExpress uses three measures to determine the best path for an application flow.

Target QoE

This is a user’s target for an application, or how a user wants to experience an application. For example, if a goal is for users to have an excellent experience for Zoom calls, you would set the Target QoE to Excellent. For each application that is monitored through AppExpress, you must set a Target QoE (quality of experience) measure. The Target QoE is used to determine whether performance for a flow is optimal or not.

The Target QoE is calculated using Apdex. Apdex (Application Performance Index) is an open standard that defines a method to report, benchmark, and rate software application performance.

  • Apdex normalizes a large sample set of measurements into a score between 0 and 100.

  • The measurements are sorted into three bins:

    • Satisfied: Users are happy with their quality of experience.

    • Tolerable: Users aren’t happy but aren’t bothered enough to complain.

    • Frustrated: User experience is impacted; users are likely to complain.

  • The point at which the performance of an application moves from Satisfied to Tolerable is the T boundary threshold.

  • The point at which the performance of an application moves from Tolerable to Frustrated is the F boundary threshold.

  • For Target QoE, failed User flows and failed synthetic pings contribute to the Frustrated bin.

  • Apdex is calculated for flows once at the start of the flow.

  • See https://www.apdex.org for more information about Apdex.

img

In AppExpress, the T and F boundary thresholds are the two User Experience Thresholds that you set when you add a new application definition. To do this, navigate to Configuration > Templates & Policies > Applications & Saas > Application Definitions and click +Add New Application. For more information about application definitions and setting the QoE measures for an AppExpress application, see Application Definitions.

Ping QoE

The Ping QoE is an Apdex score that is derived from synthetic probes (ICMP echo-request/response, TCP connect, HTTP, or HTTPS) that are sent across all available paths. For each AppExpress application, the system compares the Ping QoE against the Target QoE, to determine which path best meets the Target QoE, and then the flows for that application are put on that path.

User QoE

When users begin using an application, the system gathers data based on the real-time flows for the application. The User QoE is an Apdex score that is derived from these observed user flows. The system compares the User QoE against the Target QoE, and if the real-time flows for an application are no longer meeting the Target QoE, the system begins hunting for a different path that can meet the Target QoE. This process is continuous while an application is in use.

NOTE: AppExpress uses LAN to WAN flows to calculate User QoE and to gather application performance data. TCP and UDP flows are analyzed for User QoE determination. ICMP and other IP types are not supported by AppExpress. Also, EdgeHA flows are ignored by AppExpress.

Transport Types

There are three transport types that are handled by AppExpress.

Local Breakout

All Primary labels are considered. For information on Primary labels, see the Break Out Locally Using These Interfaces, Available Interfaces, and Link Selection section in Business Intent Overlays.

Third Party Service Tunnels

This includes SSE integrations such as Zscaler or Netskope. Services created using Service Orchestration are also included. All primary tunnels are considered. This means that AppExpress tries both the primary and secondary POPs (point of presence) for Zscaler, Netskope, etc. See the configuration information for Zscaler and Netskope.

Backhaul via BIOs to Hubs

AppExpress selects the backhaul peer based on the lowest peer priority configured, and it does not consider route metric or administrative distance. When no peer priority is configured, no paths are searched. AppExpress does not support passthrough paths. Up to 6 backhaul peers are supported.


Back to top

© Copyright 2024 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein. Aruba Networks and the Aruba logo are registered trademarks of Aruba Networks, Inc. Third-party trademarks mentioned are the property of their respective owners. To view the end-user software agreement, go to Aruba EULA.

Open Source Code:

Hewlett Packard Enterprise Company
Attn: General Counsel
WW Corporate Headquarters
1701 E Mossy Oaks Rd Spring, TX 77389
United States of America