Cisco 300-415: Centralized Policy and Traffic Engineering — 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

Centralized policy in Cisco SD-WAN is the framework that allows you to program traffic behavior and routing intent from vSmart controllers across the entire fabric. vSmart, which manages the overlay control plane via OMP, distributes centralized control policy (for OMP routes and TLOCs) and data-plane policies such as data, application-aware routing (app-route), and cflowd. These policies shape topology (hub-and-spoke, mesh restriction), select paths based on application performance, steer flows to services, and segment traffic by VPN. Because policies can alter both control-plane reachability and data-plane forwarding, careful design, preview, and staged deployment are essential to avoid outages.

Centralized Policy Types and Building Blocks

• Centralized control policy

  • Scope: Control plane (OMP) between WAN Edge devices and vSmart.
  • Purpose: Filter/modify OMP routes and TLOC advertisements, set attributes (preference, tag, origin, TLOC), and build topologies (hub-and-spoke, partial mesh).
  • Direction: Inbound (to vSmart from WAN Edge) and outbound (from vSmart to WAN Edge).

• Centralized data policy

  • Scope: Data plane classification (L3/L4, fields, app-ID) at WAN Edge, installed by vSmart.
  • Purpose: Permit/deny flows, set VPN, set TLOC, set DSCP/marking, police, mirror, and service insertion/chaining.
  • Direction: Evaluated at the WAN Edge relative to the service side (LAN) or tunnel side (WAN) depending on where it is programmed; designs typically target service-side ingress for user-to-WAN flows and tunnel-side for return if symmetric behavior is required.

• Application-aware routing (app-route) policy

  • Scope: Data-plane path selection based on application and SLA (loss, latency, jitter) measured by BFD.
  • Purpose: Steer traffic to preferred TLOCs/colors, define probe-based SLA classes, set fallbacks, and perform dynamic traffic engineering per application/family.
  • Key behavior: Continuously evaluates path performance; can switch paths when SLA degrades.

• cflowd policy

  • Scope: Flow telemetry (IPFIX/NetFlow-like) generated by WAN Edges.
  • Purpose: Enable/disable exporters per VPN, define sampling rates, templates, and collectors (vManage or external).
  • Design note: Sampling must balance visibility with CPU/bandwidth overhead; per-VPN enablement supports segmented reporting.

Policy lists are reusable match objects:

• Site list: Site IDs used to select where policies attach and to match route origin/destination sites.
• VPN list: VRFs (VPNs) used to segment policy scope and build per-segment rules.
• Prefix list: IP prefixes to match OMP routes or data traffic.
• Data prefix list: Specialized prefix object for data policy classification.
• TLOC list: Tuples of system IP, color, and encapsulation used to match or set TLOC attributes.
• Color list: One or more transport colors (e.g., biz-internet, mpls, public-internet) for targeting/link affinity.
• Application list: NBAR2 application/groups to classify traffic for app-route or data policies.
• SLA class: Latency, loss, jitter thresholds linked to app-route for performance-based steering.

Policy sequence structure and evaluation:

• Sequences are ordered, first-match wins. Each sequence has:
  • Match conditions: Lists/fields (site/VPN/prefix/TLOC/color/app, L4 ports, DSCP, protocol).
  • Actions: Accept/deny, set attributes (TLOC, VPN, DSCP, preference, tag), service insertion, police, mirror.
• Default action: Applied if no sequences match. Common defaults are accept (control/data) to avoid unintended drops; explicit deny defaults are used deliberately and require careful validation.
• Direction:
  • Control policy direction is at vSmart (inbound/outbound OMP).
  • Data and app-route policies operate on traffic at the WAN Edge; choose service-side or tunnel-side behavior to fit the flow you intend to affect, and ensure return traffic symmetry when stateful services are in-path.

Control-Plane Policy Design and Route/TLOC Manipulation

Control policy is the authoritative tool for shaping the overlay topology because it determines which OMP routes and TLOCs a site can send or receive:

• OMP route manipulation

  • Use inbound control policy to filter, tag, or set attributes on routes learned from a site before they enter the overlay RIB at vSmart.
  • Use outbound control policy to limit which routes are advertised to specific sites (e.g., do not advertise spoke-learned prefixes to other spokes).
  • Common actions: set preference (influences OMP best-path), set tag (for subsequent matching), set origin, set site-of-origin constraints.

