Skip to main content
Cisco SD-WAN
Support
Product Documentation
Viptela Documentation

Configuring Application-Aware Routing

This article provides general procedures for configuring application-aware routing from the CLI.

Configuration Components

Application-aware routing consists of three components:

  • Identify the applications of interest. To determine which applications are running on vEdge routers, you enable application visibility on these devices. Then you configure an application-aware routing policy on the vSmart controller, which defines the applications of interest and the data plane tunnel performance characteristics required to transmit an application's data traffic. These characteristics are called a service-level agreement (SLA). The controller automatically pushes the policy to the appropriate vEdge routers.
  • Monitor and measure data plane tunnel performance is done automatically and continuously by the vEdge routers, by tracking BFD Hello packets. Application-aware routing periodically polls the performance statistics to calculate the packet jitter and latency and packet loss information for each tunnel. The default polling interval is good for most network situations, but you can modify it to meet specific business needs.
  • Map application traffic to a specific data plane tunnel is done on the vEdge routers, based on the SLA requirements defined in application-aware routing policy and based on the real-time performance of the vEdge routers' data plane tunnels. You can modify how often a vEdge router calculates each tunnel's SLA and determines a tunnel's SLA classification.

Regardless of whether you have configured an application-aware routing policy, each vEdge router automatically monitors traffic jitter, loss, and latency and other interface characteristics on their data plane tunnels. To display this information, use the show app-route stats command on the vEdge router. You can use these statistics to determine the baseline performance characteristics of the vEdge router's tunnels. You can also use them to create appropriate application-aware routing policies and to modify existing policies.

Configure Application-Aware Routing Policy

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 vEdge router.

An application-aware routing policy matches applications with an SLA, that is, with the data plane tunnel performance characteristics that are necessary to transmit the applications' data traffic. The primary purpose of application-aware routing policy is to optimize the path for data traffic being transmitted by vEdge routers.

An application-aware routing policy is a type of centralized data policy: you configure it on the vSmart controller, and the controller automatically pushes it to the affected vEdge routers. As with any policy, an application-aware routing policy consists of a series of numbered (ordered) sequences of match-action pairs that are evaluated in order, from lowest sequence number to highest sequence number. When a data packet matches one of the match conditions, an SLA action is applied to the packet to determine the data plane tunnel to use to transmit the packet. If a packet matches no parameters in any of the policy sequences, and if no default SLA class is configured, the packet is accepted and forwarded with no consideration of SLA. Because application-aware routing policy accepts nonmatching traffic by default, it is considered to be a positive policy. Other types of policies in the Viptela software are negative policies, because by default they drop nonmatching traffic.

To create and apply an application-aware routing policy, include the following components in the vSmart controller's configuration:

Component

Description

Configuration Command

Lists

Groupings of related items that you reference in the match and action portions of the data policy configuration. For application-aware routing policy, you can group IP prefixes, sites, and VPNs.

policy lists

SLA class

Required performance metrics for the application.

policy sla-class

Application-aware routing policy instance

Container for an application-aware routing policy.

policy app-route-policy

Numbered sequences of match–action pairs

Sequences that establish the order in which the policy components are applied.

policy app-route-policy vpn-list sequence

Match parameters

Conditions that packets must match to be considered for an application-aware routing policy.

policy app-route-policy vpn-list sequence match

Actions

SLA class to apply to matching data packets.

policy app-route-policy vpn-list sequence action

Default action

Action to take if a data packet matches none of the application-aware routing policy conditions.

policy app-route-policy vpn-list default-action

Application of application-aware routing policy

Apply an application-aware routing policy to overlay network sites.

apply-policy site-list app-route-policy

General Routing Policy Configuration Procedure

