SD-WAN Data Policy and Application-Aware Routing

This is the feature people actually buy SD-WAN for. Application-aware routing (AAR) measures the real-time quality of every transport - loss, latency, jitter - and steers each application over the path that currently meets its needs. Voice over the low-latency link, backup over the cheap one, and if the good link degrades, voice moves automatically before users notice. No traditional WAN can do that.

This article covers centralised data policy and AAR: how traffic is matched, how SLA classes work, and how the fabric measures paths. It extends the complete SD-WAN guide. Policy and command syntax is drawn from Cisco's current 20.x documentation, clearly labelled as a documented reference.

Data policy vs control policy

The control policy shaped what routes exist and where they point - the map. Data policy operates on the map: it matches actual traffic flows and decides what happens to each one. Both are centralised (authored on the Controller and pushed to edges), but data policy is about packets, not routes.

Data policy can do several things - permit/deny (a distributed firewall), set DSCP, do NAT for direct internet access, and - the headline - application-aware routing, steering flows onto paths that meet a service-level agreement.

How AAR works: SLA classes and BFD measurement

The foundation is measurement. Every data-plane tunnel runs BFD, and SD-WAN uses it not just for liveness but to continuously measure each path's loss, latency, and jitter. Those measurements are the raw material AAR acts on.

You define SLA classes - named thresholds an application requires:

policy
 sla-class VOICE-SLA
  loss     1        ! max 1% loss
  latency  150      ! max 150 ms
  jitter   30       ! max 30 ms
 !
 sla-class BULK-SLA
  loss     10
  latency  300
 !

Then an app-route policy matches traffic and binds it to an SLA class plus a preferred colour:

 app-route-policy STEER-APPS
  vpn-list SERVICE-VPNS
  sequence 10
   match
    app-list VOICE-APPS         ! e.g. RTP, SIP
   !
   action
    sla-class VOICE-SLA preferred-color mpls
    ! if MPLS meets VOICE-SLA, use it; if not, use any path that does
   !
  !
  sequence 20
   match
    app-list BACKUP-APPS
   !
   action
    sla-class BULK-SLA preferred-color biz-internet
   !
  !
 !

The behaviour: use the preferred colour if it currently meets the SLA; if it does not, use any path that does; if none meets it, fall back per your policy (strict drop, or use the best available). The edge is constantly comparing live BFD measurements against the SLA thresholds and moving flows accordingly - per-application, in real time.

Why this is impossible on a traditional WAN

A traditional WAN routes by destination prefix and a static metric. It has no concept of "this application needs under 150 ms and this path is currently at 200 ms". It cannot measure jitter per-tunnel, it cannot classify by application, and it certainly cannot move a flow mid-session because a link degraded. AAR does all three, continuously. That capability - not the automation, not the templates - is the reason SD-WAN displaced traditional WAN for anyone carrying voice or video over mixed transports.

Verifying AAR on the edge (documented reference)

The live path measurements

Edge# show sdwan app-route stats
                          MEAN    MEAN     MEAN
REMOTE-TLOC   COLOR       LOSS%   LATENCY  JITTER  SLA-CLASS
------------------------------------------------------------------
10.0.0.12     mpls        0.0     12       2       VOICE-SLA, BULK-SLA
10.0.0.12     biz-internet 2.1    45       18      BULK-SLA

This is AAR's decision-making laid bare. The MPLS path to the remote edge has 0% loss, 12 ms latency, 2 ms jitter - it meets both SLA classes, so voice can use it. The internet path is at 2.1% loss and 45 ms - it fails VOICE-SLA (over the 1% loss threshold) but meets BULK-SLA, so backup traffic uses it but voice does not. Watch this table during a brownout and you see flows move as a path drops below its SLA.

What the edge is enforcing

Edge# show sdwan policy from-vsmart app-route-policy
from-vsmart app-route-policy STEER-APPS
 ...

Edge# show sdwan app-route sla-class
 SLA-CLASS   INDEX  LOSS  LATENCY  JITTER
 VOICE-SLA   1      1     150      30
 BULK-SLA    2      10    300      -

Direct Internet Access as a data policy action

A common data-policy action is steering internet-bound traffic straight out the local internet transport rather than backhauling it to a data centre - Direct Internet Access. In a data policy this is a match on the destination (or an application) with a nat use-vpn 0 action, sending that traffic out the local internet circuit with NAT. DIA is important enough to have its own article in this cluster; the point here is that it is expressed as a data policy, in the same framework as AAR.

Application identification

AAR is only as good as its ability to recognise applications. SD-WAN uses several methods:

NBAR2 - deep packet inspection that recognises thousands of applications by signature. The workhorse.
Custom applications - define your own by IP/port/domain for in-house apps NBAR2 does not know.
SaaS / cloud onramp - specific optimisations for Office 365, Salesforce, and other SaaS, measuring the path to the actual SaaS endpoint.

The quality of application identification is what separates a working AAR deployment from one that misclassifies traffic and steers it wrong. Getting the app-lists right (and validating them with show sdwan app-fwd statistics) is where the real deployment effort goes.

Design guidance

Start with a small set of SLA classes. Voice, video, business-critical, bulk. You do not need dozens - a handful of tiers covers most requirements and stays maintainable.
Set preferred colours deliberately. Voice preferring MPLS with internet as the SLA-meeting fallback is the canonical design. Bulk preferring internet keeps expensive MPLS free for what needs it.
Decide the fallback behaviour. When no path meets the SLA, do you drop (strict, for traffic that is useless if degraded) or use the best available (for traffic that is better late than never)? This is a per-class choice with real consequences.
Tune BFD carefully. The measurement interval and multiplier determine how fast AAR reacts and how much control-plane load the measurement generates. Too aggressive and you get flapping; too slow and users notice degradation before AAR does.
Validate application identification before trusting the steering. A misidentified application is steered by the wrong policy.

Key takeaways

AAR steers each application onto the path that currently meets its SLA, measured live via BFD (loss, latency, jitter). This is the headline reason SD-WAN replaced traditional WAN.
Data policy (centralised, on the Controller) matches actual flows and acts on them - permit/deny, DSCP, NAT/DIA, and application-aware routing. Control policy shapes routes; data policy steers packets.
You define SLA classes (loss/latency/jitter thresholds), then bind applications to an SLA class and a preferred colour: use the preferred path if it meets the SLA, else any path that does.
show sdwan app-route stats shows the live per-path measurements AAR decides on - the single most illuminating AAR command.
Application identification (NBAR2, custom apps, SaaS onramp) is what AAR acts on - get it right or steering is wrong.
Design with a few SLA classes, deliberate preferred colours, an explicit fallback per class, and carefully tuned BFD.

Next: SD-WAN localized policy - ACLs and route policies at the edge. The full cluster index lives on the SD-WAN pillar.