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

General Cisco vManage Configuration Procedure

To configure application-aware routing policy, use the Cisco vManage policy configuration wizard. The wizard consists of four sequential screens that guide you through the process of creating and editing policy components:

• Create Applications or Groups of Interest—Create lists that group together related items and that you call in the match or action components of a policy.

• Configure Topology—Create the network structure to which the policy applies.

• Configure Traffic Rules—Create the match and action conditions of a policy.

• Apply Policies to Sites and VPNs—Associate policy with sites and VPNs in the overlay network.

In the first three policy configuration wizard screens, you are creating policy components or blocks. In the last screen, you are applying policy blocks to sites and VPNs in the overlay network.

For a application-aware routing policy to take effect, you must activate the policy.

Step 1: Start the Policy Configuration Wizard

To start the policy configuration wizard:

1. In Cisco vManage NMS, select the Configure > Policies screen. When you first open this screen, the Centralized Policy tab is selected by default.

2. Click Add Policy.

The policy configuration wizard opens, and the Create Applications or Groups of Interest screen is displayed.

Step 2: Create Applications or Groups of Interest

To create lists of applications or groups to use in centralized policy:

1. Create new lists of groups, as described:

   • Application

     1. In the left bar, click Application.

     2. Click New Application List.

     3. Enter a name for the list.

     4. Click either the Application or Application Family button.

     5. From the Select drop-down, select the desired applications or application families.

     6. Click Add.

   • Prefix

     1. In the left bar, click Prefix.

     2. Click New Prefix List.

     3. Enter a name for the list.

     4. In the Add Prefix field, enter one or more data prefixes separated by commas.

     5. Click Add.

   • Site

     1. In the left bar, click Site.

     2. Click New Site List.

     3. Enter a name for the list.

     4. In the Add Site field, enter one or more site IDs separated by commas.

     5. Click Add.

   • SLA Class

     1. In the left bar, click SLA Class.

     2. Click New SLA Class List.

     3. Enter a name for the list.

     4. 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 0 through 1,000 milliseconds.

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

     5. Click Add.

   • VPN

     1. In the left bar, click VPN.

     2. Click New VPN List.

     3. Enter a name for the list.

     4. In the Add VPN field, enter one or more VPN IDs separated by commas.

     5. Click Add.

2. Click Next to move to Configure Topology in the wizard. When you first open this screen, the Topology tab is selected by default.

Step 3: Configure the Network Topology

To configure the network topology:

1. In the Topology tab, create a network topology

   Hub and Spoke - Policy for a topology with one or more central hub sites and with spokes connected to a hub.

   1. In the Add Topology drop-down, select Hub and Spoke.

   2. Enter a name for the hub-and-spoke policy.

   3. Enter a description for the policy.

   4. In the VPN List field, select the VPN list for the policy.

   5. In the left pane, click Add Hub and Spoke. A hub-and-spoke policy component containing the text string My Hub-and-Spoke is added in the left pane.

   6. Double-click the My Hub-and-Spoke text string, and enter a name for the policy component.

   7. In the right pane, add hub sites to the network topology:

      1. Click Add Hub Sites.

      2. In the Site List Field, select a site list for the policy component.

      3. Click Add.

      4. Repeat Steps 7a, 7b, and 7c to add more hub sites to the policy component.

   8. In the right pane, add spoke sites to the network topology:

      1. Click Add Spoke Sites.

      2. In the Site List Field, select a site list for the policy component.

      3. Click Add.

      4. Repeat Steps 8a, 8b, and 8c to add more spoke sites to the policy component.

   9. Repeat Steps 5 through 8 to add more components to the hub-and-spoke policy.

   10. Click Save Hub and Spoke Policy.

   Mesh - Partial-mesh or full-mesh region

   1. In the Add Topology drop-down, select Mesh.

   2. Enter a name for the mesh region policy component.

   3. Enter a description for the mesh region policy component.

   4. In the VPN List field, select the VPN list for the policy.

   5. Click New Mesh Region.

   6. In the Mesh Region Name field, enter a name for the individual mesh region.

   7. In the Site List field, select one or more sites to include in the mesh region.

   8. Repeat Steps 5 through 7 to add more mesh regions to the policy.

   9. Click Save Mesh Region.

2. To use an existing topology:

   1. In the Add Topology drop-down, click Import Existing Topology. The Import Existing Topology popup displays.

   2. Select the type of topology.

   3. In the Policy drop-down, select the name of the topology.

   4. Click Import.

3. Click Next to move to Configure Traffic Rules in the wizard. When you first open this screen, the Application-Aware Routing tab is selected by default.

Step 4: Configure Traffic Rules

To configure traffic rules for application-aware routing policy:

1. In the Application-Aware Routing bar, select the Application-Aware Routing tab.

2. Click the Add Policy drop-down.

