This lesson will show an example of a common problem with Application-aware Routing. App-route policies can only select local colors according to a pre-defined SLA class. However, what happens in point-to-multipoint topologies where one local color establishes tunnels to multiple remote colors? Let's find out our take on the problem.

Scenario Overview

An organization has a hub-and-spoke SD-WAN network where spokes have a single local color biz-internet and the hub has two local colors - gold and biz-internet. Figure 1 shows an example where vEdge-3 is a spoke and vEdge-1 is the hub.

Notice that both colors are public and not restricted, so routers establish two tunnel combinations:

• biz-internet <-> biz-internet
• biz-internet <-> gold

Scenario Requirements

You are tasked to configure the network in such a way so that it satisfies the following requirements:

• The organization wants to use Application-aware routing to track the quality of overlay tunnels and move the database traffic (VPN 4) off any link that experiences performance degradation.
• All traffic in VPN 4 must go over the overlay tunnel that meets the following SLA:
  • Loss < 1%
  • Latency < 100ms
  • Jitter < 20ms
• The hub's gold color must be a preferred entry point for the traffic coming from the spokes. 
• Only if the gold color doesn't meet SLA, the traffic should come in over the biz-internet color.
• You are not allowed to change the underlay network but you are allowed to change the overlay.

Figure 2 illustrates these requirements visually. Notice that vEdge-3 has only biz-internet color and vEdge-1 has biz-internet and gold.

Initial Topology and Configs

We will use the simple topology illustrated in Figure 2 to demonstrate a solution to this problem.

The initial configuration of each SD-WAN device can be found on the section page here. The only initial configuration change we made for this scenario is that we have changed the color of vEdge-1's ge0/1 interface to "gold" unrestricted. 

The Problem

First, let's verify that vEdge-3 has only one local color.

vEdge-3# show bfd sessions | t

SYSTEM   SITE                                     DETECT      TX                  
IP       ID    LOCAL COLOR   COLOR         STATE  MULTIPLIER  INTERVAL  UPTIME    
----------------------------------------------------------------------------------
1.1.1.1  1     biz-internet  gold          up     7           1000      0:00:00:08
1.1.1.1  1     biz-internet  biz-internet  up     7           1000      0:00:20:40

Application-aware routing has a problem with this type of topologies because an App-route policy can only select local colors. In the direction from vEdge-1 to vEdge-3, this is not an issue because vEdge-1 can track the performance of both local colors and dynamically select the one that satisfies the pre-defined SLA class. Additionally, we can configure the "gold" color as the preferred one in case both satisfy SLA. However, in the opposite direction, from vEdge-3 to vEdge-1, we have only one local color "biz-internet". How can we ensure that the App-route policy will prefer to send traffic over the biz-internet<->gold tunnel (the orange one)?

Let's think a little bit about this situation from the perspective of vEgde-3:

• If we create a new data policy that matches VPN 4 traffic and sets vEdge-1's gold tloc as next-hop - this will unconditionally force the traffic over the orange tunnel and will completely disable AAR. If the orange tunnel is available but doesn't meet SLA, traffic won't switch over to the green tunnel.
• If we create a new control policy that makes OMP prefer vEdge-1's gold tloc as next-hop - this will also unconditionally force the traffic to vEdge-1's gold tloc and will break AAR. If the orange tunnel is available but doesn't meet SLA, traffic won't switch over to the green tunnel.

Therefore, we must use another technique to ensure that spokes send traffic to the hub over the hub's gold color.

Let's go ahead and configure the policy lists and the SLA class that we will need in the Application-aware routing policy. We need a new VPN list that matches VPN 4 and two site lists - one for the hub and one for spokes.

policy
 lists
  vpn-list VPN4
   vpn 4
  !
  site-list HUB
   site-id 1
  !
  site-list SPOKES
   site-id 3-6
  !
 !
!

Then let's create a new SLA-class named DATABASE and define the tunnel quality metrics as per the scenario requirements.

policy
 sla-class DATABASE
  loss    1
  latency 100
  jitter  20
 !
!

Now let's define a simple app-route policy that matches all traffic in VPN4 and set the pre-defined SLA class along with a preferred local color gold.

policy
 app-route-policy APP-ROUTE-POLICY
  vpn-list VPN4
   // notice that there is no match statement, so it matches all traffic
   sequence 11
    action
     sla-class DATABASE preferred-color gold
    !
 !
!

Lastly, let's apply the app-route policy to both site-list.

apply-policy
 site-list HUB
  app-route-policy APP-ROUTE-POLICY
 !
 site-list SPOKES
  app-route-policy APP-ROUTE-POLICY
 !
!

Now that the application-aware routing policy is pushed to both WAN edge routers, let's go ahead and check the routing in normal circumstances (no packet loss/latency/jitter is present and all tunnels meet SLA).

We can see that in the direction from hub to spokes (from vEdge-1 to vEdge-3), gold is the preferred color.

vEdge-1# show policy service-path vpn 4 interface ge0/4 \
> source-ip 10.1.4.10 dest-ip 10.3.4.10 protocol 6 dest-port 80 all
Number of possible next hops: 1
Next Hop: IPsec
  Source: 10.10.1.1 12366 Destination: 39.3.0.3 12346 Color: gold

However, in the opposite direction, since spokes only have one local color, the traffic is load-balanced over both tunnels - biz-internet-gold and biz-internet-biz-internet.

vEdge-3# show policy service-path vpn 4 interface ge0/4 \
> source-ip 10.3.4.10 dest-ip 10.1.4.10 protocol 6 dest-port 80 all
Number of possible next hops: 2
Next Hop: IPsec
  Source: 192.168.1.3 12346 Destination: 39.3.0.1 12346 Color: biz-internet
Next Hop: IPsec
  Source: 192.168.1.3 12346 Destination: 10.10.1.1 12366 Color: biz-internet

As you can see, with the App-route policy alone, we cannot make the hub's gold color be preferred in the direction from spokes to the hub.

Okay, you can stop at this point and try to solve the requirements by yourself. Try to imagine different failure scenarios and how your solution will fit into each one. Then return to the lesson and check our solution. If you have found a better solution, please let us know in the comments section below.

The Solution

This lesson will show a solution to this challenge that is pretty common in regular network designs with traditional Cisco IOS/IOS-XE.