Application-Aware Routing

Feature history for application-aware routing

This table describes the developments of this feature, by release.
Table 1. Feature History

Feature

Release information

Description

Application-Aware Routing for IPv6

Cisco IOS XE Catalyst SD-WAN Release 17.9.1a

Cisco vManage Release 20.9.1

This feature enables you to configure application-aware routing (AAR) policies to operate with IPv6 application traffic.

You can configure AAR for IPv6 traffic in Cisco vManage.

Application-Aware Routing for Hub and Spoke

Cisco vManage Release 20.9.1

This feature enables you to configure an application-aware routing policy on a hub device and apply the policy to packets that the hub device receives from a spoke device and sends to another spoke device. Applying the application-aware routing policy helps you realize the required SLA for spoke-hub-spoke traffic.

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.

Best of the Worst (BOW) Tunnel Selection

Cisco IOS XE Catalyst SD-WAN Release 17.5.1a

Cisco vManage Release 20.5.1

This feature introduces a new policy action fallback-to-best-path to pick the best path or color out of the available colors.

When the data traffic does not meet any of the SLA class requirements, this feature allows you to select the best tunnel path criteria sequence using the Fallback Best Tunnel option under each SLA class to avoid packet loss.

You can configure best tunnel path to pick the best path while configuring SLA class.

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).

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.

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.

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.

Application-aware routing

An application-aware routing (AAR) is a network optimization feature that

  • tracks network and path characteristics of the data plane tunnels between Cisco IOS XE Catalyst SD-WAN devices

  • uses collected information such as packet loss, latency, and jitter to compute optimal paths for data traffic, and

  • considers factors in path selection beyond standard routing protocols, offering advantages such as optimized traffic flow and reduced network costs.

This image shows how SD-WAN builds multiple tunnels over Internet and MPLS and dynamically steers application traffic over the best-performing path.

Benefits of AAR

  • Direct application traffic over WAN links that meet the required SLA for packet loss, latency, and jitter during normal network operation.

  • Detect brownouts or soft failures in real time and automatically redirect traffic to the best available path to minimize performance degradation.

  • Re-adjust traffic paths automatically once network conditions recover.

  • Reduce network costs by load-balancing traffic more efficiently across available links.

  • Improve application performance without upgrading the WAN.

TLOCs support on Cisco IOS XE Catalyst SD-WAN devices

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.

Components of application-aware routing

The Cisco IOS XE Catalyst SD-WAN Application-Aware Routing solution consists of three elements: identification, monitoring and measuring, and mapping application traffic to a specific transport tunnel.

The application-aware routing solution includes the following 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.


Fundamentals of application-aware routing policy

Scope and purpose of application aware routing

Application-aware routing policy affects only traffic that is flowing from the service side (the local/WAN side) to the tunnel (WAN) side of the Cisco IOS XE Catalyst SD-WAN device.

It maps applications to the data plane tunnel performance characteristics required to transmit their traffic. The primary purpose of application-aware routing policy is to optimize the path for data traffic being transmitted by Cisco IOS XE Catalyst SD-WAN devices.

Policy type and deployment model

An application-aware routing policy is a type of centralized data policy. You configure it on the Cisco SD-WAN Controller, and the controller automatically pushes it to the affected Cisco IOS XE Catalyst SD-WAN devices.

Like any policy, an application-aware routing policy contains a series of numbered (ordered) match-action sequences that the system evaluates from the lowest sequence number to the highest. When a data packet matches a condition, the system applies an SLA action to determine the data plane tunnel used to transmit the packet.

Default behavior and policy nature

If a packet does not match any parameters in the policy sequences, and if no SLA class is configured for the default-action, the packet is accepted and forwarded with no consideration of SLA. This is because application-aware routing policy accepts nonmatching traffic by default, it is classified as a positive policy. Other types of policies in the Cisco IOS XE Catalyst SD-WAN software are negative policies, because they drop non-matching traffic by default.

IPv6 support enhancement

Starting from Cisco IOS XE Catalyst SD-WAN Release 17.9.1a and Cisco vManage Release 20.9.1, you can configure AAR and data policies to control IPv6 traffic based on match application or app-list criteria.

Prior to Cisco IOS XE Catalyst SD-WAN Release 17.9.1a, IPv6 traffic did not have capability to match the IPv6 traffic based on Application name or application list to steer IPv6 traffic based on the desired intent.

Default action of application-aware routing policy

This section describes how the default action in an application-aware routing policy determines packet handling when no match conditions are met.

The policy’s default action defines how it handles packets that match none of the match conditions. For application-aware routing policy, if you do not configure a default action, the policy accepts all data packets and transmits them based on normal routing decisions, without considering SLA.

To modify this behavior, include the default-action SLA-class SLA-class-name command in the policy, specifying the name of an SLA class you defined in the policy SLA-class command.

When you apply an SLA class in a policy's default action, you cannot specify the strict option.

If no data plane tunnel satisfies the SLA class in the default action, the Cisco IOS XE Catalyst SD-WAN device selects one of the available tunnels by performing load-balancing across equal paths.

Expected behavior when data flow matches both AAR and data policies

  1. When data policy local TLOC action is configured, the App-route preferred-color and backup-preferred-color actions are ignored.

  2. The SLA-class and SLA-strict actions are retained from the application routing configuration.

  3. The data policy TLOC takes precedence.

When there is a local-TLOC-list action that has multiple options, choose the local-TLOC that meets SLA.

  • If no local-TLOC meets SLA, then choose equal-cost multi-path routing (ECMP) for the traffic over the local-TLOC-list.

  • If none of the local-TLOC is up, then choose a TLOC that is up.

  • If none of the local-TLOC is up and the DP is configured in restrict mode, then drop the traffic.


Note


When a loopback interface with a public IP address is configured as a TLOC and bound to a NAT-enabled physical WAN interface, DIA forwarding works. However, strict color-based exit selection using centralized data policy local-tloc or local-tloc-list is not supported if the bound physical WAN interface is not itself configured as a TLOC.


Application-aware routing for multicast protocols

This reference describes application-aware routing support for multicast protocols, and multicast traffic classification on Cisco IOS XE Catalyst SD-WAN devices.

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.

Multicast traffic classification

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.

SLA

A service-level agreement (SLA) class is a policy construct that

  • Defines maximum jitter, latency, packet loss, or their combination for data plane tunnels,

  • Drives actions in application-aware routing, and

  • Applies to tunnels formed by local and remote TLOC pairs.

You can define only four unique SLA classes in an application-aware route policy and configure up to eight SLA classes on devices in later releases. Earlier releases supports only four SLA configuration.

SLA components

SLA comprises of the following parameters:

Table 2. SLA Components

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

Threshold values for SLA class lists

Starting with Cisco IOS XE Catalyst SD-WAN Release 17.15.1a, the threshold values for SLA class lists are adjusted, as detailed in the table below. These changes may affect your network traffic behavior upon upgrading.

Table 3. Threshold values for SLA class lists

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

From Cisco Catalyst SD-WAN Manager Release 20.12.x, the threshold values for default SLA classes are not configurable.

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 the data flow matches the app-route and data policy sequences, the following expected behaviors occur:

  • If the preferred colors in application-aware routing meet the SLA requirements and overlap with the 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 some colors overlap with the data policy and meet the SLA in application-aware routing, those 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 for forwarding. If the data policy specifies preferred colors, those colors are selected; otherwise, load balancing occurs across all colors in the data policy.

SLA classes

This feature enhancement increases the number of SLA classes supported on Cisco SD-WAN Controller and SD-WAN Edge devices. With the increased SLA class support, you can align SLA classes with IP Virtual Private Networks (IP-VPNs) on Multi-Protocol Label Switching (MPLS) networks to transport traffic to a global network.

The SLA enhancement supports multitenancy by allowing different SLA classes to be pushed to 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.

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.

Maximum SLA classes supported on Cisco IOS XE Catalyst SD-WAN devices

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 upto 16 SLA classes.

Table 4. Maximum SLA classes supported on Cisco IOS XE Catalyst SD-WAN devices

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

6

6

Classification of tunnels into SLA classes

Classifying tunnels into one or more SLA classes for application-aware routing consists of three main 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