Following are the high-level steps for configuring an application-aware routing policy:

  1. Create a list of overlay network sties to which the application-aware routing policy is to be applied (in the apply-policy command):
    vSmart(config)# policy
    vSmart(config-policy)# lists site-list list-name
    vSmart(config-lists-list-name)# site-id site-id

    The list can contain as many site IDs as necessary. Include one site-id command for each site ID. For contiguous site IDs, you can specify a range of numbers separated with a dash (–). Create additional site lists, as needed.
  2. Create SLA classes and traffic characteristics to apply to matching application data traffic:
    vSmart(config)# policy sla-class sla-class-name
    vSmart(config-sla-class-class-name)# jitter milliseconds
    vSmart(config-sla-class-class-name)# latency milliseconds

    vSmart(config-sla-class-class-name)# loss percentage
  3. Create lists of applications, IP prefixes, and VPNs to use in identifying application traffic of interest (in the match section of the policy definition):
    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
  4. Create an application-aware routing policy instance and associate it with a list of VPNs:
    vSmart(config)# policy app-route-policy policy-name
    vSmart(config-app-route-policy-policy-name)# vpn-list list-name
  5. Within the policy, create one or more numbered sequence of match–action pairs, where the match parameters define the data traffic and applications of interest and the action parameters specify the SLA class to apply if a match occurs.
    1. Create a sequence:
      vSmart(config-policy-name)# sequence number
    2. Define match parameters for data packets:
      ​​vSmart(config-sequence-number)# match parameters
    3. Define the action to take if a match occurs. Here, the action can only be an SLA class to apply.
      vSmart(config-sequence-number)# action sla-class sla-class-name
      vSmart(config-sequence-number)# action sla-class sla-class-name [preferred-color color] [strict]

      The preferred-color option sets the data plane tunnel color to prefer when an SLA class match occurs. If no tunnel of the preferred color is available, traffic is forwarded using another tunnel that matches the SLA class. That is, color preference is a loose matching, not a strict matching.
      With the strict option, if no data plane tunnel matches the SLA, the data traffic is dropped.
      The match–action pairs within a policy are evaluated in numerical order, based on the sequence number, starting with the lowest number. If a match occurs, the corresponding action is taken and policy evaluation stops.
    4. Count the packets or bytes that match the policy:
      vSmart(config-sequence-number)# action count
    5. Place a sampled set of packets that match the SLA class rull into syslog files:
      vSmart(config-sequence-number)# action log
  6. If a packet does not match any of the conditions in one of the sequences, a default action is taken. 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:
    vSmart(config-policy-name)# default-action sla-class sla-class-name
  7. Apply the policy to a site list:
    vSmart(config)# apply-policy site-list list-name app-route-policy policy-name

Structural Components of Policy Configuration for Application-Aware Routing

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 
 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
         log
         sla-class sla-class-name [preferred-color color] [strict]
     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 vSmart controllers.

List Type

Description

Command

Application list

List of one or more applications or application families running on the subnets connected to the vEdge router. Each app-list can contain either applications or application families, but you cannot mix the two.
application-name is the name of an application. The Viptela software supports about 2300 different applications. To list the supported applications, use the ? in the CLI.
application-family is one of the following: antivirus, application-service, audio_video, authentication, behavioral, compression, database, encrypted, erp, file-server, file-transfer, forum, game, instant-messaging, mail, microsoft-office, middleware, network-management, network-service, peer-to-peer, printer, routing, security-service, standard, telephony, terminal, thin-client, tunneling, wap, web, and webmail.

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

Data prefix list

List of one or more IP prefixes.

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

Site list

List of one or more site identifiers in the overlay network. You can specify a single site identifier (such as site-id 1) or a range of site identifiers (such as site-id 1-10).

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

VPN list

List of one or more VPNs in the overlay network. You can specify a single VPN identifier (such as vpn-id 1) or a range of VPN identifiers (such as vpn-id 1-10).

vpn-list list-name
  vpn vpn-id

In the 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 Viptela 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 Viptela software when it processes the configuration. This decision is not under user control, so the outcome is not predictable.

SLA Classes

The action taken in application-aware routing is applied based on what is called an SLA (a service-level agreement). An SLA class is defined by the maximum jitter, maximum latency, maximum packet loss, or a combination of these values, for the vEdge router's data plane tunnels. (Each tunnel is defined by a local TLOC–remote TLOC pair.) You configure SLA classes under the policy sla-class command hierarchy on vSmart controllers. You can configure a maximum of four SLA classes.

You can configure the following parameters in an SLA class:

Description

Command

Value or Range

Maximum acceptable packet jitter on the data plane tunnel jitter milliseconds 1 through 1000 milliseconds

Maximum acceptable packet latency on the data plane tunnel.

latency milliseconds

1 through 1000 milliseconds

Maximum acceptable packet loss on the data plane tunnel.

loss percentage

0 through 100 percent

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 vSmart controllers.

You can match these parameters:

Description

Command

Value or Range

Match all packets

Omit match command

Applications or application families

app-list list-name

Name of an app-list list

Group of destination prefixes

destination-data-prefix-list list-name

Name of a data-prefix-list list

Individual destination prefix

destination-ip prefix/length

IP prefix and prefix length

Destination port number

destination-port number

0 through 65535. 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 [-]).

DSCP value

dscp number

0 through 63

Internet Protocol number

protocol number

0 through 255

Group of source prefixes

source-data-prefix-list list-name

Name of a data-prefix-list list

Individual source prefix

source-ip prefix/length

IP prefix and prefix length

Source port number

source-port number

0 through 65535; enter 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 [-])

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 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. The Viptela 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:

Description

Command

Value or Range

Count matching data packets.

action count

