Cisco SD-WAN App-Aware Routing & QoS: SLA Classes, Data Policy & Cloud OnRamp

Most engineers think…

Most engineers think "if BFD says the tunnel is up, the link is fine — and if I want voice on the good link, I just set the preferred colour." So they ship a one-line policy and assume voice is protected.

Wrong — and the helpdesk tickets will tell you. "Up" only proves the pipe exists; it says nothing about loss, latency or jitter. An MPLS circuit at 4% loss is up and useless for voice. Real AAR is an SLA class (the thresholds), a match (which traffic), a preferred colour (the first choice) AND a deliberate fall-through action (what to do when nothing meets the SLA — ECMP, a named backup colour, or strict drop). Skip any one of those and the policy quietly does the wrong thing.

① The problem AAR solves — "up" is not "good enough"

Here is the trap that catches every new SD-WAN engineer. Your branch in Pune has two transports — an MPLS circuit and a cheap biz-internet link. BFD says both tunnels are up. A user complains that Microsoft Teams audio is robotic. You check — the tunnel is up. So what is wrong? The MPLS circuit is dropping 4% of packets during a carrier brownout. It is alive but useless for voice.

That gap — between "the link works" and "the link is good enough for THIS application" — is exactly what App-Aware Routing closes. AAR doesn't just check liveness; it continuously measures loss, latency and jitter on every tunnel and forwards each app on a path that meets that app's SLA. Voice gets a clean path; a backup file copy can tolerate the lossy one.

👉 So far: BFD liveness ≠ application quality. Next: the dual-SIM analogy that makes AAR click, then how the measurement loop actually runs.

The analogy every Indian engineer gets instantly: dual-SIM failover on your phone. Both SIMs show full signal bars (both "up"). But you start a UPI payment and SIM 1's data is crawling — packets are there, but slow and lossy. A smart phone would notice the payment is timing out and push it over SIM 2. AAR is that smart phone for your branch: it doesn't care that the bars are full, it cares whether this transaction is actually getting through cleanly. The second analogy: a toll expressway vs the service road running beside it. The service road is "open" (up), but it's potholed and slow. For an ambulance (voice) you want the smooth expressway even if it costs a toll; for a goods truck (a backup job) the bumpy free road is fine.

Figure 1 — AAR decision loop — measure, compare to SLA, pick the path that passes

Follow the orange dashed probes from the edge to the measure-and-compare box, then the green arrow to the chosen path. The MPLS tunnel is UP (red) but fails the voice SLA; the Internet tunnel meets it (green), so voice rides Internet.

How does AAR know a tunnel is lossy? BFD does double duty. Besides detecting liveness, the BFD hello packets (default interval 1000 ms) carry timestamps, so the edge measures round-trip latency, jitter and packet loss on every tunnel. At each poll interval (default 10 minutes), the edge averages those numbers — by default over the last 6 poll intervals (the multiplier) — and re-evaluates which tunnels meet each SLA class. Those defaults are slow on purpose (stability over twitchiness), and they are the #1 thing you tune for voice.

Four ideas that anchor the whole lesson

Tap each card — these are the vocabulary hooks you'll reuse in every later section.

📶

Up ≠ good enough

tap to flip

BFD liveness only proves the pipe exists. Loss/latency/jitter decide if it's usable. AAR routes on usable, not on alive.

📏

SLA class

tap to flip

A named bundle of max loss, latency and jitter — e.g. VOICE = 2% loss / 150 ms / 30 ms. The yardstick a tunnel must pass.

🎯

Match → action

tap to flip

Match the app (app list / DSCP / prefix), map it to an SLA class, set a preferred colour and a fall-through. The whole policy in one breath.

📲

Dual-SIM brain

tap to flip

AAR is your phone silently moving a stuck UPI payment to the other SIM — it watches the transaction, not the signal bars. So: route on quality.

Quick check · Q1 of 10

