HowToFixMe
Cisco Real World Problems

How to configure SD-WAN app-aware routing SLA class on Catalyst 8300/8500

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

⚡ At a glance
BrandCatalyst 8300/8500
FamilyCisco Real World Problems
CategoryCisco
Guide typeHow To
Skill levelIntermediate

I run a Cisco shop. Most weeks I am wrist-deep in a Catalyst 8300 / 8500 chassis or staring at a console window on Putty 0.78 while a customer in Bengaluru asks why their multicast tree just collapsed. Sd-wan application-aware routing (aar) with a custom sla class comes up almost every quarter on these boxes, usually because you want voice and video traffic to flow over the WAN circuit that meets a strict loss / latency / jitter target, with the fallback path explicit and the current config does anything but that. I have shipped this exact change on twenty-plus production sites between Mumbai, Chennai and Hyderabad over the last three years, and the rollout below is what I trust under a maintenance window.

This is a working network-engineer guide, not a slide deck. I will tell you what the CLI looks like on the Catalyst 8300 / 8500 (SD-WAN-capable branch and edge router), what the pre-flight checks are, which IOS XE bug ID bit me on the last attempt, and what the verification output should look like before you sign off. Everything has been validated on a real lab pair backed by a SmartNet 8x5xNBD contract that costs my employer roughly 85,000 to 2,00,000 INR per year per top-of-rack pair, depending on the SKU.

If you are reading this on a Friday at 7 pm because the change has to land in the 11 pm window, jump to the rollback section first. I have done that walk-of-shame more than once. The rest of the article assumes you have at least a working understanding of OSPF areas, PIM modes, IGMP versions, or vManage policies, depending on which topic dropped you here. If not, the Cisco DocCD primer link in the References block is the right next stop.

What you need before you start

Every change goes faster when the bench is set up properly. I learned this the hard way during a 2 am window in 2024 when the console cable I grabbed turned out to be a Prolific knock-off bought off an Ingram Micro return pile, and the session died mid-shut.

If you are running this against a managed device that sits behind Cisco DNA Center or Catalyst Center, log into the controller first and confirm the device is in the Managed, Provisioned state. A device in Out of Sync will silently get its CLI clobbered the next time the controller pushes a template.

Why this matters on a Catalyst 8300 / 8500

Application-aware routing in Catalyst SD-WAN is the policy that says: "for this application family, only use a tunnel that meets this loss / latency / jitter SLA, and fall back to this other tunnel if no path qualifies." It rides on BFD, not on the data path, which is why a misconfigured BFD interval will silently break AAR.

On a Catalyst 8300 / 8500, the policy is rendered as an app-route-policy under the vSmart centralised policy, and the device-side it shows up as policy app-route-policy-filter. The SLA class is a separate object: sla-class VOICE loss 1 latency 100 jitter 50 is the canonical voice class, and it can be reused across multiple app-route rules.

The trap teams new to AAR fall into is testing with a single tunnel up. If you only have one BFD session alive, AAR has nothing to fall back to, so the "preferred / backup" semantics get masked. Always test with at least two transports. MPLS + INET, or INET + LTE, and shut down BFD on the preferred tunnel during the test to confirm the failover actually fires.

Step-by-step on a Catalyst 8300 / 8500

  1. On vManage, build the SLA class. Policies → Centralised Policy → Lists → SLA Class. Define VOICE with loss 1, latency 100, jitter 50. Save.
  2. Build the app-list. Lists → Application/App-Family. Pick the SaaS / voice / video apps (e.g. ms-teams-audio, webex-voice) or define a custom L7 app list.
  3. Create the app-route-policy. Centralised Policy → Topology and AAR → App Route Policy. Sequence: match → app-list VOICE-APPS, action → sla-class VOICE preferred-color mpls, backup-sla-preferred-color biz-internet.
  4. Activate the policy. Apply the policy to the right site-list and VPN list. Hit Activate; vSmart pushes the policy to every Catalyst 8300 / 8500 matching that site-list.
  5. Validate on the Catalyst 8300 / 8500. show sdwan policy from-vsmart lists the policy. show sdwan policy app-route-policy-filter shows the active rules. show sdwan app-route stats tracks the loss / latency / jitter per tunnel.
  6. Simulate a breach. On the preferred tunnel, shut BFD or add artificial loss with tc / netem in a lab pod. Within 30 seconds the policy should fail traffic to the backup colour.
  7. Save. The configuration is template-driven, so the save happens implicitly on the next push; confirm in vManage that there is no pending sync on the device.

Verification you actually trust