Place a sampled set of packets that match the SLA class rule into the messages and vsyslog system logging (syslog) files. action log To display logging information, use the show app log flow-all, show app log flows, and show log commands on the vEdge router.

SLA class to match. All matching data traffic is directed to the tunnel whose performance matches the SLA parameters defined in the class.

action sla-classsla-class-name

SLA class name defined in policy sla-class command

Data plane tunnel color to prefer when an SLA class match occurs. If no tunnel of the preferred color is available, traffic is forwarded using another tunnel that matches the SLA class. That is, color preference is a loose matching, not a strict matching.

action sla-class sla-class-name preferred-color color

SLA class name defined in policy sla-class command and one of the supported tunnel colors.

Strict matching of SLA class. If no data plane tunnel is available that satisfies the SLA criteria, traffic is dropped. Note that for policy configured with this option, data traffic that matches the match conditions is dropped until the application-aware routing path is established.

action sla-class sla-class-name strict

SLA class name defined in policy sla-class command

If more than one data plane tunnel satisfies an SLA class criteria, the vEdge router 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 vEdge router selects one of the available tunnels by performing load-balancing across equal paths.

Applying Application-Aware Routing Policy

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 vEdge routers.

While you can configure site lists that contain overlapping site IDs, when you apply more than one application-aware route policy, you must ensure that the site lists you apply the policies to have no overlapping site IDs. If you apply more than one application-aware route policy to the same site, one policy is applied and the other is ignored. However, the decision about which policy to apply is not under user control and so is not predictable. Which policy is applied is a function of the internal behavior of Viptela software when it processes the configuration. Therefore, you must design application-aware route policy carefully to ensure that more than one policy is not applied to the same site.

As soon as you successfully activate the configuration on the vSmart controller by issuing a commit command, the controller pushes the application-aware routing policy to the vEdge routers at the specified sites.

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

To view the policy that the vSmart controller has pushed to the vEdge router, issue the show policy from-vsmart command on the router.

To display flow information for the application-aware applications running on the vEdge router, 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 vEdge router with application-aware routing policy and with other policies, the policies are applied to data traffic sequentially.

On a vEdge router, you can configure the following types of data policy:

  • Centralized data policy. You configure this policy on the vSmart controller, and the policy is passed to the vEdge router. 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 vEdge router 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 vEdge router. You configure application-aware routing policy on the 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 vEdge routers. Then, matching data traffic on the vEdge routers 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 vEdge router, so data traffic inbound from the WAN is processed only by access lists and data policy.

Configure the Monitoring of Data Plane Tunnel Performance

The Bidirectional Forwarding Detection (BFD) protocol runs over all data plane tunnels between vEdge routers, 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 vEdge router 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 vEdge router, 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.

The following parameters determine the size of the sliding window:

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

Let's use the default values for these parameters to explain how application-aware routing works:

  • For each sliding window time period, application-aware routing sees 600 BFD Hello packets (BFD Hello interval x polling interval: 1 second x 600 seconds = 600 Hello packets). These packets provide measurements of packet loss and latency on the data plane tunnels.
  • Application-aware routing retains the statistics for 1 hour (polling interval x multiplier: 10 minutes x 6 = 60 minutes).
  • The statistics are placed in six separate buckets, indexed with the numbers 0 through 5. Bucket 0 contains the latest statistics, and bucket 5 the oldest. Every 10 minutes, the newest statistics are placed in bucket 0, the statistics in bucket 5 are discarded, and the remaining statistics move into the next bucket.
  • Every 60 minutes (every hour), application-aware routing acts on the loss and latency statistics. It calculates the mean of the loss and latency of all the buckets in all the sliding windows and compares this value to the specified SLAs for the tunnel. If the calculated value satisfies the SLA, application-aware routing does nothing. 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. This is because the multiplier is 6. While application-aware always retains six buckets of data, the multiplier determines how many it actually uses to calculate the loss and latency. For example, if the multiplier is 3, buckets 0, 1, and 2 are used.

Because these default values take action only every hour, they work well for a stable network. To capture network failures more quickly so that application-aware routing can calculate new tunnels more often, adjust the values of these three parameters. For example, if you change just the polling interval to 1 minute (60,000 milliseconds), application-aware routing reviews the tunnel performance characteristics every minute, but it performs its loss and latency calculations based on only 60 Hello packets. It may take more than 1 minute for application-aware routing to reset the tunnel if it calculates that a new tunnel is needed.

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

vEdge# show 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.168.1.3  24.6.101.120    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.168.1.3  24.130.213.18   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.168.1.3  24.130.233.111  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.168.1.3  24.130.233.111  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 
...

To display the next-hop information for an IP packet that a vEdge router 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.

Enable Application Visibility on vEdge Routers

You can enable application visibility directly on vEdge routers, 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 vEdge router.

  • Was this article helpful?