Application-aware routing uses BFD Hello packets to measure loss, latency, and jitter on overlay network tunnels, ensuring tunnel liveness.

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 uses a color to identify 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. You can configure this interval with the bfd color interval command. You can configure the BFD Hello packet interval per tunnel.

Calculate average loss, latency, and jitter

Application-aware routing uses BFD polling to collect packet latency, loss, jitter, and other statistics for each tunnel.

Tunnel polling and metrics collection

BFD periodically polls all tunnels on Cisco IOS XE Catalyst SD-WAN devices to collect packet latency, loss, jitter, and other statistics for 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.”

Poll interval behavior and configuration

By default, the poll interval is 10 minutes. With the default BFD Hello packet interval set to 1 second, application-aware routing uses information from about 600 BFD Hello packets in one poll interval to calculate tunnel loss, latency, and jitter. The poll interval is user-configurable using the bfd app-route poll-interva l command. Application-aware routing configures the poll interval per Cisco IOS XE Catalyst SD-WAN device, and it applies to all tunnels originating on the device.

Reducing the poll interval without reducing the BFD Hello packet interval may affect the quality of the loss, latency, and jitter calculations. For example, if you set the poll interval to 10 seconds and keep the BFD Hello packet interval at 1 second, the system uses only 10 Hello packets to calculate tunnel loss, latency, and jitter.

Sliding window of poll intervals

Application-aware routing preserves the loss, latency, and jitter information from each poll interval for six poll intervals. At the seventh poll interval, the system discards the earliest polling interval and stores 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.

Configure SLA

Use one of these methods to configure SLA in Cisco SD-WAN for AAR.

Configure SLA class using policy groups

Use these steps to configure SLA Class using policy groups.

Procedure

Step 1

From the Cisco SD-WAN Manager menu, choose Configuration > Policy Groups > Application Priority & SLA.

Step 2

Create or edit an existing application priority and SLA policy and select Advanced Mode.

Step 3

From the left pane, click SLA Class, and then click Add SLA Class.

Step 4

Define the SLA class parameters.

  • In the Loss field, enter the maximum packet loss on the connection, a value from 0 through 100 percent.

  • In the Latency field, enter the maximum packet latency on the connection, a value from 1 through 1,000 milliseconds.

  • In the Jitter field, enter the maximum jitter on the connection, a value from 1 through 1,000 milliseconds.

Step 5

Choose the required app probe class from the App Probe Class drop-down list.

Step 6

(Optional) Check the Fallback Best Tunnel check box to enable the best tunnel criteria.

This optional field is available from Cisco IOS XE Catalyst SD-WAN Release 17.5.1a to pick the best path or color from the available colors when a SLA is not met. When this option is selected, you can choose the required criteria from the drop-down. The criteria are a combination of one or more of loss, latency, and jitter values.


Configure SLA class using classic policies

Use these steps to configure an SLA class using classic policies to set thresholds for loss, latency, and jitter, enabling application-aware routing and optimal path selection in your SD-WAN deployment.

Procedure

Step 1

From the Cisco SD-WAN Manager menu, select Configuration > Policies.

Centralized Policy is displayed by default.

Step 2

Click Add Policy.

Step 3

In the create groups of interest page, from the left pane, click SLA Class, and then click New SLA Class List.

Step 4

In the SLA Class List Name field, enter a name for the SLA class list.

Step 5

Define the SLA class parameters:

  1. In the Loss field, enter the maximum packet loss on the connection, a value from 0 through 100 percent.

  2. In the Latency field, enter the maximum packet latency on the connection, a value from 1 through 1,000 milliseconds.

  3. In the Jitter field, enter the maximum jitter on the connection, a value from 1 through 1,000 milliseconds.

  4. Choose the required app probe class from the App Probe Class drop-down list.

Step 6

(Optional) Check the Fallback Best Tunnel check box to enable the best tunnel criteria.

This optional field is available from Cisco IOS XE Catalyst SD-WAN Release 17.5.1a to pick the best path or color from the available colors when a SLA is not met. When this option is selected, you can choose the required criteria from the drop-down. The criteria are a combination of one or more of loss, latency, and jitter values.

Step 7

Select the Criteria from the drop-down. The available criteria are:

  • None

  • Latency

  • Loss

  • Jitter

  • Latency, Loss

  • Latency, Jitter

  • Loss, Latency

  • Loss, Jitter

  • Jitter, Latency

  • Jitter, Loss

  • Latency, Loss, Jitter

  • Latency, Jitter, Loss

  • Loss, Latency, Jitter

  • Loss, Jitter, Latency

  • Jitter, Latency, Loss

  • Jitter, Loss, Latency

Step 8

(Optional) Enter the Loss Variance (%), Latency Variance (ms), and the Jitter Variance (ms) for the selected criteria.

For more information, see Configure Variance for Best Tunnel Path.

Step 9

Click Add.


Configure traffic rules

Use one of these methods to configure traffic rules in Cisco SD-WAN for AAR.

Configure traffic rules using classic policies

Use this task to define or modify traffic rules for application-aware routing in Cisco SD-WAN environments.

Procedure

Step 1

Click Application Aware Routing.

Step 2

From the Add Policy drop-down list, choose Create New.

Step 3

Click Sequence Type.

A policy sequence containing the text string App Route is added in the left pane.

  1. Double-click the App Route text string and enter a name for the policy sequence.

    You can copy, delete, or rename a policy sequence.

    The name you enter is displayed both in the Sequence Type list in the left pane and in the right pane.

  2. In the right pane, click Sequence Rule.

    The Match/Actions dialog box opens, and Match is selected by default.

    The available policy match conditions appear below the dialog box.

Step 4

In the Protocol drop-down list, choose one of the following options:

  • IPv4

  • IPv6

  • Both

Depending on which protocol you choose, the Match or Actions conditions may be different.

Step 5

Click and choose one or more Match conditions. Set the values as described in the following table:

Table 5. Match conditions

Match Condition

Procedure

None (match all packets)

Do not specify any match conditions.

Application/Application Family List

Click Application/Application Family List and choose an application list.

This match condition is available for IPv6 traffic from Cisco IOS XE Release 17.9.1a and Cisco vManage Release 20.9.1.

Cloud Saas Application List

Cisco SD-WAN Manager provides a list of several cloud applications that Cisco Catalyst SD-WAN Cloud OnRamp for SaaS can use to determine the best path selection for each SaaS application.

For more information on Cisco Catalyst SD-WAN Cloud OnRamp for SaaS, see the Cisco Catalyst SD-WAN Cloud OnRamp Configuration Guide, Cisco IOS XE Release 17.x.

Note

 

Cloud Saas Application List displays as a match condition if you specify IPv4 as the Protocol option.

In the drop-down list, choose a SaaS application from the drop-down list.

DNS Application List

In the drop-down list, select an application family.

This match condition is available for IPv6 traffic from Cisco IOS XE Release 17.9.1a and Cisco vManage Release 20.9.1.

Destination Data Prefix

To match a list of destination prefixes, choose the list from the drop-down list.

To match an individual destination prefix, type the prefix in the Destination dialog box.

Destination Region

You can use Destination Region in a Cisco Catalyst SD-WAN network using Cisco Catalyst SD-WAN Multi-Region Fabric.

Choose one of the following options from the drop-down list:

  • Primary: Match traffic if the destination site is in the same primary region (also called access region) as the source.

  • Secondary: Match traffic if the destination site is not in the same primary region as the source but is within the same secondary region as the source. This traffic can reach the destination using a direct tunnel, as described for secondary regions.

  • Other: Match traffic if the destination site is not in the same primary region or secondary region as the source. This traffic requires a multi-hop path from the source to the destination.

For more information on how to configure Multi-Region Fabric, see the Cisco Catalyst SD-WAN Multi-Region Fabric (also Hierarchical SD-WAN) Configuration Guide.

Destination Port

Enter the port number. Specify a single port number, a list of port numbers (with numbers separated by a space), or a range of port numbers (with the two numbers separated with a hyphen [-]).

Traffic To

When creating a data policy or an application-aware policy for a border router for Multi-Region Fabric, you can use match criteria to match traffic flowing to the access region, the core region, or a service VPN.