The change is not done until you can prove the AAR policy is downloaded and active, the SLA class buckets are tracked per tunnel, and BFD sessions are healthy on every preferred and backup colour. On a Catalyst 8300 / 8500, run:

Then capture a Wireshark 4.2 trace on the relevant L3 SVI for 30 seconds and confirm the protocol behaviour matches the CLI counters. I keep a saved Wireshark profile called multicast-debug that pre-filters for IGMP, PIM, and Auto-RP: costs nothing to build, saves five minutes per incident later.

Log into the Cisco DNA Center / Catalyst Center 2.3.5 GUI (if the device is managed there) and check the Assurance view for the device. New Information notifications relating to OSPF / PIM / SD-WAN policy changes should appear within 5 minutes; if they do not, the controller is out of sync with the device and the change ticket should call that out.

Common gotchas on a Catalyst 8300 / 8500

Field anecdote, what this actually looked like

SD-WAN AAR rollout on a Catalyst 8300 / 8500 pair for a Hyderabad retail chain ran a little less cleanly. We built a VOICE sla-class. loss 1, latency 100, jitter 50, applied to a Cisco Webex Voice app-list. The policy activated cleanly on vManage. On site, show sdwan policy from-vsmart listed the policy. But the voice traffic kept landing on the INET tunnel even when the MPLS tunnel was green. Five minutes of show sdwan app-route stats later, the cause was clear: the BFD interval on the MPLS tunnel was 1000 ms with multiplier 6: too slow to satisfy the SLA tracking, and AAR was treating the MPLS as ‘unknown’ rather than ‘good’. Tightened to 200 ms with multiplier 3, voice landed on MPLS, fail-over to INET tested clean. Total fix: 22 minutes, plus a follow-up note to the carrier that 1000 ms BFD is not suitable for AAR.

Rollback if it goes wrong

Rollback in Catalyst SD-WAN is a vManage operation, not a CLI operation. Deactivate the policy on the affected site-list, Centralised Policy → Activate. The push usually takes 60–90 seconds per device. If the policy refuses to deactivate cleanly, snapshot the vSmart policy XML before retrying so you can hand it to TAC.

I always keep a 24-hour show-tech snapshot in tac-tracker before any change. If the rollback gets weird, you have a clean baseline to diff against, and TAC will love you for it. SmartNet response on a Catalyst 9000 is typically 4 to 8 hours for severity-2 issues. better than nothing, but a clean self-rollback inside the window is faster than waiting.

Costs and licensing in India

For an Indian buyer, a top-of-rack Catalyst 8300 / 8500 pair plus the relevant SmartNet 8x5xNBD support runs roughly 85,000 to 2,00,000 INR per year per pair depending on the SKU. Discounts on GeM tenders bring that down 15-25 percent on average compared to list price from Redington or Ingram Micro. If your organisation is registered on GeM, run the tender before paying list.

License-wise, the configuration in this guide is covered by Network Advantage on Catalyst 9000 and by Network Essentials on most other IOS XE platforms, both ride on smart licensing, which means you need a working CSSM connection or an on-prem SSM satellite. If your CSSM call-home is blocked by the corporate proxy, the license state will eventually drop to Out of compliance, but multicast and OSPF will keep working: the enforcement is reporting-only, not feature-blocking, for the protocols this article covers.

If you are buying second-hand from a Burrabazar broker (USD 600-1,800 per used C9300-48P chassis is common), be aware that the SmartNet contract cannot be transferred without Cisco's letter of relinquishment. Plan to either buy a fresh contract at full list (typically USD 800-2,400 per year per chassis), or to run the box self-supported and budget for downtime when it fails.

More frequently asked questions

Does this change require a maintenance window?

Yes. Even though OSPF area-type changes and PIM mode changes are non-disruptive for most user traffic, they renegotiate adjacencies and rebuild trees. Always run inside a planned window with a backup-on-call.

Why is AAR not failing over even though the SLA is breached?

Usually one of two reasons: BFD timers too slow to detect the breach inside the policy window, or the backup colour does not actually have a tunnel up. Check show sdwan bfd sessions first.

How granular can the SLA class be?

Loss in percent, latency in milliseconds, jitter in milliseconds. You can layer multiple SLA classes per app-route policy, VOICE strict, VIDEO moderate, BULK lenient. and the policy picks the first colour that satisfies the class.

Does SmartNet cover this kind of operational change on a Catalyst 8300 / 8500?

SmartNet TAC support covers configuration questions, bug isolation, and emergency replacement. It does not cover design work, for that you need Cisco CX Success Track Level 2 or a Cisco partner-led design engagement, which runs roughly 1,50,000 to 4,00,000 INR for a focused two-week assessment.

Related guides worth a look while you sort this one out:

References