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
- Define the Groups of Interest.
- Configure the App-Aware Policy.
- Apply to Site(s).
- Pre-verification of traffic flows.
- Activate the App-Aware Policy.
- 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
SLA Class: SLA
Preferred Color: mpls
Application/Application
Family List: HTTP-HTTPS
Destination Data
Prefix List: DATAPL-172-16-21-0
SLA Class: SLA
SLA Class: SLA
Preferred Color: biz-internet
Application/Application
Family List: SQL
Destination Data
Prefix List: DATAPL-172-16-21-0
SLA Class: SLA
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.



































