One of the most common use cases of centralized data policies is the ability to do traffic engineering based on applications, which is referred to as Application Pinning. For example, in dual-WAN scenarios (INET+MPLS), an organization may want to route all noncritical traffic through the best-effort Internet link while routing all business-critical apps through the expensive MPLS circuit that have guaranteed SLA. Additionally, the organization may want to drop the noncritical traffic flows in case of an Internet link failure to prevent MPLS circuit oversubscription. On the other hand, in case of an MPLS circuit failure, all business-critical apps should fall back to any available transport. Figure 1 illustrates an example where web applications represent the noncritical traffic, and VoIP applications represent critical business data.

This task would be very hard to achieve in a traditional WAN environment and would require a high volume of manual box-to-box configurations. However, in Cisco SD-WAN, this is as easy as creating and applying a centralized data policy with a couple of application-specific rules. 

A data policy that accomplishes these requirements would have the following logic:

seq 11
 match {noncritical apps}
 action {steer the traffic to the Internet, in case of a failure drop it}
!
seq 21
 match {critical apps}
 action {steer the traffic to MPLS, in case of a failure fallback to routing}

There are two data policy actions available that can be used when we want to steer traffic in a particular direction in the network:

• set local-tloc {color}
• set tloc {tloc-list}

Local TLOC selection (Loose Preference)

The first option is to specify a local TLOC color using the following command:

set local-tloc color {color}

This action depends on the VPN routing table. It instructs the WAN edge router to look at all available routes in the routing table and forward the traffic out of the ones that point to an egress interface marked with the color specified in the color argument. If such an interface is not available (because a tunnel is down, the interface is not configured, or whatever), then the traffic is routed out via any available TLOC according to the routing table. This action is referred to as Loose Preference.

If we want to specify more than one local-tloc color, we can use a local-tloc-list that specifies multiple colors.

Remote TLOC selection (Strict Preference)

The second policy action that is used to steer traffic is to set a remote tloc next-hops. 

set tloc-list {list-name} vpn {vpn-id}

This action doesn’t depend on the VPN routing table but instead mandates the router to send the traffic to the tlocs specified in the tloc-list. If, for whatever reason, there aren’t any available overlay tunnels to any of the specified tlocs, the traffic is dropped. That is why this action is referred to as a Strict Preference.

Configuring Application Pinning

The initial lab topology

The lab topology that we will use for this example is shown in figure 4 below. The overlay topology is hub and spoke with vEdges 1 and 2 acting as hub routers and the vEdges 3 - 6 being spokes.

In the previous four lab lessons, we have created a centralized data policy named DATA-POLICY-TO-SPOKES. In labs #1 and #2, we have enabled Direct Internet access (DIA) to the guest segment VPN6. Then in labs #3 and #4, we have enabled reliable Direct Internet access (DIA) to the employees in VPN 1. In this lab, we are going to work with VPN2. At the moment, there is no policy definition for that segment in the existing data policy applied to the spoke vEdges. We will configure Application pinning using Local TLOC selection and Remote TLOC selection in VPN 2.

Editing the existing data policy

In this lab example, we will create an additional section in the data policy applied to spokes (DATA-POLICY-TO-SPOKES) that will be added under VPN 2. In there, we will create a sequence that matches all packets classified as “web” traffic and sets a new next hop. For this purpose, we will first need to configure the following lists that will later be invoked in the policy definition.

policy
 lists
  !
  vpn-list VPN2
   vpn 2
  !
  tloc-list BIZ-INET-TLOCS
   tloc 1.1.1.1 color biz-internet encap ipsec
   tloc 1.1.1.2 color biz-internet encap ipsec
  !
  app-list VOIP-APPS
   app-family audio_video
  !
  app-list WEB-APPS
   app-family web
  !

Once the lists are configured, we can create a new section concerning VPN2 in the current data policy applied to spokes.

policy
 data-policy DATA-POLICY-TO-SPOKES
  vpn-list VPN2
   !
   sequence 11
    match
     app-list WEB-APPS
    !
    action accept
     set
      tloc-list BIZ-INET-TLOCS vpn 2
     !
   !
   sequence 21
    match
     app-list VOIP-APPS
    !
    action accept
     set
      local-tloc color mpls
     !
   !
   default-action accept
  !

In sequence 11, we match any application that is classified by the DPI engine as part of the app-family “WEB.” Then we set tloc next-hops, instructing the router to forward the traffic directly over any available IPsec tunnel pointing to one of the hub’s biz-internet tlocs. As we said earlier, this action referred to as Remote TLOC selection is a strict preference, which means that in case of a failure of the Internet circuit, the traffic will be dropped and will not fall back over to the MPLS transport.

In sequence 21 we match any application that is classified by the DPI engine as part of the app-family “AUDIO_VIDEO”. Then we set a local-tloc color mpls. This instructs the router to prefer any routes from the VPN routing table that point to an egress interface marked with the MPLS color. This action referred to as Local TLOC selection is a loose preference which means that in case of failure on the MPLS circuit, the traffic will fallback to any other route available in the VPN routing table.

Notice that we changed the default action at the end of the policy to “accept”. This will account for any unclassified packets (for example any FIF packets).

Testing the Remote TLOC Selection

Once the configuration is committed, we can check the forwarding path for any web application such as Facebook, youtube, and so on. 

vEdge-6# show policy service-path vpn 2 interface ge0/3 source-ip 10.6.2.4 dest-ip 0.0.0.0 protocol 6 app youtube all
Number of possible next hops: 2
Next Hop: IPsec
  Source: 39.3.0.2 12346 Destination: 39.3.0.1 12346 Color: biz-internet
Next Hop: IPsec
  Source: 39.3.0.2 12346 Destination: 39.3.0.3 12346 Color: biz-internet

You can see that the router is going to forward any web traffic to the HUB using the biz-internet transport. Because we enforced this using the Remote TLOC Selection approach, if we shut down the Internet link on vEdge-6, we will see that the traffic is going to be blackholed.

vEdge-6# conf t
Entering configuration mode terminal
vEdge-6(config)# vpn 0 int ge0/0
vEdge-6(config-interface-ge0/0)# shutdown 
vEdge-6(config-interface-ge0/0)# commit and-quit 
Commit complete.
vEdge-6# show policy service-path vpn 2 interface ge0/3 source-ip 10.6.2.4 dest-ip 0.0.0.0 protocol 6 app youtube all
Number of possible next hops: 1
Next Hop: Blackhole

Testing the Local TLOC Selection

On the other hand, if we check the forwarding decision for any traffic flows classified as part of application-family “AUDIO_VIDEO”, we are going to see that the mpls transport is preferred.