3. Select Create New, and in the left pane, click Sequence Type. A policy sequence containing the text string App Route is added in the left pane.

4. Double-click the App Route text string, and enter a name for the policy sequence. The name you type is displayed both in the Sequence Type list in the left pane and in the right pane.

5. In the right pane, click Sequence Rule. The Match/Action box opens, and Match is selected by default. The available policy match conditions are listed below the box.

6. To select one or more Match conditions, click its box and set the values as described in the following table:

   Table 1.

   Match Condition	Procedure
   None (match all packets)	Do not specify any match conditions.
   Applications/Application Family List	In the Match conditions, click Applications/Application Family List. In the drop-down, select the application family. To create an application list: Click New Application List. Enter a name for the list. Click the Application button to create a list of individual applications. Click the Application Family button to create a list of related applications. In the Select Application drop-down, select the desired applications or application families. Click Save.
   Destination Data Prefix	In the Match conditions, click Destination Data Prefix. To match a list of destination prefixes, select the list from the drop-down. To match an individual destination prefix, type the prefix in the Destination box.
   Destination Port	In the Match conditions, click Destination Port. In the Destination field, 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 [-]).
   DNS Application List (to enable split DNS)	In the Match conditions, click DNS Application List. In the drop-down, select the application family.
   DNS (to enable split DNS)	In the Match conditions, click DNS. In the drop-down, select Request to process DNS requests for the DNS applications, and select Response to process DNS responses for the applications.
   DSCP	In the Match conditions, click DSCP. In the DSCP field, type the DSCP value, a number from 0 through 63.
   PLP	In the Match conditions, click PLP. In the PLP drop-down, select Low or High. To set the PLP to high, apply a policer that includes the exceed remark option.
   Protocol	In the Match conditions, click Protocol. In the Protocol field, type the Internet Protocol number, a number from 0 through 255.
   Source Data Prefix	In the Match conditions, click Source Data Prefix. To match a list of source prefixes, select the list from the drop-down. To match an individual source prefix, type the prefix in the Source box.
   Source Port	In the Match conditions, click Source Port. In the Source field, 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 [-]).

7. To select actions to take on matching data traffic, click the Actions box. The available policy actions are listed below the box.

8. Set the policy action for a Counter match condition. Count matching data packets.

   1. In the Action conditions, click Counter.

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

9. Set the policy action for a Log match condition. 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 5 minutes thereafter, as long as the flow is active.

   1. In the Action conditions, click Log to enable logging.

10. Set the policy action for a 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 software 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.

    1. In the Action conditions, click SLA Class List.

    2. In the SLA Class drop-down, select one or more SLA classes.

    3. Optionally, in the Preferred Color drop-down, select the color of the data plane tunnel or tunnels to prefer. Traffic is load-balanced across all 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.

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

11. Click Save Match and Actions.

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

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

14. Click Save Application-Aware Routing Policy.

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

Step 5: Apply Policies to Sites and VPNs

In the last screen of the policy configuration wizard, you associate the policy blocks that you created on the previous three screens with VPNs and with sites in the overlay network.

To apply a policy block to sites and VPNs in the overlay network:

1. If you are already in the policy configuration wizard, skip to Step 6. Otherwise, in Cisco vManage NMS, select the Configure > Policies screen. When you first open this screen, the Centralized Policy tab is selected by default.

2. Click Add Policy. The policy configuration wizard opens, and the Create Applications or Groups of Interest screen is displayed

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

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

5. Click Next. The Apply Policies to Sites and VPNs screen opens.

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.

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.

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.

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

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

11. Click Save Policy. The Configuration > Policies screen opens, and the policies table includes the newly created policy.

Step 6: Activate an Application-Aware Routing Policy

Activating an application-aware routing policy sends that policy to all connected Cisco vSmart Controllers. To activate a policy:

1. In Cisco vManage NMS, select the Configure > Policies screen. When you first open this screen, the Centralized Policy tab is selected by default.

2. Select a policy.

3. Click the More Actions icon to the right of the row, and click Activate. The Activate Policy popup opens. It lists the IP addresses of the reachable Cisco vSmart Controllers to which the policy is to be applied.

4. Click Activate.

Here are the structural components required to configure application-aware routing policy. Each one is explained in more detail in the sections below.

policy
  lists
    app-list list-name
      (app application-name | app-family application-family)
    prefix-list list-name 
      ip-prefix prefix 
    site-list list-name 
      site-id site-id 
    vpn-list list-name 
      vpn-id vpn-id 
 log-frequency number
 sla-class sla-class-name 
   jitter milliseconds
   latency milliseconds
   loss percentage 
 app-route-policy policy-name 
   vpn-list list-name 
     sequence number 
       match
         match-parameters 
       action
         
         count counter-name
         log
         sla-class sla-class-name [strict] [preferred-color colors]
     default-action
       sla-class sla-class-name 
