Configuring Application Aware Routing

Configuring Application Aware Routing

Posted on Jan 27, 2020 (0)

Configuring Application Aware Routing

Application-aware routing policy affects traffic which flows from Service Side VPN to Tunnel WAN side of vEdge Router.

This policy matches the application with SLA, which is data plane tunnel performance characteristic which is necessary to transfer that application data traffic and which helps to optimize the path for data traffic being transmitted by vEdge Router.

An application-aware routing policy comes under centralized data policy which is configured on vSmart controller and the vSmart will push it to all affected vEdge router. This policy contains a series of sequence filled with match-action pairs that are evaluated in order from lowest to highest sequence and when any data packet match the match conditions , SLA action is applied to packet to determine data tunnel used for transmit packet . If no match occurs and if no default SLA class is configured, packet is accepted and forwarded with no consideration of SLA.

Application-Aware policy also accepts the nonmatching traffic by default so it is said as positive policy and other type of policy are negative policies because by default it drops non matching traffic.

CLI Configure Procedure:

Create a list of SDWAN Viptela overlay sties on 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

Create SLA classes and traffic characteristics which will be used by application data traffic to match:

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

For identification of application traffic of interest create lists of applications, IP prefixes, and VPNs

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

 Create instance of an application-aware routing policy 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

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.

Create a sequence

vSmart(config-app-route-policy)# sequence number

Define match parameters for data packets:

vSmart(config-sequence)# match parameters

Define the action to take if a match occurs with any 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

The Preferred-color identify to use the specific tunnel when data traffic matches SLA class. If more than one tunnel match the SLA, traffic is sent to preferred tunnel and if preferred color tunnel is not available, traffic is sent to any available tunnel

Strict or backup-sla-preferred-color is used to determine how to handle data traffic if no tunnel matches SLA. Use strict keyword to drop traffic if no tunnel match SLA.

If a data packet does not match any condition, a default action is taken which will accept all non-matching traffic and forward it with no SLA consideration by following configuration.

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

Apply the policy to a site list:

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

SLA Class:

SLA class is set of parameter which defines maximum jitter, maximum latency, maximum packet loss which is application aware routing policy uses to select best path. Following are the parameters used:

  • Jitter milliseconds (1 through 1000 milliseconds)
  • Latency Milliseconds (1 through 1000 milliseconds)
  • Loss percentage ( o through 100 percent )

Match Parameter:

Following are the match parameter which Application-aware routing policy matches IP Prefixes, and fields in IP header.

  • Match all packets:  Omit match command
  • Application or Application families:  app-list listname
  • Group of destination prefixes: destinationdata- prefixlist listname
  • Destination port number: destinationport number  0 through 65535.
  • 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.

How Application Aware Routing policy is applied with combination with other Data policies:

When the application aware routing policy are configured along with other policies, these policies are applied to data traffic sequentially. In any vEdge Router following are the types of data policy configured.

Centralized Data Policy: by following commands like policy data-policy configuration and it is applied by apply-policy site-list data-policy

Localized Data Policy: Configured as access-list by policy access-list command and is applied to VPN interface by vpn interface access-list in.

Application-aware routing Policy: command used for is policy app-route-policy

Only one data policy and one application-aware routing policy to a single side is applied in overlay network.

For data traffic flowing from service side of router to WAN side of router, policy evolution occurs in following order.

  • Apply input access-list on LAN interface and if the traffic is not dropped due to access-list, traffic passes to Application aware routing policy for evolution
  • Apply Application aware routing policy, and if data traffic is not dropped as result of policy than is passed to data policy for evolution. If data traffic not matches and no default action is configured, it transmit it with SLA consideration
  • Apply Centralized data policy, if traffic is not dropped due to this policy then traffic is passed to output access-list for evolution
  • Apply output access-list on WAN interface, if traffic is not dropped after this access-list evolution, traffic is transmitted out on WAN interface.

For data traffic flowing from WAN side of router to Service side of router, policy evolution occurs in following order

  • Apply input access-list on WAN interface and evaluate
  • Apply and Evaluate Data policy
  • Apply and Evaluate output access-list and if passed sent to towards destination

Configure to monitor Data Plane tunnel performance:

BFD protocol which runs over data plane tunnel between vEdge Router monitors the liveness, network and path characteristics of tunnel. The information gathered by BFD is used by Application-aware routing to determine transmission performance of tunnel.

BFD sends Hello packets periodically to test the liveness and fault of a data plane 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. Once you configure Application aware routing, vEdge router uses these statistics to determine data tunnel performance

Following parameter determine Size of sliding window:

Table page 21

Let’s see how Application aware routing works by using default value:

Application-aware routing see 600 BFD hello packet (BFD hello interval * Polling interval, 1 sec * 600 = 600 BFD packets) per sliding window time period.

Application aware routing keeps these value captured by BFD packet for 1 hrs (Polling interval * multiplier: 10 mint * 6 = 60 mints)

These statistics are kept in Six separate bucket indexed from 0 to 5. Bucket 0 has latest value and bucket 5 has oldest and every 10 minutes newest values are placed in bucket 0 and values in bucket 5 are discarded.

For Every 60 minutes Application-aware routing calculates mean of loss and latency of all bucket in all sliding window and 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.

To show values of each data tunnel use show app-route stats command.

Application-Aware Routing Policy Configuration Example

 Configure steps:

  • 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

 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

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

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

Apply the policy to the desired sites in the Viptela overlay network:

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

Display the configuration changes:

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

Validate that the configuration contains no errors:

vSmart(config)# validate
Validation complete

Activate the configuration:

vSmart(config)# commit
Commit complete.


    You are will be the first.


Please login here to comment.