• TLOC manipulation

  • Match on TLOC attributes (system IP, color, encap) to filter or prefer specific transports.
  • Actions include changing preferred TLOC attributes or preferences so route advertisements bias toward a given color (e.g., prefer MPLS for critical subnets).
  • Trade-off: Overly aggressive TLOC filtering can strand sites if the remaining transport fails. Prefer attribute tuning over blanket deny unless you have redundant paths.

• Topology patterns

  • Hub-and-spoke: Outbound control policy from vSmart to spokes denies advertisement of spoke-originated routes to other spokes; hubs receive and advertise all.
  • Mesh restriction: Similar to hub-and-spoke but permits specific spoke-to-spoke pairs (e.g., regional meshes) by exceptions in policy sequences.
  • Segmentation: Combine VPN lists with route filtering to keep per-VPN overlays isolated; advertise only default or select prefixes to constrained sites.

Failure modes and trade-offs:

• A misapplied outbound control policy with deny default can withdraw critical routes, isolating sites. Always default accept and add targeted denies unless your preview explicitly confirms coverage.
• Changing OMP attributes at scale can trigger route churn; stagger deployment by site lists to reduce control-plane shock.
• TLOC attribute rewrites can lead to asymmetric forwarding if the reverse path is not equivalently influenced; validate both directions.

Application-Aware Routing, Service Insertion, and Segmentation

Application-aware routing (AAR) and data policy together deliver fine-grained traffic engineering:

• AAR and traffic steering

  • SLA classes define acceptable loss/latency/jitter; BFD probes per TLOC pair feed real-time measurements.
  • App-route policy matches applications or L3/L4 fields and selects preferred color/TLOC lists; if SLA is violated, fail over per the policy.
  • Design tips:
    • Avoid tight SLA thresholds that cause flapping; include hysteresis using probe multipliers and reasonable thresholds.
    • For apps sensitive to packet reordering, prefer “move on next new flow” instead of mid-flow switches, or pin flows using consistent hashing where supported.
    • When both AAR and data policy set TLOC, give AAR precedence for path selection and use data policy for service insertion/marking; avoid overlapping actions in the same traffic class.

• Service chaining and service insertion

  • Data policy action “service” inserts traffic through on-prem or colocation services (firewall, IDS/IPS, SD-WAN service nodes).
  • Chain multiple services in order where required; ensure symmetric insertion for stateful services on both forward and return paths.
  • Trade-offs: Each service hop adds latency and potential failure domains. Implement health checks and fail-open/closed behaviors consistent with security posture.

• Traffic segmentation

  • VPNs provide hard segmentation; centralized policy applies per-VPN using VPN lists.
  • Inter-VPN routing (route leaking) can be achieved with data policy using “set VPN” for specific flows; strictly constrain with prefix/application matches and audit frequently.
  • For shared services (e.g., DNS, identity), advertise service prefixes from a services VPN to consumer VPNs with control policy rather than broad data-plane leaks.

Example app-route snippet illustrating SLA-based steering:

app-route-policy CRITICAL-APPS
  sequence 10
    match application-list BUS_APPS
    sla-class GOLD
    preferred-color mpls fallback biz-internet
  !
  sequence 20
    match application-list BEST_EFFORT
    sla-class BRONZE
    preferred-color biz-internet fallback public-internet
  !
  default-action accept
!

Operations: Attachment, Validation, and Troubleshooting

Policy attachment through vSmart:

• Define centralized policies in vManage and attach them to site lists and VPN lists. vSmart compiles the policy and distributes it to WAN Edges over secure DTLS/TLS OMP sessions in VPN 0.
• Scope changes carefully; a single policy instance can affect hundreds of sites. Use site lists to stage deployments by region or function.

Policy simulation, preview, and staged deployment:

• Preview: Before activation, use vManage preview to inspect device-specific compiled policy (what each WAN Edge will receive). Confirm match/action logic, default actions, and directions.
• Simulation: Use policy simulation to test flow matches and expected actions (e.g., which TLOC a given app/5-tuple will use). Validate SLA class mappings and application classification.
• Staged deployment:
  • 1. Attach to a canary site list (few sites).
  • 2. Monitor control and data-plane KPIs (OMP route counts, BFD, app-route hits).
  • 3. Expand the site list incrementally.
• Versioning and rollback: Maintain prior policy versions; if unexpected behavior is detected, deactivate the new policy or roll back to the previous version promptly.

Debugging unintended outcomes and precedence:

• Control-plane verification

  • show omp tlocs, show omp routes: Confirm the presence/absence of routes and TLOCs per policy intent.
  • show policy received/installed: Verify control policy counters and which sequences matched.
  • Symptom: Spokes cannot reach others after deployment → check outbound control policy deny lines to spokes and default actions.

