Data Policy and Service Chaining: The Bypass Nobody Reports

Control policy and data policy are both written on the controller, both activated centrally, and do entirely different things. Control policy shapes what sites learn — it acts on advertisements, before any packet exists. Data policy acts on packets, and although it is authored centrally it is enforced at the edge routers rather than on the controller. Confusing the two produces requirements aimed at the wrong mechanism, which is why a surprising number of "the policy is not working" cases are a policy that was never capable of doing what was asked. The first question about any policy requirement is therefore which of the two it belongs to, and the answer is rarely ambiguous once the question is asked.

Service chaining is the most interesting thing data policy does and the one with the most moving parts. Steering traffic through a firewall that lives at a different site requires three independent things to be true: the service must be advertised, the policy must reference it, and the path to it must exist. Any one of them missing produces traffic that either bypasses the inspection silently or disappears — and which of those happens is a behaviour worth establishing deliberately rather than discovering. That single question turns out to be the most consequential decision in the whole arrangement.

This article covers what data policy can do that control policy cannot, how matching and direction work, how service chaining is assembled end to end, what happens when the service is unreachable, and the failures that send traffic somewhere nobody intended. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.

Blog ClaimA service chain has three independent parts — the advertisement, the policy and the path — and the failure mode when one is missing is traffic that silently skips the inspection it was supposed to receive, which is worse than traffic that stops.

Control policy acts on advertisements at the controller; data policy acts on packets at the edge. A service chain requires an advertisement, a policy that names it, and a path to the site hosting it.

What Does a Data Policy Do That a Control Policy Cannot?

What is the division?

Control policy decides what a site knows; data policy decides what happens to a packet. Anything expressed in terms of protocols, ports, applications or actions on traffic is data policy territory, and anything expressed in terms of which sites can reach which is control policy territory. The two overlap at exactly one point — both can stop two sites communicating — and they do it differently enough that the choice matters.

A Deeper Dive into the Division

Where each is enforced

This is the structural difference and it explains most of the rest. Control policy runs on the controller as advertisements pass through it, so its effect is baked into what the edge receives. Data policy is pushed to the edges and runs there, on every packet, which is why it can act on packet contents the controller never sees and why its counters live on the edge rather than centrally.

! Control policy: read on the CONTROLLER
vSmart# show running-config policy
vSmart# show omp routes vpn 10
!
! Data policy: read on the EDGE, where it runs
Edge# show sdwan policy from-vsmart
Edge# show sdwan policy data-policy-filter
! ^ the counters are here because the enforcement is here
!
! Both were authored centrally. Only one is enforced centrally.

Blocking, done two ways

Stopping two sites communicating can be done by control policy — withhold the routes so neither knows how to reach the other — or by data policy, which drops the packets. The first is cleaner and is not a security control, because a site that learns the prefix another way can still reach the destination. The second is an actual filter. Choosing between them is a question of whether the requirement is topological or security-driven.

Requirement	Mechanism	Strength
Branches should not have direct tunnels	Control policy	Topological — not a filter
Branches must not reach each other at all	Data policy drop	Enforced per packet
Block one protocol between two sites	Data policy	Only data policy sees ports
Force traffic through a firewall	Data policy service action	Per packet, per match
Prefer one transport for an application	Application-aware routing	A third policy type

The actions available

Accept and drop are the obvious pair. Beyond them, a data policy can steer traffic through an advertised service, pin it to a specific transport, change its routing context, send it out of a local internet circuit, rate limit it, re-mark it, or count and log it. That list is what makes data policy the general-purpose tool, and it is also why a data policy accumulates responsibilities over time until nobody is sure what it does.

! A data policy with several actions, for illustration
policy
 data-policy BRANCH-POLICY
  vpn-list CORPORATE
   sequence 10
    match
     app-list SOCIAL
    action drop
     count SOCIAL-DROPPED
    !
   !
   sequence 20
    match
     destination-data-prefix-list INTERNET
    action accept
     nat use-vpn 0
     ! ^ direct internet access from the branch
    !
   !
   sequence 30
    match
     destination-data-prefix-list DATACENTRE
    action accept
     set service FW vpn 10
    !
   !
   default-action accept
  !
 !
