Configuring Application-Aware Routing

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-site-list)# 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)# jitter milliseconds
   vSmart(config-sla-class)# latency milliseconds
   vSmart(config-sla-class)# 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)# vpn-list list-name
5. If you configure a logging action, configure how often to log packets to the syslog files:
   vEdge(config)# policy log-frequency number
6. Within the policy, create one or more numbered sequences 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-app-route-policy)# sequence number
   2. Define match parameters for data packets:
      ​​vSmart(config-sequence)# match parameters
   3. Define the action to take if a match occurs. Use one of the following combinations:
      
      (Option 1) Define SLA class. If no available tunnels meet the SLA criteria, drop traffic:
      vSmart(config-sequence)# action sla-class sla-class-name strict
      
      (Option 2) Define SLA class. If no available tunnels meet the SLA criteria, use the tunnel color specified as backup:
      vSmart(config-sequence)# action sla-class sla-class-name
      vSmart(config-sequence)# action backup-sla-preferred-color colors
      
      (Option 3) Define SLA class and preferred tunnel color. If no available tunnels meet the SLA criteria, drop traffic:
      vSmart(config-sequence)# action sla-class sla-class-name preferred-color colors strict
      
      (Option 4) Define SLA class and preferred tunnel color. If no available tunnels meet the primary SLA criteria, use the tunnel color specified as backup:
      vSmart(config-sequence)# action sla-class sla-class-name preferred-color colors
      vSmart(config-sequence)# action backup-sla-preferred-color colors
      
      In each option, the first line directs matching data traffic to a tunnel interface that meets the SLA characteristics in the specified SLA class.
      
      When you specify an SLA class with no additional parameters, data traffic that matches the SLA is forwarded as long as one tunnel interface is available. 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.
      
      The preferred-color keyword configures a specific type of tunnel to use when data traffic matches an SLA class. If more than one tunnel matches the SLA, traffic is sent to the preferred tunnel. If a tunnel of the preferred color is not available, traffic is sent through any tunnel that matches the SLA class. If no tunnel matches the SLA, data traffic is sent through one of the available tunnels. 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.
      
      Use either the strict keyword or the backup-sla-preferred-color keyword to determine how to handle traffic if no tunnel matches the SLA. In a single action configuration snippet, you cannot include both  strict and backup-sla-preferred-color. 
      
      Use the strict keyword to drop the data traffic if no tunnel matches the SLA.
      
      Use the backup-sla-preferred-color keyword to define one or more tunnel types to use in case no available tunnels match the SLA. Traffic is sent out the configured tunnel if that tunnel interface is available, and if that tunnel is unavailable, traffic is sent out using another available tunnel. As with the preferred-color option, the backup SLA preferred color is loose matching.
      
      Example:
      Defines the preferred tunnel type as gold, and the backup tunnel types as biz-internet and silver:
      vSmart(config-sequence)# action sla-class voice-traffic preferred-color gold
      vSmart(config-sequence)# action backup-sla-preferred-color biz-internet silver
   4. Count the packets or bytes that match the policy:
      vSmart(config-sequence)# action count counter-name
   5. Place a sampled set of packets that match the SLA class rull into syslog files:
      vSmart(config-sequence)# action log
   6. 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.
7. 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
8. 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 
 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
         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.

Logging Frequency

If you configure a logging action, by default, the vEdge router logs all data packet headers to a syslog file. To log only a sample of the data packet headers:

vEdge(config)# policy log-frequency number

number specifies how often to to log packet headers. For example, if you configure log-frequency 20, every sixteenth packet is logged. While you can configure any integer value for the frequency, the software rounds the value down to the nearest power of 2.

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
Packet loss priority (PLP)	plp	(high | low) By default, packets have a PLP value of low. To set the PLP value to high, apply a policer that includes the exceed remark option.
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 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. 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
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 is unavailable, traffic is sent out another available tunnel. The backup SLA preferred color is a loose matching, not a strict matching	backup-sla-preferred-color color	3g, biz-internet, blue, bronze, custom1, custom2, custom3, default, gold, green lte, metro-ethernet, mpls, private1 through private6, public-internet, red, silver
Count matching data packets.	action count counter-name	Name of a counter.
Place a sampled set of packets that match the SLA class rule into the messages and syslog 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.	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 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.	action sla-class​ sla-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. If no tunnel matches the SLA, data traffic is sent through any available tunnel. 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 action sla-class sla-class-name preferred-color color 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.

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