Cisco Catalyst SD-WAN centralizes policy, but not every policy changes the same part of the network.

A centralized control policy changes routing information and topology decisions in the overlay control plane.

A centralized data policy changes how actual packets are treated or steered in the data plane.

That difference is foundational to the current 300-415 ENSDWI v1.2 exam and to real SD-WAN troubleshooting. When a policy produces an unexpected result, the first question should be whether the engineer intended to change route distribution or packet forwarding.

Control policy operates on routing information

Cisco documents centralized control policy as a mechanism that operates on OMP routes and TLOC information.

The policy is provisioned centrally on the Cisco SD-WAN Controller and can influence which routes enter the controller’s route table, how attributes are modified, and which routes are advertised to edge devices.

That makes control policy appropriate for decisions such as:

• changing route preference
• influencing which TLOC is preferred
• changing OMP tags
• accepting or rejecting routes
• building hub-and-spoke routing behavior
• steering route advertisements toward a service

The policy changes what the overlay believes about reachability.

It is therefore closer to routing policy than to an ACL applied to every packet.

Control policy can be applied on the inbound or outbound side of the controller’s OMP processing depending on the policy design. That gives the administrator a way to influence what enters the controller’s routing view and what a selected set of sites receives. Site lists, VPN lists, prefix lists, TLOC lists, and other match objects make the policy reusable across many edges without configuring each router independently.

The important design question is scope. A route-policy change that is intended for one region or one service VPN should not be attached so broadly that it changes reachability for unrelated sites. Centralization increases consistency, but it also increases the blast radius of a badly scoped policy.

The controller evaluates control policy

A centralized control policy remains on the controller.

Cisco’s current documentation emphasizes that the policy itself is not pushed to the edge devices. The controller evaluates the policy against OMP routing information and distributes the resulting route information.

That distinction is operationally important.

If the problem is “this branch never learned the remote prefix,” inspect centralized control policy and OMP advertisement behavior.

Do not start by debugging a data-plane packet rule if the route never reached the branch in the first place.

Cisco SD-WAN controllers provide the centralized control-plane context in which OMP policy is evaluated and route outcomes are distributed to edge devices.

Cisco’s current policy architecture makes the execution location explicit. Control policy and VPN-membership decisions are evaluated on the SD-WAN Controller. Centralized data policy and application-aware routing are distributed to the relevant IOS XE Catalyst SD-WAN edges, where packet actions occur.

That is why a centralized data policy can affect traffic without turning the controller into a transit hop. The controller is the policy authority; the edge is the enforcement point. When troubleshooting, confirm both that the intended policy was activated centrally and that the target edge actually received and installed the policy.

Data policy operates on packets

Centralized data policy is different.

Cisco describes it as affecting the flow of data traffic through the VPN segments.

Instead of deciding which routes exist, a data policy can match traffic characteristics and apply forwarding actions.

Depending on feature and release, data-policy actions can be used for functions such as:

• policy-based path steering
• service insertion
• packet marking
• QoS treatment
• dropping selected traffic
• changing next-hop behavior

The key is that the route can already exist.

The data policy changes what happens to packets that match the policy.

Data-policy matches can be much more specific than a routing advertisement. The policy can distinguish traffic by VPN, prefixes, protocol, DSCP, application, ports, or other supported fields, then apply the action only to those flows.

That granularity is useful for service insertion, direct internet access, selective path steering, marking, or filtering. It also means a data-policy mistake can affect one application while ordinary pings and route lookups continue to look correct. Packet symptoms and counters become more important than route existence in that situation.

Control policy answers “where should reachability go?”

Consider a hub-and-spoke topology.

A centralized control policy can change which OMP routes are advertised so that spoke sites learn paths through a designated hub rather than learning direct paths to every other spoke.

The forwarding behavior changes because the route information distributed to the spokes changed.

That is a control-plane decision.

A generic policy-based routing article can help illustrate packet-steering logic, but centralized SD-WAN control policy should not be reduced to PBR. Control policy works on OMP routing information before the edge makes normal forwarding decisions.

Data policy instead answers “what should happen to matching traffic?”

Now imagine the route remains the same but selected traffic needs different treatment.

A data policy can match source/destination information, applications, prefixes, protocol characteristics, or other supported fields and apply an action.

The routing table may still contain the same destination prefix. The packet treatment changes because the data policy matched.

That makes data policy useful for traffic-specific requirements that should not require changing route advertisement for the entire VPN.

A hub-and-spoke example shows why control policy is powerful. Rather than adding static routes at every branch, the controller can advertise different OMP information to hubs and spokes so the topology is expressed through route distribution. Spokes can be prevented from learning direct spoke routes while hubs learn the broader set needed for transit.

