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:
- 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. - 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 - 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 - 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 - If you configure a logging action, configure how often to log packets to the syslog files:
vEdge(config)# policy log-frequency number - 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. 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 - Count the packets or bytes that match the policy:
vSmart(config-sequence)# action count counter-name - Place a sampled set of packets that match the SLA class rull into syslog files:
vSmart(config-sequence)# action log - 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.
- Create a sequence:
- 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 - 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. |
app-list list-name |
Data prefix list |
List of one or more IP prefixes. |
data-prefix-list list-name |
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 |
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 |
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 |
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. |
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 |
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:
- 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.
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.