apply-policy site-list list-name
  app-route-policy policy-name

Lists

Application-aware routing policy uses the following types of lists to group related items. You configure these lists under the policy lists command hierarchy on Cisco vSmart Controllers.

app-list list-name
  (app application-name |
  app-family application-family)

data-prefix-list list-name
  ip-prefix prefix/length

site-list list-name
  site-id site-id

vpn-list list-name
  vpn vpn-id

In the Cisco vSmart Controller configuration, you can create multiple iterations of each type of list. For example, it is common to create multiple site lists and multiple VPN lists so that you can apply data policy to different sites and different customer VPNs across the network.

When you create multiple iterations of a type of list (for example, when you create multiple VPN lists), you can include the same values or overlapping values in more than one of these list. You can do this either on purpose, to meet the design needs of your network, or you can do this accidentally, which might occur when you use ranges to specify values. (You can use ranges to specify data prefixes, site identifiers, and VPNs.) Here are two examples of lists that are configured with ranges and that contain overlapping values:

• vpn-list list-1 vpn 1-10

  vpn-list list-2 vpn 6-8

• site-list list-1 site 1-10

  site-list list-2 site 5-15

When you configure data policies that contain lists with overlapping values, or when you apply data policies, you must ensure that the lists included in the policies, or included when applying the policies, do not contain overlapping values. To do this, you must manually audit your configurations. The Cisco IOS XE SD-WAN configuration software performs no validation on the contents of lists, on the data policies themselves, or on how the policies are applied to ensure that there are no overlapping values.

If you configure or apply data policies that contain lists with overlapping values to the same site, one policy is applied and the others are ignored. Which policy is applied is a function of the internal behavior of Cisco IOS XE SD-WAN device when it processes the configuration. This decision is not under user control, so the outcome is not predictable.

VPN Lists

Each application-aware policy instance is associated with a VPN list. You configure VPN lists with the policy app-route-policy vpn-list command. The VPN list you specify must be one that you created with a policy lists vpn-list​ command.

Sequences

Within each VPN list, an application-aware policy contains sequences of match–action pairs. The sequences are numbered to set the order in which data traffic is analyzed by the match–action pairs in the policy. You configure sequences with the policy app-aware-policy vpn-list sequence command.

Each sequence in an application-aware policy can contain one match command and one action command.

Match Parameters

Application-aware routing policy can match IP prefixes and fields in the IP headers. You configure the match parameters with the match command under the policy app-route-policy vpn-list sequence command hierarchy on Cisco vSmart Controllers.

You can match these parameters:

Action Parameters

When data traffic matches the match parameters, the specified action is applied to it. For application-aware routing policy, the action is to apply an SLA class. The SLA class defines the maximum packet latency or maximum packet loss, or both, that the application allows on the data plane tunnel used to transmit its data. TheCisco SD-WAN software examines the recently measured performance characteristics of the data plane tunnels and directs the data traffic to the WAN connection that meets the specified SLA.

The following actions can be configured:

If more than one data plane tunnel satisfies an SLA class criteria, the Cisco IOS XE SD-WAN device selects one of them by performing load-balancing across the equal paths.

Default Action

A policy's default action defines how to handle packets that match none of the match conditions. For application-aware routing policy, if you do not configure a default action, all data packets are accepted and transmitted based on normal routing decisions, with no consideration of 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 SD-WAN device selects one of the available tunnels by performing load-balancing across equal paths.

For an application-aware route policy to take effect, you apply it to a list of sites in the overlay network:

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

When you apply the policy, you do not specify a direction (either inbound or outbound). Application-aware routing policy affects only the outbound traffic on the Cisco IOS XE SD-WAN devices.

For all app-route-policy policies that you apply with apply-policy commands, the site IDs across all the site lists must be unique. That is, the site lists must not contain overlapping site IDs. An example of overlapping site IDs are those in the two site lists site-list 1, site-id 1-100, and site-list 2 site-id 70-130. Here, sites 70 through 100 are in both lists. If you were to apply these two site lists to two different app-route-policy policies, the attempt to commit the configuration on the Cisco vSmart Controller would fail.

The same type of restriction also applies to the following types of policies:

• Centralized control policy (control-policy)

• Centralized data policy (data-policy)

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

You can, however, have overlapping site IDs for site lists that you apply for different types of policy. For example, the sites lists for app-route-policy and data-policy policies can have overlapping site IDs. So for the two example site lists above, site-list 1, site-id 1-100, and site-list 2 site-id 70-130, you could apply one to a control policy and the other to a data policy.

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

To view the policy configured on the Cisco vSmart Controller, use the show running-config command on the controller.

To view the policy that the Cisco vSmart 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.

How Application-Aware Routing Policy Is Applied in Combination with Other Data Policies