!

Three policy types, not two

Alongside control and data policy there is a third that acts on traffic: application-aware routing, which chooses a transport based on measured path quality. It overlaps with data policy in that both can influence which tunnel traffic uses, and it differs in that its decision is continuous and driven by measurement rather than fixed by a match. Knowing which of the three owns a requirement is the first step in every policy conversation.

The practical rule is that data policy makes a decision once, from the packet's contents, and application-aware routing makes a decision repeatedly, from the network's condition. A requirement to send an application over a particular circuit is data policy. A requirement to send it over whichever circuit currently meets a quality target is not, and writing it as data policy produces something that pins traffic to a path regardless of how that path is performing.

Counting, which should be on by default

Every sequence can carry a counter, and adding one to each costs nothing and turns an opaque policy into an observable one. Without counters, establishing whether a sequence ever matches requires inference; with them it is a single command. This is the cheapest improvement available to any data policy and it is omitted more often than not.

! A counter on every sequence, named after what it does
sequence 10
 match
  app-list SOCIAL
 action drop
  count SOCIAL-DROPPED
 !
!
! Then the policy becomes readable at runtime
Edge# show sdwan policy data-policy-filter
NAME               COUNTER NAME        PACKETS      BYTES
BRANCH-POLICY      SOCIAL-DROPPED      184,221      24,188,392
BRANCH-POLICY      DIA-PERMITTED       2,041,882    1,884,022,104
BRANCH-POLICY      FW-STEERED          0
! ^ a zero counter on a sequence that should be busy
!   is the fastest possible diagnosis

Authored centrally, enforced locallyA data policy is written once and runs in many places, which means its counters are per edge and a question like "is this rule being hit" has a different answer at every site. Checking one site tells you about that site, and comparing two sites is frequently how an unexpected difference is found.

Sub claimControl policy runs on the controller and data policy runs on the edges, which is why one can act on advertisements the other never sees and the other can act on packet contents the first never sees.

How Is a Data Policy Matched and Applied?

What decides whether a packet is considered?

Three scopes, all of which must include the packet. The site list decides which edges receive the policy at all. The routing context list decides which contexts it applies within. And the direction decides which packets on those edges are examined — those arriving from the local network, those arriving from the overlay, or both. A policy that appears to do nothing has usually failed one of those three rather than failed its match.

A Deeper Dive into Matching

Direction, which is the usual mistake

Traffic entering an edge from the local network and traffic arriving from a tunnel are different populations, and a policy applied to the wrong one examines packets that were never the ones in question. Steering branch traffic towards a firewall means examining what arrives from the branch's own network, which is the service-side direction. Applying it to the tunnel side examines traffic arriving from other sites, which is a different requirement entirely.

! The three scopes, and the direction among them
apply-policy
 site-list BRANCHES
  data-policy BRANCH-POLICY from-service
  ! ^ examines packets arriving from the branch LAN
 !
 site-list HUBS
  data-policy HUB-POLICY from-tunnel
  ! ^ examines packets arriving from the overlay
 !
!
! 'all' examines both, and is the right answer less often
! than it is used, because it doubles what the policy
! has to be correct about.
!
Edge# show sdwan policy from-vsmart | include direction|data-policy

What can be matched

Addresses, ports and protocols as expected, plus two more that make the policy expressive: marking, which allows a policy to act on decisions made elsewhere, and application identity, which allows it to act on what the traffic is rather than on which port it happens to use. Application matching is the one that makes policies readable — a rule about a named application communicates intent in a way a port list does not.

! Lists make a policy readable and maintainable
policy
 lists
  data-prefix-list DATACENTRE
   ip-prefix 10.50.0.0/16
  !
  app-list SOCIAL
   app facebook
   app twitter
  !
  app-list BUSINESS-CRITICAL
   app-family enterprise-applications
  !
  vpn-list CORPORATE
   vpn 10
  !
  site-list BRANCHES
   site-id 100-999
  !
 !
!

Sequence order and the default action

First match wins, as usual, and the default action decides what happens to everything unmatched. Unlike control policy, where a reject default is a reasonable allow-list design, a drop default on a data policy discards all traffic that the sequences did not explicitly handle — which is every protocol nobody thought about. It is occasionally the right choice and it needs to be a decision rather than an oversight.