Rahul at Infosys says: "Both my tunnels show BFD up, but voice is choppy on the MPLS path. AAR is configured. Why might voice still be stuck on the bad link for several minutes?"

a) AAR only works on Internet links, never MPLSb) The default 10-minute poll interval means AAR is slow to react — tune it down for voicec) BFD must be disabled for AAR to rund) Voice can't be matched by AAR at all

Correct: b. The default poll interval is 10 minutes and AAR averages over 6 intervals, so reaction to a brownout is slow by design. For voice you tune the poll interval down (or use Enhanced AAR) so the SLA breach is noticed in seconds. AAR works on any transport; BFD must be RUNNING (it feeds AAR); and voice is a prime AAR match target.

Pause & Predict

Predict: if you crank the poll interval all the way down to catch brownouts instantly, what new problem are you likely to create? Type your guess.

Answer: Flapping and false positives. A very short interval averages over only a handful of BFD hellos, so one momentary blip can breach the SLA and bounce traffic between tunnels — hurting the very voice calls you wanted to protect. Cisco's own guidance warns that a 10-second poll with 1-second BFD hellos uses just ~10 samples, weakening the loss/latency/jitter calculation. The modern fix is Enhanced AAR, which measures from real data-plane packets and adds SLA dampening instead of you fighting the timers by hand.

② SLA classes + app-route policy — thresholds, match, colours

AAR is built from three pieces: a SLA class list (the thresholds), an app-route policy (match traffic → map to the class → set colours), and the action for when reality doesn't cooperate. You build all of it inside the centralized policy on the Controller, then push it. The vManage path to define the class is worth memorising: Configuration > Policies > Centralized Policy > Custom Options > Lists > SLA Class > New SLA Class List.

An SLA class is just three numbers with a name. A sensible VOICE class might be loss ≤ 2%, latency ≤ 150 ms, jitter ≤ 30 ms. A BUSINESS-DATA class is looser — loss ≤ 5%, latency ≤ 300 ms. A tunnel "meets" the class only if it satisfies all the thresholds you set (leave a value blank and it isn't checked). Cisco also ships predefined classes you'll recognise from QoS: realtime, full-mesh, low-loss-low-latency.

SD-WAN Controller (vSmart) — define the SLA class + an app-route sequence (CLI add-on)

policy
 sla-class VOICE_SLA
  latency 150
  loss    2
  jitter  30
 !
 app-route-policy STEER_VOICE
  vpn-list CORP_VPNS
  sequence 10
   match
    app-list MS_TEAMS
   !
   action
    sla-class VOICE_SLA preferred-color biz-internet
    backup-sla-preferred-color mpls
   !
  !
 !
!

Expected output

% SLA class "VOICE_SLA" created (loss 2 / latency 150 / jitter 30)
% app-route-policy "STEER_VOICE" seq 10: match app-list MS_TEAMS
%   action: prefer biz-internet if SLA met; fall back to mpls only if NO tunnel meets SLA
Configuration committed. Apply to sites via apply-policy site-list BRANCHES.

Notice the match options in that sequence. You don't have to match by application name — you can match by DSCP (e.g. EF for voice), by source/destination prefix, by DSCP plus app — whatever identifies the traffic cleanly. App lists ride on NBAR2 deep-packet recognition, so "MS_TEAMS" really does mean Teams, not just a port number.

🖥️ This is the screen you'll build the SLA class on — vManage → Configuration → Policies → Centralized Policy → Custom Options → Lists → SLA Class → New SLA Class List. Real wizard fields. (Recreated for clarity — your console matches this.)

vmanage.lab.local · Configuration · Policies · Centralized Policy · Lists · SLA Class

SLA Class List Name

VOICE_SLA

Loss (%)

Latency (ms)

150

Jitter (ms)

App Probe Class

None (BFD measured)

Fallback Best Tunnel

Off

Add → Save Policy

Now the part exam writers love: the four actions that decide what happens when tunnels do — or don't — meet the SLA. They are a fall-through ladder. sla-class alone: ECMP-forward across every tunnel that meets the class. preferred-color: try the named colour first if it meets the SLA, otherwise any tunnel that does. backup-sla-preferred-color: a named colour used only when no tunnel meets the SLA. strict: if no tunnel meets the SLA, drop the packet. The trap: by default (no strict), when nothing meets the SLA, traffic is ECMP'd across all tunnels anyway — degraded but delivered.

Figure 2 — The four SLA actions as a fall-through ladder

Read top to bottom: preferred colour first, then any SLA-met tunnel, then the 'nobody qualifies' branch. Only strict ever drops. You cannot combine strict and backup-sla-preferred-color in one action.

Common mistake — strict drops your voice and you blame the circuit

Symptom: during a brief brownout, voice goes completely silent — not choppy, silent — and recovers by itself. Cause: someone set the action to strict, so when no tunnel met the SLA for a poll interval, AAR dropped the packets instead of using a degraded path. Fix: use strict only when a degraded path is genuinely worse than no path (rare). For voice, prefer backup-sla-preferred-color so the call survives on a fallback colour. Remember you can't set both strict and backup in the same action.

Pause & Predict

Predict: you match Salesforce by DSCP EF and bind it to a VOICE_SLA class, but the rule never seems to act on Salesforce. What's the most likely reason the match fails? Type your guess.

Answer: Salesforce isn't marked EF. EF (DSCP 46) is the voice marking — Salesforce is interactive data, not real-time voice, so it almost never carries EF at the WAN edge. Your match condition is looking for a value the traffic doesn't have, so the sequence is skipped. Fix: match Salesforce by app-list (NBAR2) or its prefix, and reserve the EF-matched VOICE_SLA sequence for traffic that's actually marked EF (or that you re-mark to EF on ingress). Match on something the packet really carries.

Quick check · Q2 of 10

Sneha at TCS needs Webex to ride MPLS when MPLS is clean, but to keep flowing on biz-internet even when NEITHER link meets the SLA (a degraded call beats a dropped one). Which action does she set?

a) strict, so bad packets are droppedb) sla-class only, no coloursc) preferred-color mpls with backup-sla-preferred-color biz-internetd) A localized data policy