If you configure a Cisco IOS XE SD-WAN device with application-aware routing policy and with other policies, the policies are applied to data traffic sequentially.

On a Cisco IOS XE SD-WAN device, you can configure the following types of data policy:

• Centralized data policy. You configure this policy on the Cisco vSmart Controller, and the policy is passed to the device. You define the configuration with the policy data-policy configuration command, and you apply it with the apply-policy site-list data-policy, or apply-policy site-list vpn-membership command.

• Localized data policy, which is commonly called access lists. You configure access lists on the device with the policy access-list configuration command. You apply them, within a VPN, to an incoming interface with the vpn interface access-list in configuration command or to an outgoing interface with the vpn interface access-list out command.

• Application-aware routing policy. Application-aware routing policy affects only traffic that is flowing from the service side (the local/LAN side) to the tunnel (WAN) side of the Cisco IOS XE SD-WAN device. You configure application-aware routing policy on the Cisco vSmart Controller with the policy app-route-policy configuration command, and you apply it with the apply-policy site-list app-route-policy command. When you commit the configuration, the policy is passed to the appropriate devices. Then, matching data traffic on the device is processed in accordance with the configured SLA conditions. Any data traffic that is not dropped as a result of this policy is passed to the data policy for evaluation. If the data traffic does not match and if no default action is configured, transmit it without SLA consideration.

You can apply only one data policy and one application-aware routing policy to a single site in the overlay network. When you define and apply multiple site lists in a configuration, you must ensure that a single data policy or a single application-aware routing policy is not applied to more than one site. The CLI does not check for this circumstance, and the validate configuration command does not detect whether multiple policies of the same type are applied to a single site.

For data traffic flowing from the service side of the router to the WAN side of the router, policy evaluation of the traffic evaluation occurs in the following order:

1. Apply the input access list on the LAN interface. Any data traffic that is not dropped as a result of this access list is passed to the application-aware routing policy for evaluation.

2. Apply the application-aware routing policy. Any data traffic that is not dropped as a result of this policy is passed to the data policy for evaluation. If the data traffic does not match and if no default action is configured, transmit it without SLA consideration.

3. Apply the centralized data policy. Any data traffic that is not dropped as a result of the input access list is passed to the output access list for evaluation.

4. Apply the output access list on the WAN interface. Any data traffic that is not dropped as a result of the output access list is transmitted out the WAN interface.

For data traffic coming from the WAN through the router and into the service-side LAN, the policy evaluation of the traffic occurs in the following order:

1. Apply the input access list on the WAN interface. Any data traffic that is not dropped as a result of the input access list is passed to the data policy for evaluation.

2. Apply the data policy. Any data traffic that is not dropped as a result of the input access list is passed to the output access list for evaluation.

3. Apply the output access list on the LAN interface. Any data traffic that is not dropped as a result of the output access list is transmitted out the LAN interface, towards its destination at the local site.

As mentioned above, application-aware routing policy affects only traffic that is flowing from the service side (the local/LAN side) to the tunnel (WAN) side of the Cisco IOS XE SD-WAN device, so data traffic inbound from the WAN is processed only by access lists and data policy.

Enable Application Visibility on Cisco IOS XE SD-WAN Devices

You can enable application visibility directly on Cisco IOS XE SD-WAN devices, without configuring application-aware routing policy so that you can monitor all the applications running in all VPNs in the LAN. To do this, configure application visiblity on the router:

vEdge(config)#  policy app-visibility 

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

This topic shows a straightforward example of configuring application-aware routing policy. This example defines a policy that applies to ICMP traffic, directing it to links with latency of 50 milliseconds or less when such links are available.

Configuration Steps

You configure application-aware routing policy on a Cisco vSmart Controller. The configuration consists of the following high-level components:

• Definition of the application (or applications)

• Definition of SLA parameters

• Definition of sites, prefixes, and VPNs

• Application-aware routing policy itself

• Specification of overlay network sites to which the policy is applied

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.

Here is the procedure for configuring this application-aware routing policy on a Cisco vSmart Controller:

1. Define the SLA parameters to apply to matching ICMP traffic. In our example, we want to direct ICMP traffic to links that have a latency of 50 milliseconds or less:

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

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

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

3. Configure the application-aware routing policy. Note that in this example, we apply the policy to the application in two different ways: In sequences 1, 2, and 3, we specify the protocol number (protocol 1 is ICMP, protocol 6 is TCP, and protocol 17 is UDP).

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

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

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

5. Display the configuration changes:

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

6. Validate that the configuration contains no errors:

   vSmart(config)# validate
   Validation complete

7. Activate the configuration:

   vSmart(config)# commit
   Commit complete.

8. Exit from configuration mode:

   vSmart(config)# exit
   vSmart#

Full Example Configuration

Putting all the pieces of the configuration together gives this configuration:

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