In Traditional WAN networks, routers make forwarding decisions based primarily on link-state and routing metrics. Cisco SD-WAN allows us to configure SLA-based routing that considers performance characteristics such as packet loss, latency, and jitter when making forwarding decisions. This is done using Application-aware Routing policies (App-route). However, AAR policies are one of the hardest topics of Cisco SD-WAN to learn because they represent a technique to route data traffic across the WAN that network engineers have typically not used before. That is why in this lesson we are going to deep-dive into the different App-route policy actions that Cisco SD-WAN offers as of the latest release (20.6.1).

The structure of an App-route Policy

There are four key parts to the Application-aware Routing policy process:

Step 1: Creating the App-route policy - As with all other centralized policy types, the first thing is always to define the policy via vManage's GUI or for practicing purposes directly through the CLI on vSmart. The basic building blocks of an application-aware routing policy are as follow:

1. VPN-list that specifies which vpn-ids the policy will affect;
2. App-list that matches the applications of interest;
3. App-probe-class that specifies the BFD dscp value to be used when probing the WAN (optional);
4. SLA-class that specifies the maximum packet loss, latency, and jitter;
5. The match-action rules of the App-route policy itself;
6. A site-list that specify which sites will receive the AAR policy;

The exact order in which we configure each of these components is irrelevant from the point of view of vManage's GUI or vSmart's CLI parser. However, from network engineers' point of view, a logical order would be to first define all lists that would be later invoked in the match-action rules of the AAR policy. Once all necessary lists are defined, the logic of the AAR policy itself would be as follow:

app-route-policy {name}
  vpn-list {name}
   sequence {number}
    match 
     applications based on L3/L4 info or DPI engine
    !
    action 
     choose outgoing tunnel based on SLA
 !

Step 2: Pushing the policy down to vEdges - Once the App-route policy is defined and activated, vManage pushes it to the vSmart controller. The policy becomes part of vSmart's running-config. vSmart then sends the policy via OMP updates to all vEdges that are matched by the site-ids listed in the applied site-list. The Edge routers that receive the policy execute it in memory, which means that they do not store the app-route policy in their permanent configuration files. Upon reboot, each vEdge needs to first establish the control-plane connection to the SD-WAN controllers and receive the latest applicable version of the current AAR policy.

Step 3: Measuring the performance of overlay tunnels - In Cisco SD-WAN, once a vEdge router establishes an overlay tunnel, it automatically starts a BFD session with the remote peer. This behavior cannot be disabled or changed. The WAN edge router then uses this BFD session to monitor the link-state of the tunnel and also measure performance characteristics such as packet loss, jitter, and latency;

Step 4: Mapping applications to overlay tunnels that meet SLA - The BFD reports the performance metrics of each overlay tunnel to the applied AAR policy. The policy evaluates these metrics against the configured SLA threshold and makes SLA-based forwarding decisions.

Understanding the AAR policy actions

One of the most difficult things when it comes to Application-aware Routing policies is to understand the different actions that a WAN edge router could take in case of an out-of-threshold condition.

SLA-class

The simplest action that we can configure in an AAR policy sequence is an SLA-class with no additional parameters as highlighted in the output below. The data traffic that matches the sequence will be ECMP-forwarded across all overlay tunnels that match the SLA class thresholds.

policy
 app-route-policy APP-ROUTE-POLICY
  vpn-list VPN1
   sequence 11
    match
     dscp 46
    !
    action
     sla-class VOICE-SLA
 !

If no overlay tunnel matches the SLA thresholds, the data traffic is ECMP-forwarded across all available tunnels.

Preferred-Color

In cases where multiple overlay tunnels meet the SLA thresholds, we may want to specify preferred tunnels. This is done using the preferred-color [color] parameter. When this option is used, the software first tries to forward the data traffic through the preferred color, if it meets the SLA. If the preferred tunnel does not meet the SLA, the data traffic is sent through any overlay tunnel that matches the SLA class.

policy
 app-route-policy APP-ROUTE-POLICY
  vpn-list VPN1
   sequence 11
    match
     dscp 46
    !
    action
     sla-class VOICE-SLA preferred-color mpls
 !

If no tunnel meets the SLA, data traffic is ECMP-forwarded across any available tunnel. Notice that the preference-color option is a loose matching. This means that the data traffic is always forwarded, no matter whether the preferred-color tunnel meets the SLA or not.

Multiple Preferred-Color

We can specify more than one preferred color as shown in the output below. When there are multiple preferred colors configured, the software tries to load-balance the data traffic across all preferred colors that meet the SLA.