Correct: c. preferred-color mpls uses MPLS while it meets the SLA; backup-sla-preferred-color biz-internet pins traffic to biz-internet only when NO tunnel meets the SLA — exactly "degraded beats dropped". strict would drop the call; sla-class-only ECMPs without honouring her MPLS preference; a localized data policy is the wrong tool (this is centralized AAR).

③ Data policy vs AAR — engineering the path by hand

AAR picks the best of the tunnels you already have. Centralized data policy is the other tool: it engineers the path by hand, regardless of SLA. Think of AAR as "send voice on whichever lane is cleanest" and data policy as "force ALL guest traffic out the local ISP, no matter what."

The headline data-policy use cases an L2 engineer meets daily: Direct Internet Access (DIA) — send branch internet/guest traffic straight out the local ISP instead of hairpinning to a data centre (the dabbawala dropping a tiffin at the nearest station instead of routing every box through Churchgate). NAT — translate that DIA traffic to the WAN edge's public IP. Service chaining / service insertion — steer flows through a firewall or IPS sitting in a service VPN before they leave. set-TLOC / local-TLOC-color — pin a flow to a specific transport, overriding the natural path.

SD-WAN Controller (vSmart) — guest VPN DIA with NAT via centralized data policy

policy
 data-policy BRANCH_DIA
  vpn-list GUEST_VPN
  sequence 20
   match
    source-ip 10.20.4.0/24
   !
   action accept
    nat use-vpn 0
   !
  !
  default-action accept
 !
!
apply-policy
 site-list BRANCHES
  data-policy BRANCH_DIA from-service
 !
!

Expected output

% data-policy "BRANCH_DIA" seq 20 matches guest subnet 10.20.4.0/24
%   action accept + nat use-vpn 0  -> exit locally via transport VPN 0 (DIA)
% applied from-service to site-list BRANCHES
Guest traffic now egresses the branch ISP (203.0.113.10) instead of the DC.

