Cisco 300-415: Data Plane Tunnels, BFD and Application-Aware Routing — Study Guide

By Laurynas Brazys · 14 August 2026 · #cisco #300-415 #certification #exam-prep #study-guide

Part of the Cisco SD-WAN 300-415 ENSDWI — Study Guide. Practice with verified answers in the Cisco exam hub, or take timed practice tests on ExamRoll.io.

Overview

Cisco SD-WAN separates the control plane from the data plane and builds an encrypted, policy-driven overlay across disparate transports. The vSmart controller manages the overlay control plane and WAN Edge connectivity, distributing routes, security keys, and intent via OMP. WAN Edge routers form secure IPsec data-plane tunnels to other WAN Edges, while control connections to vSmart, vBond, and vManage use DTLS by default (or TLS). Path liveness and quality are continuously measured with BFD, which feeds Application-Aware Routing (AAR) policies to steer applications along the best-performing tunnels according to SLA classes based on loss, latency, jitter, or MOS.

Overlay and Data-Plane Fundamentals

• Control plane versus data plane

  • Control plane: WAN Edges establish secure DTLS/TLS control connections to vBond (for NAT traversal and orchestration), vSmart (policy and route exchange via OMP), and vManage (management, device configuration, and certificate storage). In staging state, devices form control connections but do not establish data tunnels.
  • Data plane: WAN Edges form IPsec tunnels directly to other WAN Edges for user traffic. The data plane is responsible for forwarding and enforces traffic-engineering decisions conveyed via control-plane policy.

• IPsec data-plane tunnels and TLOCs

  • A Transport Locator (TLOC) uniquely identifies a WAN transport attachment and is defined by the tuple {system-IP, color, encapsulation}. Encapsulation is IPsec or GRE; in most deployments and on IOS XE SD-WAN (cEdge), IPsec is used.
  • Colors are semantic labels for underlay types and NAT properties (for example, mpls, biz-internet, public-internet, lte, private1–private6). Public colors typically imply NAT traversal with assistance from vBond.
  • Tunnels form between every reachable pair of TLOCs unless restricted. With two sites, each with one WAN Edge and two public TLOCs, and no restrict attributes, four IPsec tunnels form (full mesh between color pairs).
  • TLOC extension allows two redundant WAN Edges at a site to share transports through a cross-link, enabling transport redundancy without duplicating physical circuits per chassis.

• Transport and service labels

  • vSmart uses OMP to advertise routes and TLOCs and to allocate labels carried in the overlay header. Transport labels identify remote TLOCs for demultiplexing traffic across the overlay. Service labels identify the destination service VPN or chained service. These labels are internal to the SD-WAN overlay and are not MPLS underlay labels.

• Operational trade-offs and failure modes

  • Miscolored transports (for example, marking MPLS as public-internet) can cause suboptimal tunnel formation or NAT traversal failures.
  • The restrict attribute prevents unwanted full-mesh growth; omitting it on internet colors can lead to excessive tunnel scale and unnecessary probing overhead.
  • Certificate or clock issues prevent control-plane connectivity (DTLS/TLS). Without control-plane convergence to vSmart, no data-plane keys are exchanged and IPsec tunnels do not form.

BFD Path Liveness and Quality Measurement

• BFD operation

  • Cisco SD-WAN runs BFD on every data-plane tunnel to provide near-real-time liveness detection and quality measurement. BFD uses lightweight periodic hellos to detect up/down state (blackouts) and active probes to measure latency, jitter, and loss (brownouts).
  • Key timers and intervals
    • Hello interval: commonly 1000 ms (configurable per color or globally).
    • Multiplier: commonly 6 (configurable), yielding a detection time of hello-interval × multiplier (for example, ~6 seconds).
    • App-probe interval for AAR performance sampling: typically 1 second (configurable), with rolling averages computed over a short window to smooth transient spikes.
  • BFD measures
    • Latency: round-trip time of probes on each tunnel.
    • Jitter: variation in inter-probe latency.
    • Loss: percentage of probes not returned.
    • MOS: derived from latency, jitter, and loss for voice suitability.

• Brownout versus blackout handling

  • Blackout: BFD session down (no connectivity) triggers immediate removal of the path from forwarding. Traffic is shifted according to next available tunnel preference without waiting for AAR evaluation.
  • Brownout: BFD remains up, but measured metrics violate SLA thresholds. AAR can steer specific application flows to alternate tunnels that meet SLAs, even while the original tunnel continues to carry other traffic.

