5.

3 Cisco SD-WAN Policies

vSmart Policy Operation and

Construction 

This topic will help you understand the operation of control and how data policies operate. In this topic,
you will also learn how VPN membership policies operate. This topic also explains how to construct a
vSmart policy.
Control Policy Operation
The following describes control policy operation in Cisco SD-WAN:

Control policies are configured, applied, and executed on vSmart.

Control policies use OMP Routing information to enable services and engineer specialized routing
applications.
Control policies are used to enable the following services:

Service chaining
Traffic engineering
Extranet VPNs
Service and path affinity
Arbitrary VPN topologies

Cisco SD-WAN devices periodically exchange OMP updates, which carry routing information
pertaining to the overlay network. Two items that these updates contain are vRoute attributes and
transport locator (TLOC) attributes. The Cisco vSmart controller uses these attributes from the OMP
updates to determine the topology and status of the overlay network and install routing information
about the overlay network into its route table. The controller then advertises the overlay topology to the
WAN Edge routers in the network by sending OMP updates to them.

A control policy examines the vRoute and TLOC attributes carried in OMP updates and can modify
attributes that match the policy. Any changes that result from the control policy are applied directionally,
either inbound or outbound.

The figure shows a control policy named prefer_local that is configured on a Cisco vSmart controller
and that is applied to Site 1 (via site-list list1) and to Site 2 (via site-list list2). The upper-left arrow
shows the policy being applied to Site 1—more specifically, to site-list list1, which contains an entry
for Site 1. The command to apply the policy is  control-policy   prefer_local  in. The keyword in
indicates an inbound policy: the policy is applied to OMP updates that are coming into the Cisco
vSmart controller from the WAN Edge router. For all OMP updates that the Site 1 WAN Edge router
sends to the Cisco vSmart controller, the prefer_local control policy is applied before the updates
reach the route table on the Cisco vSmart controller. If any vRoute or TLOC attributes in an OMP
update match the policy, any changes that result from the policy actions occur before, the vSmart
controller installs the OMP update information into its route table.

On the right side of the figure, the same prefer_local policy is used, but here it is applied to Site 2 via
the  control-policy   prefer_local  out command. The out keyword in the command indicates an
outbound policy, which means that the policy is applied to OMP updates that the Cisco vSmart
controller is sending to the WAN Edge router at Site 2. Any changes that result from the policy occur
outbound after the information from the route table of the Cisco vSmart controller has been placed into
an OMP update and before the WAN Edge router receives the update.

An inbound policy affects the centralized route table on the Cisco vSmart controller and thus can have
a broad effect on the route attributes advertised to all the WAN Edge routers in the overlay network. In
contrast, a control policy applied in the outbound direction influences only the route tables on the
individual WAN Edge routers included in the site list, so it generally has a more limited scope.

Data Policy Operation

Data Policies have these characteristics:

Data policies are configured and applied on the vSmart, and then pushed to the WAN Edge routers
configured policy in the data plane.
A data policy acts on an entire VPN and not interface-specific.
Some of the applications enabled by control policies can also be enabled by data policies.
Data policies are used to enable the following services:

Service chaining
Cflowd
NAT
Traffic policing and counting

Data policies are simpler to administer, because they apply only to a single node and do not interact
across the network.

The data policy examines the fields in the headers of data packets, looking at the source and
destination addresses, ports, the protocol and DSCP values, and for matching packets, it can modify
the next hop in various ways or apply a policer to the packets. Data policies are configured and applied
on the Cisco vSmart controller, and are carried in OMP updates to the WAN Edge routers in the site list
that the policy is applied to. The match operation and any resultant actions are performed on the WAN
Edge router as it transmits or receives data traffic.
In the figure, a data policy named change_next_hop is applied to a list of sites that includes Site 3.
The OMP update that the Cisco vSmart controller sends to the WAN Edge router at Site 3 includes this
policy definition. When the WAN Edge router sends or receives data traffic that matches the policy, it
changes the next hop to the specified TLOC. Nonmatching traffic is forwarded to the original next-hop
TLOC.

In the  apply-policy  command for a data policy, you specify a direction from the perspective of the
WAN Edge router. In the figure, the "all" direction applies the policy to data traffic transiting the tunnel
interface, both what the WAN Edge router is sending and what it is receiving. You can limit the span of
the policy to only incoming traffic (with a  data-policy change_next_hop from-tunnel  command) or
to only outgoing traffic (with a  data-policy change_next_hop from-service  command).

VPN Membership Policy Operation

When configuring VPN membership, it's important to understand the following information:

The default behavior of the SD-WAN OMP architecture is to advertise any configured VPN to any
node where it is configured.
This behavior automatically establishes connectivity without unnecessary configuration and
operational overhead.
However, certain VPNs might be of a sensitive nature, such that their membership must be tightly
controlled.
The VPN membership policy serves to restrict the distribution of VPN information from vSmart to
those that are explicitly approved.

Both allowed list and denied list behavior can be established.

With a VPN membership policy, a node not explicitly allowed to participate in a VPN may have the
VPN configured but will see only local connectivity and routing information.

VPN membership policy, as the name implies, affects the VPN route tables that are distributed to
particular WAN Edge routers. In an overlay network with no VPN membership policy, the Cisco vSmart
controller pushes the routes for all VPNs to all WAN Edge routers. If your business usage model
restricts the participation of specific WAN Edge routers in particular VPNs, a VPN membership policy is
used to enforce this restriction.
The figure illustrates how VPN membership policy works. This topology has three WAN Edge routers:

The WAN Edge routers at Sites 1 and 2 service only VPN 2.

The WAN Edge router at Site 3 services both VPN 1 and VPN 2.

You need the router at Site 3 to receive all route updates from the Cisco vSmart controller, because
these updates are for both VPN 1 and VPN 2. However, because the other two routers service only
VPN 2, you can filter the route updates sent to them, removing the routes associated with VPN 1 and
sending only the ones that apply to VPN 2.

Notice that you do not set a direction when applying a VPN membership policy. The Cisco vSmart
controller always applies this type of policy to the OMP updates that it sends outward to the WAN Edge
routers.

vSmart Policy Construction

Groups of Interest:

data-prefix-list used in data-policy to define prefix and upper layer ports either singularly or jointly
for traffic matching.
prefix-list used in control-policy to define prefixes for RIB matching.
site-list used in control-policy and apply-policy to match source sites or to define sites for policy
application.
tloc-list used in control-policy to define tlocs for RIB matching and to apply redefined tlocs to
vroutes.
vpn-list used in control-policy to define prefixes for RIB matching, in data-policy and app-route-
policy to define VPNs for policy application.

policy
lists
data-prefix-list app1
ip-prefix 1.1.1.1/32
port 100
!
 prefix-list pfx1
ip-prefix 1.1.1.1/32
!
site-list site1
site-id 100
!
tloc-list site1_tloc
tloc 1.1.1.1 color mpls
vpn-list vpn1
vpn 1
!

Groups of interest lists are how you group related items so that you can reference them all together.
Examples of items you put in the lists are prefixes, TLOCs, VPNs, and overlay network sites. In vSmart
policy, you invoke lists in two places: when you create a policy definition and when you apply a policy.
Separating the definition of the related items from the definition of policy means that when you can add
or remove items from a list, you make the changes only in a single place: You do not have to make the
changes through the policy definition. So, if you add ten sites to your network and you want to apply an
existing policy to them, you simply add the site identifiers to the site list. You can also change policy
rules without manually modifying the prefixes, VPNs, or other things that the rules apply to.

Policies:

Policy definition dictates type of policy and the appropriate syntax.

VPN-list is used by data-policy and app-route-policy to list the VPNs for which the policy is
applicable.
Sequence defines each sequential step of the policy by sequence number.
Match decides what entity to match on in the specific policy sequence.
Action determines the action for the preceding match statement.
Default-action is the action to take for any entity that was not matched in any sequence of the
policy (set to reject by default).

policy
policy-type <name>
vpn-list <vpn-list>
sequence <n>
match <route tloc|vpn|other>
!
action <accept|reject|drop> set
<attribute> <value>
!
default-action <reject|accept>
!
!
!
!

The policy definition is where you create the policy rules. You specify match conditions (route-related
properties for control policy and data-related fields for data policy) and actions to perform when a
match occurs. A policy contains match–action pairings that are numbered and that are examined in
sequential order. When a match occurs, the action is performed, and the policy analysis on that route
or packet terminates. Some types of policy definitions apply only to specific VPNs.
The figure shows the components of the vSmart policy definition. These items are listed in the logical
order you should use when designing policy, and this order is also how the items are displayed in the
configuration, regardless of the order in which you add them to the configuration.

apply-policy
site-list <name>
control-policy <name> <in|out>
!
site-list <name>
data-policy <name>
vpn-membership <name>
!
!

Policy Application:

Site-list determines to which sites a given policy is applied.

Direction applies only to control policies.
Policy Type and Name refer to an already configured policy to be applied toward sites specified in
the site-list for the section.

For a policy definition to take effect, you associate it with sites in the overlay network.

The following are the configuration components:

The site-list determines the sites to which a given policy is applies. The direction (in | out) applies
only to control-policy.
The policy type—control-policy, data-policy, vpn-membership—and name refer to an already
configured policy to be applied to the sites specified in the site-list for the section.

vSmart Policy Example

The policy example shows a complete policy, which consists of lists, policy definition, and policy
application. The example illustrated creates two lists (a site-list and a tloc-list), defines one policy (a
control policy), and applies the policy to the site-list. In the figure, the items are listed as they are
presented in the node configuration. In a normal configuration process, you create lists first (group all
the things you want to use), then define the policy itself (define what things you want to do), and finally
apply the policy (specify the sites that the configured policy affects).

A VPN membership data policy consists of a series of numbered (ordered) sequences of match-action
pairs that are evaluated in order, from the lowest sequence number to the highest sequence number.
When a packet matches one of the match conditions, the associated action is taken, and policy
evaluation on that packet stops. Keep this fact in mind as you design your policies to ensure that the
desired actions are taken on the items subject to the policy.

If a packet matches no parameters in any of the sequences in the policy configuration, it is, by default,
rejected and discarded.

vSmart Policy GUI Example

To configure a vSmart policy in the vManage GUI, go to the Policies page by

choosing Configuration in the left-side navigation menu and then choose Policies. The policies page
allows you to configure a Centralized or Localized policy. The Custom Options button on the top-right
side of the page allows you to configure or modify the individual components used in policies such as
lists or access control lists (ACLs). In this example, you will configure the prefer_local policy by using
the Cisco vManage GUI. By clicking the Centralized Policy button and then the Add Policy button,
you will start the vSmart policy workflow.

The first step in the workflow is to configure the needed groups of interest. On the left side menu, you
can navigate to the different groups of interest. You can view the existing lists or create a new list if
needed. In this example, you will create a site list and a TLOC list. First, create the site list by clicking
the Site lists button on the left side menu. Then click the New Site list button and enter the required
information. You will need to enter a name for the site list and add the site-ids that will be included in
this list. Once you are done, make sure to click the Add button.

Next, you will create the TLOC list. From the left side menu, click the TLOC list button. Then click
the New TLOC List button. This will bring up a new window to configure the TLOC list. You will need to
enter a name for the TLOC list, the TLOC IP, color, encapsulation type, and a preference value. Once
you have entered the required information, click the Save button. Click the Next button to continue to
the next step of the workflow.
The next step of the workflow is to configure the topology and VPN membership. In this example, you
will configure the topology only. Click the Add Topology button to view the drop-down menu. When
configuring the topology, you may choose to configure a hub-and-spoke topology, mesh topology, or a
custom topology. In this example, you will configure a custom topology.

The custom control policy page allows you to configure a control policy to define your custom topology.
By default, only the default action is configured when you create a control policy. Click the Sequence
Type button and choose Route policy to configure a new policy entry. By default, no rules are
configured. Click the Sequence Rule button to create a new control policy rule. When configuring a
rule, you may choose the matching conditions and the actions taken. In this example, you will
choose Site List in the matching conditions and choose the site1 site list. In the actions,
choose Accept and TLOC List. Choose the prefer_site1 list for the TLOC list. Once you have
configured the rule, click the Save Match And Actions button and then click the Save Control
Policy button.
Proceed in the workflow to the final section. The final step of the workflow allows you to view and
choose where to apply the configured policies. In this section, you will see all the policies you have
configured in the workflow. You will need to choose where to apply the configured policies. In this
example, you will choose where to apply the configured topology policy. Choose the site list you will
apply the policy to, and then click the Add button. Once you are done, save the policy. When a policy
is configured, it must be activated to be enabled. Choose the configured policy from the list and
activate it.
Summary:

Control policies examine the vRoute and TLOC attributes carried in OMP updates. Any changes that
result from a control policy are applied directionally, either inbound or outbound.
Data policies are configured and applied on vSmart and then pushed to the WAN Edge routers. Data
policies act on an entire VPN and are not interface-specific. Data policies are used to enable service
chaining, NAT, and traffic policing and counting.
The default behavior of Cisco SD-WAN OMP architecture is to advertise any configured VPN to any
node where it is configured. Certain VPNs may be of a sensitive nature, such that their membership
must be tightly controlled. VPN membership policy serves to restrict the distribution of VPN
information from vSmart to those that are explicitly approved.

Content Review Question

Which of the following two options define a vpn-list group of interest? (Choose two.)

It is used in control policies to define prefixes for RIB matching.

It is used in control policy and apply-policy to match source sites.

It is used in control policy to define TLOCs for RIB matching.

It is used in data policies to define prefix and upper layer ports.

It is used in data policies to define VPNs for policy application.

Submit