So when AAR and data policy both touch a flow, which one wins? The order of operations on a WAN Edge is: local ingress policy → app-aware routing → centralized data policy. AAR is evaluated first, but a data policy that matches the same flow can overwrite AAR's path decision. The important nuance Cisco documents: when AAR's preferred colours don't meet the SLA but some data-policy colours do, those are used; and if no transport colour meets the SLA, the data-policy colours always take precedence. In plain words — design them as a team, not as rivals.

Figure 3 — AAR vs data policy — different jobs, and who overrides whom

Left = AAR (pick the SLA-clean path among existing tunnels). Right = data policy (force traffic out a chosen exit/service). The amber bar at the bottom is the order of operations and the override rule — memorise it for 300-415.

▶ Follow one Teams packet through AAR, then a guest packet through data policy

Watch the WAN Edge make two different decisions on two different flows, step by step. Press Play for the healthy path, then Break it to see the failure.

① ClassifyTeams voice matched by app-list; guest HTTP matched by data policy

▼

② AAR checkvoice: biz-internet meets VOICE_SLA → preferred-color picks it

▼

③ Data policyguest: data-policy nat use-vpn 0 forces local DIA exit, overriding natural path

▼

④ Forwardvoice → clean Internet tunnel; guest → local ISP 203.0.113.10

Press Play to step through the healthy path. Then press Break it.

Aditya at HCL faces this

Aditya, an L2 engineer, set a beautiful AAR policy to keep Salesforce on the low-latency biz-internet colour. But a separate data policy he forgot about is sending ALL of that VPN's traffic out the MPLS TLOC — and Salesforce keeps using MPLS no matter what AAR says.

Likely cause

Order of operations. AAR is evaluated first, but the centralized data policy matches the same flow and OVERWRITES the path decision with its set-TLOC / colour action. Two correct policies, applied to the same traffic, fighting each other.

Diagnosis

He checks what the edge actually received from the Controller and which policy is acting on the flow, rather than assuming AAR is the only thing touching it.

vManage → Monitor → Devices → (branch cEdge) → Real Time → 'Policy From vSmart' and 'App Route Statistics'; CLI: show sdwan policy from-vsmart and show sdwan policy service-path vpn 10 interface ... source-ip ... dest-ip ...

Fix

Scope the data policy so it doesn't match the Salesforce flow (tighten its match, or sequence Salesforce to 'accept' with no TLOC override before the catch-all), letting AAR's SLA decision stand for that app.

Verify

show sdwan policy service-path now returns the biz-internet TLOC for the Salesforce 5-tuple, and App Route Statistics shows Salesforce on the SLA-met colour; guest/other traffic still follows the intended data policy.

Pause & Predict

Predict: an architect says "just put everything in data policy, skip AAR — it's simpler." What capability do they lose? Type your guess.

Answer: Live SLA-driven path selection. Data policy is static traffic engineering — it forces a path but has no idea whether that path currently meets loss/latency/jitter. The moment the chosen circuit browns out, data policy keeps pinning traffic to the bad link. AAR is the part that watches quality in real time and moves the app off a degraded path. You want both: AAR for quality, data policy for deliberate steering (DIA, NAT, service chaining).

Quick check · Q3 of 10

Meera at Airtel sees a guest flow that AAR was supposed to leave alone, but a centralized data policy is NATting it out the local ISP. Both policies match the flow. Which statement about the order of operations is correct?

a) AAR is evaluated first, then data policy — and the data policy can overwrite AAR's path decisionb) Data policy is evaluated first and AAR always overrides it afterwardsc) AAR and data policy never touch the same flowd) Localized policy is evaluated after data policy and wins

Correct: a. The edge order is local ingress → AAR → centralized data policy; AAR runs first but a matching data policy overwrites the path (here the DIA/NAT action). Data policy is not first; AAR does not always override after; both clearly can match the same flow; localized policy runs at ingress, not last.