• Design guidance and trade-offs

  • Aggressive timers speed failover but raise CPU and bandwidth overhead, especially in large meshes. Balance hello and probe intervals against scale and transport stability.
  • Asymmetric path characteristics (for example, satellite or cellular) demand relaxed SLA thresholds and potentially higher multipliers to avoid flapping.
  • For voice and interactive apps, prefer faster app-probe intervals and enabling hysteresis/hold-down to reduce oscillation during transient congestion.

Application-Aware Routing: Policy and SLA Design

• Application identification and classification

  • WAN Edges use DPI (NBAR2 on IOS XE SD-WAN) to classify applications by signatures, protocol heuristics, and, where available, metadata such as TLS SNI and QUIC ALPN. For encrypted traffic without identifiable metadata, the engine falls back to flow attributes (5‑tuple) and configured mappings (ports, DSCP).
  • Classification typically occurs on first packets and is cached for session consistency. Keep signatures up to date to maintain accuracy.

• SLA classes and measurement policy

  • Define SLA classes with thresholds for loss, latency, jitter, and optionally MOS. Each SLA class references a performance-probe profile (app-probe) that drives BFD’s sampling interval and smoothing behavior.
  • Typical SLA examples:
    • Voice: latency ≤ 150 ms, jitter ≤ 30 ms, loss ≤ 1%, MOS ≥ 4.0.
    • Transactional: latency ≤ 200 ms, loss ≤ 1%.
    • Bulk: no strict SLA; prefer higher-bandwidth, lower-cost paths.

• Path preference behavior

  • AAR policy ties application lists to SLA classes and specifies preferred-color and backup-color (or TLOC lists). The decision logic:
    1. If preferred path meets SLA, send traffic on preferred.
    2. If preferred violates SLA but backup meets it, steer to backup.
    3. If no path meets SLA, use best available path by preference or cost (degrade gracefully).
  • Brownout steering is per-flow; existing flows can be moved depending on policy (new-flow steering is default; mid-flow move may be constrained for TCP unless session resiliency is designed in).

• Policy construction elements

  • Build app lists (DPI groups), SLA classes (loss/latency/jitter/MOS), and TLOC lists (colors) in vManage. Then create an AAR policy sequence mapping app-list → SLA-class → preferred/backup colors.
  • Combine with traffic data policies if you must set DSCP, enforce zones, or insert service chaining before AAR decisions.
  • Use control-policy separately to influence route acceptance/advertisement; do not conflate AAR (data-policy) with control-policy. Site lists scope where AAR applies.

• Design trade-offs

  • Overly strict SLAs can cause oscillation. Introduce hysteresis or penalty timers to avoid frequent path shifts.
  • Consider cost: place metered cellular paths only as last-resort backups; enable data caps where available.
  • Coordinate with QoS: AAR picks the path; per-path QoS and queueing must still protect critical classes during congestion.

Verification and Troubleshooting

• Rapid health checks

  • Control plane:
    • cEdge: show sdwan control connections
    • vEdge: show control connections
  • Data-plane tunnels:
    • cEdge: show sdwan tunnels
    • vEdge: show ipsec outbound-connections / show ipsec inbound-connections
  • BFD sessions and quality:
    • cEdge: show sdwan bfd sessions; show sdwan app-route stats
    • vEdge: show bfd sessions; show app-route stats

• Example command snippets

  show sdwan tunnels
  show sdwan bfd sessions
  show sdwan app-route stats sla-class <name>
  show sdwan app-route statistics flows
  show sdwan omp tlocs
  

  show control connections
  show omp routes | include <prefix>
  show ipsec sa detail
  

• What to look for

  • Tunnel state is up, but BFD loss/latency/jitter exceeds SLA: brownout—expect AAR steering. Validate that the backup path meets SLA and that policy binds the correct app list.
  • BFD session flapping: reduce aggressiveness or investigate underlay drops/queuing; verify MTU and fragmentation (DF-bit handling) to avoid probe loss.
  • No tunnels formed over a color: verify color NAT/public/private semantics, interface NAT configuration, and that vBond is reachable for NAT traversal. Confirm time and certificates if control connections are absent.
  • Unexpected full-mesh and probe scale: apply restrict on internet colors or use TLOC lists to scope connectivity.
  • DPI misclassification: update NBAR2 signatures and confirm no conflicting L4 port overrides. For encrypted apps, consider SNI/ALPN-based classification or DSCP marking upstream.