policy
 app-route-policy APP-ROUTE-POLICY
  vpn-list VPN1
   sequence 11
    match
     dscp 46
    !
    action
     sla-class VOICE-SLA preferred-color mpls lte
 !

Again, if no preferred color meets the SLA, the data traffic is ECMP-forwarded across all available tunnels.

Strict

The strict option tells the vEdge router to simply drop the data traffic if no tunnel meets the SLA class.

policy
 app-route-policy APP-ROUTE-POLICY
  vpn-list VPN1
   sequence 11
    match
     dscp 46
    !
    action
     sla-class VOICE-SLA strict
 !

Many network engineers ask themselves the question - Why would anybody need to drop traffic when the latency of the WAN jumps above the threshold? Well, there are many real-time systems where the timely delivery of data is critical. For example, radars and air-traffic surveillance systems make calculations based on the current position of an airplane in space. However, an airplane flies at a speed of 1000km/h. If the exact coordinates of a plane are received with 0.5 sec delay, they are useless, because the plane is not there anymore. Furthermore, when the system receives coordinates of the same plane via multiple radars, out-of-sync data could actually harm more than help. Therefore, for such systems, it is better to not receive the data when the latency of the WAN jumps above the threshold. That’s one example of why this option exists. However, 99.9% of the time, it won’t be used.

Fallback-to-best-path

Fallback to the best path is a new AAR action that basically tells the WAN edge router "if no tunnel meets the SLA-thresholds, choose the best of the worst tunnels based on pre-defined criteria".  

policy
 app-route-policy APP-ROUTE-POLICY
  vpn-list VPN1
   sequence 11
    match
     dscp 46
    !
    action
     sla-class VOICE-SLA fallback-to-best-path
 !

Then under the applied sla-class, we define what the sorting criteria would be. If we configure it to be latency for example, in case no tunnel meets the SLA-class, the vEdge router will choose the overlay tunnel that has the lowest latency.

policy
 sla-class VOICE-SLA
  loss            2
  latency         250
  jitter          25
  app-probe-class VOICE-PROBE-CLASS
  fallback-best-tunnel
   criteria latency
!

Backup-sla-preferred-color

The backup preferred color is a parameter that tells the WAN edge router where to forward the data traffic when no tunnel meets the SLA thresholds. Similar to the preferred-color action, the backup-SLA-preferred-color is considered to be a loose matching which means that if the configured color is not available, the router will forward the traffic through any available color.

policy
 app-route-policy APP-ROUTE-POLICY
  vpn-list VPN1
   sequence 11
    match
     dscp 46
    !
    action
     sla-class VOICE-SLA preferred-color mpls
     backup-sla-preferred-color metro-ethernet
 !

The main difference between preferred-color and backup-sla-preferred-color is that:

• preferred-color – matched data traffic is pinned to a transport color (or colors) as long as the overlay tunnels meet the SLA thresholds;
• backup-sla-preferred-color – matched data traffic is pinned to a transport color ONLY when no tunnel meets the SLA thresholds.

Notice that in a single match-action rule, we can't configure both the strict and backup-sla-preferred-color actions.

Default Action

Unlike centralized data policies where the default action is to drop all packets, the default action for application-aware routing policies is to accept and transmit the data traffic based on the VPN routing table, with no SLA-based considerations.

policy
 app-route-policy APP-ROUTE-POLICY
  vpn-list VPN1
   sequence 11
    match
     dscp 46
    !
    action
     sla-class VOICE-SLA
    !
    default-action sla-class DEFAULT-SLA
 !

However, Cisco SD-WAN allows us to define a "default" sla-class at the end of an Application-aware Routing Policy as shown in the output above. This feature is useful in cases where we want to implement some baseline SLA requirements. For example, let's say that we do not want to forward any data traffic through a tunnel that experiences latency higher than 300ms. We define a sla-class named DEFAULT-SLA and apply it under the default action for the app-route policy. Then when the data traffic that is not matched at any policy rule hits the default action, the router will first try to forward the traffic through the tunnels that have latency lower than 300ms (tunnels that meet the SLA). If no overlay tunnel meets the SLA class configured in the default action, the WAN edge router will forward the data traffic through any of the available tunnels load-balancing across any equal paths.

Notice that we cannot configure the strict option under the default-action.

Summary of all App-route Actions

The following flow chart illustrates all App-route actions that we have seen so far:

Notice that each app-route action leads to the data traffic being forwarded. The only exception is the strict keyword which explicitly drops the traffic if no overlay tunnel meets the SLA requirements.