④ QoS on the edge + Cloud OnRamp

AAR chooses which tunnel; QoS decides what happens inside that tunnel when it's congested. They're partners: AAR avoids the lossy link, QoS protects voice on the link you're actually using. Edge QoS is four moves in order — classify (map traffic to a forwarding class), queue (drop it in the right hardware queue), schedule (decide who gets served first), shape (cap the rate per transport so you don't overrun the circuit).

The hardware facts to memorise: every interface has 8 hardware queues, numbered 0–7. Queue 0 is always the Low-Latency Queue (LLQ) — that's where voice goes, and it's serviced first (priority). Queues 1–7 carry user-defined classes and are scheduled by default with WRR. You build this with localized data policy (the QoS map + class maps), then bind it to the interface, and you can shape per transport so a 50 Mbps broadband link is never overrun. On a hub, per-tunnel QoS shapes each spoke separately so one busy branch can't starve the rest.

WAN Edge (cEdge IOS-XE) — verify AAR + QoS are doing their job

show sdwan app-route stats remote-system-ip 10.0.0.12
show sdwan bfd sessions
show policy-map interface GigabitEthernet0/0/1

Expected output

app-route stats: tunnel biz-internet  loss 0.2%  latency 22ms  jitter 4ms  -> VOICE_SLA: met
                 tunnel mpls         loss 4.1%  latency 19ms  jitter 6ms  -> VOICE_SLA: NOT met
bfd sessions: 10.0.0.12  biz-internet  up   10.0.0.12  mpls  up   (both UP — only SLA differs)
policy-map GigabitEthernet0/0/1: class VOICE (Q0/LLQ) 0 drops; class BULK (Q5/WRR) 318 drops (shaped)

Last piece: Cloud OnRamp. Cloud OnRamp for SaaS continuously probes the path to apps like Microsoft 365 and Webex from each exit (DIA at the branch vs via the data centre/gateway) and steers each app out the lowest-loss, lowest-latency exit — AAR's quality idea, extended to the cloud's front door. Cloud OnRamp for Multicloud automates SD-WAN gateways into AWS, Azure and GCP so branches reach cloud-hosted apps over the fabric instead of the open internet. You enable both from Configuration > Cloud OnRamp in vManage.

Figure 4 — Brownout before/after — a Teams call hops off lossy MPLS to broadband in ~1s

Left: without AAR the call stays pinned to MPLS at 4% loss and breaks up. Right: AAR detects the SLA breach and moves the call to clean broadband — with Enhanced AAR, in about a second.

Worth knowing for a 2025–2026 deployment: classic AAR reacts on the slow BFD poll cycle (minutes). Enhanced Application-Aware Routing (EAAR), introduced around 20.12, measures performance from real data-plane packets (not just control-plane BFD), adds a small metadata header (so watch MTU), and includes SLA dampening to stop flapping — giving sub-minute, even ~1-second, reroutes for voice. You can spot EAAR-enabled sessions with show sdwan bfd sessions alt. This is the modern answer to "AAR is too slow for voice" — instead of fighting the poll timers, you let inline measurement do it.

Figure 5 — AAR & QoS cheat-sheet — one card for the exam and the SOC floor

Your one-glance map of everything in this lesson — keep it open while you build your first policy, and revisit it before any SD-WAN interview or the 300-415.

Pro tip — the mental model that sticks

For any app-routing task ask three questions: (1) What's the SLA? loss/latency/jitter the app tolerates → that's your SLA class. (2) How do I match it? app-list / DSCP / prefix. (3) What if no path qualifies? ECMP (default), a named backup colour, or strict-drop — pick on purpose. Then separately: AAR chooses the tunnel, QoS protects traffic inside it, data policy engineers exits (DIA/NAT/service-chain), and Cloud OnRamp extends quality to SaaS. Almost every config maps onto that grid.