• Operational reasoning

  • Always validate control connectivity first (vBond for orchestration/NAT, vSmart for OMP/policy, vManage for config/certs). Without vSmart, data-plane keys are not distributed, and no IPsec SA forms.
  • Correlate AAR decisions with BFD measurements and SLA classes. If a path is selected contrary to expectation, inspect the SLA compliance status at the time of decision, not just current averages.
  • For dual-DC designs, avoid duplicate LAN routes by harmonizing overlay AS on DC WAN Edges when redistributing OMP↔BGP across a DC interconnect.

Practical Problem Scenario

Contoso Health operates 300 clinics with dual transports at each site: MPLS (mpls color) and broadband (biz-internet color). Users report intermittent poor voice quality, while data apps are fine. The goal is to prefer MPLS for voice, fail over to broadband during brownouts, and ensure rapid blackout failover without oscillation.

1. Validate overlay health and data-plane formation

• Rationale: Confirm prerequisites. Use show sdwan control connections to ensure DTLS/TLS to vSmart/vBond/vManage is stable and show sdwan tunnels to verify full MPLS and broadband tunnel mesh. If tunnels over biz-internet are missing, check color assignment and NAT; vBond must be reachable in public space to assist NAT traversal.

2. Calibrate BFD and probe timers

• Rationale: Set BFD hello 1000 ms, multiplier 6 for balanced liveness detection (~6 s) and reasonable scale. Configure app-probe interval 1 s for timely brownout detection. Excessively aggressive timers can cause CPU overhead and flapping; too relaxed impedes responsiveness for voice.

3. Define SLA classes

• Rationale: Create an SLA class Voice-SLA with latency ≤ 150 ms, jitter ≤ 30 ms, loss ≤ 1%, MOS ≥ 4.0. Create a Data-SLA with latency ≤ 200 ms, loss ≤ 1%. These thresholds reflect voice sensitivity and typical WAN performance; MOS consolidates user experience across metrics.

4. Build application lists

• Rationale: Use DPI (NBAR2) to define App-List-Voice for SIP/RTP/Teams/Zoom media and App-List-Data for transactional apps. Include TLS SNI/QUIC ALPN patterns for modern voice/video platforms. Where classification is uncertain, fall back to DSCP EF/AF41 markings enforced at the LAN edge.

5. Construct AAR policy

• Rationale: Map App-List-Voice to Voice-SLA with preferred-color mpls and backup-color biz-internet. Map App-List-Data to Data-SLA with preferred-color biz-internet and backup-color mpls to preserve MPLS bandwidth. This ensures voice uses MPLS when healthy and shifts to broadband only during brownouts or blackouts, while data prefers the cost-effective internet.

6. Add hysteresis and hold-down

• Rationale: Configure a revert timer so voice returns to MPLS only after sustained SLA compliance (for example, 30–60 s). This avoids oscillation during transient jitter spikes. Similarly, apply a penalty or dampening on broadband if it repeatedly violates SLA within a short window.

7. Coordinate QoS and MTU

• Rationale: On both transports, ensure EF queueing and shaping align with circuit rates. Mismatch can inflate jitter/loss seen by BFD probes and voice RTP. Validate path MTU and disable DF where fragmentation is inevitable, preventing probe drops that masquerade as loss.

8. Verify and iterate

• Rationale: Use show sdwan app-route stats sla-class Voice-SLA to confirm SLA pass/fail per tunnel. Observe live flows with show sdwan app-route statistics flows to ensure voice steers to MPLS and shifts to broadband only when MPLS violates SLA. During tests, intentionally congest MPLS to validate brownout behavior, then measure reversion timing.

By following these steps, Contoso Health ensures that BFD provides fast blackout detection, AAR reacts to brownouts using precise SLA classes, and DPI accurately classifies voice applications. The combination yields predictable voice quality, efficient use of transports, and controllable failover behavior across the SD-WAN fabric.

← WAN Edge Configuration and Template Management · All domains · Centralized Policy and Traffic Engineering →

Practice these questions → · Timed practice on ExamRoll.io →