Information About Application-Aware Routing
Application-aware routing tracks network and path characteristics of the data plane tunnels between Cisco IOS XE Catalyst SD-WAN devices and uses the collected information to compute optimal paths for data traffic. These characteristics include packet loss, latency, and jitter. The ability to consider factors in path selection other than those used by standard routing protocols—such as route prefixes, metrics, link-state information, and route removal on the Cisco IOS XE Catalyst SD-WAN device—offers a number of advantages to an enterprise:
-
In normal network operation, the path taken by application data traffic through the network can be optimized, by directing it to WAN links that support the required levels of packet loss, latency, and jitter defined in an application’s SLA.
-
In the face of network brownouts or soft failures, performance degradation can be minimized. The tracking of network and path conditions by application-aware routing in real time can quickly reveal performance issues, and it automatically activates strategies that redirect data traffic to the best available path. As the network recovers from the soft failure conditions, application-aware routing automatically readjusts the data traffic paths.
-
Network costs can be reduced because data traffic can be more efficiently load-balanced.
-
Application performance can be increased without the need for WAN upgrades.
Each Cisco IOS XE Catalyst SD-WAN device supports up to eight TLOCs, allowing a single Cisco IOS XE Catalyst SD-WAN device to connect to up to eight different WAN networks. This capability allows path customization for application traffic that has different needs in terms of packet loss and latency.
Application-Aware Routing Support for Multicast Protocols
Feature |
Release Information |
Description |
---|---|---|
Application-Aware Routing Policy Support for Multicast |
Cisco IOS XE Catalyst SD-WAN Release 17.3.1a Cisco vManage Release 20.3.1 |
This feature enables support for configuring application-aware routing policy for multicast traffic on Cisco IOS XE Catalyst SD-WAN devices based on source and destination, protocol matching and SLA requirement. |
Starting from Cisco IOS XE Catalyst SD-WAN Release 17.3.1a, application-aware routing supports overlay multicast traffic on Cisco IOS XE Catalyst SD-WAN devices. In older releases, an application-route policy is supported only for unicast traffic.
The Cisco IOS XE Catalyst SD-WAN devices classify the multicast traffic based on the group address and sets the SLA class. The group address can be source IP, destination IP, source prefixes, and destination prefixes. In the forwarding plane, any traffic for group address must use only those TLOC paths that meet the SLA requirement. You can perform the path selection for a group based on the preferred color, backup color, or the default action.
Restrictions for Multicast Protocols
Network-Based Application Recognition (NBAR) using the Cisco Catalyst SD-WAN Application Intelligence Engine (SAIE) flow is not supported for multicast.
Note |
In Cisco vManage Release 20.7.1 and earlier releases, the SAIE flow is called the deep packet inspection (DPI) flow. |
Components of Application-Aware Routing
The Cisco IOS XE Catalyst SD-WAN Application-Aware Routing solution consists of three elements:
-
Identification—You define the application of interest, and then you create a centralized data policy that maps the application to specific SLA requirements. You single out data traffic of interest by matching on the Layer 3 and Layer 4 headers in the packets, including source and destination prefixes and ports, protocol, and DSCP field. As with all centralized data policies, you configure them on a Cisco Catalyst SD-WAN Controller, which then passes them to the appropriate Cisco IOS XE Catalyst SD-WAN devices.
-
Monitoring and measuring—The Cisco IOS XE Catalyst SD-WAN software uses BFD packets to continuously monitor the data traffic on the data plane tunnels between devices, and periodically measures the performance characteristics of the tunnel. To gauge performance, the Cisco IOS XE Catalyst SD-WAN device looks for traffic loss on the tunnel, and it measures latency by looking at the one-way and round-trip times of traffic traveling over the tunnel. These measurements might indicate suboptimal data traffic conditions.
-
Mapping application traffic to a specific transport tunnel—The final step is to map an application’s data traffic to the data plane tunnel that provides the desired performance for the application. The mapping decision is based on two criteria: the best-path criteria computed from measurements performed on the WAN connections and on the constraints specified in a policy specific to application-aware routing.
To create a data policy based on the Layer 7 application itself, configure the Cisco Catalyst SD-WAN Application Intelligence Engine (SAIE) flow with a centralized data policy. With the SAIE flow, you can direct traffic to a specific tunnel, based on the remote TLOC, the remote TLOC, or both. You cannot direct traffic to tunnels based on SLA classes.
Note |
In Cisco vManage Release 20.7.1 and earlier releases, the SAIE flow is called the deep packet inspection (DPI) flow. |
SLA Classes
Feature |
Release Information |
Description |
---|---|---|
Support for SLA Classes |
Cisco IOS XE Catalyst SD-WAN Release 17.2.1r |
This feature allows you to configure up to a maximum of eight SLA classes on Cisco SD-WAN Controller. Using this feature, you can configure additional options in an application-aware routing policy. |
Support for six SLA Classes per Policy |
Cisco IOS XE Catalyst SD-WAN Release 17.3.1a Cisco vManage Release 20.3.1 |
This feature allows you to configure up to six SLA classes per policy on Cisco IOS XE Catalyst SD-WAN devices. This enhancement allows additional options in an application-aware routing policy. |
SLA Class Support Enhancement |
Cisco IOS XE Catalyst SD-WAN Release 17.6.1a Cisco vManage Release 20.6.1 |
This feature is an enhancement to support up to 16 SLA classes on Cisco IOS XE Catalyst SD-WAN devices. |
Application Aware Routing and Data Policy SLA Preferred Colors |
Cisco IOS XE Catalyst SD-WAN Release 17.6.1a Cisco vManage Release 20.6.1 |
This feature provides different behaviors to choose preferred colors based on the SLA requirements when both application-aware routing policy and data policies are configured. |
A service-level agreement (SLA) determines actions taken in application-aware routing. The SLA class defines the maximum jitter, maximum latency, maximum packet loss, or a combination of these values for data plane tunnels in Cisco IOS XE Catalyst SD-WAN devices. Each data plane tunnel comprises a local transport locators (TLOC) and a remote TLOC pair. You can configure SLA classes under the policy sla-class command hierarchy on Cisco SD-WAN Controllers. From Cisco IOS XE Catalyst SD-WAN Release 17.2.1r, you can configure a maximum of eight SLA classes on Cisco SD-WAN Validator. However, you can define only four unique SLA classes in an application-aware route policy. In releases earlier than Cisco IOS XE Catalyst SD-WAN Release 17.2.1r, you can configure a maximum of four SLA classes.
Starting from Cisco IOS XE Catalyst SD-WAN Release 17.3.1a, you can configure up to six SLA classes per policy on the Cisco IOS XE Catalyst SD-WAN devices.
You can configure the following parameters in an SLA class.
Description |
Command |
Value or Range |
---|---|---|
Maximum acceptable packet jitter on the data plane tunnel |
jitter milliseconds |
1–1000 milliseconds |
Maximum acceptable packet latency on the data plane tunnel. |
latency milliseconds |
1–1000 milliseconds |
Maximum acceptable packet loss on the data plane tunnel. |
loss percentage |
1–100 percent |
Starting from Cisco IOS XE Catalyst SD-WAN Release 17.15.1a, the threshold values for SLA class list are as follows:
SLA Class |
Loss % |
Latency (ms) |
Jitter (ms) |
---|---|---|---|
Voice-And-Video |
2 |
300 |
60 |
Transactional Data |
1 |
200 |
200 |
Bulk data |
5 |
500 |
500 |
Default |
5 |
500 |
500 |
SLA Support Enhancement
From Cisco IOS XE Catalyst SD-WAN Release 17.6.1a and Cisco vManage Release 20.6.1, you can configure more than six SLA classes per policy on Cisco IOS XE Catalyst SD-WAN devices.
Cisco IOS XE Catalyst SD-WAN devices need 16 GB RAM or more to support upto16 SLA classes.
This feature enhancement increases the number of SLA classes supported on Cisco SD-WAN Controller and SD-WAN Edge devices. With the increase in the SLA class support, you can align SLA classes to IP Virtual Private Networks (IP-VPN) on Multi-Protocol Label Switching (MPLS) networks for transporting traffic to a global network.
The SLA enhancement helps in multitenancy, where you can push different SLA classes for different tenants. The multitenancy feature requires the Cisco SD-WAN Controller to support more than eight SLA classes. To allocate SLA classes to different tenants, the global limit for policies must be 64.
Note |
You cannot configure the default SLA. The default SLA is configured in all the devices to forward traffic when no user-defined SLA is met. |
Supported Platforms and Models |
User-configurable SLA Classes prior to Cisco IOS XE Catalyst SD-WAN Release 17.6.1a (+1 Default SLA Class) |
User-configurable SLA Classes from Cisco IOS XE Catalyst SD-WAN Release 17.6.1a (+1 Default SLA Class) |
---|---|---|
ASR 1001 HX -16GB
|
6 |
15 |
ASR 1002 X -16GB
|
6 |
15 |
ASR 1002 HX -16GB
|
6 |
15 |
ASR 1001 X -16GB
|
6 |
15 |
ISR 4451 X
|
6 |
7 |
ISR 4431
|
6 |
7 |
Catalyst 8300 Edge Platforms
|
NA |
7 |
Catalyst 8500 Edge platforms -16GB
|
NA |
15 |
Any other Cisco IOS XE Catalyst SD-WAN devices (C11xx, ISR1100, and CSR1000v) |
6 |
6 |
SLA-Preferred Colors
From Cisco IOS XE Catalyst SD-WAN Release 17.6.1a, when you configure both application-aware routing policy and data policy, and if data flow matches the app-route and data policy sequences, the following expected behaviors occur:
-
If the preferred colors that you configure in application-aware routing meet the SLA requirements, and these preferred colors have some colors that are common with data policy, the common preferred colors are chosen over others for forwarding. (Prior to Cisco IOS XE Catalyst SD-WAN Release 17.6.1a, the data policy-preferred colors were forwarded and the application-aware routing policy preferences were ignored.)
-
If preferred colors in application-aware routing do not meet the SLA, but there are colors that are common with the data policy, and these colors meet the SLA in application-aware routing, then these colors take precedence and are chosen for forwarding.
-
If no tunnels or colors meet the SLA in application-aware routing, the data policy takes precedence and is chosen for forwarding. If the data policy has preferred colors, these colors are chosen. Otherwise, load balance occurs across all the colors in the data policy.
Classification of Tunnels into SLA Classes
The process of classifying tunnels into one or more SLA classes for application-aware routing has three parts:
-
Measure loss, latency, and jitter information for the tunnel.
-
Calculate the average loss, latency, and jitter for the tunnel.
-
Determine the SLA classification of the tunnel.
Measure Loss, Latency, and Jitter
When a data plane tunnel in the overlay network is established, a BFD session automatically starts on the tunnel. In the overlay network, each tunnel is identified with a color that identifies a specific link between a local TLOC and a remote TLOC. The BFD session monitors the liveness of the tunnel by periodically sending Hello packets to detect whether the link is operational. Application-aware routing uses the BFD Hello packets to measure the loss, latency, and jitter on the links.
By default, the BFD Hello packet interval is 1 second. This interval is user-configurable (with the bfd color interval command). Note that the BFD Hello packet interval is configurable per tunnel.
Calculate Average Loss, Latency, and Jitter
BFD periodically polls all the tunnels on the Cisco IOS XE Catalyst SD-WAN devices to collect packet latency, loss, jitter, and other statistics for use by application-aware routing. At each poll interval, application-aware routing calculates the average loss, latency, and jitter for each tunnel, and then calculates or recalculates each tunnel's SLA. Each poll interval is also called a "bucket."
By default, the poll interval is 10 minutes. With the default BFD Hello packet interval at 1 second, this means that information from about 600 BFD Hello packets is used in one poll interval to calculate loss, latency, and jitter for the tunnel. The poll interval is user-configurable (with the bfd app-route poll-interval command). Note that the application-aware routing poll interval is configurable per Cisco IOS XE Catalyst SD-WAN device; that is, it applies to all tunnels originating on a device.
Reducing the poll interval without reducing the BFD Hello packet interval may affect the quality of the loss, latency, and jitter calculation. For example, setting the poll interval to 10 seconds when the BFD Hello packet interval is 1 second means that only 10 Hello packets are used to calculate the loss, latency, and jitter for the tunnel.
The loss, latency, and jitter information from each poll interval is preserved for six poll intervals. At the seventh poll interval, the information from the earliest polling interval is discarded to make way for the latest information. In this way, application-aware routing maintains a sliding window of tunnel loss, latency, and jitter information.
The number of poll intervals (6) is not user-configurable. Each poll interval is identified by an index number (0 through 5) in the output of the show app-route statistics command.
Determine SLA Classification
To determine the SLA classification of a tunnel, application-aware routing uses the loss, latency, and jitter information from the latest poll intervals. The number of poll intervals used is determined by a multiplier. By default, the multiplier is 6, so the information from all the poll intervals (specifically, from the last six poll intervals) is used to determine the classification. For the default poll interval of 10 minutes and the default multiplier of 6, the loss, latency, and jitter information collected over the last hour is considered when classifying the SLA of each tunnel. These default values have to be chosen to provide damping of sorts, as a way to prevent frequent reclassification (flapping) of the tunnel.
The multiplier is user-configurable (with the bfd app-route multiplier command). Note that the application-aware routing multiplier is configurable per Cisco IOS XE Catalyst SD-WAN device; that is, it applies to all tunnels originating on a device.
If there is a need to react quickly to changes in tunnel characteristics, you can reduce the multiplier all the way down to 1. With a multiplier of 1, only the latest poll interval loss and latency values are used to determine whether this tunnel can satisfy one or more SLA criteria.
Based on the measurement and calculation of tunnel loss and latency, each tunnel may satisfy one or more user-configured SLA classes. For example, a tunnel with a mean loss of 0 packets and mean latency of 10 milliseconds would satisfy a class that has been defined with a maximum packet loss of 5 and a minimum latency of 20 milliseconds, and it would also satisfy a class that has been defined with a maximum packet loss of 0 and minimum latency of 15 milliseconds.
Regardless of how quickly a tunnel is reclassified, the loss, latency, and jitter information is measured and calculated continuously. You can configure how quickly application-aware routing reacts to changes by modifying the poll interval and multiplier.
Per-Class Application-Aware Routing
Feature Name |
Release Information |
Description |
---|---|---|
Per-Class Application-Aware Routing |
Cisco IOS XE Catalyst SD-WAN Release 17.4.1a Cisco vManage Release 20.4.1 |
This feature enhances the capabilities of directing traffic to next-hop addresses based on the service level agreement (SLA) definitions. These SLA definitions along with the policy to match and classify traffic types can be used to direct traffic over specific Cisco Catalyst SD-WAN tunnels. The SLA definition comprises of values of loss, latency, and jitter, which are measured using the Bidirectional Forwarding Detection (BFD) channel that exists between two transport locators (TLOCs). |
Per-Class Application-Aware Routing Overview
The SLA definition comprises of values of loss, latency, and jitter, which are measured using the BFD channel that exists between two TLOCs. These values collectively represent the status of the network and the BFD link. The BFD control messages are sent with a high priority Differentiated Services Code Point (DSCP) marking of 48.
The SLA metrics based on the high priority packet does not reflect the priority that is received by the actual data that flows through the edge device. The data, depending on the application class, can have different DSCP values in the network. Therefore, a more accurate representation of the loss, latency, and jitter for the traffic profiles is required for the networks to use such measurements to direct traffic types to the right tunnels.
Application-aware routing uses policies that constrain paths that can be used for forwarding the application. These constraints are usually expressed in terms of SLA classes that contain loss, latency, and jitter requirements that must be met. This requires that these metrics be measured on all the paths to the destination of the traffic using active probing or by passive monitoring.
Active probing methods include generation of synthetic traffic that is injected along with real traffic. The expectation is that the probes and the real traffic is forwarded in the same way. BFD probing, ICMP, periodic HTTP requests and IP SLA measurements are some examples of active probing mechanisms. The Cisco Catalyst SD-WAN solution uses BFD based probes for active measurements. Passive monitoring methods rely on the Cisco Catalyst SD-WAN Application Intelligence Engine (SAIE) flow and monitoring actual traffic. For example, RTP/TCP traffic is monitored for loss, latency, and jitter.
Note |
In Cisco vManage Release 20.7.1 and earlier releases, the SAIE flow is called the deep packet inspection (DPI) flow. |
Application Probe Class
An application probe class (app-probe-class) comprises of a forwarding class, color, and DSCP. This defines the marking per color of applications that are forwarded. The color or DSCP mapping is local to a Cisco SD-WAN network site. However, a few colors and the DSCP mapping for a color does not change per site. The forwarding class determines the QoS queue in which the BFD echo request is queued at the egress tunnel port. This is applicable only for BFD echo request packets. The packet-loss-priority for BFD packets is fixed to low. When BFD packets are sent with SLA class, they use the same DSCP value. When BFD packets are sent with app-probe-class along with SLA class, the BFD packets are sent for each SLA app-probe-class separately in a round-robin manner.
Note |
When the application route policy is applied at a site, only the colors relevant to the site are used. Since six SLA classes are supported on Cisco IOS XE Catalyst SD-WAN devices, the device correspondingly supports up to six app-probe-classes. |
Default DSCP Values
The default DSCP value that is used in the DSCP control traffic is 48. However, there is a provision to change the default value along with the option to configure on the edge devices. All the network service providers may not necessarily use DSCP 48.
The BFD packet having the default DSCP can also be used for other features such as PMTU. A change in the default DSCP means that the other features are affected by the new default DSCP value. Therefore, we recommend that you configure the highest priority DSCP marking that the service provider provides (usually 48, but can be different based on the SLA agreement of the service provider). The color level overrides the global level default DSCP marking.