! The two defaults, and what each implies
data-policy PERMISSIVE
 vpn-list CORPORATE
  sequence 10
   match
    app-list SOCIAL
   action drop
  !
  default-action accept
  ! ^ deny-list: only what is named is dropped
 !
!
data-policy STRICT
 vpn-list CORPORATE
  sequence 10
   match
    destination-data-prefix-list APPROVED
   action accept
  !
  default-action drop
  ! ^ allow-list: everything else stops, including DNS,
  !   management traffic and anything not yet thought of
 !
!

Application matching and what it depends on

Matching on application identity rather than on ports makes a policy express intent, and it introduces a dependency worth understanding: something has to identify the application, and that identification is not instantaneous. The first packets of a flow are frequently classified as unknown, because there is not yet enough of the conversation to tell what it is. Whatever the policy does with unknown traffic therefore applies to the opening of every flow.

For an accept-based rule that is harmless. For a rule that drops or steers, it means the first packets may take a different path from the rest of the flow, which for a stateful device in the path can be the difference between a working connection and a broken one. Designs that steer by application through a stateful service deserve a test with real traffic rather than a ping.

Localised policy, which is a different object

Alongside the centrally authored data policy, an edge can carry access lists applied directly to its interfaces. These are useful for site-specific requirements that do not belong in a central object, and they are enforced independently — so a packet can be permitted centrally and dropped locally, or the reverse. When behaviour does not match the central policy, a local access list is one of the first things to rule out.

! Local access lists exist alongside the central policy
Edge# show sdwan policy access-list-counters
Edge# show sdwan running-config policy
!
! Versus what arrived from the controller
Edge# show sdwan policy from-vsmart
!
! Both can act on the same packet. If the observed
! behaviour does not match the central policy, check
! whether something local is also involved.

Pitfall: the policy applied in the wrong direction Symptom: a data policy is active, present on the edge, and its counters are all zero. The traffic it was written for is flowing normally and is clearly not being examined. Cause: the direction selects which packets the policy inspects, and a policy meant for traffic leaving the branch applied to traffic arriving from the overlay never sees it. Nothing errors, because examining the other direction is a legitimate thing to do. Confirm: show sdwan policy data-policy-filter shows zero on every sequence while the site is clearly busy. Fix: change the direction in the application, and add counters to every sequence so that this state is visible in one command rather than inferred.

Sub claimThree scopes must all include a packet before a data policy examines it, which makes an all-zero counter a scope problem rather than a match problem and points at the direction first.

How Does Service Chaining Actually Work?

What has to be in place?

The site hosting the service advertises it, which puts it in the overlay's service table. A data policy at the source references it by name. And a path to the hosting site must exist, because steering traffic there is an ordinary forwarding operation once the decision is made. Three independent pieces, configured in different places, and a chain is only as good as the weakest of them.

A Deeper Dive into Service Chaining

Advertising the service

The hosting site declares that it offers a service of a particular type at a particular address, and that declaration is distributed as its own advertisement type. Naming it by type rather than by address is what makes the policy portable: a policy that references a firewall keeps working when the firewall is replaced or moved, because the reference is to the role rather than to the device.

! At the site that hosts the firewall
sdwan
 service FW address 10.50.0.250
 ! ^ 'FW' is the type; the address is where it lives
!
! Confirm it entered the overlay's service table
HUB-1# show sdwan omp services
ADDRESS                                     PATH
FAMILY   VPN  SERVICE  ORIGINATOR    FROM PEER   ID    LABEL  STATUS
---------------------------------------------------------------------
ipv4     10   FW       10.255.0.11   10.255.0.2  22    1005   C,I,R
!
! And that a remote site can see it
BRANCH-1# show sdwan omp services | include FW
! ^ if this is empty, no policy referencing FW can work

Referencing it from the policy

! Steer data centre traffic through the firewall
policy
 data-policy BRANCH-POLICY
  vpn-list CORPORATE
   sequence 30
    match
     destination-data-prefix-list DATACENTRE
    action accept
     set service FW vpn 10
     count FW-STEERED
    !
   !
   default-action accept
  !
 !
