Cisco Catalyst SD-WAN Deep Dive Part 4: BFD, App-Route SLAs, and cEdge Forwarding

Part 3 ended with a promise to leave policy behind and look at actual forwarding. Before we get there, though, there’s a piece of plumbing that both app-route policy and fast failover depend on, and it’s been mentioned twice already without explanation: BFD, running over every data-plane tunnel, all the time.

BFD isn’t optional here — it’s the heartbeat the whole data plane runs on

Once an IPsec tunnel forms between two TLOCs (Part 1, step 6), a BFD session comes up over it automatically — this isn’t a feature you turn on, it’s baseline behavior for every tunnel in the fabric. Two things ride on that BFD session simultaneously:

1. Failure detection. Standard BFD job: fast Hello exchange, declare the path down after a configurable number of missed Hellos, and feed that failure up so OMP can withdraw the affected TLOC-derived paths quickly rather than waiting on a much slower underlay-level failure signal.
2. Continuous SLA measurement. This is the part that’s easy to miss if you’ve only used BFD for fast reroute elsewhere. Catalyst SD-WAN’s BFD Hello packets carry loss, latency, and jitter measurements for the path they’re running over, computed continuously, per TLOC pair. That per-path SLA data is what app-route policy (next section) actually steers on — it isn’t a separate probing mechanism, it’s the same BFD session already running for failure detection.

Default Hello intervals are tuned by color: private colors (mpls, metro-ethernet) default to a 1000ms Hello with a multiplier around 7, reflecting an assumption of a more stable, low-jitter underlay; public colors (biz-internet, lte) typically warrant tighter tuning in practice precisely because consumer-grade Internet and cellular paths are noisier and you want SLA measurement to be responsive rather than smoothed into uselessness. None of this is fixed in stone — both intervals and multipliers are configurable per TLOC — but the out-of-box defaults already encode “trust MPLS more, watch Internet more closely,” which is a reasonable starting assumption for most designs.

This is conceptually the same problem the SD-WAN resilience series works through in BFD-and-convergence-tuning terms — fast failure detection riding under a routing/control layer so the control layer doesn’t have to wait out a slow IGP or BGP hold-timer to notice a dead path. The mechanism differs (that series tunes BFD under BGP/OSPF on FortiGate ADVPN hubs; here it’s BFD natively woven into OMP’s own path validity), but the underlying motivation — don’t let your routing protocol’s own timers be the bottleneck on failure detection — is identical.

App-route policy: SLA-class matching, not just “use the best path”

With BFD continuously producing loss/latency/jitter numbers per TLOC pair, app-route policy is what turns those numbers into a forwarding decision. The model is: define an SLA class with thresholds (e.g., “loss ≤ 2%, latency ≤ 100ms, jitter ≤ 30ms”), then match specific applications or traffic (by DSCP, by ACL, by Cisco’s application-recognition signatures) to that SLA class. Any TLOC pair currently meeting the thresholds is eligible; the edge picks among eligible paths (with multipath spreading traffic across however many qualify, same multipath mechanics from Part 2), and any path that drifts out of SLA gets pulled from consideration in near-real-time as the BFD-measured stats update — no separate polling cycle, no waiting for a scheduled health check.

This is a genuinely different model from purely OMP-best-path-driven forwarding: OMP best-path selection (Part 2) decides what’s reachable; app-route policy decides which of the reachable, multipath-eligible options is good enough right now for a given application. A voice/video SLA class might exclude a perfectly reachable but currently-jittery Internet TLOC that a bulk-transfer SLA class would happily use. It’s the SD-WAN industry’s general “application-aware routing” pitch, and on this platform it’s built directly out of the BFD measurement stream rather than a bolted-on synthetic probe.

For a direct comparison against how a different vendor’s stack handles the same SLA-aware-steering problem at the QoS layer, the Fortinet traffic-shaping and QoS internals post covers FortiGate’s performance-SLA health checks and shaping-policy interaction — broadly the same goal (don’t send latency-sensitive traffic down a degraded path), implemented as a FortiGate SD-WAN rule construct rather than a controller-pushed SLA-class policy.

Where vEdge and cEdge actually diverge

Up to this point in the series, “vEdge or cEdge” has mostly been a software-lineage footnote. At the forwarding layer it stops being a footnote.

cEdge runs the SD-WAN data plane as an integrated part of IOS-XE’s existing forwarding infrastructure — the same QFP (QuantumFlow Processor) packet-processing pipeline that’s been doing CEF-based forwarding, NAT, zone-based firewall, and everything else IOS-XE routers have done for years. SD-WAN’s tunnel encapsulation/decapsulation and TLOC-aware path selection are additional steps in that same pipeline, which is exactly why a cEdge platform can run SD-WAN forwarding and traditional IOS-XE features (NAT, ACLs, ZBFW, even on-box UTM components) side by side on the same box without bolting on a second, parallel forwarding stack. The practical upshot from Part 1’s “don’t deploy new vEdge” guidance becomes concrete here: cEdge isn’t just newer hardware, it’s a fundamentally more capable forwarding architecture because it inherited decades of IOS-XE forwarding-plane investment rather than relying on a smaller, SD-WAN-only codebase.

vEdge (ViptelaOS) has its own purpose-built forwarding path, designed from day one specifically for the SD-WAN job and nothing else. It’s simpler, it’s been stable for a long time, and there’s nothing wrong with it for what it does — but it doesn’t have IOS-XE’s broader feature surface sitting underneath it, which is the direct cause of most “why can’t I do X on this vEdge” questions you’ll run into supporting legacy estate. If a design requires SD-WAN forwarding plus genuinely heavyweight router-grade features in the same box, that requirement alone usually settles the vEdge-vs-cEdge question before you’ve even looked at a spec sheet.

What it looks like on the box

A trimmed show bfd sessions on a healthy cEdge, two transports up:

SOURCE TLOC REMOTE TLOC DST PUBLIC IP DST PUBLIC PORT TRANSITIONS STATE
SYSTEM-IP COLOR SYSTEM-IP COLOR
10.1.0.10 mpls 10.1.0.20 mpls 198.51.100.20 12346 0 up
10.1.0.10 biz-internet 10.1.0.20 biz-internet 203.0.113.50 12426 1 up

And the SLA-relevant half, a trimmed show app-route stats for the same pair:

SRC TLOC COLOR DST TLOC COLOR LOSS% LATENCY(ms) JITTER(ms)
mpls mpls 0 8 1
biz-internet biz-internet 1 34 6

A voice SLA class with a tight jitter threshold would happily use the mpls path here and might exclude biz-internet depending on where the threshold sits — exactly the decision app-route policy is making continuously, off exactly this data.

Next

Part 5 stops talking about mechanisms in isolation and walks full topologies end to end: dual-MPLS-plus-Internet branch design, direct Internet access (DIA) and local breakout decisions, and TLOC extension for sites that don’t have their own WAN circuit but still need to participate in the fabric through a neighboring site’s transport.