DNS (to enable split DNS)

In the drop-down list, choose Request to process DNS requests for the DNS applications, and choose Response to process DNS responses for the applications.

DSCP

Type the DSCP value, a number from 0 through 63.

PLP

Choose Low or High. To set the PLP to High, apply a policer that includes the exceed remark option.

Protocol

Type the internet protocol number, a number from 0 through 255.

ICMP Message

For Protocol (IPv4), when you select a value as 1 in the Protocol field in the Match Conditions section, the ICMP Message field displays where you can select an ICMP message to apply to the data policy.

For Protocol (IPv6), when you select a value as 58 in the Protocol field in the Match Conditions section, the ICMP Message field displays where you can select an ICMP message to apply to the data policy.

Note

 

This field is available from Cisco IOS XE Release 17.4.1 or Cisco SD-WAN Release 20.4.1, and also Cisco vManage Release 20.4.1.

When Protocol is selected as Both, the ICMP Message or ICMPv6 Message field displays.

Source Data Prefix

To match a list of source prefixes, choose the list from the drop-down list.

To match an individual source prefix, enter the prefix in the Source field.

Source Port

Enter the port number. Specify a single port number, a list of port numbers (with numbers separated by a space), or a range of port numbers (with the two numbers separated with a hyphen [-]).

Step 6

Cliick Actions to select actions for the matched data traffic. Set the values as described in the following table:

Table 6. Actions
Action Procedure
Backup SLA Preferred Color

Set the policy action for a Backup SLA Preferred Color match condition. When no tunnel matches the SLA, direct the data traffic to a specific tunnel. Data traffic is sent out the configured tunnel if that tunnel interface is available. If that tunnel interface is not available, traffic is sent out to another available tunnel. You can specify one or more colors. The backup SLA preferred color is a loose matching condition, not a strict matching condition.

Counter

Set the policy action for a Counter match condition.

Click Counter.

In the Counter Name field, enter the name of the file in which to store packet counters.

Log

You can place a sampled set of packets that match the SLA class rule into system logging (syslog) files. In addition to logging the packet headers, a syslog message is generated the first time a packet header is logged and then every five minutes thereafter, as long as the flow is active.

Click Log to enable logging.

SLA Class List

Set the policy action for an SLA Class List match condition. For the SLA class, all matching data traffic is directed to a tunnel whose performance matches the SLA parameters defined in the class. The device first tries to send the traffic through a tunnel that matches the SLA. If a single tunnel matches the SLA, data traffic is sent through that tunnel. If two or more tunnels match, traffic is distributed among them. If no tunnel matches the SLA, data traffic is sent through one of the available tunnels.

Click SLA Class List.

In the SLA Class drop-down list, choose one or more SLA classes.

Optionally, when the Preferred Color is not selected, you can choose the preferered color group from the Preferred Color Group drop-down list. Select the preferred color group of the data plane tunnel or tunnels to prefer. You can configure up to three levels of priority based on the color or path preference. This field is available from Cisco IOS XE Catalyst SD-WAN Release 17.9.1a and Cisco vManage Release 20.9.1.

Optionally, in the Preferred Color drop-down list, choose the color of the data plane tunnel or tunnels to prefer. Traffic is load-balanced across all the tunnels. If no tunnels match the SLA, data traffic is sent through any available tunnel. That is, color preference is a loose matching, not a strict matching.

Click Strict/Drop to perform strict matching of the SLA class. If no data plane tunnel is available that satisfies the SLA criteria, traffic is dropped.

Set a Remote Preferred Color in the AAR policy to control traffic routing based on the application list. You can add multiple remote preferred colors in the AAR policy.

Use the Restrict to Remote Color to restrict the tunnel to preferred TLOCs. With Restrict to Remote Color option, the traffic drops when the SLA is not met with the preferred remote color.

Click Fallback to best path to select the best available tunnel to avoid a packet drop.

Note

 
The Fallback to best path option is available from Cisco IOS XE Catalyst SD-WAN Release 17.5.1a and Cisco SD-WAN Release 20.5.1.

You can select the Fallback to best path action only when the Fallback Best Tunnel option is enabled while defining a SLA class. If the Fallback Best Tunnel option is not enabled, then the following error message displays in Cisco SD-WAN Manager:

SLA Class selected, does not have Fallback Best Tunnel enabled. 
Please change the SLA class or change to Strict/Drop.

Click Load Balance to load balance traffic across all the tunnels.

Cloud SLA

Cloud SLA enables traffic to use the best path selection with Cisco Catalyst SD-WAN Cloud OnRamp for SaaS.

Click Cloud SLA.

Step 7

Click Save Match and Actions.

Create additional sequence rules as desired. Drag and drop to re-arrange them.

Step 8

Click Save Application Aware Routing Policy.

Step 9

Click Next to move to Apply Policies to Sites and VPNs in the wizard.


Configure traffic class using policy groups

Use these steps to configure traffic Class using policy groups.

Procedure

Step 1

From the Cisco SD-WAN Manager menu, choose Configuration > Policy Groups > Application Priority & SLA.

Step 2

Create or edit an existing application priority and SLA policy and select Advanced Mode.

Step 3

Click Add Traffic Policy.

Step 4

Enter the name of the VPN and set the direction to Service.

Step 5

Click Add Rules.

Step 6

In the Protocol drop-down list, choose one of the following options:

  • IPv4

  • IPv6

  • Both

Depending on which protocol that you choose, the Match or Actions conditions may be different.

Step 7

Click and choose one or more Match conditions. Set the values as described in the following table:

Table 7. Match conditions

Match Condition

Procedure

None (match all packets)

Do not specify any match conditions.

Application/Application Family List

Click Application/Application Family List and choose an application list.

This match condition is available for IPv6 traffic from Cisco IOS XE Release 17.9.1a and Cisco vManage Release 20.9.1.

Cloud Saas Application List

Cisco SD-WAN Manager provides a list of several cloud applications that Cisco Catalyst SD-WAN Cloud OnRamp for SaaS can use to determine the best path selection for each SaaS application.

For more information on Cisco Catalyst SD-WAN Cloud OnRamp for SaaS, see the Cisco Catalyst SD-WAN Cloud OnRamp Configuration Guide, Cisco IOS XE Release 17.x.

Note

 

Cloud Saas Application List displays as a match condition if you specify IPv4 as the Protocol option.

In the drop-down list, choose a SaaS application from the drop-down list.

DNS Application List

In the drop-down list, select an application family.

This match condition is available for IPv6 traffic from Cisco IOS XE Release 17.9.1a and Cisco vManage Release 20.9.1.

Destination Data Prefix

To match a list of destination prefixes, choose the list from the drop-down list.

To match an individual destination prefix, type the prefix in the Destination dialog box.

Destination Region

You can use Destination Region in a Cisco Catalyst SD-WAN network using Cisco Catalyst SD-WAN Multi-Region Fabric.

Choose one of the following options from the drop-down list:

  • Primary: Match traffic if the destination site is in the same primary region (also called access region) as the source.

  • Secondary: Match traffic if the destination site is not in the same primary region as the source but is within the same secondary region as the source. This traffic can reach the destination using a direct tunnel, as described for secondary regions.

  • Other: Match traffic if the destination site is not in the same primary region or secondary region as the source. This traffic requires a multi-hop path from the source to the destination.

For more information on how to configure Multi-Region Fabric, see the Cisco Catalyst SD-WAN Multi-Region Fabric (also Hierarchical SD-WAN) Configuration Guide.

Destination Port

Enter the port number. Specify a single port number, a list of port numbers (with numbers separated by a space), or a range of port numbers (with the two numbers separated with a hyphen [-]).

Traffic To

When creating a data policy or an application-aware policy for a border router for Multi-Region Fabric, you can use match criteria to match traffic flowing to the access region, the core region, or a service VPN.

DNS (to enable split DNS)

In the drop-down list, choose Request to process DNS requests for the DNS applications, and choose Response to process DNS responses for the applications.

DSCP

Type the DSCP value, a number from 0 through 63.

PLP

Choose Low or High. To set the PLP to High, apply a policer that includes the exceed remark option.

Protocol

Type the internet protocol number, a number from 0 through 255.

