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.
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
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.
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 ---------------------------------------------------------------------------------- 220.127.116.11 1 biz-internet gold up 7 1000 0:00:00:08 18.104.22.168 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: 22.214.171.124 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: 126.96.36.199 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.
This lesson will show a solution to this challenge that is pretty common in regular network designs with traditional Cisco IOS/IOS-XE.
Full Content Access is for Registered Users Only (it's FREE)...
- Learn any CCNA, DevNet or Network Automation topic with animated explanation.
- We focus on simplicity. Networking tutorials and examples written in simple, understandable language for beginners.