!
apply-policy
 site-list BRANCHES
  data-policy BRANCH-POLICY from-service
 !
!
! The counter is what proves it is being used
BRANCH-1# show sdwan policy data-policy-filter | include FW-STEERED

What the path looks like

Traffic matched by the policy is forwarded to the site hosting the service instead of directly to its destination. That site delivers it to the service, the service returns it, and the site then forwards it onward. From the branch's perspective the destination is unchanged; only the path is different. A trace from the branch shows the service site as an intermediate hop, which is the clearest confirmation that the chain is engaged.

! The service site should appear as a hop
BRANCH-1# traceroute vrf 10 10.50.1.100
!
! Compare against a destination NOT matched by the policy
BRANCH-1# traceroute vrf 10 10.60.1.100
! ^ this one should go directly
!
! And the counters at both ends
BRANCH-1# show sdwan policy data-policy-filter | include FW-STEERED
HUB-1#    show sdwan omp services | include FW

Return traffic, which is a separate decision

A policy applied to traffic leaving a branch says nothing about the replies coming back. Those arrive at the destination site from the overlay and are governed by whatever policy applies there — frequently none. For a stateful service that is a problem, because inspecting one direction and not the other means the device sees half a conversation and may discard it.

Designs that steer through a stateful service therefore need symmetry arranged deliberately: either both directions steered through the same service site, or the service placed where the traffic naturally passes in both directions. The second is easier and is another argument for placing services on the path rather than building detours to them.

! Check both directions, not just the one you configured
BRANCH-1# show sdwan policy data-policy-filter | include FW-STEERED
HUB-1#    show sdwan policy data-policy-filter
! ^ is anything steering the return traffic?
!
! And the practical test: a real session, not a ping
!   a ping may succeed while a TCP session fails,
!   because only the latter needs both directions
!   to pass the same stateful device

Chaining more than one service

Several services can be applied in sequence, and each one is another detour. The latency cost is cumulative and so is the failure surface — a chain through two services at two sites depends on both sites, both services and both paths. Long chains are technically supported and operationally expensive, and the usual advice is to put services where the traffic already goes rather than building detours to reach them. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.

Design	Latency cost	Failure surface	Suits
Service at the destination site	None	The site itself	Most cases — put it where traffic goes
Service at a hub on the path	Low	The hub	Hub-and-spoke topologies
Service at a dedicated site	A detour each way	That site plus its paths	Centralised inspection requirements
Two services at two sites	Two detours	Both sites, both paths	Rarely worth it

The chain is invisible from the destinationA server receiving inspected traffic sees an ordinary connection from the branch; nothing in the packet says it was steered. That makes the chain unverifiable from either endpoint and confirmable only from the network — the steering counter at the source and the trace showing the service site as a hop.

Put the service where the traffic already goesA chain that steers traffic to a site it was already traversing costs nothing in latency and adds no new dependency. A chain that sends branch traffic across the country to be inspected and back again costs on every packet and depends on a path that has nothing else to do with the conversation. The first is almost always achievable with some thought about placement.

Sub claimA service is referenced by role rather than by address, which is what lets the device behind it change without touching the policy and what makes the advertisement — not the address — the thing that must be verified.

What Happens When the Service Is Unavailable?

Why does this need deciding?

Because there are two defensible answers and they are opposites. Traffic can bypass the unavailable service and continue to its destination uninspected, which preserves connectivity and silently removes a security control. Or it can be discarded, which preserves the control and turns a service outage into a connectivity outage. Both are reasonable and the choice belongs to whoever owns the requirement, not to whoever configures it.

A Deeper Dive into Unavailability

Establish the behaviour rather than assume it

The behaviour when a referenced service cannot be reached varies by platform and release, and it is not something to infer from a diagram. The way to know is to test it: take the service out of the picture in a lab or a controlled window, send matched traffic, and observe whether it arrives. That takes a few minutes and it answers a question that otherwise gets answered during an incident, by users.