Common mistake — DSCP gets re-marked and your QoS classifies wrong

Symptom: voice is marked EF at the LAN but lands in the default queue (Q1–7) on the WAN, getting dropped under load. Cause: the tunnel/transport re-marked or didn't trust the DSCP, so your QoS class-map never matched EF. Fix: confirm the edge trusts/preserves the inner DSCP (and that the SLA/QoS match uses the value you actually see on the WAN side). No queue can prioritise traffic it never classified.

Prove you've got the AAR + QoS model

Take a real ask — "keep Teams clean across both transports and don't let backups starve voice." Name the SLA class (VOICE: 2%/150ms/30ms), the match (app-list MS_TEAMS or DSCP EF), the action (preferred-color + backup-sla, not strict), the QoS (voice in Q0/LLQ, backups shaped in a WRR queue), and where you'd verify (show sdwan app-route stats, show policy-map interface). If you can do that cold, you're ready for the 300-415 and the branch.

Back: Centralized Policy (where AAR & data policy live)Next: Security, DIA & Troubleshooting

Quick check · Q4 of 10

Karthik at Flipkart must guarantee voice is served first even when a 100 Mbps branch link is saturated by a backup job. Which QoS placement is correct?

a) Put voice in any WRR queue (1–7) with a high weightb) Put voice in Queue 0 (the Low-Latency Queue) and shape the link so backups can't overrun itc) Disable QoS and rely on AAR aloned) Mark backups as EF so they share voice's queue

Correct: b. Queue 0 is always the Low-Latency Queue and is serviced first (priority) — that's where voice belongs; shaping caps the link so the backup can't starve it. A WRR queue doesn't give voice strict priority; AAR alone picks the tunnel but doesn't protect voice from congestion inside it; marking backups EF would put bulk traffic into the priority queue and ruin voice.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from Cisco SD-WAN docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

🧠 In your own words

Type one line: In one line, why can a tunnel be "up" yet still need AAR to move your voice traffic off it? Then compare to the expert version.

Expert version: Because "up" (BFD liveness) only means packets cross the tunnel — it doesn't measure loss/latency/jitter, so an up-but-lossy link (e.g. 4% loss during a brownout) destroys voice; AAR measures those metrics and reroutes voice to a tunnel that actually meets the SLA.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on AAR & QoS at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time.

📖 Glossary

App-Aware Routing (AAR): Centralized-policy feature that forwards each app onto a tunnel currently meeting that app's SLA (loss/latency/jitter), not just any 'up' tunnel.
SLA class: A named set of max loss, latency and jitter a tunnel must satisfy to carry a class of traffic; leave a value blank and it isn't checked.
App-route policy: The centralized policy that matches traffic (app-list/DSCP/prefix), maps it to an SLA class, and sets preferred colours and a fall-through action.
Preferred colour: The first-choice transport an app uses IF it meets the SLA; otherwise AAR falls through to any SLA-met tunnel.
backup-sla-preferred-color: A named transport used ONLY when no tunnel meets the SLA — pins traffic to a fallback instead of ECMPing everywhere.
strict (AAR action): Drops the packet when no tunnel meets the SLA; the only AAR action that drops. Cannot be combined with backup-sla in one action.
BFD: Bidirectional Forwarding Detection — per-tunnel hello probe (default 1000 ms) that detects liveness AND feeds AAR's loss/latency/jitter measurements.
Poll interval / multiplier: AAR averages BFD measurements over the poll interval (default 10 min) across the last 6 intervals before re-deciding; tune down for voice.
Enhanced AAR (EAAR): From ~20.12: measures from real data-plane packets (not just BFD), adds a metadata header (watch MTU) and SLA dampening for sub-minute reroutes.
Centralized data policy: Controller-pushed policy that engineers the path by hand — DIA, NAT, service chaining, set-TLOC, drop/count/mirror; can overwrite AAR's choice.
DIA (Direct Internet Access): Send branch internet/guest traffic straight out the local ISP (often with NAT) instead of hairpinning to a data centre.
QoS queues / LLQ: Each interface has 8 hardware queues (0–7); Queue 0 is the Low-Latency Queue serviced first (voice); Q1–7 use WRR by default.
Cloud OnRamp: SaaS variant probes the best exit to apps like M365/Webex; Multicloud variant automates SD-WAN gateways into AWS/Azure/GCP.