ICMP Message

For Protocol (IPv4), when you select a value as 1 in the Protocol field in the Match Conditions section, the ICMP Message field displays where you can select an ICMP message to apply to the data policy.

For Protocol (IPv6), when you select a value as 58 in the Protocol field in the Match Conditions section, the ICMP Message field displays where you can select an ICMP message to apply to the data policy.

Note

 

This field is available from Cisco IOS XE Release 17.4.1 or Cisco SD-WAN Release 20.4.1, and also Cisco vManage Release 20.4.1.

When Protocol is selected as Both, the ICMP Message or ICMPv6 Message field displays.

Source Data Prefix

To match a list of source prefixes, choose the list from the drop-down list.

To match an individual source prefix, enter the prefix in the Source field.

Source Port

Enter the port number. Specify a single port number, a list of port numbers (with numbers separated by a space), or a range of port numbers (with the two numbers separated with a hyphen [-]).

Step 8

To select actions for the matched data traffic, click Actions. Set the values as described in the following table:

Table 8. Actions
Action Procedure
Backup SLA Preferred Color

Set the policy action for a Backup SLA Preferred Color match condition. When no tunnel matches the SLA, direct the data traffic to a specific tunnel. Data traffic is sent out the configured tunnel if that tunnel interface is available. If that tunnel interface is not available, traffic is sent out to another available tunnel. You can specify one or more colors. The backup SLA preferred color is a loose matching condition, not a strict matching condition.

Counter

Set the policy action for a Counter match condition.

Click Counter.

In the Counter Name field, enter the name of the file in which to store packet counters.

Log

You can place a sampled set of packets that match the SLA class rule into system logging (syslog) files. In addition to logging the packet headers, a syslog message is generated the first time a packet header is logged and then every five minutes thereafter, as long as the flow is active.

Click Log to enable logging.

SLA Class List

Set the policy action for an SLA Class List match condition. For the SLA class, all matching data traffic is directed to a tunnel whose performance matches the SLA parameters defined in the class. The device first tries to send the traffic through a tunnel that matches the SLA. If a single tunnel matches the SLA, data traffic is sent through that tunnel. If two or more tunnels match, traffic is distributed among them. If no tunnel matches the SLA, data traffic is sent through one of the available tunnels.

Click SLA Class List.

In the SLA Class drop-down list, choose one or more SLA classes.

Optionally, when the Preferred Color is not selected, you can choose the preferered color group from the Preferred Color Group drop-down list. Select the preferred color group of the data plane tunnel or tunnels to prefer. You can configure up to three levels of priority based on the color or path preference. This field is available from Cisco IOS XE Catalyst SD-WAN Release 17.9.1a and Cisco vManage Release 20.9.1.

Optionally, in the Preferred Color drop-down list, choose the color of the data plane tunnel or tunnels to prefer. Traffic is load-balanced across all the tunnels. If no tunnels match the SLA, data traffic is sent through any available tunnel. That is, color preference is a loose matching, not a strict matching.

Click Strict/Drop to perform strict matching of the SLA class. If no data plane tunnel is available that satisfies the SLA criteria, traffic is dropped.

Set a Remote Preferred Color in the AAR policy to control traffic routing based on the application list. You can add multiple remote preferred colors in the AAR policy.

Use the Restrict to Remote Color to restrict the tunnel to preferred TLOCs. With Restrict to Remote Color option, the traffic drops when the SLA is not met with the preferred remote color.

Click Fallback to best path to select the best available tunnel to avoid a packet drop.

Note

 
The Fallback to best path option is available from Cisco IOS XE Catalyst SD-WAN Release 17.5.1a and Cisco SD-WAN Release 20.5.1.

You can select the Fallback to best path action only when the Fallback Best Tunnel option is enabled while defining a SLA class. If the Fallback Best Tunnel option is not enabled, then the following error message displays in Cisco SD-WAN Manager:

SLA Class selected, does not have Fallback Best Tunnel enabled. 
Please change the SLA class or change to Strict/Drop.

Click Load Balance to load balance traffic across all the tunnels.

Cloud SLA

Cloud SLA enables traffic to use the best path selection with Cisco Catalyst SD-WAN Cloud OnRamp for SaaS.

Click Cloud SLA.

Step 9

Click Save Match and Actions.

Create additional sequence rules as desired. Drag and drop to re-arrange them.

Step 10

Click Save Application Aware Routing Policy.

Step 11

Click Next to move to Apply Policies to Sites and VPNs in the wizard.


Best tunnel path

To avoid data packet loss and configure the best application-aware routing tunnel selection when a SLA is not met, you can configure specific policy actions.
  • backup-preferred-color

  • fallback-to-best-path

Figure 1. Flow Chart for Application-Aware Routing Tunnel Selection

Variance configuration for best tunnel path

This section explains how variance configuration affects best tunnel path selection in Cisco SD-WAN Manager when using best of worst (BOW) logic for SLA class requirements.

Cisco SD-WAN Manager uses best of worst (BOW) to find a best tunnel when no tunnel meets any of the SLA class requirements.

Assume that the required latency to meet the SLA class requirements is 100 ms and tunnel T1 has 110 ms. Tunnel T2 has 111 ms and tunnel T3 has 112 ms.

Based on the BOW logic, the best tunnel is T1. T2 and T3 are equally the best tunnels, with only a difference of a few ms.

You configure variance in Cisco SD-WAN Manager when configuring an SLA class. Variance accommodates small deviations during best tunnel selection.

For more information, see Configure SLA Class.

Example: Without variance configured

At time t1: T1 has 100 ms, T2 has 101 ms, and T3 has 102 ms

At time t2: T1 has 101 ms, T2 has 100 ms, and T3 has 102 ms

At time t3: T1 has 101 ms, T2 has 112 ms, and T3 has 100 ms

At time t1, the best tunnel changes from T1 to T2, and for time t2, the best tunnel changes from T2 to T3. Because variance is not configured, this leads to data path reprogramming and changes to the data traffic paths.

Assume instead that you configure variance to dampen a small deviation in ms.

For example, you configure variance as 5 ms, which means that the best tunnel SLA = 100 ms. The range is from 100 ms to 105 ms.

Example: With variance configured

BOW(t1) = {T1, T2, T3}

BOW(t2) = {T1, T2, T3}

BOW(t3) = {T1, T2, T3}

With variance configured, there is no data path reprogramming required or changes to data traffic paths.

Verify variance configuration for best tunnel path

This section explains how configuring variance for latency, jitter, or loss impacts the selection of the best tunnel path in SD-WAN policies.

Example for latency variance

Device# show sdwan policy from-vsmart
from-vsmart sla-class video
latency                       100
jitter                        150
 fallback-best-tunnel         latency

Tunnel T1: Latency: 110 msec, Loss: 0%, Jitter: 200 msec  
Tunnel T2: Latency: 115 msec, Loss: 0%, Jitter: 200 msec  
Tunnel T3: Latency: 120 msec, Loss: 0%, Jitter: 200 msec  
  • When latency variance is not configured, tunnel T1 is selected as the best tunnel.

  • When a latency variance of 10 ms is configured, tunnels T1, T2, and T3 all qualify as best tunnels.

  • The rangeif from 110 ms to 120 ms.

  • This range is calculated as best latency (110 ms) + latency variance (10 ms).

  • Use the following formula to determine eligible tunnels: (best_latency, best_latency + latency_variance)

Example for jitter variance

Device# show sdwan policy from-vsmart
from-vsmart sla-class video
latency                       100
jitter                        150
 fallback-best-tunnel         jitter

Tunnel T1: Latency: 90 msec, Loss: 0%, Jitter: 160 msec  
Tunnel T2: Latency: 80 msec, Loss: 0%, Jitter: 200 msec  
Tunnel T3: Latency: 70 msec, Loss: 0%, Jitter: 152 msec 
  • When jitter variance is not configured, tunnel T3 is selected as the best tunnel.

  • When a jitter variance of 10 ms is configured, tunnels T1 and T3 qualify as the best tunnels.

  • The range is from 152 ms to 162 ms.

  • This range is calculated as best jitter (152 ms) + jitter variance (10 ms).

  • Use the following formula to determine eligible tunnels: (best_jitter, best_jitter + jitter_variance)

