A Centralized Data Policy allows network administrators to override the normal forwarding decisions that would occur at specific WAN edge routers and define a different set of actions that would be performed instead. It is provisioned through the vMange GUI and pushed to the vSmart controllers (hence, it is centralized). Data policies are applied to traffic flows throughout VPNs in the overlay network. They can permit and deny traffic based either on a 6-tuple match (src IP, dst IP, src port, dst port, DSCP value, and protocol type) or on VPN membership. An important point to understand is that a centralized data policy acts on an entire VPN and is not interface-specific (localized data policies control the flow of packets in and out of specific interfaces). 

By default, no centralized data policy is provisioned in a Cisco SD-WAN solution. Therefore all prefixes within every VPN are reachable from anywhere within the VPN. When we want to restrict access between specific sources and destinations within the VPN, we use a centralized data policy that filters traffic based on a 6-tuple.

A centralized data policy can be applied in three different modes from the perspective of a WAN edge router:

  • From-Service (Upstream )
  • From-Tunnel ( Downstream)
  • All (Upstream and Downstream)
Centralized Data Policy Direction
Figure 1. Centralized Data Policy Direction

This allows for a different policy to be applied to the same site list but in a different direction. 

apply-policy site-list <name>
  data-policy <name> all | from-service | from-tunnel

Applying a policy

A data policy itself is never pushed to the WAN edge routers in the overlay fabric. vSmart controllers actually push the results of the data policy via OMP and the effects of the policy are reflected on the WAN edge devices.This concept is visualized in figure 2 below:

Provisioning a data policy
Figure 2. Provisioning a data policy

Data Policy Configuration Components

 

Centralized data policies are configured through the Cisco vManage policy wizard. It guides you through four sequential screens that define different parts of the policy construct:

  • Create Groups of Interest — At this step, we create lists of interesting items that will later be called in the match or action statements in the policy.
  • Configure Traffic Rules — At this point, we specify the match and action conditions.
  • Apply Policies to Sites and VPNs — At this step, we associate the policy with a site list and VPNs.

The following figure 3 illustrates the components of a centralized data policy:

Data Policy Configuration Components
Figure 3. Data Policy Configuration Components

The following match criteria are available:

data-policy <name>
 vpn-list <name>
  sequence <n>
   match
    app-list <name>
    destination-data-ipv6-prefix-list <name>
    destination-data-prefix—list <name>
    destination-ip <ip-address>
    destination-ipv6 <ipv6-address>
    destination-port <port>
    dns request | response
    dns app-list <name>
    dscp <dscp>
    packet-length <length>
    plp <plp>
    protocol <protocol>
    source-data-ipv6-prefix-list <name>
    source-data-ip-prefix-list <name>
    source-ip <ip-address>
    source-ipv6 <ipv6-address>
    source-port <port>
    tcp-syn
  !
 !

and the following actions are available:

action
 accept
   set
    dscp <dscp>
    forwarding-class <name>
    local-tloc <tloc>
    local-tloc-list <list>
    next-hop <ip-address>
    next-hop-ipv6 <ipv6-address>
    policer <name>
    service <name>
    tloc <tloc>
    tloc-list <name>
    vpn <vpn-id>
  cflowd
  count <counter>
  drop
  log
  loss-protect-fec-always
  loss-protect-fec-adaptive
  loss-protect-packet-dup
  nat-pool <nat-pool>
  nat use-vpn <vpn-id>
  redirect dns
  tcp-optimization
  !
 !
 default-action accept
!

Use cases

These types of policies are typically used to manipulate traffic flows across the overlay fabric. Here are some typical use-cases that we are going to configure and analyze in the next couple of lessons:

  • Permit/Deny a set of sources to send traffic to any destination outside the local site. For example, allowing some host to communicate only with other hosts that are within the local site;
  • Modify the next-hop of a set of sources when sending traffic to a specific set of destinations outside the local site. For example, traffic steering voice traffic over one path and data traffic over another of specific hosts within the local site;
  • Permit/Deny a set of source IP addresses and ports to send traffic to any destination outside the local site;
  • Permit/Deny a set of source IP addresses and ports to send traffic to a specific port at a specific destination outside the local site. 

Centralized Control vs. Data Policies

Before jumping into the lab examples, we must emphasize the main differences between control and data policies. You will see that, in some scenarios, both policy types can equally achieve the same objectives. However, control and data policies have some fundamental differences, such: 

  • Control policies act on the OMP routing advertisements to/from the vSmart controller while data policies act on application traffic that goes through WAN edge routers. 
  • Control policies are executed on vSmart, and only the results are advertised to vEdges in the form of OMP updates. On the other hand, data policies are sent to WAN edge routers and executed locally in memory.
  • A control policy is applied to a site list in either inbound or outbound direction. A data policy is applied to a site-list in “from-service,” “from-tunnel,” or both directions. Furthermore, all match-action rules are configured under a VPN-list and only affect the packet flows tagged with the listed VPN-ids.
Centralized Control vs Data Policy
Figure 4. Centralized Control vs Data Policy

Now, having all that in mind, let’s jump into our first lab example.