• Data-plane and AAR verification

  • show app-route stats/flows and show bfd sessions: Validate SLA state and path decisions.
  • show sdwan policy service-path or equivalent: Confirm service insertion counters and chaining order.
  • show ip route vpn X and traceroute vpn X: Verify actual forwarding path.
  • Symptom: Unexpected path changes/flapping → relax SLA or adjust probe multipliers; ensure overlapping data policy is not also setting TLOC.

• Policy precedence and conflicts

  • AAR decisions typically take precedence for path selection; use data policy primarily for service insertion, marking, and access control.
  • Overlapping match criteria across policies can create ambiguity. Keep match domains mutually exclusive or introduce ordering and tags to disambiguate.
  • Default accept can mask missing sequences; add explicit “observe-only” counters (e.g., mirror/police low) or temporary logging to validate matches before enforcing denies.

• cflowd validation

  • show cflowd statistics/exporters: Ensure exporters per VPN are active and sampling as intended.
  • High CPU after enabling cflowd → increase sampling interval or narrow to essential VPNs/apps.

Practical Problem Scenario

Northwind Traders is migrating to Cisco SD-WAN and must enforce hub-and-spoke for PCI VPNs, steer Office 365 to the best Internet path, and insert a regional firewall service for guest traffic without impacting critical applications.

Approach:

1. Build policy lists

   • Create site lists: HUBS (data centers), SPOKES (branches).
   • Create VPN lists: PCI_VPN, GUEST_VPN, CORP_VPN.
   • Create application lists: O365, BEST_EFFORT.
   • Create color lists: PRIVATE (mpls), DIA (biz-internet, public-internet). Rationale: Reusable lists allow precise scope and safe staged rollout; separating VPNs supports segmentation.

2. Define SLA classes

   • GOLD: loss 0.5%, latency 100 ms, jitter 20 ms.
   • SILVER: loss 1%, latency 150 ms, jitter 30 ms. Rationale: Align thresholds to realistic transport performance to prevent path flapping; tighter for O365 than for best-effort.

3. Implement control policy for PCI hub-and-spoke

   • Inbound to vSmart: tag routes learned from SPOKES in PCI_VPN.
   • Outbound from vSmart: to SPOKES, advertise HUB routes and defaults; deny advertisement of SPOKE-originated PCI routes to other SPOKES; to HUBS, advertise all. Rationale: Topology is enforced at the control plane, ensuring spokes only learn each other through hubs and preserving segmentation in the PCI VPN.

4. Create app-route policy for O365 and best-effort

   • Match O365 in CORP_VPN with GOLD SLA; preferred color DIA with fallback PRIVATE.
   • Match BEST_EFFORT with SILVER; preferred PRIVATE with fallback DIA. Rationale: O365 performs best over direct Internet when SLA is met; fail back to MPLS as needed. Best-effort can prefer MPLS for cost/policy while allowing DIA fallback.

5. Insert regional firewall for guest traffic

   • Data policy in GUEST_VPN: service insertion to the regional firewall service chain on both forward (service side to WAN) and return (tunnel to service) directions.
   • Ensure the firewall service health is monitored; define fail-open for guest use case to preserve availability. Rationale: Stateful inspection requires symmetric traversal; bidirectional insertion avoids session drops. Guest risk tolerance allows fail-open if the service is down.

6. Attach policies via vSmart with staged rollout

   • Attach control policy to HUBS and a canary subset of SPOKES in PCI_VPN.
   • Attach app-route and data policies to a limited region first. Rationale: Limits blast radius; validates policy behavior before global expansion.

7. Validate and monitor

   • Preview compiled policies per device; confirm default actions.
   • Use simulation to test sample flows (O365 from CORP_VPN branch, guest web traffic from GUEST_VPN).
   • Monitor show omp routes/tlocs (PCI reachability), show app-route stats (O365 path), show policy service-path (guest firewall counters), and BFD sessions. Rationale: Confirms both control- and data-plane outcomes match design, and that SLA-driven steering operates as expected.

8. Expand and harden

   • Gradually add remaining SPOKES to the control policy attachment.
   • Tighten guest policy with rate limits; adjust O365 SLA thresholds if path oscillations occur. Rationale: Iterative tuning reduces operational risk and ensures stable user experience.

This sequence cleanly separates topology control (OMP) from data-plane steering and services, uses segmentation to protect PCI, applies SLA-based app routing for performance, and maintains operational safety through preview, simulation, and staged attachment.

← Data Plane Tunnels · All domains · Security →

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