! Establish the behaviour deliberately, in a window
!
! 1. Confirm the chain is working first
BRANCH-1# show sdwan policy data-policy-filter | include FW-STEERED
BRANCH-1# traceroute vrf 10 <destination>
!
! 2. Remove the service advertisement at the host site
HUB-1(config)# sdwan
HUB-1(config-sdwan)# no service FW address 10.50.0.250
!
! 3. Observe what matched traffic now does
BRANCH-1# show sdwan omp services | include FW
BRANCH-1# traceroute vrf 10 <destination>
! ^ does it arrive, and does it still pass through
!   the service site, or does it stop?
!
! 4. Restore, and write the answer down

Which answer suits which requirement

If the inspection is	The right failure mode is	Because
A regulatory requirement	Discard	Uninspected traffic is a compliance breach
A security control on untrusted traffic	Discard	Bypassing it defeats its purpose
Optimisation or visibility	Bypass	The traffic is fine without it
Inspection of internal, trusted traffic	Usually bypass	Availability outweighs the control

Stating the choice where it will be found

Whichever behaviour is chosen, it needs to be written down somewhere an incident responder will look, because at three in the morning the difference between "traffic is being dropped because the firewall is down, as designed" and "traffic is being dropped for an unknown reason" is the difference between a five-minute call and a long one. The policy itself is not that place; a runbook entry for the service is.

The same note should say what the intended recovery is. If the design is to discard, then restoring the service is the only fix and nobody should be looking for a network fault. If the design is to bypass, then the urgent question is a security one rather than a connectivity one, and a different team needs to know immediately.

Making the service itself redundant

The cleanest answer to the question is to make it rarely relevant. A service advertised from two sites gives the chain an alternative, so a single service or site failure does not force the bypass-or-discard decision at all. That is more configuration and it removes the failure mode rather than choosing how to handle it, which is generally the better engineering. It also removes the need to explain the chosen failure behaviour to anybody, because the situation that triggers it stops arising.

! The same service type advertised from two sites
! ===== HUB-1 =====
sdwan
 service FW address 10.50.0.250
!
! ===== HUB-2 =====
sdwan
 service FW address 10.51.0.250
!
! Both appear in the service table
BRANCH-1# show sdwan omp services | include FW
ipv4  10  FW  10.255.0.11  10.255.0.2  22  1005  C,I,R
ipv4  10  FW  10.255.0.12  10.255.0.2  23  1005  C,I,R
! ^ two originators. Losing one leaves the chain intact.

Monitoring the chain rather than the service

A firewall being up is not the same as the chain being engaged, and monitoring the appliance tells you nothing about whether traffic is reaching it. The counter on the steering sequence is the measure that matters: it rises when traffic is being sent through the service and stops when it is not, whatever the reason. That one number covers the advertisement, the policy and the path at once.

! The one measurement that covers all three parts
BRANCH-1# show sdwan policy data-policy-filter | include FW-STEERED
!
! A counter that stops rising means one of:
!   the advertisement is gone
!   the policy stopped matching
!   the path to the service site is down
! ...and any of them means traffic is no longer inspected.
!
! Supporting detail if it does stop
BRANCH-1# show sdwan omp services | include FW
BRANCH-1# show sdwan bfd sessions | include 10.255.0.11

A silent bypass is the worst outcome and the most likely defaultTraffic continuing to its destination uninspected produces no alarm, no user report and no counter that anybody is watching. If the inspection matters, the thing to monitor is the steering counter rather than the appliance, because only the counter distinguishes "inspected" from "delivered".

Sub claimThe behaviour when a service is unreachable is a policy decision with two defensible answers, which makes establishing it by test — rather than inferring it — part of deploying a chain rather than an optional extra.

Which Data Policy Failures Send Traffic Somewhere Unexpected?

What are the failures worth memorising?

Four. The wrong direction, which examines the wrong packets. A drop default action that discards protocols nobody considered. A service referenced but never advertised, which silently bypasses. And a sequence order where a broad early rule shadows a specific later one, so the specific rule never runs.

A Deeper Dive into the Failure Catalogue

The service that was never advertised

