Application-aware routing introduction

This lesson uses classic BFD-based AAR on Cisco IOS XE Catalyst SD-WAN 17.x with Manager 20.x. The policy excerpt uses Controller syntax, not WAN Edge configuration mode. Exact features and commands depend on the paired releases; enhanced AAR modes are outside this example.

Choppy calls on a circuit that is up

At about two in the afternoon, calls from BR-01 to the voice gateway behind HUB-01 start to break up. The MPLS circuit that carries them shows up, with no errors on the interface. The provider is dropping a few per cent of packets somewhere inside its network. A route cannot see that: the link is up, so the route stays. Application-aware routing exists to notice it and move the calls to the internet path until MPLS recovers.

What the router measures

Every tunnel between two WAN Edge routers already runs BFD (Bidirectional Forwarding Detection) hello packets, by default one per second, to detect a dead tunnel. AAR reuses those probes to measure the tunnel's quality:

• Loss: the share of probes that do not come back, as a percentage.
• Latency: a tunnel-delay measurement in milliseconds. Check the command and release before treating a displayed value as one-way or round-trip delay.
• Jitter: how much that delay varies, in milliseconds.

Results are collected in intervals. The router averages the values it has collected over several recent intervals and compares the average with each SLA class. The poll interval and the number of intervals used (the multiplier) are configurable. On many releases the defaults are an interval of ten minutes and a multiplier of six, which suits a stable network and reacts slowly; designs that carry voice usually shorten both. Check the defaults for your release, and remember the trade-off: faster reaction also means more path changes when a link is only briefly bad.

SLA classes and the policy

An SLA class is a set of thresholds: a path qualifies when its measured loss, latency and jitter are all within them. An application-aware routing policy then matches traffic (by application, by DSCP value, by address and so on) and names the SLA class and the transports to prefer.

Reading it aloud gives the whole model: match voice in VPN 20; among tunnels that meet the VOICE thresholds, prefer the MPLS colour; apply this at the branch sites. The policy is about which paths are eligible and which is preferred, not about changing the routes themselves.

Four conditions and what the router does

Voice from BR-01 to HUB-01 under the VOICE class (2% loss limit), preferring MPLS. Decide which path voice will take before reading the last column.

When neither path qualifies, inspect the action. The shortened preferred-colour example above does not enable Strict/Drop or best-tunnel fallback. Non-strict handling can use an available tunnel even though it misses the SLA; Strict/Drop discards matching traffic when no tunnel qualifies. Fallback to best path needs its own policy action and SLA-class criteria on supported releases, starting with IOS XE 17.5.1a and Manager 20.5.1. An available path is not necessarily a healthy one, and other data policies can also affect the choice.

A brownout moves traffic because the path no longer meets the SLA; a failure removes the path. Both end on the other transport, for different reasons.

What AAR is not

• Not an instruction to move every packet after one loss. Classic AAR uses measured intervals and policy. One lost probe alone does not establish the forwarding outcome.
• Not a replacement for QoS. AAR chooses a path; queuing and marking decide how traffic is treated on it.
• Not instant. Detection speed depends on the measurement settings, which is why failure detection (BFD, seconds) is much faster than brownout detection (averages, longer).
• Not controlled from the Controller at packet time. The edge router measures and decides locally.

Checking which path is in use

BR-01#show sdwan app-route stats
REMOTE SYSTEM IP  LOCAL COLOR  REMOTE COLOR   INDEX  PACKETS  LOSS  LATENCY  JITTER
10.255.1.1        mpls         mpls           0      600      6     41       9
10.255.1.1        mpls         mpls           1      600      5     38       8
10.255.1.1        biz-internet biz-internet   0      600      0     22       2
10.255.1.1        biz-internet biz-internet   1      600      0     21       3

The first command shows what the router measured, the second shows what it was told to enforce, and the third shows the decision. A complaint about a path then becomes three observations, not a guess.

Testing it in a lab

To see AAR act, make one path worse on purpose in a lab: put a WAN emulator, or a Linux bridge with tc netem, in line on the MPLS side and add loss. Then watch the three commands above, and remove the impairment and watch the traffic return. Do this only in a lab; never impair a production circuit. Record how long each reaction took. With default measurement settings the first test usually shows how slow AAR is, which is the lesson.

Technical reference: Cisco IOS XE 17.x application-aware routing guide. Commands and outputs here are authored teaching examples; no router image or live network was executed.

Test yourself on application-aware routing