Example for loss variance

Device# show sdwan policy from-vsmart
from-vsmart sla-class video
latency                       100
jitter                        1
 fallback-best-tunnel         loss

Tunnel T1: Latency: 110 msec, Loss: 2%, Jitter: 200 msec  
Tunnel T2: Latency: 115 msec, Loss: 3%, Jitter: 200 msec  
Tunnel T3: Latency: 120 msec, Loss: 4%, Jitter: 200 msec
  1. When loss variance is not configured, tunnel T1 is selected as the best tunnel.

  2. When a loss variance of 1% is configured, tunnels T1 and T2 qualify as the best tunnels.

  3. The range is from 2% to 3%.

  4. This range is calculated as best loss (2%) + loss variance (1%).

  5. Use the following formula to determine eligible tunnels: (best_loss, best_loss + loss_variance)

Per-class application-aware routing

A per-class application-aware routing policy is a network routing mechanism that

  • uses SLA metrics such as loss, latency, and jitter measured between TLOCs

  • applies policies that constrain paths for forwarding applications based on SLA classes, and

  • requires active probing or passive monitoring to measure metrics on all paths to the traffic destination.

SLA metrics overview

The SLA definition includes loss, latency, and jitter values measured using the BFD channel between two TLOCs. These values collectively represent the status of the network and the BFD link. The system sends BFD control messages with a high-priority Differentiated Services Code Point (DSCP) marking of 48.

However, SLA metrics derived from these high-priority packets do not reflect the priority that actual data traffic receives as it flows through the edge device. Depending on the application class, data traffic can carry different DSCP values in the network. Therefore, the network requires a more accurate representation of loss, latency, and jitter for real traffic profiles so it can direct different traffic types to the appropriate tunnels.

Application-aware routing and SLA policies

Application-aware routing uses policies to constrain the paths available for forwarding applications. These constraints are typically defined as SLA classes containing loss, latency, and jitter requirements that the network must meet.

To enforce these policies, the system measures SLA metrics across all paths to the traffic destination. It performs these measurements using either active probing or passive monitoring.

Active probing methods

Active probing generates synthetic traffic and injects it alongside real traffic. The network expects both probe traffic and real traffic to follow the same forwarding behavior.

Examples of active probing mechanisms include:

  • BFD probing

  • ICMP probes

  • Periodic HTTP requests

  • IP SLA measurements

The Cisco Catalyst SD-WAN solution uses BFD-based probes for active measurements.

Passive monitoring methods

Passive monitoring relies on the Cisco Catalyst SD-WAN Application Intelligence Engine (SAIE) to observe real traffic flows and measure loss, latency, and jitter directly from live traffic. For example, the system monitors RTP and TCP traffic to gather these metrics.

In Cisco vManage Release 20.7.1 earlier releases, the SAIE flow was referred to as the deep packet inspection (DPI) flow.

Application probe classes

A application probe class is a policy component that

  • defines forwarding class, color, and DSCP markings for application-aware routing probes,

  • determines the QoS queue for BFD echo requests at the egress tunnel port, and

  • controls DSCP usage and probe behavior when combined with SLA classes.

App-Probe class behavior and scope

Color and DSCP mapping are local to each Cisco SD-WAN network site, although some colors remain consistent across sites. BFD packet-loss priority is fixed to low.

When BFD packets use an SLA class, they use the same DSCP value. When BFD packets use both an SLA class and an app-probe-class, probes are sent separately for each SLA app-probe-class in a round-robin manner.

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.

Configure an application probe class

Use one of these methods to configure an application probe class

Configure app probe class using policy groups

Use these steps to configure app probe class using policy groups.

Procedure

Step 1

From the Cisco SD-WAN Manager menu, choose Configuration > Policy Groups > Objects and Profiles.

Step 2

From the left pane, click App Probe Class, and then click Add app probe class.

Step 3

Enter the probe class name in the Probe Class Name field.

Step 4

Choose the required class map from the Class Map drop-down list.

Step 5

Choose the appropriate color from the Color drop-down list and enter the DSCP value.

Step 6

Click + icon, to add more entries as required.

Step 7

Click Save.


Application probe class configuration using CLI

Configure the application probe class and map it with the SLA class using CLI commands.

Use this example to configure an application probe class for real-time video and map it to an SLA class.

Device(config)# app-probe-class real-time-video
Device(config)# forwarding-class videofc
Device(config)# color mpls dscp 34
Device(config)# color biz-internet dscp 40
Device(config)# color lte dscp 0
Device(config)# sla-class streamsla
Device(config)# latency 20
Device(config)# loss 10
Device(config)# app-probe-class real-time-video

Configure the default DSCP value using the BFD template:


                                 
Device(config)# bfd default-dscp 50 
Device(config)# bfd color mpls 15   

Configure an application probe class using classic policies

Use these steps to configure an application probe class, define its probe classes, and associate them with forwarding classes for application-aware routing.

Procedure

Step 1

From the Cisco SD-WAN Manager menu, choose Configuration > Policies.

Step 2

In Centralized Policy, click Add Policy. The Create Groups of Interest page appears.

Step 3

Choose the list type App Probe Class from the left navigation panel to create your groups of interest.

Step 4

Click New App Probe Class.

Step 5

Enter the probe class name in the Probe Class Name field.

Step 6

Choose the required forwarding class from the Forwarding Class drop-down list.

If there are no forwarding classes, create a class from the Class Map list page under the Localized Policy Lists in the Custom Options menu.

To create a forwarding class:

  1. In the Custom Options drop-down, choose Lists from the Localized Policy options.

  2. In the Define Lists window, choose the list type Class Map from the left navigation panel.

  3. Click New Class List to create a new list.

  4. Enter Class and choose the Queue from the drop-down list.

  5. Click Save.

Step 7

In the Entries pane, choose the appropriate color from the Color drop-down list and enter the DSCP value.

Click + sign to add more entries as required.

Step 8

Click Save.


Add app-probe-class to an SLA class

Use these steps to create a new SLA class and associate it with an app probe class to enable performance monitoring based on loss, latency, and jitter criteria.

Procedure


Step 1

From the left pane, select SLA Class.

Step 2

Click New SLA Class List.

Step 3

In the SLA Class List Name field, enter a name for the SLA class list.

Step 4

Enter the required values for Loss (%), Latency (ms), and Jitter (ms).

Step 5

Choose the required app probe class from the App Probe Class drop-down list.

Step 6

Click Add.

The new SLA Class created with loss, latency, jitter, and app probe class is added to the table.


Default DSCP values

The DSCP control traffic uses the default DSCP value of 48. However, you can change the default value and configure it on the edge devices. All 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.

Configure default DSCP on a Cisco BFD template

Use these steps to configure the default DSCP value on a Cisco BFD template, ensuring that BFD packets are marked appropriately for traffic prioritization and quality of service.

Procedure


Step 1

From the Cisco SD-WAN Manager menu, selectConfiguration > Templates > Feature Templates > .

Note

 

In Cisco vManage Release 20.7.x and earlier releases, Feature Templates is titled Feature.

Step 2

Click Add Template and select a device from the device list in the left pane.

Step 3

In the right pane, select the BFD template listed under Basic Information.

Enter Template Name and Description in the respective fields.

Step 4

In the Basic Configuration pane, enter Multiplier and Poll Interval (milliseconds).

Step 5

In the Default DSCP value for BFD Packets field, enter the required device specific value or choose the default value for DSCP.

Step 6

(Optional) In the Color pane, choose the required color from the drop-down list.

Step 7

Enter the required Hello Interval (milliseconds) and Multiplier.

Step 8

Choose the Path MTU Discovery value.

Step 9

Enter the BFD Default DSCP value for tloc color.

Step 10

Click Add.

The default DSCP and color values are configured on the BFD template.


Configure BFD template using configuration groups

Use these steps to configure BFD template using configuration groups.

Procedure


Step 1

From the Cisco SD-WAN Manager menu, choose Configuration > Configuration Groups.

Step 2

Create and configure a BFD feature in a System profile.

Step 3

Configure basic settings.

Table 9. Basic Configuration

Field

Description