Pitfall: a policy referencing a service no site advertises Symptom: the policy is active, the sequence matches traffic, and the traffic reaches its destination without passing through the firewall. Nothing errors and the security control is simply absent. Cause: the service action names a service type that is not in the overlay's service table, because the hosting site never advertised it or the advertisement was lost in a configuration change. The policy has nothing to steer towards. Confirm: show sdwan omp services on the branch does not list the service; the steering counter is zero or the traffic counter and the steering counter disagree. Fix: restore the advertisement at the hosting site, and monitor the steering counter so that this state is detected rather than discovered.

The shadowed sequence

Pitfall: a broad sequence placed before a specific one Symptom: a rule that should steer or drop particular traffic never matches, and its counter stays at zero while an earlier, broader rule's counter climbs. The specific rule is present and correct. Cause: first match wins, and a broad accept placed earlier consumes the packets the specific rule was written for. This is the same shadowing that affects any ordered rule list and it is easier to introduce here because sequences are added over time by different people. Confirm: counters — the zero one is shadowed and the busy one above it is the culprit. Fix: reorder so that specific rules precede general ones, and use the counters as the evidence rather than reading the policy.

The drop default

Pitfall: default-action drop on a policy written as a deny-list Symptom: activating the policy breaks far more than intended at every site it applies to — name resolution, management access, monitoring, anything the sequences did not explicitly permit. Cause: the sequences name what should be dropped, implying everything else should pass, and the default action says otherwise. Unlike a control policy, where the effect is missing routes, here the effect is discarded packets. Confirm: the default-action counter, if present, is climbing rapidly; affected traffic is diverse and has nothing in common except not being named. Fix: roll back, then set the default deliberately — and put a counter on the default action so its behaviour is visible.

A diagnostic order that works

! Scope, then match, then action
!
! 1. Did the policy reach this edge at all?
Edge# show sdwan policy from-vsmart
!
! 2. Is it examining the right direction?
Edge# show sdwan policy from-vsmart | include direction|from-
!
! 3. Is any sequence matching?
Edge# show sdwan policy data-policy-filter
! ^ all zeros = scope problem, not a match problem
!
! 4. Is the right sequence matching?
! ^ a busy broad rule above a zero specific rule
!   is shadowing
!
! 5. For a service action, does the service exist?
Edge# show sdwan omp services
!
! 6. Anything local also acting on this traffic?
Edge# show sdwan policy access-list-counters

Reviewing a policy that has grown

A data policy accumulates sequences over years as requirements arrive, and the usual end state is an object nobody fully understands where every sequence was added for a reason that is no longer recorded. The counters are what make a review possible: a sequence that has matched nothing in a month is a candidate for removal, and one that is busy is evidence of a requirement still in force.

The review that works is mechanical rather than analytical. Collect counters from a representative set of sites, list the sequences with no matches, and ask their owners whether the requirement still exists. That converts an intimidating document into a short list of specific questions, and it is the only way a long-lived policy stays comprehensible. Doing it annually keeps the object roughly the size it needs to be rather than the size it has accumulated to.

What to monitor

Counters on every sequence, collected per site, with two specific alerts. A sequence whose counter is zero at a site where it should be busy, which catches scope and shadowing problems. And a steering counter that stops rising, which catches every way a service chain can silently disengage. Both are cheap, both have known expected values, and neither is covered by anything else. Between them they detect every failure described in this section.

Testing a policy before it reaches the estate

A data policy applies to every site in its list simultaneously, so the useful precaution is to apply it to one site first. A site list containing a single identifier, verified with counters and a real session, proves the policy does what was intended before the list is widened — and the widening is then a one-line change to something already known to work.

This is worth more here than for control policy, because a data policy's failures affect packets rather than advertisements and are therefore visible to users immediately. A control policy mistake leaves routes missing; a data policy mistake drops traffic. The same caution costs the same effort and prevents a larger class of incident.

Blueprint framing

The CCIE Enterprise Infrastructure v1.1 blueprint covers SD-WAN policy within the software-defined infrastructure domain. Data policy questions are usually phrased as an outcome — send this traffic through that service, block this between those sites — and the marks are in the scoping: the right site list, the right routing context, and above all the right direction. Being able to explain where a data policy is enforced, as distinct from where it is written, covers the conceptual half.