The same technique can create regional topologies, preferred exits, or service chains by changing which routes or TLOCs are accepted, modified, or advertised. Because the result becomes part of each edge’s routing view, the effect applies to all matching traffic unless another forwarding policy later changes packet treatment.

Application-aware routing is another data-plane policy type

Cisco separates application-aware routing from basic centralized control policy.

Application-aware routing uses SLA classes and BFD path measurements to select a tunnel that meets application requirements.

The policy is configured centrally, but the action is executed on edge devices because it affects packet forwarding.

This is a good example of why “centralized” does not mean “the controller forwards the packets.”

The controller is where intent is defined. The edge is still where user traffic is actually forwarded.

For a data policy, the routing table can remain unchanged while one traffic class is redirected to a service, assigned a preferred next hop, remarked, or dropped. This is conceptually closer to policy-based routing than control policy is, but SD-WAN data policy is integrated with VPN, application, and overlay constructs rather than being only a local interface feature.

A good diagnostic test is to compare two flows to the same destination. If one application follows the normal route and another does not, the difference strongly suggests data-plane classification or policy rather than a missing OMP route.

Default actions can surprise engineers

Policy behavior after a non-match matters.

Cisco’s centralized policy documentation describes explicit default behavior for routes or packets that do not match configured sequences.

An engineer who understands only the match clauses can therefore create an outage even when every sequence looks correct individually.

Always inspect:

• sequence order
• match conditions
• accept/reject behavior
• actions
• the policy’s default action
• where the policy is applied

Policy is evaluated as a complete ordered system, not as isolated lines.

Application-aware routing belongs in the same execution family as data policy because it ultimately chooses how matching packets use available tunnels. The policy can be defined centrally, but the edge evaluates real-time BFD SLA information and selects the forwarding path locally.

This is also why app-route behavior can coexist with control policy. Control policy determines which candidate routes and TLOCs are available to the site. Application-aware routing chooses among viable tunnels for a specific traffic class. If control policy removed a path entirely, AAR cannot select it no matter how good its latency would have been.

Control policy can modify route attributes

Centralized control policy can change OMP attributes that affect path selection.

For example, preference can influence which OMP path is chosen when multiple advertisements exist.

A TLOC-related action can influence which transport locator is associated with accepted route information.

This is why control policy interacts so closely with OMP.

If an edge prefers an unexpected transport, inspect both the route’s OMP attributes and the policy that modified them.

The broad Cisco SD-WAN architecture article is useful prerequisite reading, but policy troubleshooting requires looking at the actual route and TLOC attributes.

Sequence order and default behavior deserve the same care as match conditions. A broad early sequence can prevent a later specific sequence from ever being reached. A default reject or default accept can change what happens to every packet or route that did not match the explicit rules.

Before activation, read the policy top to bottom as a decision tree. After activation, verify counters, route advertisements, and policy state on a limited site set when possible. Central policy is easier to manage at scale precisely because one definition can affect many devices; that same leverage is why staged validation matters.

Data policy can change forwarding without changing OMP

A data policy can steer or treat packets even though OMP distributed the route normally.

This separation is valuable because it lets the network keep a stable routing view while enforcing traffic-specific behavior.

It also gives troubleshooting a clean boundary.

If the route table looks right but packet behavior is wrong, data policy is a stronger suspect than centralized control policy.

If the route itself is missing or has the wrong preferred path before packet matching occurs, start in the control plane.

Route attributes give control policy a way to express preference without removing all alternatives. For example, changing OMP preference can make one candidate path more attractive while leaving another available for resilience. TLOC actions can influence which transport attachment is associated with the route.

That is different from a packet-level steering rule. If the unexpected behavior is visible in the OMP route before any user packet arrives, investigate the control policy. If OMP looks correct but only matching traffic is treated differently, investigate the data or app-route policy.

A practical decision framework

Use centralized control policy when the requirement is fundamentally about:

• route advertisement
• topology
• path preference
• OMP attributes
• which sites learn which routes

Use centralized data policy when the requirement is fundamentally about:

• packet matching
• traffic steering
• service insertion
• marking
• dropping
• forwarding behavior after the route already exists

Use application-aware routing when traffic should select among available tunnels based on measured SLA quality.

This framework prevents a common design mistake: using a packet policy to solve a routing-distribution problem, or changing route advertisements when only one application needs special treatment.

The most useful policy habit is to name the object you are trying to change before choosing the policy type. If the object is OMP reachability, topology, or route attributes, start with control policy. If the object is a packet or application flow after reachability already exists, start with data policy or application-aware routing. Then verify the result where that policy executes—the controller for route decisions and the edge for packet treatment.