Poll Interval(In Millisecond)

Specify how often BFD polls all data plane tunnels on a router to collect packet latency, loss, and other statistics used by application-aware routing.

Range: 1 through 4,294,967,296 (232 – 1) milliseconds

Default: 600,000 milliseconds (10 minutes)

Multiplier

Specify the value by which to multiply the poll interval, to set how often application-aware routing acts on the data plane tunnel statistics to figure out the loss and latency and to calculate new tunnels if the loss and latency times do not meet the configured SLAs.

Range: 1 through 6

Default: 6

DSCP Values for BFD Packets(decimal)

Specify the Differentiated Services Code Point (DSCP) value of the BFD packets that is used in the DSCP control traffic.

Range: 0-63

Default: 48


Apply policies to sites and VPNs

Use one of these methods to apply policies to sites and VPNs.
  • Policy groups: Add the application priority & SLA policy to a policy group, associate the required devices, and activate the policy group. For more information, refer to Deploy Policy Group Workflow in Policy Groups Configuration Guide.

  • CLI commands

  • Classic policies

Restrictions for policy application

Site ID requirement

  • For all app-route-policy policies applied using apply-policy commands, site IDs across all site lists must be unique.

  • Site lists must not contain overlapping site IDs.

    Example of overlap:

    • site-list 1: site-id 1–100

    • site-list 2: site-id 70–130

    • Sites 70–100 exist in both lists. If these two site lists are applied to different app-route-policy policies, committing the configuration on the target will fail.

  • The same non-overlapping site ID requirement applies to:

    • Centralized control policy (control-policy)

    • Centralized data policy (data-policy)

    • Centralized data policy used for cflowd flow monitoring (data-policy that includes a cflowd action and an apply-policy containing a cflowd-template command)

Allowed overlaps between different policy types

  • Site lists can contain overlapping site IDs only when they are applied to different policy types.

  • Example:

    • site-list 1 (1–100) applied to a control policy

    • site-list 2 (70–130) applied to a data policy.

  • This configuration is allowed.

Apply policies to sites and VPNs using classic policies

Use these steps to apply policy blocks to sites and VPNs in the overlay network to enforce application-aware routing and centralized policies.

Before you begin

Ensure you have created the required policy blocks in the previous steps of the policy configuration wizard.

Have lists of sites and VPNs ready for association with policy blocks.

Procedure


Step 1

From the Cisco SD-WAN Manager menu, choose Configuration > Policies. Centralized Policy is selected and displayed by default.

Step 2

Click Add Policy. The Create Applications or Groups of Interest page is displayed.

Step 3

Click Next. The Network Topology window opens, and in the Topology bar, Topology is selected by default.

Step 4

Click Next. The Configure Traffic Rules window opens, and in the Application-Aware Routing bar, Application-Aware Routing is selected by default.

Step 5

Click Next. The Apply Policies to Sites and VPNs window opens.

Step 6

In the Policy Name field, enter a name for the policy. This field is mandatory and can contain only uppercase and lowercase letters, the digits 0 through 9, hyphens (–), and underscores (_). It cannot contain spaces or any other characters.

Step 7

In the Policy Description field, enter a description of the policy. It can contain up to 2048 characters. This field is mandatory, and it can contain any characters and spaces.

Step 8

From the Topology bar, select the type of policy block. The table then lists policies that you have created for that type of policy block.

Step 9

Click Add New Site List and VPN list. Select one or more site lists and select one or more VPN lists. Click Add.

Step 10

Click Preview to view the configured policy. The policy is displayed in CLI format.

Step 11

Click Save Policy. The Configuration > Policies page appears, and the policies table includes the newly created policy.

As soon as you successfully activate the configuration on the Cisco Catalyst SD-WAN Controller by issuing a commit command, the controller pushes the application-aware routing policy to the Cisco IOS XE Catalyst SD-WAN devices at the specified sites.


Apply policies to sites and VPNs using CLI commands

To apply an application-aware route policy to a list of sites in the overlay network, use this CLI command:
device(config)# apply-policy site-list list-name app-route-policy policy-name

Verify applied policy

Use these commands to verify and monitor policies configured on the controller and pushed to routers.
  • To view the policy configured on the Cisco Catalyst SD-WAN Controller, use the show running-config command on the controller.

  • To view the policy that the Cisco Catalyst SD-WAN Controller has pushed to the device, issue the show policy from-vsmart command on the router.

  • To display flow information for the application-aware applications running on the device, issue the show app dpi flows command on the router.

Activate an application-aware routing policy

Use this task to activate an application-aware routing policy to control how application traffic is routed across the network based on defined criteria.

Procedure


Step 1

From the Cisco SD-WAN Manager menu, choose Configuration > Policies.

By default, the Centralized Policy page is displayed.

Step 2

For the desired policy, click ... and select Activate.

The Activate Policy window opens and displays the IP addresses of the reachable Cisco SD-WAN Controllers where the policy will be applied.

Step 3

Click Activate.


When you activate an application-aware routing policy, the policy is sent to all the connected Cisco SD-WAN Controllers.

Configure application-aware routing policies

Use one of these steps to configure application-aware routing policies:

Configure application-aware routing using CLI commands

Use these steps to control how application traffic is routed across overlay networks, ensuring that traffic meets specific SLA criteria such as latency, jitter, and loss.

Procedure


Step 1

Create lists of overlay network sites to which the policy will be applied.

Example:

vSmart(config)# policy
vSmart(config-policy)# lists site-list list-name
vSmart(config-site-list)# site-id site-id
  1. Include one site-id command for each site.

  2. For contiguous site IDs, specify a range using a dash (–).

  3. Create additional site lists as needed.

Step 2

Define SLA classes with traffic characteristics to apply to matching application data traffic.

Example:

vSmart(config)# policy sla-class sla-class-name
vSmart(config-sla-class)# jitter milliseconds
vSmart(config-sla-class)# latency milliseconds
vSmart(config-sla-class)# loss percentage
vSmart(config-sla-class)# app-probe-class app-probe-class
vSmart(config-sla-class)# fallback-best-tunnelcriterialatencylossjitter

Step 3

Create Lists of Applications, IP Prefixes, and VPNs.

Example:

vSmart(config)# policy lists
vSmart(config-lists)# app-list list-name
vSmart(config-app-list)# (app application-name | app-family family-name)

vSmart(config-lists)# prefix-list list-name 
vSmart(config-prefix-list)# ip-prefix prefix/length

vSmart(config-lists)# vpn-list  list-name
vSmart(config-vpn-list)# vpn vpn-id

Step 4

Create an application-aware routing policy instance and associate it with a list of VPNs.

Example:

vSmart(config)# policy app-route-policy policy-name
vSmart(config-app-route-policy)# vpn-list list-name

Step 5

Create match-action sequences: Define one or more numbered sequences that match data traffic and apply SLA classes.

  1. Create a sequence.

    Example:

    vSmart(config-app-route-policy)# sequence number
  2. Define match parameters for data packets.

    Example:

    ​​vSmart(config-sequence)# match  parameters
  3. Define the action to take if a match occurs.

    Example:

    vSmart(config-sequence)# action sla-class sla-class-name [strict]
    vSmart(config-sequence)# action sla-class sla-class-name [strict] preferred-color colors
    vSmart(config-sequence)# <userinput>action backup-sla-preferred-color</userinput> <varname>colors</varname>

Step 6

Configure action options for SLA classes:

  1. Configure basic SLA Class

    sla-class sla-class-name

    Forwards matching traffic as long as one tunnel meets the SLA.

    • If one tunnel matches, traffic goes through it.

    • If multiple tunnels match, traffic is distributed among them.

    • If no tunnel matches, traffic uses any available tunnel.

  2. Configure preferred tunnel color.

    sla-class sla-class-name
              preferred-color color
    Traffic prefers a tunnel of the specified color.
    • If no tunnel matches the SLA, data traffic is sent through any available tunnel. In this sense, color preference is considered to be a loose matching, not a strict matching, because data traffic is always forwarded, whether a tunnel of the preferred color is available or not.

    • When no tunnel matches the SLA, you can choose how to handle the data traffic:

      • strict—Drop the data traffic.

      • backup-sla-preferred-color color —Direct the data traffic to a specific tunnel. Data traffic is sent out the configured tunnel if that tunnel interface is available; if that tunnel is unavailable, traffic is sent out another available tunnel. You can specify one or more colors. As with the preferred-color option, the backup SLA preferred color is loose matching. In a single action configuration, you cannot include both the strict and backup-sla-preferred-color options.

  3. Count matching packets/bytes:

    vSmart(config-sequence)# action count counter-name
  4. Place a sampled set of packets into syslog:

    vSmart(config-sequence)# action log

    Match–action pairs are evaluated in numerical order. If no match occurs, the default action applies. For application-aware routing, the default is to accept nonmatching traffic. To apply SLA parameters to nonmatching packets:

Step 7

If a packet does not match any of the conditions in one of the sequences, configure the default action.

Example:

vSmart(config-policy-name)# default-action sla-class sla-class-name

For application-aware routing policy, the default action is to accept nonmatching traffic and forward it with no consideration of SLA. You can configure the default action so that SLA parameters are applied to nonmatching packets.

Step 8

Apply the policy to a site list.

Example:

vSmart(config)# apply-policy site-list list-name app-route-policy policy-name

Configure application-aware routing policies using classic policies

This section describes how to configure application-aware routing policies using classic policies, including the sequence of steps and requirements for policy activation.

To configure application-aware routing policy, use the Cisco SD-WAN Manager policy configuration wizard. For Centralized Policy configuration details, refer to Configure Centralized Policies.

The wizard consists of four sequential windows that guide you through the process of creating and editing policy components:

Procedure


Step 1

Create applications or groups of interest.

Create lists that group related items and reference them in the match or action components of a policy. For configuration details, see Configure Groups of Interest.

Step 2

Configure traffic rules.

Define the match and action conditions of the policy.

Step 3

Apply policies to sites and VPN.

Associate the created policy blocks with sites and VPNs in the overlay network.

In the first three policy configuration wizard windows, you create the policy components or blocks. In the final window, you apply these policy blocks to sites and VPNs

Step 4

Activate the policy, to make an application-aware routing policy effective.


Configure an application-aware routing policy using CLI

This task enables you to configure application-aware routing policy on a Cisco Catalyst SD-WAN Controller. The policy directs ICMP traffic to links with latency of 50 milliseconds or less.

You configure application-aware routing policy on a Cisco Catalyst SD-WAN Controller.

The order in which you configure these components is immaterial from the point of view of the CLI. However, from an architectural design point of view, a logical order is to first define all the parameters that are invoked in the application-aware routing policy itself or that are used to apply the policy to various sites in the overlay network. Then, you specify the application-aware routing policy itself and the network sites to which you want to apply the policy.

Procedure


Step 1

Define the SLA parameters to apply to matching ICMP traffic.

Example:

​vSmart# config
vSmart(config)# policy sla-class test_sla_class latency 50
vSmart(config-sla-class-test_sla_class)#

This example directs ICMP traffic to links with latency of 50 milliseconds or less.

Step 2

Define the site and VPN lists to which you want to apply the application-aware routing policy.

Example:

vSmart(config-sla-class-test_sla_class)# exit
vSmart(config-sla-class-test_sla_class)# lists vpn-list vpn_1_list vpn 1
vSmart(config-vpn-list-vpn_1_list)# exit
vSmart(config-lists)# site-list site_500 site-id 500
vSmart(config-site-list-site_500)#

Step 3

Configure the application-aware routing policy and specify the protocol numbers for ICMP, TCP, and UDP.

Example:

vSmart(config-site-list-site_500)# exit
vSmart(config-lists)# exit
vSmart(config-policy)# app-route-policy test_app_route_policy
vSmart(config-app-route-policy-test_app_route_policy)# vpn-list vpn_1_list
vSmart(config-vpn-list-vpn_1_list)# sequence 1 match protocol 6
vSmart(config-match)# exit
vSmart(config-sequence-1)# action sla-class test_sla_class strict
vSmart(config-sequence-1)# exit
vSmart(config-vpn-list-vpn_1_list)# sequence 2 match protocol 17
vSmart(config-match)# exit
vSmart(config-sequence-2)# action sla-class test_sla_class
vSmart(config-sequence-2)# exit
vSmart(config-vpn-list-vpn_1_list)# sequence 3 match protocol 1
vSmart(config-match)# exit
vSmart(config-sequence-3)# action sla-class test_sla_class strict
vSmart(config-sequence-3)# exit
vSmart(config-sequence-4)#

In this example, protocol 1 is ICMP, protocol 6 is TCP, and protocol 17 is UDP.

Step 4

Apply the policy to the desired sites in the Cisco IOS XE Catalyst SD-WAN overlay network.

Example:

vSmart(config-sequence-4)# top
vSmart(config)# apply-policy site-list site_500 app-route-policy test_app_route_policy

Step 5

Display the configuration changes.

Example:

vSmart(config-site-list-site_500)# top
vSmart(config)# show config

Step 6

Validate that the configuration contains no errors.

Example:

vSmart(config)# validate
Validation complete

Step 7

Activate the configuration.

Example:

vSmart(config)# commit
Commit complete.

Step 8

Exit from configuration mode.

Example:

vSmart(config)# exit
vSmart#

Complete configuration example:

vSmart# show running-config policy
policy
 sla-class test_sla_class
  latency 50
 !
 app-route-policy test_app_route_policy
  vpn-list vpn_1_list
   sequence 1
    match
     protocol 6
    !
    action sla-class test_sla_class strict
   !
   sequence 2
    match
     protocol 17
    !
    action sla-class test_sla_class
   !
   sequence 3
    match
     protocol 1
    !
    action sla-class test_sla_class strict
   !
  !
 !
 lists
  vpn-list vpn_1_list
   vpn 1
  !
  site-list site_500
   site-id 500
  !
  site-list site_600
   site-id 600
  !
 !
!
apply-policy
 site-list site_500
  app-route-policy test_app_route_policy
 !
!

Multicast protocol example:


policy
!
 sla-class SLA_BEST_EFFORT
  jitter 900
 !
 sla-class SLA_BUSINESS_CRITICAL
  loss    1
  latency 250
  jitter  300
 !
 sla-class SLA_BUSINESS_DATA
  loss    3
  latency 400
  jitter  500
 !
 sla-class SLA_REALTIME
  loss    2
  latency 300
  jitter  60
 !
 app-route-policy policy_multicast
  vpn-list multicast-vpn-list
   sequence 10
    match
     source-ip      10.0.0.0/8
     destination-ip 10.255.255.254/8
    !
    action
     count mc-counter-10
     sla-class SLA_BUSINESS_CRITICAL
    !
   !
   sequence 15
    match
     source-ip      172.16.0.0/12
     destination-ip 172.31.255.254/12
    !
    action
     count mc-counter-15
     sla-class SLA_BEST_EFFORT
    !
   !
   sequence 20
    match
     destination-ip 192.168.0.1
    !
    action
     count mc-counter-20
     sla-class SLA_BUSINESS_CRITICAL
    !
   !
   sequence 25
    match
     protocol       17
    !
    action
     count mc-counter-25
     sla-class SLA_REALTIME
    !
   !
   sequence 30
    match
     source-ip      192.168.0.0/16
     destination-ip 192.168.255.254
     protocol       17
    !
    action
     count mc-counter-30
     sla-class SLA_BUSINESS_DATA preferred-color lte    
    !
   !
   default-action sla-class SLA_BEST_EFFORT
   !
   sequence 35
    match
     source-ip      10.0.0.0/8
     destination-ip 10.255.255.254/8
     protocol       17
    !
    action
     count mc-counter-35
     sla-class SLA_BUSINESS_DATA preferred-color lte
     backup-sla-preferred-color 3g
    !
   !
 lists
  vpn-list multicast-vpn-list
   vpn 1
   vpn 60
   vpn 4001-4010
   vpn 65501-65510
  !
  site-list multicast-site-list
   site-id 1100
   site-id 500
   site-id 600
  !
 !
!
apply-policy
 site-list multicast-site-list
  app-route-policy policy_multicast
 !
!

Remote color preference example:


vSmart# show running-config policy
policy
 sla-class SLA1
  latency 100
 !