Put a counter on every sequence, including the defaultIt costs one line per sequence and converts the whole policy from something that has to be reasoned about into something that can be read at runtime. Every failure in this section is visible in the counter output, and most of them are visible at a glance.

Sub claimAll four failures are visible in the sequence counters and none is obvious from reading the policy, which makes counting the single highest-value thing to add to any data policy.

Conclusion

Data policy and control policy are authored in the same place and do fundamentally different jobs. Control policy acts on advertisements at the controller and decides what sites know. Data policy acts on packets at the edges and decides what happens to them. Requirements phrased in terms of ports, applications or actions on traffic belong to the second, and a requirement aimed at the wrong mechanism produces a policy that cannot do what was asked no matter how it is written.

Service chaining is three independent things — an advertisement, a policy that names it, and a path to the hosting site — and its characteristic failure is the quiet one. When a part is missing, traffic may simply carry on to its destination without the inspection it was supposed to receive, generating no alarm and no report. That makes the steering counter, rather than the health of the appliance, the measurement that actually says whether the control is working.

Everything else follows from scoping and observability. Three scopes must all include a packet before a policy examines it, and the direction is the one most often wrong. The default action decides the fate of everything nobody thought about, and on a data policy that means discarded packets rather than missing routes. And a counter on every sequence turns all of it into something readable in one command, which is the cheapest improvement available and the one most often skipped. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.

External Links

Reference Notes

Cisco SD-WAN documentation describes centralised data policy as configured on vManage, activated on vSmart, and enforced on the WAN Edge routers to which it is pushed.
Cisco documentation describes the application of a data policy to a site list and a VPN list, with a direction of from-service, from-tunnel or all.
Cisco documentation describes data policy match conditions including source and destination prefixes, ports, protocol, DSCP and application lists.
Cisco documentation describes data policy actions including accept, drop, set service, set TLOC, set VPN, NAT, policer and counters.
Cisco documentation describes service advertisement, in which a site announces a service type and address that is distributed as an OMP service route.
Cisco documentation describes the set service action, which steers matching traffic through a service advertised elsewhere in the overlay.
RFC 7665 defines a service function chaining architecture, describing the general model of steering traffic through ordered service functions.
Cisco documentation describes localised data policy in the form of access lists applied to interfaces on a WAN Edge, enforced independently of centralised policy.
RFC 2474 defines the Differentiated Services field, which data policy can match on and set.
RFC 7011 specifies IPFIX, the basis for the flow export a data policy can request for matched traffic.
Cisco documentation describes show sdwan policy data-policy-filter, which reports the per-sequence counters configured within a data policy.
The CCIE Enterprise Infrastructure v1.1 unified exam topics include SD-WAN policy within the software-defined infrastructure domain.

Latest Cisco, PMP, AWS, CompTIA, Microsoft Materials on SALE Get Now

What Does a Data Policy Do That a Control Policy Cannot?

What is the division?

A Deeper Dive into the Division

Where each is enforced

Blocking, done two ways

The actions available

Three policy types, not two

Counting, which should be on by default

How Is a Data Policy Matched and Applied?

What decides whether a packet is considered?

A Deeper Dive into Matching

Direction, which is the usual mistake

What can be matched

Sequence order and the default action

Application matching and what it depends on

Localised policy, which is a different object

How Does Service Chaining Actually Work?

What has to be in place?

A Deeper Dive into Service Chaining

Advertising the service

Referencing it from the policy

What the path looks like

Return traffic, which is a separate decision

Chaining more than one service

What Happens When the Service Is Unavailable?

Why does this need deciding?

A Deeper Dive into Unavailability

Establish the behaviour rather than assume it

Which answer suits which requirement

Stating the choice where it will be found

Making the service itself redundant

Monitoring the chain rather than the service

Which Data Policy Failures Send Traffic Somewhere Unexpected?

What are the failures worth memorising?

A Deeper Dive into the Failure Catalogue

The service that was never advertised

The shadowed sequence

The drop default

A diagnostic order that works

Reviewing a policy that has grown

What to monitor

Testing a policy before it reaches the estate

Blueprint framing

Conclusion

External Links

Reference Notes

Latest Cisco, PMP, AWS, CompTIA, Microsoft Materials on SALE
Get Now