📚 Sources

Cisco Catalyst SD-WAN Policies Configuration Guide, IOS XE 17.x — "Application-Aware Routing" (SLA class = max loss/latency/jitter; BFD probes; poll interval default 10 min averaged over 6 intervals; actions sla-class / preferred-color / backup-sla-preferred-color / strict; strict and backup cannot be combined). cisco.com/c/en/us/td/docs/routers/sdwan/configuration/policies/ios-xe-17/policies-book-xe/application-aware-routing.html
Cisco Catalyst SD-WAN Policies Configuration Guide — "Enhanced Application-Aware Routing" (EAAR from ~20.12: inline data-plane measurement, metadata header/MTU, SLA dampening; show sdwan bfd sessions alt). cisco.com/c/en/us/td/docs/routers/sdwan/configuration/policies/ios-xe-17/policies-book-xe/m-enhanced-application-aware-routing.html
Cisco Catalyst SD-WAN Forwarding and QoS Configuration Guide, IOS XE 17.x — "Forwarding and QoS" + "Per-Tunnel QoS" (8 hardware queues 0–7, Queue 0 = LLQ, default WRR, localized policy classify/schedule/shape, per-tunnel QoS hub on IOS XE). cisco.com/c/en/us/td/docs/routers/sdwan/configuration/qos/ios-xe-17/qos-book-xe/forwarding-qos.html
Cisco Community — "Understand BFD Protocol Relationship with App-Aware Routing" (BFD detects link failure and gathers loss/latency/jitter; poll-interval vs BFD hello sampling trade-off; tuning the poll interval for voice). community.cisco.com / cisco.com/c/en/us/support/docs/routers/sd-wan/221604-understand-bfd-protocol-relationship-wit.html
NetworkAcademy.IO (CCIE Enterprise / SD-WAN) — "Configuring Application-Aware Routing Policies" & "AAR alongside Data Policy" (action semantics; order local-ingress → AAR → data policy; data policy can overwrite AAR; when no colour meets SLA, data-policy colours take precedence). networkacademy.io/ccie-enterprise/sdwan/aar-alongside-data-policy
Daniels Networking Blog (lostintransit.se) — "Catalyst SD-WAN Enhanced Application Aware Routing" (EAAR 20.12, ~10–60s aggressive reaction, dampening, 12-byte metadata header). lostintransit.se/2024/02/19/catalyst-sd-wan-enhanced-application-aware-routing/
Cisco ENSDWI 300-415 exam blueprint — Domain: Policies (configure app-aware routing, SLA classes, centralized data policy, QoS, Cloud OnRamp). learningnetwork.cisco.com/s/ensdwi-exam-topics

What's next?

You can now steer apps by SLA and shape them with QoS. The final lesson ties it together with branch security, Direct Internet Access hardening, and a real troubleshooting playbook for when control connections, OMP or AAR misbehave.

Next · Security, DIA & Troubleshooting → Practice on exam.techclick.in →

Cisco SD-WAN App-Aware Routing & QoS: — SLA Classes, Data Policy & Cloud OnRamp

🎯 By the end you will be able to

Pick where you want to start

Why AAR exists

SLA classes & policy

Data policy vs AAR

QoS & Cloud OnRamp

① The problem AAR solves — "up" is not "good enough"

Four ideas that anchor the whole lesson

② SLA classes + app-route policy — thresholds, match, colours

③ Data policy vs AAR — engineering the path by hand

▶ Follow one Teams packet through AAR, then a guest packet through data policy

④ QoS on the edge + Cloud OnRamp

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?