Traditional routing can choose a path that is reachable but poor for the application using it.<\/p>\n
A voice call can traverse a tunnel with high jitter. An interactive application can take a high-latency path even though a better transport exists. A bulk-transfer application may not care about either condition.<\/p>\n
Cisco Catalyst SD-WAN application-aware routing solves that mismatch by combining application classification with real-time path measurements and SLA policy.<\/p>\n
It is a core subject in the current 300-415 ENSDWI<\/a> v1.2 blueprint.<\/p>\n OMP and the routing table tell the edge which destinations can be reached.<\/p>\n BFD tells the platform whether overlay tunnels are alive and also measures characteristics such as latency, loss, and jitter.<\/p>\n Application-aware routing adds another question:<\/p>\n Which available path currently meets the service requirement for this application?<\/strong><\/p>\n That is different from ordinary best-path selection.<\/p>\n A path can remain perfectly valid for routing while failing the SLA threshold for a particular application.<\/p>\n AAR is therefore not a replacement for OMP. OMP still has to provide a reachable destination and viable TLOC candidates. AAR operates only after those alternatives exist. If one site has a single usable tunnel, no application-aware policy can manufacture a second path when the first path becomes poor.<\/p>\n That dependency is useful during design. Redundant transports should be genuinely diverse enough that a brownout on one path does not simply affect the other path in the same way. Two circuits that share the same last-mile failure domain may look redundant in the dashboard while offering little real performance diversity.<\/p>\n Catalyst SD-WAN overlay BFD does more than detect failure.<\/p>\n Cisco documents BFD<\/a> as measuring latency, loss, jitter, and related tunnel statistics that application-aware routing can use.<\/p>\n Those measurements create the feedback loop.<\/p>\n If the MPLS path is up but starts exceeding the configured loss threshold, a real-time application may be moved to another tunnel that remains within policy.<\/p>\n Cisco BFD<\/a> supplies the protocol foundation, while Catalyst SD-WAN turns its tunnel statistics into an input for traffic engineering.<\/p>\n Cisco’s current SD-WAN documentation describes BFD measurement in polling intervals and maintains a sliding history of tunnel quality. The exact defaults and threshold behavior can evolve by release, which is another reason to verify the deployed version rather than memorizing one timer as universal.<\/p>\n The broader principle is stable: AAR should react to measured behavior over time, not to one isolated packet. Smoothing and history help prevent a single transient spike from producing a path change that is more disruptive than the impairment itself.<\/p>\n An SLA class expresses the path quality an application requires.<\/p>\n Depending on configuration, the class can include thresholds such as:<\/p>\n The policy is not asking which path has the mathematically lowest latency at every instant.<\/p>\n It is asking whether a path is inside or outside the defined service boundary.<\/p>\n That is an important design distinction because aggressively moving traffic every time one path becomes a few milliseconds better can create instability.<\/p>\n An SLA class should represent application tolerance, not an arbitrary desire to use the numerically \u201cbest\u201d link.<\/p>\n SLA thresholds should be designed from application requirements. Voice is usually sensitive to jitter, loss, and delay. Interactive transactions may tolerate little latency but modest jitter. Bulk replication may tolerate high delay while caring more about available throughput and cost.<\/p>\n A threshold that is too strict can put all tunnels out of SLA during normal variation. A threshold that is too loose can keep users on a visibly bad path. Test the policy against observed baselines from each transport rather than copying a generic number into every site.<\/p>\n The application-aware routing policy ties the traffic match to the SLA class and path preference.<\/p>\n Cisco’s policy framework includes app-route policy definitions that use SLA classes for application-aware routing.<\/p>\n The edge device then makes packet-forwarding decisions using the current tunnel measurements.<\/p>\n That means the policy is centrally defined but locally enforced on the edge.<\/p>\n The controller does not sit in the user-data path.<\/p>\n Application identification has to be trustworthy.<\/strong><\/p>\n A policy can only make an application-specific decision if the edge can classify the traffic appropriately.<\/p>\n Catalyst SD-WAN can use application intelligence to recognize traffic beyond simple port numbers.<\/p>\n That matters because many modern applications use shared protocols and dynamic cloud infrastructure.<\/p>\n However, application classification should still be treated as evidence, not magic. Encrypted traffic, application changes, or ambiguous flows can affect recognition.<\/p>\n For critical traffic, understand what field or classification method the policy actually uses.<\/p>\n The app-route policy also needs a deterministic fallback when no preferred path meets the SLA. Current Cisco policy behavior can combine preferred colors, SLA state, and other data-policy preferences. The exact result depends on the configured policy, so \u201cout of SLA\u201d does not automatically mean \u201cdrop the flow.\u201d<\/p>\n Document the fallback explicitly: should the application use a nonpreferred but healthy color, use the best available out-of-SLA path, follow a data-policy preference, or be denied? Operations teams need to know what degraded-but-intentional behavior looks like before an incident.<\/p>\n Catalyst SD-WAN uses colors to identify transport characteristics.<\/p>\n An application-aware policy can prefer particular colors while still using SLA state to decide whether those tunnels are acceptable.<\/p>\n For example, an organization might prefer one transport for voice when it meets SLA and fall back to another when the preferred path degrades.<\/p>\n This is more flexible than static routing preference because path quality participates in the decision.<\/p>\n It also explains why a QoS<\/a> policy and application-aware routing are complementary rather than interchangeable.<\/p>\n AAR chooses a suitable path.<\/p>\n QoS controls how traffic is treated when competing for resources on that path.<\/p>\n Application recognition is another dependency. If the match uses an application identity, confirm that the platform is actually classifying the flow as expected. If the policy uses DSCP or prefixes instead, verify those fields before the AAR decision point.<\/p>\n Encrypted and cloud-hosted applications can change addresses or share transport characteristics with other services. A policy that assumes one static server IP may age poorly even if the SLA logic is perfect. Classification and path measurement are two separate inputs, and both must be correct.<\/p>\n A complete link failure is easy to detect.<\/p>\n The harder problem is a brownout: the tunnel stays up, but performance becomes bad enough to hurt an application.<\/p>\n BFD may still report the session as operational while its measured loss or latency violates the SLA class.<\/p>\n Application-aware routing can then move matching traffic away from that path.<\/p>\n This is one of the strongest practical reasons to use performance-aware SD-WAN instead of relying only on route availability.<\/p>\nReachability is not the same as application quality<\/h2>\n
BFD provides the path measurements<\/h2>\n
SLA classes define what \u201cgood enough\u201d means<\/h2>\n
\n
App-route policy maps traffic to the SLA requirement<\/h2>\n
Preferred colors express transport intent<\/h2>\n
Brownout handling is where AAR becomes valuable<\/h2>\n