Tuesday, June 23, 2020

SDWAN: Application-Aware Routing

Overview

This feature ensures traffic to use the best path depending on the business requirements such as mission-critical and delay-sensitive applications. It has the ability to dynamically steer the traffic to different circuits depending on the circuit's condition which are packet loss, latency, and jitter. These are the SLA parameters that have to be set as it influences the traffic flow from the service side (which is from the local side of the vEdge) to what circuit certain traffic will prefer. It considers these factors in path selection and is possible with the use of BFD probes which are sent every second by default and performance is recorded by the vEdge.

The Application-Aware routing policy affects only traffic that is flowing from the service side to the tunnel side (WAN) of the vEdge router. This is a type of centralized data policy which is configured in the vManage and once the policy is activated it pushes it to the vSmart(s) and pushes again the policy to the vEdge routers that are configured to learn this policy.

I've created a lab that shows how this feature works.

In the scenario below, the controllers are cloud-based, and there are 3 sites: Site 100 and Site 200, and Site 10 (controllers). Sites 100 and 200 have a pair of vEdges and connected to a Layer3 switch. Two loopbacks have been configured on the Layer3 switch of both sites to test the traffic flows.

The objective is for the traffic from Site 100 to Site 200 to prefer a circuit based from the following requirements.
  • FTP traffic to 172.16.21.0/24 - Use MPLS circuit
  • HTTP/HTTPS traffic to 172.16.21.0/24 - Use Internet circuit
  • SQL traffic to 172.16.21.0/24- Use MPLS circuit
  • All other types of traffic to 172.16.21.0/24 and 172.16.22.0/24 should continue to use the default behavior which is full-mesh connectivity.

Topology



Summary Steps

  1. Define the Groups of Interest.
  2. Configure the App-Aware Policy.
  3. Apply to Site(s).
  4. Pre-verification of traffic flows.
  5. Activate the App-Aware Policy.
  6. Post-verification of traffic flows.


Define the Groups of Interest


Navigate to Configuration > Policies > Centralized Policy > Add Policy.



Define the Groups of Interest. Click Application and New Application List to define which applications will be matched in the App-Aware Policy. Select the Applications to be matched and set an Application List Name. Click Add.










Create a Site List for Site 100 and click Add. (A range of sites can also be defined and/or separated by commas e.g. 100-200, or 100,101,102.)








Create the Service VPN and click Add. (A range of sites can also be defined and/or separated by commas.)










Create the Data Prefix List and click Add. 172.16.21.0/24 will be set later as the destination prefix on the App-Aware Policy configuration. As you can see in the left-hand corner, there is also an option that says "Prefix". The difference between the two is that "Data Prefix List" is used for Traffic Data Policies (Data Plane). Configuring App-Aware Policy is on the Data Plane. While "Prefix" is used for manipulating routes in the Control Plane which we will not perform in this scenario.











Define the SLA. Enter a SLA Class List Name, and then the Packet Loss, Latency and Jitter. Click Add.












Now that we have done the Groups of Interest, next is to configure the App-Aware Policy. Click Next.

This will take you to the Configure Topology and VPN Membership page. Routes will not be manipulated in this scenario so we will skip this part. Click Next.








Configure the App-Aware Policy


In this page "Configure Traffic Rules" is where we will configure the App-Aware Policy. Under Application Aware Routing, click Add Policy and Create New.









Click Sequence Type and Sequence Rule.

The Applications, Data Prefix List, and SLA Class that were defined earlier will be matched in this policy. And for simplicity the same SLA Class is used. Also set the Policy Name and Description as required. Take note that the Application/Application Family List cannot be combined under a single sequence, so 3 different sequences have been created.

Application/Application Family List: FTP
Destination Data Prefix List: DATAPL-172-16-21-0
SLA Class: SLA
Preferred Color: mpls

Application/Application Family List: HTTP-HTTPS
Destination Data Prefix List: DATAPL-172-16-21-0
SLA Class: SLA
Preferred Color: biz-internet

Application/Application Family List: SQL
Destination Data Prefix List: DATAPL-172-16-21-0
SLA Class: SLA
Preferred Color: mpls














Leave the Default Action to its default setting.







Here's what it looks like after configuration. And click Save Application Aware Routing Policy.













The Application Aware Routing Policy has been created. Click Next.













Apply to Site(s)

This is where you will define what Sites will be using the policy. Enter a Policy Name and Policy Description, and click Application-Aware Routing. Since we have not touched the other policies there is no need to define anything under the Topology, Traffic Data, and Cflowd. 











Click New Site List and VPN List. Select SITE100 and VPN1, and click Add. Imagine if you have hundreds or thousands of sites that will use this same policy, you can define Site List objects and select it under this option. This can also be applied to multiple Service VPNs. Multiple objects of Site List and VPN List can be added.








You may click Preview to see what the configuration looks like which will be pushed by vManage to the vSmart(s). vSmart(s) will then push this policy to the vEdge(s) that have been defined. Click Save Policy to proceed to the next page.










































This takes you to the main page of Centralized Policy.







But before we activate the policy, let's first verify the traffic flows. Navigate to Monitor > Network. And select vEdge1/vEdge2 > Troubleshooting > Simulate Flows. Both are on the same site - Site 100.















Pre-verification of traffic flows

Verify traffic to Site 200 for prefix 172.16.21.0/24. For simplicity let’s just use vEdge1, but it has the same output for vEdge2. As shown in the screenshots below, all traffic going to Site 200 (for both prefixes 172.16.21.0/24 and 172.16.22.0/24) uses both MPLS and Internet circuits. Later we will see the difference after we activate the App-Aware Policy.

 Select VPN1 and the VPN1 source interface and enter the Destination IP. Leave the Application blank and click Simulate.

Normal traffic













For other types of traffic, enter or select the Application in the drop-down menu.
FTP










HTTP/HTTPS


SQL

Traffic to 172.16.22.0/24

Activate the App-Aware Policy

Return to Configuration > Policies and activate the policy. This will be pushed by vManage to the vSmart(s) and then from vSmart(s) to the vEdge(s).









Post-verification of traffic flows

Navigate back again to Monitor > Network > vEdge/vEdge2 > Troubleshooting > Simulate Flows.

Normal traffic is the same as expected. Next, we will see the traffic flow for the different applications.










FTP traffic to 172.16.21.0/24 prefers the MPLS circuit.









If compared to FTP traffic to the other prefix 172.16.22.0/24, it uses both circuits.













HTTP/HTTPS traffic to 172.16.21.0/24 prefers the Internet circuit.











SQL traffic to 172.16.21.0/24 prefers the MPLS circuit.