app-route-policy AAR1
  vpn-list vpn1
   sequence 1
    match
     destination-ip 10.1.1.0/24
    !
    action
     sla-class SLA1 preferred-color mpls lte
     sla-class remote-preference
      remote-color          mpls lte
      remote-color-restrict

Ranking color preference example:

app-route-policy SAMPLE _AAR
 vpn-list ONE
  sequence 10
   match
    dscp 46
   !
   action
    sla VOICE_SLA strict preferred-color-group GROUP2_COLORS
   !
  !
  sequence 20
   match
    dscp 34
   !
   action
    sla VOICE_SLA preferred-color-group GROUP1_COLORS
   !
  !
  sequence 30
   match
    dscp 28
   !
   action
    sla VOICE_SLA preferred-color-group GROUP3_COLORS
   !
  !
 !
policy lists
  preferred-color-group GROUP1_COLORS
   primary-preference
    color-preference biz-internet
    path-preference direct-tunnel
   ! 
   secondary-preference
    color-preference mpls
    path-preference multi-hop-path
   !
   tertiary-preference
    color-preference lte
   !
  !
  preferred-color-group GROUP2_COLORS
   primary-preference
    color-preference mpls 
   !
   secondary-preference
    color-preference biz-internet
   !
  !
  preferred-color-group GROUP3_COLORS
   primary-preference
    color-preference mpls biz-internet lte
   !


Note


You can configure path-preference option only if you enable the Multi-Region Fabric option in Cisco SD-WAN Manager.


AAR policy for IPv6 applications example:

policy
  sla-class Default
   jitter 100
   latency 300
   loss 25
  !
 app-route-policy _VPN1_AAR-Policy-for-IPv6-Traffic
  vpn-list VPN1
    sequence 1
     match
      app-list Msft-0365
     !
     action
      sla-class Default  preferred-color public-internet
     !
    !
 !
 lists
  app-list Msft-0365
   app ms-office-web-apps 
  !
  site-list SITE-100
   site-id 100 
  !
  vpn-list VPN1
   vpn 1 
  !
 !
!
apply-policy
 site-list SITE-100
  app-route-policy _VPN1_AAR-Policy-for-IPv6-Traffic
 !
!

Data plane tunnel performance monitoring

Monitor data plane tunnel health and performance using BFD statistics for application-aware routing decisions.

Monitor data plane tunnel performance

The Bidirectional Forwarding Detection (BFD) protocol runs over all data plane tunnels between Cisco IOS XE Catalyst SD-WAN devices, monitoring the liveness, and network and path characteristics of the tunnels. Application-aware routing uses the information gathered by BFD to determine the transmission performance of the tunnels. Performance is reported in terms of packet latency and packet loss on the tunnel.

BFD sends Hello packets periodically to test the liveness of a data plane tunnel and to check for faults on the tunnel. These Hello packets provide a measurement of packet loss and packet latency on the tunnel. The Cisco IOS XE Catalyst SD-WAN device records the packet loss and latency statistics over a sliding window of time. BFD keeps track of the six most recent sliding windows of statistics, placing each set of statistics in a separate bucket. If you configure an application-aware routing policy for the device, it is these statistics that the router uses to determine whether a data plane tunnel's performance matches the requirements of the policy's SLA.

Sliding window operation and statistics

  • For each sliding window time period, application-aware routing receives 600 BFD Hello packets (BFD Hello interval × polling interval: 1 second × 600 seconds = 600 Hello packets). These packets measure packet loss and latency on the data plane tunnels.

  • Application-aware routing retains the statistics for 1 hour (polling interval × multiplier: 10 minutes × 6 = 60 minutes).

  • Application-aware routing places the statistics in six separate buckets, indexed 0 through 5. Bucket 0 contains the latest statistics, and bucket 5 contains the oldest. Every 10 minutes, the system places the newest statistics in bucket 0, discards the statistics in bucket 5, and moves the remaining statistics to the next bucket.

  • Every 60 minutes (every hour), application-aware routing acts on the loss and latency statistics. It calculates the mean loss and latency across all buckets in all sliding windows and compares the result with the specified SLAs for the tunnel. If the calculated value satisfies the SLA, application-aware routing takes no action. If the value does not satisfy the SLA, application-aware routing calculates a new tunnel.

  • Application-aware routing uses the values in all six buckets to calculate the mean loss and latency for a data tunnel because the multiplier is 6. Although application-aware routing always retains six buckets of data, the multiplier determines how many buckets it uses to calculate the loss and latency. For example, if the multiplier is 3, it uses buckets 0, 1, and 2.

Adjusting parameters for faster detection

These default values take action only every hour, so they work well for a stable network. To capture network failures more quickly and allow application-aware routing to calculate new tunnels more often, adjust the values of these three parameters.

For example, if you change the polling interval to 1 minute (60,000 milliseconds), application-aware routing reviews tunnel performance characteristics every minute, but it performs loss and latency calculations based on only 60 Hello packets. If application-aware routing determines that it needs a new tunnel, it may take more than 1 minute to reset the tunnel.

Parameters for sliding window size

Use these parameters to configure the sliding window size for BFD-based application-aware routing.

Parameters

Default

Configuration command

Range

BFD Hello packet interval

1 second

BFD color color hello-interval seconds

1 through 65535 seconds

Polling interval for application-aware routing

10 minutes (600,000 milliseconds)

BFD app-route poll-interval milliseconds

1 through 4,294,967 (232 – 1) milliseconds

Multiplier for application-aware routing

6

BFD app-route multiplier number

1 through 6

Monitor tunnel statistics and routing paths

  • To display the next-hop information for an IP packet that a device sends out a service side interface, use the show policy service-path command.

  • To view the similar information for packets that the router sends out a WAN transport tunnel interface, use the show policy tunnel-path command.

  • To display statistics for each data plane tunnel, use the show sdwan app-route stats command:

    Device# show sdwan app-route stats 
    
                                                                                                             TX    RX    
                                        SRC    DST    MEAN  MEAN            TOTAL          AVERAGE  AVERAGE  DATA  DATA  
    SRC IP       DST IP          PROTO  PORT   PORT   LOSS  LATENCY  INDEX  PACKETS  LOSS  LATENCY  JITTER   PKTS  PKTS  
    ---------------------------------------------------------------------------------------------------------------------
    192.0.2.1  192.0.2.254  ipsec  12346  12346  0     22       0      596      0     21       2        0     0     
                                                                     1      596      0     21       2        0     0     
                                                                     2      596      0     21       2        0     0     
                                                                     3      597      1     21       2        0     0     
                                                                     4      596      0     21       2        0     0     
                                                                     5      596      0     29       4        0     0     
    192.0.2.1  192.0.2.254  ipsec  12346  12346  0     24       0      596      0     24      3       0        0     
                                                                     1      596      0     25       3        0     0     
                                                                     2      596      0     25       3        0     0     
                                                                     3      596      0     24       3        0     0     
                                                                     4      596      0     24       3        0     0     
                                                                     5      596      0     24       3        0     0     
    192.0.2.1  192.0.2.254  ipsec  12346  34083     0   21      0      596      0     21      3       0        0       
                                                                     1      596      0     22       3        0     0     
                                                                     2      596      0     22       3        0     0     
                                                                     3      596      0     21       3        0     0     
                                                                     4      596      0     21       3        0     0     
                                                                     5      596      0     21       3        0     0     
    
    192.0.2.1  192.0.2.254  ipsec  12346  36464   0     23       0     596      0     23      3       0        0     
                                                                     1      596      0     23       3        0     0     
                                                                     2      596      0     24       3        0     0     
                                                                     3      596      0     23       4        0     0     
                                                                     4      596      0     23       4        0     0     
                                                                     5      596      0     23       4        0     0 
    ...

Enable application visibility on Cisco IOS XE Catalyst SD-WAN devices

Enable application visibility on Cisco IOS XE Catalyst SD-WAN devices to monitor all applications running in all VPNs in the LAN without configuring application-aware routing policy.

To configure application visibility on the router, use:

device(config)#  policy app-visibility 

To monitor the applications, use the show app dpi applications and show app dpi supported-applications commands on the device.