ENSDWI Part 9: Data Policies, Segmentation, App-Aware Routing, and DIA

17 July 2026 Cisco ENSDWI SDWAN

Part 8 built topologies by editing routing information at vSmart. This part is the packet-plane half of the Policies domain: policies that vSmart distributes but edges execute, plus segmentation and DIA. Blueprint lines 4.2 through 4.5.

4.2 Centralized data policy

Matches packets (5-tuple, DSCP, application via SD-AVC) in a VPN and acts on them. Defined centrally, applied to site-lists + VPN-lists, pushed over OMP to edges and executed there — this is what shows up in show sdwan policy from-vsmart.

policy
 data-policy DP-GUEST
  vpn-list GUEST-VPN
   sequence 10
    match
     source-data-prefix-list GUEST-RANGE
     app-list STREAMING
    action drop
   !
   sequence 20
    match protocol 17 destination-port 53
    action accept
     set next-hop 10.99.1.10          ! or: set service FW / nat use-vpn 0 / set tloc ...
   !
   default-action accept
 !
apply-policy
 site-list BRANCHES
  data-policy DP-GUEST from-service

Key mechanics:

Direction on apply: from-service (LAN→WAN), from-tunnel (WAN→LAN), or all. Most Internet/guest policies are from-service.
Default action is drop for data policy — same trap shape as control policy’s reject, different keyword. (Data = drop, control = reject; the exam checks the vocabulary.)
Actions: accept/drop, set next-hop / TLOC / VPN (service chaining and leak), nat use-vpn 0 (DIA — below), nat pool, count, log, DSCP rewrite, forward to SIG.
Application matching needs SD-AVC/DPI; first packets of a new flow may classify late — describe-level awareness.
Localized data policy is the contrast case: ACLs/QoS defined in templates, applied per-interface on one device, not distributed by vSmart. “Configured in a feature template, applies to one interface” = localized; “built in vManage policy builder, applied to site lists” = centralized.

4.3 Segmentation: VPNs and per-VPN topologies

4.3.a VPN segmentation

Segmentation in Catalyst SD-WAN is VPN-based (IOS-XE calls them VRFs; OMP calls them VPNs — same thing, and the exam uses both words):

VPN 0 transport, VPN 512 management, VPNs 1–511 (excl. 512) service. Service VPNs are end-to-end segments: label-tagged in the tunnel, so one IPsec tunnel carries all VPNs with per-VPN separation (the label rides in the ESP-encapsulated packet, MPLS-over-IPsec-style — deep dive Part 4 shows the encap stack).
OMP advertises routes per VPN; edges install only VPNs they have configured. No route leaking between VPNs unless engineered (route leaking via OMP export/policy on cEdge, or service-side fusion router/firewall).
Inter-VPN traffic through a fusion point (firewall between VRFs at a hub) is the standard “Guest must not reach Corp, both need Internet” answer — same pattern as the multi-VRF guest Wi-Fi design on the Fortinet side of this site.

4.3.b Topologies per VPN

Because control policy can match vpn-list, each VPN can have its own topology: Corp VPN full-mesh, PCI VPN hub-and-spoke through the DC firewall, Guest VPN DIA-only with no site-to-site routes at all. One fabric, per-segment topology — implemented exactly with Part 8’s tools scoped by VPN. The exam phrase is “end-to-end segmentation with per-VPN topology”; the implementation is control policy + vpn-lists.

4.4 Application-aware routing (AAR)

The headline SD-WAN feature: steer applications onto paths that currently meet their SLA.

Measurement: BFD packets inside every tunnel carry timestamps; each poll interval (default 10 min, per Part 2) produces loss/latency/jitter per tunnel; app-route multiplier (default 6) sets how many intervals average into the verdict. Tighten both for faster reaction (minimums: 10 s poll in practice — know “defaults are tunable, default 10 min × 6”).

SLA classes define thresholds:

policy
 sla-class VOICE
  loss 1
  latency 150
  jitter 30

App-route policy binds apps to SLA classes:

 app-route-policy AAR
  vpn-list CORP
   sequence 10
    match app-list VOICE-APPS
    action sla-class VOICE preferred-color mpls
    ! backup-sla-preferred-color biz-internet

Behaviour rules the exam tests precisely:

Traffic uses preferred colors whose tunnels currently meet the SLA.
Preferred colors out of SLA → any other color meeting the SLA.
No path meets the SLA → traffic uses the best available path anyway — AAR never blackholes by default. (sla-strict/fallback tweaks exist; default forwards regardless.)
No SLA match at all (app not in policy) → normal routing.

AAR is also pushed via OMP and executed on edges (show sdwan policy from-vsmart again). Verification: show sdwan app-route stats, show sdwan app-route sla-class, and the vManage per-tunnel loss/latency/jitter charts — the standard exhibit shows one tunnel breaching latency and asks where voice goes.

4.5 Direct Internet access (DIA)

Break local traffic out of the branch straight to the Internet instead of backhauling. Two configuration routes, both tested:

Route-based: leak/point a default (or specific prefixes) from the service VPN at the VPN 0 transport interface with ip nat route vrf 10 0.0.0.0 0.0.0.0 global (cEdge) — all matching traffic in that VPN exits locally, NATed.
Policy-based: centralized data policy with action accept + nat use-vpn 0 for matched apps/prefixes — per-application DIA (O365 local, everything else via DC). Add fallback so matched traffic reroutes over the overlay if the local exit dies — without fallback, a dead DIA path blackholes the matched traffic. That distinction is a known exam question.

Requirements either way: NAT enabled on the VPN 0 transport interface (interface ... / nat), and for app-granular DIA, SD-AVC. Security follow-on: DIA exposes the branch — pair with the embedded firewall/IPS or SIG redirect, which is Part 10’s whole subject and how the exam links the two domains.

Cross-reference: Cloud OnRamp for SaaS chooses the best Internet exit per app; DIA is the local exit. OnRamp SaaS in DIA mode rides on exactly this NAT plumbing.

Policy-type summary table (memorise)

Policy	Built	Executes	Default action	Matches
Control	vManage → vSmart	vSmart	reject	OMP/TLOC routes
Centralized data	vManage → OMP → edge	edge	drop	packets (5-tuple/app/DSCP)
App-route (AAR)	vManage → OMP → edge	edge	route normally	flows vs SLA classes
Localized (ACL/QoS)	template → device	edge interface	per-ACL	packets on one device

Exam traps for this domain

Data policy default = drop; control policy default = reject. Vocabulary is tested.
from-service vs from-tunnel on data-policy application — read the direction.
Labels segment VPNs inside one tunnel; there is not a tunnel per VPN.
Per-VPN topology = control policy scoped with vpn-lists.
AAR with nothing meeting SLA still forwards (best path) — it degrades, it doesn’t drop.
AAR reaction time = poll interval × multiplier; defaults 10 min × 6.
DIA via data policy needs nat use-vpn 0, NAT on the transport interface, and fallback if overlay backup is expected.

Part 10 picks up where DIA’s security hole left off: service insertion, the embedded security stack — firewall, IPS, URL filtering, AMP, SSL/TLS proxy, TrustSec — and cloud security with Umbrella DNS and SIG.