In traditional networking, configurations are typically applied on a device-per-device basis using CLI. This leads to a lot of boilerplate code and management inefficiencies. Cisco SD-WAN has been designed to overcome this by implementing a centralized management-plane that administers all devices. The solution uses policies to manipulate the overlay fabric in a centralized fashion and templates to eliminate the boilerplate configurations and reuse code. 

What are Cisco SD-WAN Policies?

Policies are an essential part of the Cisco SD-WAN solution and are used to influence the packet flow across the overlay fabric. They are created on vManage through the Policy Wizard GUI and when applied, are pushed via NETCONF transactions either to vSmart controllers (centralized policies) or directly to vEdges (localized policies). 

A Cisco SD-WAN policy is the sum of at least one list, that identifies interesting values, one policy definition, that defines actions, and at least one application, that defines where this policy will be applied. This concept is visualized in figure 1.

It is important to understand that policies are configured on vSmart or vEdge.  vManage is only a graphical user interface used to create and store policies, but once a policy is activated through the vManage GUI, it is configured with a NETCONF transaction either on vSmart or vEdge. Therefore, activating a policy via vManage is equal to manipulating the configuration of vSmart.  If we define the policy shown in figure 1 using vManage and apply it, we are going to see that it will appear in the running-configuration of vSmart as shown in the cli output below.

vSmart# show run
!
policy
 lists
  site-list HUB
   site-id 50
  !
  site-list SPOKES
   site-id 60
   site-id 70
   site-id 80
   site-id 90
  !
 !
 control-policy POLICY-1
  sequence 1
   match tloc
    site-list HUB
   !
   action accept
   !
  !
  default-action reject
 !
!
apply-policy
 site-list SPOKES
  control-policy POLICY-1 out
 !
!

We can clearly see the lists marked in green, the policy definition highlighted in yellow, and the policy application colored with orange. Another important nuance is that vSmart does not store policies, it only loads the currently active policy in its running-configuration. All policy versions and revisions are stored on vManage. Therefore vManage is responsible for roll-backs, version control, and making sure that policy changes are persistent across multiple vSmart controllers.

While all policies are defined using the vManage Policy Wizard, different types are enforced on different devices at different locations in the network. This is visualized in figure 2 below. Localized Control and Data policies such as Access-lists, Classification, Marking, Policing, or local-site routing are enforced directly on the WAN edge routers with NETCONF transactions. On the other hand, centralized policies, that affect the whole overlay fabric, are applied to vSmart and only the result of the policy is advertised to the WAN edge routers using the Overlay Management Protocol (OMP).

At this point, you may be wondering what is NETCONF. It is a popular network management protocol designed to manage remote configurations. Its operations on top of a Remote Procedure Call (RPC) layer and uses XML or JSON for data encoding. Typically the protocol messages are exchanged over Transport Layer Security (TLS) with mutual X.509 Authentication. You do not need to know more about it in order to work with the Cisco SD-WAN Viptela solution.

Cisco SD-WAN Policy Types

As you are already well aware, the Cisco SD-WAN solution follows the SDN principles and separates the control plane from the data plane. It is also designed to be centrally managed but at the same time allows you to make changes on a single device. To encompass these principles, the solution allows us to configure a few different types of policies. Centralized policies allow us to manipulate the whole overlay fabric in a centralized fashion and localized ones give us the ability to manipulate only a particular device or location. Because the control and data plane are separated, centralized policies are also separated into centralized-control-policies that affect the control-plane operations and centralized-data-policies that directly affect the forwarding of packets. The following figure visualizes the Cisco SD-WAN policy's structure.

Policy Key Points

Cisco SD-WAN policies are not easy to work with at first and the best way to get comfortable with them is to practice. However, before we begin playing around, I would like to highlight some key points that are good to be known beforehand. 

A policy is processed in the following order of steps:

• All match–action clauses are processed in sequential order, starting from the lowest sequence number upwards.
• When a match occurs, the configured action is performed and the sequential processing does NOT continue further (all other match-action pairings are skipped).
• If a match does not occur, the configured entity is subject to the default action configured (by default it is reject).

Centralized policies (the ones configured on vSmart) are always applied to a site-list.

• Only one of each type of policies can be applied to a site-list. For example, you can configure one control-policy in and one control-policy out but not two control policies in the outbound direction.
• Cisco does not recommend including a site in more than one site-list. Doing this may result in unpredictable behavior of the policies applied to these site-lists.
• Centralized-Control-policy is unidirectional applied either inbound or outbound. For example, If we need to manipulate omp routes that the controller sends and receives, we must configure two control policies.
• Centralized-Data-policy is directional and can be applied either to the traffic received from the service side of the vEdge router, traffic received from the tunnel side, or both.
• VPN membership policy is always applied to traffic outbound from the vSmart controller.

vEdge Order of Operations

As you have seen by now, there are several different types of policies in the Cisco SD-WAN solution. That basically means that multiple different types can be applied to a given WAN Edge device. To design and implement policies in large-scale deployments, you must have a good understanding of the order of operations of the WAN edge nodes.

Figure 3 visualizes the steps that a WAN edge router takes when forwarding a packet through:

1. IP Destination Lookup: WAN edge devices are in essence just routers, so the forwarding decision always starts with IP address lookup.
2. Ingress Interface ACL: Localized policies are typically used to create ACLs and tie them to vEdge interfaces. As in traditional networking, these ACLs can be used for filtering, marking, and traffic policing. 
3. Application-Aware Routing:  If there is an Application-Aware Routing policy applied, it makes a routing decision based on the defined SLA characteristics such as packet loss, latency, jitter, load, cost, and bandwidth of a link. 
4. Centralized Data Policy: The centralized data policy is evaluated after the Application-Aware Routing policy and is able to override the Application-Aware Routing forwarding decision.
5. Forwarding: At this point, the destination IP address is compared against the routing table, and the output interface is determined.
6. Security Policy: If there are security services attached to the WAN edge node, they are processed in the following sequence - Firewall, IPS (Intrusion Prevention), URL-Filtering, and lastly AMP (Advanced Malware Protection). The necessary tunnel encapsulations are performed and VPN labels are inserted.
7. Egress Interface ACL: As with ingress ACLs, local policy is able to create ACLs that are applied on egress as well. If traffic is denied or manipulated by the egress ACL, those changes will take effect before the packet is forwarded.
8. Queueing and Scheduling: Egress traffic queueing services such as Low-Latency (LLQ) and Weighted Round Robin (WRR) queueing are performed before the packet leaves.