Application-Aware Routing
Key Points
- AAR overrides the default tunnel choice using live loss/latency/jitter; routing protocols still decide reachability.
- An SLA class is a reusable object; a tunnel must satisfy every threshold (loss, latency, jitter) to be SLA-compliant.
- BFD measures metrics over a default 10-minute poll interval with a default multiplier of 6, smoothing transient spikes.
- The app-probe-class lets probes use a specific DSCP so measurements reflect the real QoS queue (e.g., EF for voice).
- EAAR uses inline data-plane packets plus dampening for faster, more stable failover, but must be enabled on both ends.
Routing protocols answer "Can I reach the destination?" AAR answers a harder one: "Of all the ways I can reach it, which will my users actually enjoy right now?" A useful analogy is Waze: the road map (your routing protocol) shows which roads connect, but Waze layers live traffic on top and reroutes you. AAR is the WAN equivalent — OMP, BGP, and OSPF decide reachability, but AAR overrides the default tunnel based on live path conditions.
The AAR solution rests on three pillars:
| Pillar | What it does | How |
|---|---|---|
| Identification | Classifies the flow and maps it to an SLA class | L3/L4 headers (IP, ports, protocol, DSCP) or NBAR2 signatures |
| Measurement | Continuously measures loss, latency, jitter per tunnel | BFD probes (and optionally EAAR) |
| Path selection | Steers each flow onto an SLA-satisfying tunnel | Filters tunnels by SLA compliance, then applies preferences |
One subtlety: AAR is evaluated only after the overlay route is installed. If OMP tie-breaking never installs the route, the app-route policy is never invoked — a common troubleshooting trap.
SLA Classes and Probes (BFD)
An SLA class defines maximum tolerable loss-percentage, latency (ms), and jitter (ms). Think of it as a bouncer's checklist: a tunnel must satisfy every item. For example, voice-gold = loss ≤ 1%, latency ≤ 100 ms, jitter ≤ 30 ms; email-bronze = loss ≤ 5%, latency ≤ 300 ms, jitter ≤ 100 ms. Exceed any single threshold and the tunnel is marked SLA-violating and dropped from the candidate set. Set thresholds on real WAN behavior: too strict flags every tunnel "bad"; too loose never reroutes.
The numbers come from BFD (Bidirectional Forwarding Detection) sessions on each tunnel. BFD detects liveliness (fast failure detection) and measures loss/latency/jitter, recorded as PfR data. Timing matters: BFD collects stats over a poll interval defaulting to 10 minutes, computes averages, and a multiplier (default 6) means decisions look across several intervals' weighted averages. This makes standard AAR deliberately conservative — a 30-second loss burst may dilute into a 10-minute average that never breaches SLA.
Figure 8.1: BFD vs. EAAR measurement loops feeding SLA evaluation
over 10-min poll interval"] A2 --> A3["Compute weighted average
(multiplier x6)"] A3 --> A4["Update per-tunnel PfR metrics"] A4 --> A1 end subgraph Enhanced["Enhanced AAR (inline data-plane)"] direction TB B1["Inspect live application packets"] --> B2["Derive loss / latency / jitter inline"] B2 --> B3["Apply dampening
(prevent flapping)"] B3 --> B4["Report metrics back via BFD"] B4 --> B1 end A4 --> SLA{"Tunnel meets
SLA class?"} B4 --> SLA SLA -->|Faster reaction via EAAR| OUT["SLA-compliant / SLA-violating state"]
Enhanced Application-Aware Routing (EAAR), introduced around release 20.12, derives metrics from inline data-plane packets — the live traffic itself — and reports back via BFD, giving faster detection and quicker reroute. It includes a dampening mechanism to prevent flapping. Two operational notes: EAAR is disabled by default, and it must be enabled on both the local and remote edges to function.
Key Takeaway: SLA classes define the loss/latency/jitter thresholds an application demands; BFD continuously measures those metrics over a 10-minute averaging window, while EAAR uses live data-plane packets for much faster reaction.
App-Route Policies
The rules tying applications to SLA classes live in a centralized app-route policy, built in vManage (Cisco SD-WAN Manager) and pushed by vSmart. It is a dedicated policy type. Building blocks:
| Component | Purpose |
|---|---|
| VPN-list | Which VPN IDs the policy applies to |
| Application / traffic match | App-list (NBAR2 signatures) or data-prefix list, optionally src/dst IP, ports, DSCP |
| App-probe-class | Sets the DSCP used for AAR/BFD probes (e.g., probe EF to measure the voice queue) |
| SLA-class | The loss/latency/jitter thresholds to evaluate |
| TLOC / color preference | Preferred transport colors or TLOC lists, used with SLA status |
The policy is organized as match → action sequences. The app-probe-class deserves emphasis: WAN paths behave differently per queue — the priority queue carrying voice may show 20 ms latency while best-effort shows 200 ms. Probing with EF measures the actual queue your voice will use, making decisions far more accurate.
Key Takeaway: An app-route policy is a centralized match/action policy that maps applications to SLA classes and color preferences; app-probe-class lets you probe a specific DSCP so measurements reflect the real QoS queue.
Path Preference and Failover
With SLA classes defined and policy attached, the edge selects a tunnel as follows:
- Identify traffic and SLA — match the flow, determine the SLA class.
- Gather metrics — retrieve loss/latency/jitter from BFD (and EAAR) per candidate tunnel.
- Filter by SLA compliance — discard any tunnel exceeding a threshold.
- Apply preferences — narrow to preferred-color/TLOC; pick best by performance.
- Forward — install a forwarding entry over the chosen tunnel.
- React to change — if the tunnel later violates SLA, reroute to a still-compliant one (EAAR makes this fast).
- If no tunnel meets SLA — use best-available, fall back to default routing, or stay to avoid flapping.
Figure 8.2: AAR path-selection decision flow against the SLA
app-route policy"] MATCH --> SLA["Determine applicable SLA class"] SLA --> METRICS["Gather loss / latency / jitter
from BFD + EAAR per tunnel"] METRICS --> FILTER["Filter: discard tunnels that
exceed any SLA threshold"] FILTER --> ANY{"Any SLA-compliant
tunnel remaining?"} ANY -->|Yes| PREF["Apply preferred color / TLOC list"] PREF --> MULTI{"Multiple candidates
qualify?"} MULTI -->|Yes| BEST["Choose best by performance"] MULTI -->|No| BEST BEST --> FWD["Install forwarding entry
over chosen tunnel"] ANY -->|No| FALLBACK["Fallback action:
best-available, default routing,
or stay to avoid flapping"] FALLBACK --> FWD FWD --> WATCH{"Chosen tunnel
later violates SLA?"} WATCH -->|Yes - EAAR reroutes fast| METRICS WATCH -->|No| WATCH
Worked example. A branch reaches the DC over MPLS and biz-internet. voice-gold = loss ≤ 1%, latency ≤ 100 ms, jitter ≤ 30 ms; data-silver = loss ≤ 3%, latency ≤ 200 ms, jitter ≤ 50 ms. At runtime:
| Tunnel | Loss | Latency | Jitter | voice-gold? | data-silver? |
|---|---|---|---|---|---|
| MPLS | 0.5% | 80 ms | 20 ms | Pass | Pass |
| Internet | 2% | 150 ms | 40 ms | Fail (loss, latency) | Pass |
Voice takes MPLS (only compliant path, and preferred). Data finds both compliant but policy prefers biz-internet, so data uses Internet — keeping MPLS free for voice. If MPLS degrades to 5% loss, BFD marks it non-compliant and voice shifts to Internet (if compliant and permitted), preserving experience. EAAR makes that transition far faster than waiting on the 10-minute average.
Key Takeaway: Path selection filters tunnels by SLA compliance, then applies color/TLOC preferences; when the chosen tunnel degrades, AAR reroutes to a still-compliant path — and EAAR with dampening makes failover both faster and more stable.