Data Policies

Data policy influences the flow of data traffic traversing the network based either on fields in the IP header of packets or the router interface on which the traffic is being transmitted or received. Data traffic travels over the IPsec connections between Cisco IOS XE SD-WAN devices, shown in purple in the adjacent figure.

The Cisco IOS XE SD-WAN architecture implements two types of data policy:

  • Centralized data policy controls the flow of data traffic based on the source and destination addresses and ports and DSCP fields in the packet's IP header (referred to as a 5-tuple), and based on network segmentation and VPN membership. These types of data policy are provisioned centrally, on the Cisco vSmart controller, and they affect traffic flow across the entire network.

  • Localized data policy controls the flow of data traffic into and out of interfaces and interface queues on a Cisco IOS XE SD-WAN device. This type of data policy is provisioned locally using access lists. It allows you to classify traffic and map different classes to different queues. It also allows you to mirror traffic and to police the rate at which data traffic is transmitted and received. 

By default, no centralized data policy is provisioned. The result is that all prefixes within a VPN are reachable from anywhere in the VPN. Provisioning centralized data policy allows you to apply a 6-tuple filter that controls access between sources and destinations.
As with centralized control policy, you provision centralized data policy on the Cisco vSmart controller, and that configuration remains on the Cisco vSmart controller. The effects of data policy are reflected in how the Cisco IOS XE SD-WAN devices direct data traffic to its destination. Unlike control policy, however, centralized data polices are pushed to the devices in a read-only fashion. They are not added to the router's configuration file, but you can view them from the CLI on the router.

With no access lists provisioned on a Cisco IOS XE SD-WAN device, all data traffic is transmitted at line rate and with equal importance, using one of the interface's queues. Using access lists, you can provision class of service, which allows you to classify data traffic by importance, spread it across different interface queues, and control the rate at which different classes of traffic are transmitted. You can provision policing.

Centralized Data Policy

Centralized data policy is policy that is configured on a Cisco vSmart Controller (hence, it is centralized) and that affects data traffic being transmitted between the routers on the Cisco SD-WAN overlay network.

Centralized Data Policy Overview

Data policy operates on the data plane in the Cisco IOS XE SD-WAN overlay network and affects how data traffic is sent among Cisco IOS XE SD-WAN devices in the network. The Cisco IOS XE SD-WAN architecture defines two types of data policy, centralized data policy, which controls the flow of data traffic based on the IP header fields in the data packets and based on network segmentation, and localized data policy, which controls the flow of data traffic into and out of interfaces and interface queues on the devices.

Centralized data policy is applied to packets that originate from a specific sender, or source address, for instance, from a workstation in a local site that is sending voice, data, or other traffic, and it controls which destinations within a VPN the traffic can reach. Data policy is applied to data traffic based on a 6-tuple of fields in the packet's IP header: source IP address, source port, destination IP address, destination port, DSCP, and protocol.

As with control policy, data policy is provisioned centrally on a Cisco vSmart Controller and is applied only on the Cisco vSmart Controller controller. The data policy itself is never pushed to the devices in the network. What is pushed to the Cisco IOS XE SD-WAN devices, via OMP and based on the site ID, are the results of the data policy; hence, the effects of the policy are reflected on the devices. Normally, the data policy on a Cisco IOS XE SD-WAN device acts as the data policy for the entire site that sits behind the device. Data policy that comes from the Cisco vSmart Controller is always implicitly applied in the inbound direction.

Data policy can be applied to data traffic based on the packet header fields, such as the prefix, port, protocol, and DSCP value, and they can also be applied based on the VPN in the overlay network to which the traffic flows.

Data Policy Based on Packet Header Fields

Policy decisions affecting data traffic can be based on the packet header fields, specifically, on the source and destination IP prefixes, the source and destination IP ports, the protocol, and the DSCP.

This type of policy is often used to modify traffic flow in the network. Here are some examples of the types of control that can be effected with centralized data policy:

  • Which set of sources are allowed to send traffic to any destination outside the local site. For example, local sources that are rejected by such a data policy can communicate only with hosts on the local network.

  • Which set of sources are allowed to send traffic to a specific set of destinations outside the local site. For example, local sources that match this type of data policy can send voice traffic over one path and data traffic over another.

  • Which source addresses and source ports are allowed to send traffic to any destination outside the local site or to a specific port at a specific destination. 

Deep Packet Inspection

In addition to examining the network- and transport-layer headers in data packets, centralized data policy can be used to examine the application information in the data packets' payload. This deep packet inspection offers control over how data packets from specific applications or application families are forwarded across the network, allowing you to assign the traffic to be carried by specific tunnels. To control the traffic flow of specific application traffic based on the traffic loss or latency properties on a tunnel, use application-aware routing.

To base policy decisions on source and destination prefixes and on the headers in the IP data packets, you use centralized data policy, which you configure with the policy data-policy command. The Cisco vSmart Controller pushes this type of data policy to the Cisco IOS XE SD-WAN devices. In domains with multiple Cisco vSmart Controllers, all the controllers must have the same centralized data policy configuration to ensure that traffic flow within the overlay network remains synchronized.

To base policy decisions on the application information in the packet payload, you use centralized data policy to perform deep packet inspection. You configure this by creating lists of applications with the policy lists app-list command and then calling these lists in a policy data-policy command.

To configure the VPNs that Cisco IOS XE SD-WAN devices are allowed to receive routes from, you use centralized data policy, which you configure with the policy vpn-membership command. VPN membership policy affects which routes the Cisco vSmart Controller sends to the devices. The policy itself remains on the Cisco vSmart Controller and is not pushed to the devices.

Configure Centralized Data Policy Based on Prefixes and IP Headers

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

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

Configuration Components

The following figure illustrates the configuration components for centralized data policy:

To configure centralized data policies, use the Cisco vManage policy configuration wizard. The wizard consists of four sequential screens that guide you through the process of creating and editing policy components:

  • Create Groups of Interest—Create lists that group together related items and that you call in the match or action components of a policy.

  • Configure Traffic Rules—Create the match and action conditions of a policy.

  • Apply Policies to Sites and VPNs—Associate policy with sites and VPNs in the overlay network.

In the first three policy configuration wizard screens, you are creating policy components or blocks. In the last screen, you are applying policy blocks to sites and VPNs in the overlay network.

For a centralized data policy to take effect, you must activate the policy.

This section provides general procedures for configuring centralized data policy on Cisco vSmart Controllers. Centralized data policy can be used for different purposes, which are described in the sections that follow.

Start the Policy Configuration Wizard

To start the policy configuration wizard:

Procedure
Step 1

In the Cisco vManage NMS, select the Configure > Policies screen.

Step 2

Select the Centralized Policy tab.

Step 3

Click Add Policy. The policy configuration wizard opens, and the Create Groups of Interest screen displays.

Step 1: Create Policy Lists

You can create lists of groups to use in centralized policy.

Procedure
Step 1

Create new lists, as described in the following table:

List Type

Procedure
Application

  1. In the left bar, click Application.

  2. Click New Application List.

  3. Enter a name for the list.

  4. Click either the Application or Application Family button.

  5. From the Select drop-down, select the desired applications or application families.

  6. Click Add.

Two application lists are preconfigured. You cannot edit or delete these lists.

  • Google_Apps—Includes Google applications, such as gmail, Google maps, and YouTube. To display a full list of Google applications, click the list in the Entries column.

  • Microsoft_Apps—Includes Microsoft applications, such as Excel, Skype, and Xbox. To display a full list of Microsoft applications, click the list in the Entries column.

Data Prefix

  1. In the left bar, click Data Prefix.

  2. Click New Data Prefix List.

  3. Enter a name for the list.

  4. Select either IPv4 or IPv6.

  5. In the Add Data Prefix field, enter one or more data prefixes separated by commas.

  6. Click Add.

Policer

  1. In the left bar, click Policer.

  2. Click New Policer List.

  3. Enter a name for the list.

  4. Define the policing parameters:

    1. In the Burst field, enter the maximum traffic burst size, a value from 15,000 to 10,000,000 bytes.

    2. In the Exceed field, select the action to take when the burst size or traffic rate is exceeded. It can be drop, which sets the packet loss priority (PLP) to low.

    3. In the Rate field, enter the maximum traffic rate, a value from 0 through 264 – 1 bits per second (bps).

  5. Click Add.

Prefix

  1. In the left bar, click Prefix.

  2. Click New Prefix List.

  3. Enter a name for the list.

  4. In the Add Prefix field, enter one or more data prefixes separated by commas.

  5. Click Add.

Site

  1. In the left bar, click Site.

  2. Click New Site List.

  3. Enter a name for the list.

  4. In the Add Site field, enter one or more site IDs separated by commas.

  5. Click Add.

SLA Class

  1. In the left bar, click SLA Class.

  2. Click New SLA Class List.

  3. Enter a name for the list.

  4. Define the SLA class parameters:

    1. In the Loss field, enter the maximum packet loss on the connection, a value from 0 through 100 percent.

    2. In the Latency field, enter the maximum packet latency on the connection, a value from 0 through 1,000 milliseconds.

    3. In the Jitter field, enter the maximum jitter on the connection, a value from 1 through 1,000 milliseconds.

  5. Click Add.

TLOC

  1. In the left bar, click TLOC.

  2. Click New TLOC List. The TLOC List popup displays.

  3. Enter a name for the list.

  4. In the TLOC IP field, enter the system IP address for the TLOC.

  5. In the Color field, select the TLOC's color.

  6. In the Encap field, select the encapsulation type.

  7. In the Preference field, optionally select a preference to associate with the TLOC.

  8. Click Add TLOC to add another TLOC to the list.

  9. Click Save.

VPN

  1. In the left bar, click VPN.

  2. Click New VPN List.

  3. Enter a name for the list.

  4. In the Add VPN field, enter one or more VPN IDs separated by commas.

  5. Click Add.

Step 2

Click Next to move to Configure Topology and VPN Membership in the wizard.

Step 2: Configure Traffic Rules

When you first open the Traffic Rules screen, the Application-Aware Routing tab is selected by default. To configure traffic rules for deep packet inspection, see Deep Packet Inspection.

To configure traffic rules for centralized data policy:

Procedure
Step 1

Click the Traffic Data tab.

Step 2

Click the Add Policy drop-down.

Step 3

Click Create New. The Add Data Policy screen displays.

Step 4

Enter a name and description for the data policy.
Step 5

In the right pane, click Sequence Type. The Add Data Policy popup opens.

Step 6

Select the type of data policy you want to create. Choices are: Application Firewall, QoS, Traffic Engineering, and Custom.

Step 7

A policy sequence containing the text string Application Firewall, QoS, Traffic Engineering, or Custom is added in the left pane

Step 8

Double-click the text string, and enter a name for the policy sequence. The name you type is displayed both in the Sequence Type list in the left pane and in the right pane.

Step 9

In the right pane, click Sequence Rule. The Match/Action box opens, and Match is selected by default. The available policy match conditions are listed below the box.

Step 10

For QoS and Traffic Engineering data policies: From the Protocol drop-down list, select IPv4 to apply the policy only to IPv4 address families, IPv6 to apply the policy only to IPv6 address families, or Both to apply the policy IPv4 and IPv6 address families.

Step 11

To select one or more Match conditions, click its box and set the values as described in the following table. Note that not all match conditions are available for all policy sequence types.

Match Condition Procedure IPv4 Fields IPv6 Fields
None (match all packets) Do not specify any match conditions.
Applications /Application Family List

  1. In the Match conditions, click Applications/Application Family List.

  2. In the drop-down, select the application family.

  3. To create an application list:

    1. Click New Application List.

    2. Enter a name for the list.

    3. Click Application to create a list of individual applications. Click Application Family to create a list of related applications.

    4. In the Select Application drop-down, select the desired applications or application families.

    5. Click Save.

app-list
Destination Data Prefix

  1. In the Match conditions, click Destination Data Prefix.

  2. To match a list of destination prefixes, select the list from the drop-down.

  3. To match an individual destination prefix, enter the prefix in the Destination: IP Prefix field.

source/ destination-data-prefix-list

source/ destination-data-prefix-list
Destination Port

  1. In the Match conditions, click Destination Port.

  2. In the Destination: Port field, enter the port number. Specify a single port number, a list of port numbers (with numbers separated by a space), or a range of port numbers (with the two numbers separated with a hyphen [-]).

src/dst ip

src/dst ip
DNS Application List

Add an application list to enable split DNS.

  1. In the Match conditions, click DNS Application List.

  2. In the drop-down, select the application family.

dns-app-list
DNS

Add an application list to process split DNS.

  1. In the Match conditions, click DNS.

  2. In the drop-down, select Request to process DNS requests for the DNS applications, and select Response to process DNS responses for the applications.

dns-request

dns-response
DSCP

  1. In the Match conditions, click DSCP.

  2. In the DSCP field, type the DSCP value, a number from 0 through 63.

dscp

dscp
Packet Length

  1. In the Match conditions, click Packet Length.

  2. In the Packet Length field, type the length, a value from 0 through 65535.

packet-len

packet-len
PLP

  1. In the Match conditions, click PLP to set the Packet Loss Priority.

  2. In the PLP drop-down, select Low or High. To set the PLP to high, apply a policer that includes the exceed remark option.

Protocol

  1. In the Match conditions, click Protocol.

  2. In the Protocol field, type the Internet Protocol number, a number from 0 through 255.

protocol

protocol/next header
Source Data Prefix

  1. In the Match conditions, click Source Data Prefix.

  2. To match a list of source prefixes, select the list from the drop-down.

  3. To match an individual source prefix, enter the prefix in the Source field.

source/ destination-data-prefix-list

source /destination-data-prefix-list
Source Port

  1. In the Match conditions, click Source Port.

  2. In the Source field, enter the port number. Specify a single port number, a list of port numbers (with numbers separated by a space), or a range of port numbers (with the two numbers separated with a hyphen [-]).

ports

ports
TCP

  1. In the Match conditions, click TCP.

  2. In the TCP field, syn is the only option available.

tcp flag
Step 12

To select actions to take on matching data traffic, click the Actions box.

Step 13

To drop matching traffic, click Drop. The available policy actions are listed to the right of the button.

Step 14

To accept matching traffic, click Accept. The available policy actions are listed to the right of the button.

Step 15

Set the policy action as described in the following table. Note that not all actions are available for all match conditions

Match Condition Description Procedure
Counter Count matching data packets.

  1. In the Action conditions, click Counter.

  2. In the Counter Name field, enter the name of the file in which to store packet counters.

DSCP Assign a DSCP value to matching data packets.

  1. In the Action conditions, click DSCP.

  2. In the DSCP field, type the DSCP value, a number from 0 through 63.

Forwarding Class Assign a forwarding class to matching data packets.

  1. In the Match conditions, click Forwarding Class.

  2. In the Forwarding Class field, type the class value, which can be up to 32 characters long.

Policer Apply a policer to matching data packets.

  1. In the Match conditions, click Policer.

  2. In the Policer drop-down field, select the name of a policer.
Loss Correction

Apply loss correction to matching data packets.

Forward Error Correction (FEC) recovers lost packets on a link by sending redundant data, enabling the receiver to correct errors without the need to request retransmission of data.

FEC is supported only for IPSEC tunnels, it is not supported for GRE tunnels.

  • FEC Adaptive – Corresponding packets are subjected to FEC only if the tunnels that they go through have been deemed unreliable based on measured loss. Adaptive FEC starts to work at 2% packet loss; this value is hard-coded and is not configurable.

  • FEC Always – Corresponding packets are always subjected to FEC.

  • Packet Duplication – Sends duplicate packets over a single tunnel. If more than one tunnel is available, duplicated packets will be sent over the tunnel with the best parameters.

  1. In the Match conditions, click Loss Correction.

  2. In the Loss Correction field, select FEC Adaptive, FEC Always, or Packet Duplication.

Click Save Match and Actions.
Step 16

Create additional sequence rules as desired. Drag and drop to re-arrange them.
Step 17

Click Save Data Policy.

Step 18

Click Next to move to Apply Policies to Sites and VPNs in the wizard.

Step 3: Apply Policies to Sites and VPNs

In Apply Policies to Sites and VPNs, apply a policy to overlay network sites and VPNs.

Procedure
Step 1

In the Policy Name field, enter a name for the policy. This field is mandatory and can contain only uppercase and lowercase letters, the digits 0 through 9, hyphens (–), and underscores (_). It cannot contain spaces or any other characters.

Step 2

In the Policy Description field, enter a description of the policy. It can contain up to 2048 characters. This field is mandatory, and it can contain any characters and spaces.

Step 3

From the Topology bar, select the tab that corresponds to the type of policy block—Topology, Application-Aware Routing, Traffic Data, or Cflowd. The table then lists policies that you have created for that type of policy block.

Step 4

Associate the policy with VPNs and sites. The choice of VPNs and sites depends on the type of policy block:

  1. For a Topology policy block, click Add New Site List and VPN List or Add New Site. Some topology blocks might have no Add buttons. Select one or more site lists, and select one or more VPN lists. Click Add.

  2. For an Application-Aware Routing policy block, click Add New Site List and VPN list. Select one or more site lists, and select one or more VPN lists. Click Add

  3. For a Traffic Data policy block, click Add New Site List and VPN List. Select the direction for applying the policy (From Tunnel, From Service, or All), select one or more site lists, and select one or more VPN lists. Click Add.

  4. For a cflowd policy block, click Add New Site List. Select one or more site lists, Click Add.

Step 5

Click Preview to view the configured policy. The policy is displayed in CLI format.

Step 6

Click Save Policy. The Configuration > Policies screen appears, and the policies table includes the newly created policy.

Step 4: Activate a Centralized Data Policy

Activating a centralized data policy sends that policy to all connected Cisco vSmart Controllers. To activate a centralized policy:

Procedure
Step 1

In the Cisco vManage NMS, select the Configure > Policies screen.

Step 2

Select a policy from the policy table.
Step 3

Click the More Actions icon to the right of the row, and click Activate. The Activate Policy popup opens. It lists the IP addresses of the reachable Cisco vSmart Controllers to which the policy is to be applied.

Step 4

Click Activate.

Configure Centralized Data Policy Using CLI

Following are the high-level steps for configuring a VPN membership data policy:

  1. Create a list of overlay network sites to which the VPN membership policy is to be applied (in the apply-policy command): 

    vSmart(config)# policy​ 
vSmart (config-policy)# lists site-list list-name 
vSmart(config-lists-list-name)# site-id site-id

    The list can contain as many site IDs as necessary. Include one site-id command for each site ID. For contiguous site IDs, you can specify a range of numbers separated with a dash (–). Create additional site lists, as needed.

  2. Create lists of IP prefixes and VPNs, as needed:

    vSmart(config)# policy lists 
vSmart(config-lists)# data-prefix-list list-name
vSmart(config-lists-list-name)# ip-prefix prefix/length
    vSmart(config)# policy lists
vSmart(config-lists)# vpn-list list-name
vSmart(config-lists-list-name)# vpn vpn-id
    vsmart(config)# policy lists data-ipv6-prefix-list dest_ip_prefix_list
vsmart(config-data-ipv6-prefix-list-dest_ip_prefix_list)# ipv6-prefix 2001:DB8:19::1
vsmart(config-data-ipv6-prefix-list-dest_ip_prefix_list)# commit
Commit complete.
    vsmart(config)# policy data-policy data_policy_1 vpn-list vpn_1
vsmart (config-sequence-100)# match destination-data-ipv6-prefix-list dest_ip_prefix_list
vsmart (config-match)# commit
vsmart(config-match)# exit
vsmart(config-sequence-100)# match source-data-ipv6-prefix-list dest_ip_prefix_list
vm9(config-match)# commit
Commit complete.
vm9(config-match)# end
    vsmart(config)# policy
vsmart(config-policy)#  data-policy data_policy_1
vsmart(config-data-policy-data_policy_1)# vpn-list vpn_1
vsmart(config-vpn-list-vpn_1)#    sequence 101
vsmart(config-sequence-101)# match source-ipv6 2001:DB8:19::1
vsmart(config-match)# exit
vsmart(config-sequence-101)# match destination-ipv6 2001:DB8:19::1
vsmart(config-match)#
  3. Create lists of TLOCs, as needed.
    vSmart(config)# policy​
vSmart(config-policy)# lists tloc-list list-name
vSmart(config-lists-list-name)# tloc ip-address color color encap encapsulation [preference number}

  4. Define policing parameters, as needed:

    vSmart(config-policy)# policer policer-name
vSmart(config-policer)# rate bandwidth
vSmart(config-policer)# burst bytes
vSmart(config-policer)# exceed action

  5. Create a data policy instance and associate it with a list of VPNs:

    vSmart(config)# policy data-policy policy-name
vSmart(config-data-policy-policy-name)# vpn-list list-name

  6. Create a series of match–pair sequences:

    vSmart(config-vpn-list)# sequence number
vSmart(config-sequence-number)#

    The match–action pairs are evaluated in order, by sequence number, starting with the lowest numbered pair and ending when the route matches the conditions in one of the pairs. Or if no match occurs, the default action is taken (either rejecting the route or accepting it as is).

  7. Define match parameters for packets:

    ​​vSmart(config-sequence-number)# matchparameters

  8. Define actions to take when a match occurs:

    vSmart(config-sequence-number)# action (accept | drop) [count counter-name] [log] [tcp-optimization]
vSmart(config-sequence-number)# action acccept nat [pool number] [use-vpn 0]
vSmart(config-sequence-number)# action accept redirect-dns (host | ip-address)
vSmart(config-sequence-number)# action accept set parameters
    vsmart(config)# policy data-policy data_policy_1 vpn-list vpn_1 sequence 100
vsmart(config-sequence-100)# action accept set next-hop-ipv6 2001:DB8:19::1
vsmart(config-set)#

  9. Create additional numbered sequences of match–action pairs within the data policy, as needed.

  10. If a route does not match any of the conditions in one of the sequences, it is rejected by default. To accept nonmatching prefixed, configure the default action for the policy: 

    vSmart(config-policy-name)# default-action accept

  11. Apply the policy to one or more sites in the overlay network:

    vSmart(config)# apply-policy site-list list-name data-policy policy-name (all |from-service | from-tunnel)

Structural Components of Policy Configuration for Centralized Data Policy

The following commands are the structural components required to configure VPN membership policy. Each one is explained in more detail in the sections that follow. 

policy
  lists
    app-list list-name
      (app applications | app-family application-families)
    data-prefix-list list-name 
      ip-prefix prefix 
    site-list list-name 
      site-id site-id 
    tloc-list list-name
      tloc ip-address color color encap encapsulation [preference value]
    vpn-list list-name 
      vpn vpn-id 
  policer policer-name
    burst bytes
    exceed action
    rate bandwidth
  data-policy policy-name 
    vpn-list list-name 
      sequence number 
        match
          app-list list-name
          destination-data-prefix-list list-name
          destination-ip prefix/length
          destination-port port-numbers
          dscp number
          dns-app-list list-name
          dns (request | response)
          packet-length number
          protocol number
          source-data-prefix-list list-name
          source-ip prefix/length
          source-port port-numbers
          tcp flag
        action
          cflowd (not available for deep packet inspection)
          count counter-name
          drop
          log
          redirect-dns (dns-ip-address | host)
          tcp-optimization
          accept
            nat [pool number] [use-vpn 0]
            set 
              dscp number
              forwarding-class class
              local-tloc color color [encap encapsulation] [restrict]
              next-hop ip-address
              policer policer-name
              
              tloc ip-address color color [encap encapsulation]
              tloc-list list-name
              vpn vpn-id
      default-action
        (accept | drop)
apply-policy site-list list-name 
  data-policy policy-name (all | from-service | from-tunnel)

Lists

Centralized data policy for deep packet inspection uses the following types of lists to group related items. In the CLI, you configure lists under the policy lists command hierarchy on Cisco vSmart Controllers.

  • Configuration > Policies > Centralized Policy > Add Policy > Create Groups of Interest

  • Configuration > Policies > Custom Options > Lists.

In the CLI, you configure lists under the policy lists command hierarchy on Cisco vSmart Controllers.

List Type Description

vManage /

CLI Command
Applications and application families

List of one or more applications or application families running on the subnets connected to the device.

  • application-names can be the names of one or more applications. The Cisco IOS XE SD-WAN devices supports about 2300 different applications. To list the supported applications, use the ? in the CLI.

  • application-families can be one or more of the following: antivirus, application-service, audio_video, authentication, behavioral, compression, database, encrypted, erp, file-server, file-transfer, forum, game, instant-messaging, mail, microsoft-office, middleware, network-management, network-service, peer-to-peer, printer, routing, security-service, standard, telephony, terminal, thin-client, tunneling, wap, web, and webmail.

Configuration > Policies > Centralized Policy > Add Policy > Create Groups of Interest > Application

or

Configuration > Policies > Centralized Policy > Lists > Application

app-list list-name

(app applications | app-family application-families)

Prefixes List of one or more IP prefixes. Configuration > Policies > Centralized Policy > Add Policy > Create Groups of Interest > Prefix

or

Configuration > Policies > Custom Options > Centralized Policy > Lists > Prefix

prefix-list list-name

ip-prefix prefix/length

Sites List of one or more site identifiers in the overlay network. You can specify a single site identifier (such as site-id 1) or a range of site identifiers (such as site-id 1-10). Configuration > Policies > Centralized Policy > Add Policy > Create Groups of Interest > Site

or

Configuration > Policies > Custom Options > Centralized Policy > Lists > Site

site-list list-name

site-id site-id

TLOCs

List of one or more TLOCs in the overlay network.

For each TLOC, specify its address, color, and encapsulation. address is the system IP address. color can be one of 3g, biz-internet, blue, bronze, custom1, custom2, custom3, default, gold, green, lte, metro-ethernet, mpls, mpls-restricted, private1 through private6, public-internet, red, and silver. encapsulation can be gre or ipsec.

Optionally, set a preference value (from 0 to 232 – 1) to associate with the TLOC address. When you apply a TLOC list in an action accept condition, when multiple TLOCs are available and satisfy the match conditions, the TLOC with the lowest preference value is used. If two or more of TLOCs have the lowest preference value, traffic is sent among them in an ECMP fashion.

Configuration > Policies > Centralized Policy > Add Policy > Create Groups of Interest > TLOC

or

Configuration > Policies > Custom Options > Centralized Policy > Lists > Site

tloc-list list-name

tloc ip-address color color encap encapsulation [preference number]

VPNs

List of one or more VPNs in the overlay network. For data policy, you can configure any VPNs except for VPN 0 and VPN 512.

To configure multiple VPNs in a single list, include multiple vpn options, specifying one VPN number in each option. You can specify a single VPN identifier (such as vpn 1) or a range of VPN identifiers (such as vpn 1-10).

Configuration > Policies > Centralized Policy > Add Policy > Create Groups of Interest > VPN

or

Configuration > Policies > Custom Options > Centralized Policy > Lists > VPN

vpn-list list-name

vpn vpn-id

VPN Lists

Each centralized data policy is associated with a VPN list. You configure VPN lists with the policy data-policy vpn-list command. The list you specify must be one that you created with a VPN Group of Interest or List in the Cisco vManage policy configuration wizard or with the policy lists vpn-list command.

For centralized data policy, you can include any VPNs except for VPN 0 and VPN 512. VPN 0 is reserved for control traffic, so never carries any data traffic, and VPN 512 is reserved for out-of-band network management, so also never carries any data traffic. Note that while the CLI allows you to include these two VPNs in a data policy configuration, the policy is not applied to these two VPNs.

Policer Parameters

To configure policing parameters, create a policer that specifies the maximum bandwidth and burst rate for traffic on an interface, and how to handle traffic that exceeds these values.

In Cisco vManage NMS, you configure policer parameters from:

  • Configuration > Policies > Centralized Policy > Add Policy > Create Groups of Interest > Policer

  • Configuration > Policies > Custom Options > Centralized Policy > Lists > Policer

In the CLI, you configure policer parameters as follows:

vSmart(config)# policy policer policer-name
vSmart(config-policer)# rate bps
vSmart(config-policer)# burst bytes
vSmart(config-policer)# exceed action

rate is the maximum traffic rate. It can be a value from 0 through 264 – 1 bits per second.

burst is the maximum traffic burst size. It can be a value from 15000 to 1000000 bytes.

exceed is the action to take when the burst size or traffic rate is exceeded. action can be drop (the default) or remark. The drop action is equivalent to setting the packet loss priority (PLP) bit to low. The remark action sets the PLP bit to high. In centralized data policy, access lists, and application-aware routing policy, you can match the PLP with the match plp option.

Sequences

Each VPN list consists of sequences of match–action pairs. The sequences are numbered to set the order in which data traffic is analyzed by the match–action pairs in the policy.

In the Cisco vManage NMS, you configure sequences from:

  • Configuration > Policies > Centralized Policy > Add Policy > Configure Traffic Rules > (Application-Aware Routing | Traffic Data | Cflowd) > Sequence Type

  • Configuration > Policies > Custom Options > Centralized Policy > Traffic Policy > (Application-Aware Routing | Traffic Data | Cflowd) > Sequence Type

In the CLI, you configure sequences with the policy data-policy vpn-list sequence command.

Each sequence can contain one match condition and one action condition.

Match Parameters

Centralized data policy can match IP prefixes and fields in the IP headers, as well as applications. You can also enable split DNS.

In Cisco vManage NMS, you configure match parameters from:

  • Configuration > Policies > Centralized Policy > Add Policy > Configure Traffic Rules > (Application-Aware Routing | Traffic Data | Cflowd) > Sequence Type > Sequence Rule > Match

  • Configuration > Policies > Custom Options > Centralized Policy > Traffic Policy > (Application-Aware Routing | Traffic Data | Cflowd) > Sequence Type > Sequence Rule > Match

Each sequence in a policy can contain one match condition.

For data policy, you can match these parameters:

Description vManage Configuration/CLI Configuration Command Value or Range
Match all packets

Omit Match

Omit match command

—
Applications or application families

Match Applications/Application Family List

app-list list-name

 Name of an application list or an app-list list
Group of destination prefixes

Match Destination Data Prefix

destination-data-prefix-list list-name

 Name of a data prefix list or a data-prefix-list list
Individual destination prefix

Match Destination Data Prefix

destination-ip prefix/length

 IP prefix and prefix length
Destination port number

Match Destination Port

destination-port number

 0 through 65535; specify a single port number, a list of port numbers (with numbers separated by a space), or a range of port numbers (with the two numbers separated with a hyphen [-])
Enable split DNS, to resolve and process DNS requests and responses on an application-by-application basis

Match DNS Application List

dns-app-list list-name

 Name of an app-list list. This list specifies the applications whose DNS requests are processed.
Specify the direction in which to process DNS packets

Match DNS

dns (request | response)

To process DNS requests sent by the applications (for outbound DNS queries), specify dns request.To process DNS responses returned from DNS servers to the applications, specify dns response.
DSCP value

Match DSCP

dscp number

 0 through 63
Packet length

Match Packet Length

packet-length number

 0 through 65535; specify a single length, a list of lengths (with numbers separated by a space), or a range of lengths (with the two numbers separated with a hyphen [-])
Packet loss priority (PLP)

Match PLP

plp

 (high | low)By default, packets have a PLP value of low. To set the PLP value to high, apply a policer that includes the exceed remark option.
Internet protocol number

Match Protocol

protocol number

 0 through 255
Group of source prefixes

Match Source Data Prefix

source-data-prefix-list list-name

 Name of a data prefix or a data-prefix-list list
Individual source prefix

Match Source Data Prefix

source-ip prefix/length

 IP prefix and prefix length
Source port number

Match Source Port

source-port address

 0 through 65535; specify a single port number, a list of port numbers (with numbers separated by a space), or a range of port numbers (with the two numbers separated with a hyphen [-])
TCP flag tcp flag syn

Action Parameters

Table 1. Feature History

Feature Name

Release Information

Description

Path Preference Support for Cisco IOS XE SD-WAN Devices

Cisco IOS XE Release Amsterdam 17.2.1r

This feature extends to Cisco IOS XE SD-WAN devices, support for selecting one or more local transport locators (TLOCs) for a policy action.

When data traffic matches the conditions in the match portion of a centralized data policy, the packet can be accepted or dropped, and it can be counted. Then, you can associate parameters with accepted packets.

In Cisco vManage NMS, you configure match parameters from:

  • Configuration > Policies > Centralized Policy > Add Policy > Configure Traffic Rules > (Application-Aware Routing | Traffic Data | Cflowd) > Sequence Type > Sequence Rule > Action

  • Configuration > Policies > Custom Options > Centralized Policy > Traffic Policy > (Application-Aware Routing | Traffic Data | Cflowd) > Sequence Type > Sequence Rule > Action.

In the CLI, you configure the action parameters with the policy data-policy vpn-list sequence action command.

Each sequence in a centralized data policy can contain one action condition.

In the action, you first specify whether to accept or drop a matching data packet, and whether to count it:

Description vManage Configuration/CLI Configuration Parameter Value or Range
Accept the packet. An accepted packet is eligible to be modified by the additional parameters configured in the action portion of the policy configuration.

Click Accept.

accept

 —
Enable cflowd traffic monitoring.

Click Accept, then action Cflowd

cflowd

 —
Count the accepted or dropped packets.

Action Counter

Click Accept, then action Counter

count counter-name

 Name of a counter. Use the show policy access-lists counters command on the Cisco IOS XE SD-WAN device.
Discard the packet. This is the default action.

Click Drop

drop

 —
Redirect DNS requests to a particular DNS server. Redirecting requests is optional, but if you do so, you must specify both actions.

Click Accept, then action Redirect DNS

redirect-dns hostredirect-dns ip-address

For an inbound policy, redirect-dns host allows the DNS response to be correctly forwarded back to the requesting service VPN.

For an outbound policy, specify the IP address of the DNS server.
Fine-tune TCP to decrease round-trip latency and improve throughout for matching TCP traffic.

Click Accept, then action TCP Optimization

tcp-optimization

 —

Note

On Cisco IOS XE routers, all the ongoing optimized flows are dropped when the TCP Optimization is removed.

Then, for a packet that is accepted, the following parameters can be configured:

Description vManage CLI Configuration Parameter Value or Range
Enable cflowd traffic monitoring.

Click Accept, then action Cflowd.

cflowd

 —
Direct matching traffic to the NAT functionality so that it can be redirected directly to the Internet or other external destination.

Click Accept, then action NAT Pool or NAT VPN.

nat [pool number] [use-vpn 0]

—
DSCP value.

Click Accept, then action DSCP.

set dscp value

 0 through 63
Forwarding class.

Click Accept, then action Forwarding Class.

set forwarding-class value

 Name of forwarding class

Direct matching packets to a TLOC that mathces the color and encapsulation

By default, if the TLOC is not available, traffic is forwarded using an alternate TLOC.

Click Accept, then action Local TLOC.

set local-tloc color color [encap encapsulation]

color​ can be:

3g, biz-internet, blue,

bronze, custom1, custom2,

custom3, default, gold,

green lte, metro-ethernet,

mpls, private1 through private6,

public-internet, red, and silver.

By default, encapsulation is ipsec. It can also be gre.

Direct matching packets to one of the TLOCs in the list if the TLOC matches the color and encapsulation

By default, if the TLOC is not available, traffic is forwarded using an alternate TLOC. To drop traffic if a TLOC is unavailable, include the restrict option.

Click Accept, then action Local TLOC

set local-tloc-list color color encap encapsulation [restrict]

Set the next hop to which the packet should be forwarded.

Click Accept, then action Next Hop.

set next-hop ip-address

 IP address
Apply a policer.

Click Accept, then action Policer.

set policer policer-name

 Name of policer configured with a policy policer command.

Specify a service to redirect traffic to before delivering the traffic to its destination.

The TLOC address or list of TLOCs identifies the remote TLOCs to which the traffic should be redirected to reach the service. In the case of multiple TLOCs, the traffic is load-balanced among them.

The VPN identifier is where the service is located.

Configure the services themselves on the Cisco IOS XE SD-WAN devices that are collocated with the service devices, using the vpn service command.

Click Accept, then action Service.

set service service-name [tloc ip-address​ | tloc-list list-name] [vpn vpn-id]

Standard services: FW, IDS, IDP

Custom services: netsvc1, netsvc2,netsvc3, netsvc4

TLOC list is configured with a policy lists tloc-list list.

Direct traffic to a remote TLOC that matches the IP address, color, and encapsulation.

Click Accept, then action TLOC.

set tloc address color color [encap encapsulation]

TLOC address, color, and encapsulation
Direct traffic to one of the remote TLOCs in the TLOC list if it matches the IP address, color, and encapsulation of one of the TLOCs in the list. If a preference value is configured for the matching TLOC, that value is assigned to the traffic.

Click Accept, then action TLOC.

set tloc-list list-name

 Name of a policy lists tloc-list list
Set the VPN that the packet is part of.

Click Accept, then action VPN.

set vpn vpn-id

 0 through 65530

The following table describes the IPv4 and IPv6 actions.

IPv4 Actions

IPv6 Actions

drop, dscp, next-hop (from-service only)/vpn, count, forwarding class, policer (only in interface ACL), App-route SLA (only)
App-route preferred color, app-route sla strict, cflowd, nat, redirect-dns

drop, dscp, next-hop/vpn, count, forwarding class, policer (only in interface ACL)

App-route SLA (only), App-route preferred color, app-route sla strict

policer (DataPolicy), tcp-optimization, fec-always,

policer (DataPolicy)

tloc, tloc-list (set tloc, set tloc-list)

tloc, tloc-list (set tloc, set tloc-list)

App-Route backup-preferred color, local-tloc, local-tloc-list

 App-Route backup-preferred color, local-tloc, local-tloc-list

Default Action

If a data packet being evaluated does not match any of the match conditions in a data policy, a default action is applied to the packet. By default, the data packet is dropped

In the Cisco vManage NMS, you modify the default action from:

  • Configuration > Policies > Centralized Policy > Add Policy > Configure Traffic Rules > (Application-Aware Routing | Traffic Data | Cflowd) > Sequence Type > Sequence Rule > Default Action

  • Configuration > Policies > Custom Options > Centralized Policy > Traffic Policy > (Application-Aware Routing | Traffic Data | Cflowd) > Sequence Type > Sequence Rule > Default Action.

In the CLI, you modify the default action with the policy data-policy vpn-list default-action accept command.

Apply Centralized Data Policy

For a centralized data policy to take effect, you apply it to a list of sites in the overlay network.

To apply a centralized policy in the Cisco vManage NMS:

  1. In the Cisco vManage NMS, select the Configure > Policies screen.

  2. Select a policy from the policy table.

  3. Click the More Actions icon to the right of the row, and click Activate. The Activate Policy popup opens. It lists the IP addresses of the reachable Cisco vSmart Controllers to which the policy is to be applied.

  4. Click Activate.

To apply a centralized policy in the CLI:

vSmart(config)# apply-policy site-list list-name data-policy policy-name (all | from-service | from-tunnel)

By default, data policy applies to all data traffic passing through the device: the policy evaluates all data traffic going from the local site (that is, from the service side of the router) into the tunnel interface, and it evaluates all traffic entering to the local site through the tunnel interface. You can explicitly configure this behavior by including the all option. To have the data policy apply only to traffic coming from the service site and exiting from the local site through the tunnel interface, include the from-service option. To have the policy apply only to traffic entering from the tunnel interface and traveling to the service site, include the from-tunnel option. You can apply different data policies in each of the two traffic directions.

For all data-policy policies that you apply with apply-policy commands, the site IDs across all the site lists must be unique. That is, the site lists must not contain overlapping site IDs. An example of overlapping site IDs are those in the two site lists site-list 1 site-id 1-100 and site-list 2 site-id 70-130. Here, sites 70 through 100 are in both lists. If you were to apply these two site lists to two different data-policy policies, the attempt to commit the configuration on the Cisco vSmart Controller would fail.

The same type of restriction also applies to the following types of policies:

  • Application-aware routing policy (app-route-policy)

  • Centralized control policy (control-policy)

  • Centralized data policy used for cflowd flow monitoring (data-policy hat includes a cflowd action and apply-policy that includes a cflowd-template command)

You can, however, have overlapping site IDs for site lists that you apply for different types of policy. For example, the sites lists for control-policy and data-policy policies can have overlapping site IDs. So for the two example site lists above, site-list 1 site-id 1-100 and site-list 2 site-id 70-130, you could apply one to a control policy and the other to a data policy.

As soon as you successfully activate the configuration by issuing a commit command, the Cisco vSmart Controller pushes the data policy to the devices located in the specified sites. To view the policy as configured on the Cisco vSmart Controllers, use the show running-config command on the Cisco vSmart Controller: 

vSmart# show running-config policy
vSmart# show running-config apply-policy

To view the policy that has been pushed to the Cisco IOS XE SD-WAN device, use the show sdwan policy from-vsmart command on the Cisco IOS XE SD-WAN device. 


Device# show sdwan policy from-vsmart

Deep Packet Inspection

You configure deep packet inspection using a standard centralized data policy. You define the applications of interest in a vManage policy list or with policy lists app-list CLI command, and you call these lists in the match portion of the data policy. You can control the path of the application traffic through the network by defining, in the action portion of the data policy, the local TLOC or the remote TLOC, or for strict control, you can define both.

Configure Deep Packet Inspection Using vManage

To configure a centralized data policy for deep packet inspection, use the vManage policy configuration wizard. Use the wizard to create and edit deep packet inspection policy components:

  • Configure groups of interest (lists) to group related items to be called in the centralized data policy.

  • Configure traffic rules.

  • Apply the policy.

Step 1: Start the Policy Configuration Wizard

To start the policy configuration wizard:

  1. In vManage NMS, select the Configure > Policies screen.

  2. Select the Centralized Policy tab.

  3. Click Add Policy.

The policy configuration wizard opens, and the Create Groups of Interest screen is displayed.

Step 2: Create Groups of Interest

In Create Groups of Interest, create lists of groups to use in centralized policy:

To configure groups of interest for deep packet inspection:

  1. In the left pane, select the type of list. For centralized data policy for deep packet inspection, you can use Application, Site, and VPN lists.

  2. To create a new list, click New List.

    To modify an existing list, click the More Actions icon to the right of the desired list, and click the pencil icon.

  3. In the List Name field, enter a name for the list. This field is mandatory and can contain only uppercase and lowercase letters, the digits 0 through 9, hyphens (–), and underscores (_). It cannot contain spaces or any other characters.

  4. In the field below the List Name field, enter the desired values for the list. For some lists you type the desired values, and for others you select from a drop-down.

  5. Click Add (for a new list) or Save (for an existing list).

  6. Click Next to move to the Configure Topology and VPN Membership screen.

  7. Click Next to move the Configure Traffic Rules in the wizard.

Step 3: Configure Traffic Rules

When you first open the Traffic Rules screen, the Application-Aware Routing tab is selected by default:

To configure traffic rules for deep packet inspection policy:

  1. In the Application-Aware Routing bar, click Traffic Data.

  2. To create a new centralized data policy, click Add Policy.

    To modify an existing policy, click the More Actions icon to the right of the desired policy, and click the pencil icon.

  3. If data traffic does not match any of the conditions in one of the sequences, it is dropped by default. If you want nonmatching routes to be accepted, click the pencil icon in the Default Action, click Accept, and click Save Match And Actions.

  4. To create a match–action sequence for data traffic:

    1. Click Sequence Type.

    2. To create a match–action rule, click Sequence Rule. The Match button is selected by default.

    3. Click the desired Match button, and enter the desired values in Match Conditions. For some conditions, you type the desired values, and for others you select from a drop-down.

    4. Click the Actions button. The default action is Reject. To accept matching packets, click the Accept radio button. Then click the desired action, and enter the desired values for Actions.

    5. Click Save Match and Actions.

    6. Create additional Sequence Rules or Sequence Types, as needed.

  5. To rename a Sequence Type, double-click its name in the right pane, and type the new name. The name also changes in the right pane.

  6. To re-order sequence rules and types, drag and drop them them.

  7. Click Save.

  8. Click Next to move to the Apply Policies to Sites and VPNs in the wizard.

Step 4: Apply Policies to Sites and VPNs

  1. In Apply Policies to Sites and VPNs, apply a policy to overlay network sties and VPNs:

  2. In the Policy Name field, enter a name for the policy. This field is mandatory and can contain only uppercase and lowercase letters, the digits 0 through 9, hyphens (–), and underscores (_). It cannot contain spaces or any other characters.

  3. In the Policy Description field, enter a description of the policy. It can contain up to 2048 characters. This field is mandatory, and it can contain any characters and spaces.

  4. From the Topology bar, select the Application-Aware Routing tab. The table then lists policies that you have created for that type of policy block.

  5. Click Add New Site List and VPN List or Add New Site. Some topology blocks might have no Add buttons. Select one or more site lists, and select one or more VPN lists. Click Add.

  6. Click Preview to view the configured policy. The policy is displayed in CLI format.

  7. Click Save Policy. The Configuration > Policies screen opens, and the policies table includes the newly created policy.

Step 5: Activate a Centralized Data Policy

Activating a centralized data policy sends that policy to all connected vSmart controllers. To activate a centralized policy:

  1. In vManage NMS, select the Configure > Policies screen.

  2. Select a policy from the policy table.

  3. Click the More Actions icon to the right of the row, and click Activate. The Activate Policy popup opens. It lists the IP addresses of the reachable vSmart controllers to which the policy is to be applied.

  4. Click Activate.

Configure Deep Packet Inspection Using CLI

Following are the high-level steps for configuring a centralized data policy to use for deep packet inspection:

  1. Create a list of overlay network sites to which the data policy is to be applied in the apply-policy command: 

    vSmart(config)# policy
vSmart(config-policy)# lists site-list list-name
vSmart(config-lists-list-name)# site-id site-id

    The list can contain as many site IDs as necessary. Include one site-id command for each site ID. For contiguous site IDs, you can specify a range of numbers separated with a dash (–).

    Create additional site lists, as needed.

  2. Create lists of applications and application families that are to be subject to the data policy, Each list can contain one or more application names, or one or more application families. A single list cannot contain both applications and application families. 

    vSmart(config)# policy lists
vSmart(config-lists)# app-list list-name
vSmart(config-app-list)# app application-name

vSmart(config)# policy lists
vSmart(config-lists)# app-list list-name
vSmart(config-applist)# app-family family-name

  3. Create lists of IP prefixes and VPNs, as needed:

    vSmart(config)# policy lists
vSmart(config-lists)# data-prefix-list list-name
vSmart(config-lists-list-name)# ip-prefix prefix/length

vSmart(config)# policy lists
vSmart(config-lists)# vpn-list list-name
vSmart(config-lists-list-name)# vpn vpn-id

  4. Create lists of TLOCs, as needed:

    vSmart(config)# policy​
vSmart(config-policy)# lists tloc-list list-name
vSmart(config-lists-list-name)# tloc ip-address color color encap encapsulation [preference number]

  5. Define policing parameters, as needed:

    vSmart(config-policy)# policer policer-name
vSmart(config-policer)# rate bandwidth
vSmart(config-policer)# burst bytes
vSmart(config-policer)# exceed action

  6. Create a data policy instance and associate it with a list of VPNs:

    vSmart(config)# policy data-policy policy-name
vSmart(config-data-policy-policy-name)# vpn-list list-name

  7. Create a series of match–pair sequences:

    vSmart(config-vpn-list)# sequence number
vSmart(config-sequence-number)#

    The match–action pairs are evaluated in order, by sequence number, starting with the lowest numbered pair and ending when the route matches the conditions in one of the pairs. Or if no match occurs, the default action is taken (either rejecting the route or accepting it as is).

  8. Define match parameters based on applications:

    vSmart(config-sequence-number)# match app-list list-name

  9. Define additional match parameters for data packets:

    vSmart(config-sequence-number)# match parameters

  10. Define actions to take when a match occurs:

    vSmart(config-sequence-number)# action (accept | drop) [count]

  11. For packets that are accepted, define the actions to take. To control the tunnel over which the packets travels, define the remote or local TLOC, or for strict control over the tunnel path, set both: 

    vSmart(config-action)# set tloc ip-address color color encap encapsulation
vSmart(config-action)# set tloc-list list-name
vSmart(config-action)# set local-tloc color color encap encapsulation
vSmart(config-action)# set local-tloc-list color color encap encapsulation [restrict]
  12. Define additional actions to take.
  13. Create additional numbered sequences of match–action pairs within the data policy, as needed.

  14. If a route does not match any of the conditions in one of the sequences, it is rejected by default. If you want nonmatching prefixes to be accepted, configure the default action for the policy: 

    vSmart(config-policy-name)# default-action accept

  15. Apply the policy to one or more sites in the overlay network:

    vSmart(config)# apply-policy site-list list-name data-policy policy-name (all | from-service | from-tunnel)

To enable the infrastructure for deep packet inspection on the vEdge routers, include the following command in the configuration on the routers: 

vEdge(config)# policy app-visibility

Structural Components of Policy Configuration for Deep Packet Inspection

Following are the structural components required to configure centralized data policy for deep packet inspection. Each one is explained in more detail in the sections below. 

On the vSmart controller:
policy
  lists
    app-list list-name
      (app applications | app-family application-families)
    data-prefix-list list-name 
      ip-prefix prefix 
    site-list list-name 
      site-id site-id 
    tloc-list list-name
      tloc ip-address color color encap encapsulation [preference value]
    vpn-list list-name 
      vpn vpn-id 
  policer policer-name
    burst bytes
    exceed action
    rate bps
  data-policy policy-name 
    vpn-list list-name 
      sequence number 
        match
          app-list list-name
          destination-data-prefix-list list-name
          destination-ip ip-addresses
          destination-port port-numbers
          dscp number
          packet-length number
          protocol protocol
          source-data-prefix-list list-name
          source-ip ip-addresses
          source-port port-numbers
          tcp flag
        action
          drop
          count counter-name
          log
          accept
            nat [pool number] [use-vpn 0]
            set 
              dscp number
              forwarding-class class
              local-tloc color color [encap encapsulation] [restrict]
              next-hop ip-address
              policer policer-name
              service service-name local [restrict] [vpn vpn-id]
              service service-name (tloc ip-address | tloc-list list-name) [vpn vpn-id]
              tloc ip-address color color encap encapsulation
              tloc-list list-name
              vpn vpn-id
      default-action
        (accept | drop)
apply-policy site-list list-name 
  data-policy policy-name (all | from-service | from-tunnel) 
  
On the vEdge router:
policy
  app-visibility

Action Parameters for Configuring Deep Packet Inspection

When data traffic matches the conditions in the match portion of a centralized data policy, the packet can be accepted or dropped, and it can be counted. Then, you can associate parameters with accepted packets.

In vManage NMS, you configure match parameters from:

  • Configuration > Policies > Centralized Policy > Add Policy > Configure Traffic Rules > (Application-Aware Routing | Traffic Data | Cflowd) > Sequence Type > Sequence Rule > Action

  • Configuration > Policies > Custom Options > Centralized Policy > Traffic Policy > (Application-Aware Routing | Traffic Data | Cflowd) > Sequence Type > Sequence Rule > Action.

In the CLI, you configure the action parameters under the policy data-policy vpn-list sequence action command.

Each sequence in a centralized data policy can contain one action condition.

In the action, you first specify whether to accept or drop a matching data packet, and whether to count it:

Description vManage Configuration/CLI Configuration Parameter Value or Range
Accept the packet. An accepted packet is eligible to be modified by the additional parameters configured in the action portion of the policy configuration.

Click Accept.

accept

—
Count the accepted or dropped packets.

Action Counter

Click Accept, then action Counter

count counter-name

Name of a counter. Use the show policy access-lists counters command on the Cisco device.
Discard the packet. This is the default action.

Click Drop

drop

—

To view the packet logs, use the show app log flows and show log commands.

Then, for a packet that is accepted, the following parameters can be configured. Note that you cannot use DPI with either cflowd or NAT.

Description vManage CLI Configuration Parameter Value or Range
DSCP value.

Click Accept, then action DSCP.

set dscp value

0 through 63
Forwarding class.

Click Accept, then action Forwarding Class.

set forwarding-class value

Name of forwarding class

Direct matching packets to a TLOC that mathces the color and encapsulation

By default, if the TLOC is not available, traffic is forwarded using an alternate TLOC.

Click Accept, then action Local TLOC.

set local-tloc color color [encap encapsulation]

color​ can be:

3g, biz-internet, blue,

bronze, custom1, custom2,

custom3, default, gold,

green lte, metro-ethernet,

mpls, private1 through private6,

public-internet, red, and silver.

By default, encapsulation is ipsec. It can also be gre.

Direct matching packets to one of the TLOCs in the list if the TLOC matches the color and encapsulation

By default, if the TLOC is not available, traffic is forwarded using an alternate TLOC. To drop traffic if a TLOC is unavailable, include the restrict option.

Click Accept, then action Local TLOC

set local-tloc-list color color encap encapsulation [restrict]

Set the next hop to which the packet should be forwarded.

Click Accept, then action Next Hop.

set next-hop ip-address

IP address
Apply a policer.

Click Accept, then action Policer.

set policer policer-name

Name of policer configured with a policy policer command.

Direct matching packets to the name service, before delivering the traffic to its ultimate destination.

The TLOC address or list of TLOCs identifies the remote TLOCs to which the traffic should be redirected to reach the service. In the case of multiple TLOCs, the traffic is load-balanced among them.

The VPN identifier is where the service is located.

Configure the services themselves on the vEdge routers that are collocated with the service devices, using the vpn service configuration command.

Click Accept, then action Service.

set service service-name [tloc ip-address​ | tloc-list list-name] [vpn vpn-id]

Standard services: FW, IDS, IDP

Custom services: netsvc1, netsvc2,netsvc3, netsvc4

TLOC list is configured with a policy lists tloc-list list.

Direct matching packets to the named service that is reachable via a GRE tunnel whose source is in the transport VPN (VPN 0). If the GRE tunnel used to reach the service is down, packet routing falls back to using standard routing. To drop packets when a GRE tunnel to the service is unreachable, include the restrict option. In the service VPN, you must also advertise the service using the service command. You configure the GRE interface or interfaces in the transport VPN (VPN 0).

Click Accept, then action Service.

set service service-name [tloc ip-address​ | tloc-list list-name] [vpn vpn-id]

Standard services: FW, IDS, IDP

Custom services: netsvc1, netsvc2,netsvc3, netsvc4

Direct traffic to a remote TLOC. The TLOC is defined by its IP address, color, and encapsulation.

Click Accept, then action TLOC.

set local-tloc color color [encap encapsulation]

TLOC address, color, and encapsulation

Direct traffic to one of the remote TLOCs in the TLOC list.

Click Accept, then action TLOC.

set tloc-list list-name

Name of a policy lists tloc-list list
Set the VPN that the packet is part of.

Click Accept, then action VPN.

set vpn vpn-id

0 through 65530
Default Action

If a data packet being evaluated does not match any of the match conditions in a data policy, a default action is applied to the packet. By default, the data packet is dropped.

In vManage NMS, you modify the default action from Configuration > Policies > Centralized Policy > Add Policy > Configure Traffic Rules > Application-Aware Routing > Sequence Type > Sequence Rule > Default Action.

In the CLI, you modify the default action with the policy data-policy vpn-list default-action accept command.

Apply Centralized Data Policy for Deep Packet Inspection

For a deep packet inspection centralized data policy to take effect, you apply it to a list of sites in the overlay network.

To apply a centralized policy in vManage NMS:

  1. In vManage NMS, select the Configure > Policies screen.

  2. Select a policy from the policy table.

  3. Click the More Actions icon to the right of the row, and click Activate. The Activate Policy popup opens. It lists the IP addresses of the reachable vSmart controllers to which the policy is to be applied.

  4. Click Activate.

To apply a centralized policy in the CLI:

vSmart(config)# apply-policy site-list list-name data-policy policy-name (all | from-service | from-tunnel)

By default, data policy applies to all data traffic passing through the vEdge router: the policy evaluates all data traffic going from the local site (that is, from the service side of the router) into the tunnel interface, and it evaluates all traffic entering to the local site through the tunnel interface. You can explicitly configure this behavior by including the all option. To have the data policy apply only to policy exiting from the local site, include the from-service option. To have the policy apply only to incoming traffic, include the from-tunnel option.

You cannot apply the same type of policy to site lists that contain overlapping site IDs. That is, all data policies cannot have overlapping site lists among themselves. If you accidentally misconfigure overlapping site lists, the attempt to commit the configuration on the vSmart controller fails.

As soon as you successfully activate the configuration by issuing a commit command, the vSmart controller pushes the data policy to the vEdge routers located in the specified sites. To view the policy as configured on the vSmart controller, use the show running-config command on the vSmart controller: 

vSmart# show running-config policy
vSmart# ;show running-config apply-policy

To view the policy that has been pushed to the vEdge router, use the show policy from-vsmart command on the vEdge router.

vEdge# show policy from-vsmart
Monitor Running Applications

To enable the deep packet inspection infrastructure on the vEdge routers, you must enable application visibility on the routers:

vEdge(config)# policy app-visibility

To display information about the running applications, use the show app dpi supported-applications, show app dpi applications, and show app dpi flows commands on the router.

View DPI Applications Using vManage

You can view the list of all the application-aware applications supported by the SD-WAN software on the router using the following steps:

  1. In the Cisco vManage, select the Monitor > Network screen.

  2. From the WAN-Edge pane, select the Device that supports DPI. The vManage Control Connections page displays.

  3. In the left pane, select Real Time to view the device details.

  4. From the Device Options drop-down, choose DPI Applications to view the list of applications running on the device.

  5. From the Device Options drop-down, choose DPI Supported Applications to view the list of applications that are supported on the device.

Centralized Data Policy Configuration Examples

This topic provides some examples of configuring centralized data policy to influence traffic flow across the Cisco IOS XE SD-WAN domain and to configure a Cisco IOS XE SD-WAN device to be an Internet exit point.

General Centralized Data Policy Example

This section shows a general example of a centralized data policy to illustrate that you configure centralized data policy on a Cisco vSmart Controller and that after you commit the configuration, the policy itself is pushed to the required Cisco IOS XE SD-WAN devices.

Here we configure a simple data policy on the Cisco vSmart Controller vm9: 

vm9# show running-config policy
policy
 data-policy test-data-policy
  vpn-list test-vpn-list
   sequence 10
    match
     destination-ip 209.165.201.0/27
    !
    action drop
     count test-counter
    !
   !
   default-action drop
  !
 !
 lists
  vpn-list test-vpn-list
   vpn 1
  !
  site-list test-site-list
   site-id 500
  !
 !
!

Then, apply this policy to the site list named test-site-list, which includes site 500: 

vm9# show sdwan running-config apply-policy 
apply-policy
 site-list test-site-list
  data-policy test-data-policy
 !
!

Immediately after you activate the configuration on the Cisco vSmart Controller, it pushes the policy configuration to the Cisco IOS XE SD-WAN devices in site 500. One of these devices is vm5, where you can see that the policy has been received: 

vm5# show sdwan policy from-vsmart 
policy-from-vsmart
 data-policy test-data-policy
  vpn-list test-vpn-list
   sequence 10
    match
     destination-ip 209.165.201.0/27
    !
    action drop
     count test-counter
    !
   !
   default-action drop
  !
 !
 lists
  vpn-list test-vpn-list
   vpn 1
  !
 !
!

Control Access

This example shows a data policy that limits the type of packets that a source can send to a specific destination. Here, the host at source address 192.0.2.1 in site 100 and VPN 100 can send only TCP traffic to the destination host at 203.0.113.1. This policy also specifies the next hop for the TCP traffic sent by 192.0.2.1, setting it to be TLOC 209.165.200.225, color gold. All other traffic is accepted as a result of the default-action statement. 

policy
  lists
     site-list north
       site-id 100
     vpn-list vpn-north
       vpn 100
  !
  data-policy tcp-only
     vpn-list vpn-north
       sequence 10
         match
           source-ip 192.0.2.1/32
           destination-ip 198.51.100.1/32
           protocol tcp
         action accept
           set tloc 203.0.113.1 gold
       !
       default-action accept
   !
!
apply-policy
   site north data-policy tcp-only

Restrict Traffic

This examples illustrates how to disallow certain types of data traffic from being sent from between VPNs. This policy drops data traffic on port 25, which carries SMTP mail traffic, that originates in 209.165.201.0/27. However, the policy accepts all other data traffic, including non-SMTP traffic from 209.165.201.0/27. 

policy
  lists
    data-prefix-list north-ones
      ip-prefix 209.165.201.0/27
      port 25
    vpn-list all-vpns
      vpn 1
      vpn 2
    site-list north
      site-id 100
  !
  data-policy no-mail
   vpn-list all-vpns
     sequence 10
       match
         source-data-prefix-list north-ones
       action drop
     !
     default-action accept
  !
!
apply-policy
  site north data-policy no-mail

Localized Data Policy

Data policy operates on the data plane in the Cisco IOS XE SD-WAN overlay network and affects how data traffic is sent among the Cisco IOS XE SD-WAN devices in the network. The Cisco SD-WAN architecture defines two types of data policy, centralized data policy, which controls the flow of data traffic based on the IP header fields in the data packets and based on network segmentation, and localized data policy, which controls the flow of data traffic into and out of interfaces and interface queues on a Cisco IOS XE SD-WAN device.

Localized data policy, so called because it is provisioned on the local Cisco IOS XE SD-WAN device, is applied on a specific router interface and affects how a specific interface handles the data traffic that it is transmitting and receiving. Localized data policy is also referred to as access lists (ACLs). With access lists, you can provision class of service (CoS), classifying data packets and prioritizing the transmission properties for different classes. You can configure policing.

For IPv4, you can configure QoS actions.

You can apply IPv4 access lists in any VPN on the router, and you can create access lists that act on unicast and multicast traffic. You can apply IPv6 access lists only to tunnel interfaces in the transport VPN (VPN 0).

You can apply access lists either in the outbound or inbound direction on the interface. Applying an IPv4 ACL in the outbound direction affects data packets traveling from the local service-side network into the IPsec tunnel toward the remote service-side network. Applying an IPv4 ACL in the inbound direction affects data packets exiting from the IPsec tunnel and being received by the local Cisco IOS XE SD-WAN device. For IPv6, an outbound ACL is applied to traffic being transmitted by the router, and an inbound ACL is applied to received traffic.

Explicit and Implicit Access Lists

Access lists that you configure using localized data policy are called explicit ACLs. You can apply explicit ACLs in any VPN on the router.

Router tunnel interfaces also have implicit ACLs, which are also referred to as services. Some of these are present by default on the tunnel interface, and they are in effect unless you disable them. Through configuration, you can also enable other implicit ACLs. On Cisco IOS XE SD-WAN devices, the following services are enabled by default: DHCP (for DHCPv4 and DHCPv6), DNS, and ICMP. You can also enable services for BGP, Netconf, NTP, OSPF, SSHD, and STUN.

Perform QoS Actions

With access lists, you can provision quality of service (QoS) which allows you to classify data traffic by importance, spread it across different interface queues, and control the rate at which different classes of traffic are transmitted. See Forwarding and QoS Overview.

Localized Data Policy for IPv4

This topic provides procedures for configuring IPv4 localized data policy This type of data policy is called access lists, or ACLs. You can provision simple access lists that filter traffic based on IP header fields. You also use access lists to apply QoS, and policing to data packets. You can create access lists that act on unicast and multicast traffic.

In Cisco vManage NMS, you configure localized data policy from the Configuration > Policies screen, using a policy configuration wizard. In the CLI, you configure these policies on the Cisco IOS XE SD-WAN device.

Configuration Components

An access list consists of a sequences of match–action pairs that are evaluated in order, from lowest sequence number to highest sequence number. When a packet matches one of the match conditions, the associated action is taken and policy evaluation on that packets stops. Keep this in mind as you design your policies to ensure that the desired actions are taken on the items subject to policy.

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

The following figure illustrates the configuration components for access lists.

Figure 1. Configuration Components

Configure Localized Data Policy for IPv4 Using Cisco vManage

Table 2. Feature History

Feature Name

Release Information

Description

Control Traffic Flow Using Class of Service Values

Cisco IOS XE SD-WAN Release 16.12.1b

This feature lets you control the flow of traffic into and out of a Cisco IOS XE SD-WAN device interface based on the conditions defined in the quality of service (QoS) map. A priority field and a layer 2 class of service (CoS) were added for configuring the re-write rule.

To configure IPv4 localized policy, use the Cisco vManage policy configuration wizard. The wizard is a UI policy builder that consists of five screens to configure IPv4 localized policy components:

  • Groups of Interest, also called lists—Create data prefix lists and policer parameters that group together related items and that you call in the match or action components of a policy.

  • Forwarding Classes—Define forwarding classes and rewrite rules to use for QoS.

  • Access Control Lists—Define the match and action conditions of ACLs.

  • Route Policies—Define the match and action conditions of route policies.

  • Policy Settings—Define additional policy settings, including Cloud QoS settings.

You configure some or all these components depending on the specific policy you are creating. To skip a component, click the Next button at the bottom of the screen. To return to a component, click the Back button at the bottom of the screen.

Step 1: Start the Policy Configuration Wizard

To start the policy configuration wizard:

  1. In Cisco vManage NMS, select the Configure > Policies screen.

  2. Select the Localized Policy tab.

  3. Click Add Policy.

The policy configuration wizard opens, and the Create Groups of Interest screen is displayed.

Step 2: Create Groups of Interest

In the Create Groups of interest screen create lists to use in the localized data policy:

  1. Create news lists of groups, as described in the following table:

Table 3.

List Type

Procedure

Data Prefix

  1. In the left bar, click Data Prefix.

  2. Click New Data Prefix List.

  3. Enter a name for the list.

  4. Enter one or more IP prefixes.

  5. Click Add.

Mirror

  1. In the left bar, click Mirror.

  2. Click New Mirror List. The Mirror List popup displays.

  3. Enter a name for the list.

  4. In the Remote Destination IP field, enter the IP address of the destination to which to mirror the packets.

  5. In the Source IP field, enter the IP address of the source of the packets to mirror.

  6. Click Save.

Policer

  1. In the left bar, click Policer.

  2. Click New Policer List.

  3. Enter a name for the list.

  4. In the Burst field, enter maximum traffic burst size. It can be a value from 15000 to 10000000 bytes.

  5. In the Exceed field, select the action to take when the burst size or traffic rate is exceeded. Select Drop (the default) to set the packet loss priority (PLP) to low. Select Remark to set the PLP to high.

  6. In the Rate field, enter the maximum traffic rate. It can be value from 0 through 264 – 1 bps

  7. Click Add.

  1. Click Next to move to Configure Forwarding Classes/QoS in the wizard.

Step 3: Configure Forwarding Classes for QoS

When you first open the Forwarding Classes/QoS screen, the QoS tab is selected by default:

To configure forwarding classes for use by QoS:

  1. To create a new QoS mapping:

    1. In the QoS tab, click the Add QoS drop-down.

    2. Select Create New.

    3. Enter a name and description for the QoS mapping.

    4. Click Add Queue. The Add Queue popup displays.

    5. Select the queue number from the Queue drop-down.

    6. Select the maximum bandwidth and buffer percentages, and the scheduling and drop types. Enter the forwarding class.

    7. Click Save.

  2. To import an existing QoS mapping:

    1. In the QoS tab, click the Add QoS drop-down.

    2. Select Import Existing.

    3. Select a QoS mapping.

    4. Click Import.

  3. To view or copy a QoS mapping or to remove the mapping from the localized policy, click the More Actions icon to the right of the row, and select the desired action.

  4. To configure policy rewrite rules for the QoS mapping:

    1. In the QoS tab, click the Add Rewrite Policy drop-down..

    2. Select Create New.

    3. Enter a name and description for the rewrite rule.

    4. Click Add Rewrite Rule. The Add Rule popup displays.

    5. Select a class from the Class drop-down.

    6. Select the priority (Low or High) from the Priority drop-down.

      Low priority is supported only for Cisco IOS XE SD-WAN devices.

    7. Enter the DSCP value (0 through 63) in the DSCP field.

    8. Enter the class of service (CoS) value (0 through 7) in the Layer 2 Class of Service field.

    9. Click Save.

  5. To import an existing rewrite rule:

    1. In the QoS tab, click the Add Rewrite Policy drop-down..

    2. Select Import Existing.

    3. Select a rewrite rule.

    4. Click Import.

  6. Click Next to move to Configure Access Lists in the wizard.

Step 4: Configure ACLs

  1. In the Configure Access Control Lists screen, configure ACLs.

  2. To create a new IPv4 ACL, click the Add Access Control List Policy drop-down. Then select Add IPv4 ACL Policy:

  3. Enter a name and description for the ACL.

  4. In the left pane, click Add ACL Sequence. An Access Control List box is displayed in the left pane.

  5. Double-click the Access Control List box, and type a name for the ACL.

  6. In the right pane, click Add Sequence Rule to create a single sequence in the ACL. The Match tab is selected by default.

  7. Click a match condition.

  8. On the left, enter the values for the match condition.

  9. On the right enter the action or actions to take if the policy matches.

  10. Repeat Steps 6 through 8 to add match–action pairs to the ACL.

  11. To rearrange match–action pairs in the ACL, in the right pane drag them to the desired position.

  12. To remove a match–action pair from the ACL, click the X in the upper right of the condition.

  13. Click Save Match and Actions to save a sequence rule.

  14. To rearrange sequence rules in an ACL, in the left pane drag the rules to the desired position.

  15. To copy, delete, or rename an ACL sequence rule, in the left pane, click More Options next to the rule's name and select the desired option.

  16. If no packets match any of the ACL sequence rules, the default action is to drop the packets. To change the default action:

    1. Click Default Action in the left pane.

    2. Click the Pencil icon.

    3. Change the default action to Accept.

    4. Click Save Match and Actions.

  17. Click Next to move to Configure Route Policy in the wizard.

  18. Click Next to move to the Policy Overview screen.

Step 5: Configure Policy Settings

In Policy Overview, configure policy settings:

  1. Enter a name and description for the ACL.

  2. To enable cflowd visibility so that a Cisco IOS XE SD-WAN device can perform traffic flow monitoring on traffic coming to the router from the LAN, click Netflow.

  3. To enable application visibility so that a Cisco IOS XE SD-WAN device can monitor and track the applications running on the LAN, click Application.

  4. To enable QoS scheduling and shaping for traffic that a Cisco IOS XE SD-WAN device receives from transport-side interfaces, click Cloud QoS.

  5. To enable QoS scheduling and shaping for traffic that a Cisco IOS XE SD-WAN device receives from service-side interfaces, click Cloud QoS Service Side.

  6. To log the headers of all packets that are dropped because they do not match a service configured by an Allow Service parameter on a tunnel interface, click Implicit ACL Logging.

  7. To configure how often packets flows are logged, click Log Frequency. Packet flows are those that match an access list (ACL), a cflowd flow, or an application-aware routing flow.

  8. Click Preview to view the full policy in CLI format.

  9. Click Save Policy.

Step 6: Apply a Localized Data Policy in a Device Template

  1. In Cisco vManage NMS, select the Configuration > Templates screen.

  2. If you are creating a new device template:

    1. In the Device tab, click Create Template.

    2. From the Create Template drop-down, select From Feature Template.

    3. From the Device Model drop-down, select one of the Cisco IOS XE SD-WAN devices.

    4. In the Template Name field, enter a name for the device template. This field is mandatory and can contain only uppercase and lowercase letters, the digits 0 through 9, hyphens (–), and underscores (_). It cannot contain spaces or any other characters.

    5. In the Description field, enter a description for the device template. This field is mandatory, and it can contain any characters and spaces.

    6. Continue with Step 4.

  3. If you are editing an existing device template:

    1. In the Device tab, click the More Actions icon to the right of the desired template, and click the Pencil icon.

    2. Click the Additional Templates tab. The screen scrolls to the Additional Templates section.

    3. From the Policy drop-down, select the name of a policy that you have configured.

  4. Click the Additional Templates tab located directly beneath the Description field. The screen scrolls to the Additional Templates section.

  5. From the Policy drop-down, select the name of the policy you configured in the above procedure.

  6. Click Create (for a new template) or Update (for an existing template).

Structural Components of Configuration for Access Lists

Following are the structural components required to configure access lists, shown as they appear in the CLI and when you click Preview in the Cisco vManage localized policy configuration wizard. Each component is explained in the sections below. 

policy
  lists
    data-prefix-list list-name
      ip-prefix prefix/length
  class-map
    class class map map
  cloud-qos
  cloud-qos-service-side
  implicit-acl-logging
  log-frequency number
  qos-scheduler scheduler-name
    class class-name
    bandwidth-percent percentage
    buffer-percent percentage
    drops drop-type
    scheduling (llq | wrr)
  qos-map map-name
    qos-scheduler scheduler-name
  rewrite-rule rule-name
    class class-name priority dscp dscp-value layer-2-cos number
  mirror mirror-name
    remote-dest ip-address source ip-address
  policer policer-name
    rate bandwidth
    burst bytes
    exceed action
  access-list list-name
    sequence number
      match
        match-parameters
      action
        drop
          count counter-name
          log
        accept
          class class-name 
          count counter-name
          log
          mirror mirror-name
          policer policer-name
          set dscp value
          set next-hop ipv4-address
    default-action
      (accept | drop)
vpn vpn-id
  interface interface-name
    access-list list-name (in | out)
    policer policer-name (in | out)
    rewrite-rule rule-name
Lists

Access lists use prefix lists to group related prefixes.

In the Cisco vManage NMS, you configure prefix lists from:

  • Configuration > Policies > Localized Policy > Add Policy > Create Groups of Interest

  • Configuration > Policies > Custom Options > Localized Policy > Lists > Data Prefix

In the CLI, you configure lists under the policy lists command hierarchy on Cisco IOS XE SD-WAN devices.

Table 4.

List Type

Description

vManage Configuration/ CLI Configuration Command

Data prefixes

List of one or more IP prefixes. You can specify both unicast and multicast addresses. To configure multiple prefixes in a single list, include multiple ip-prefix options, specifying one prefix in each option.

Configuration > Policies > Localized Policy > Add Policy > Create Groups of Interest > Data Prefix > New Data Prefix List

Configuration > Policies > Custom Options > Localized Policy > Lists > Data Prefix > New Data Prefix List

data-prefix-list list-name ip-prefix prefix/length

QoS Parameters

In Cisco vManage NMS, you configure QoS parameters:

  • Configuration > Policies > Localized Policy > Add Policy > Create Groups of Interest > Class Map, or Configuration > Policies > Custom Options > Localized Policy > Lists > Class Map

  • Configuration > Policies > Localized Policy > Add Policy > Configuring Forwarding Classes/QoS, or Configuration > Policies > Custom Options > Localized Policy > Configuring Forwarding Classes/QoS

  • Configuration > Policies > Localized Policy > Add Policy > Policy Overview, or Configuration > Policies > Custom Options > Localized Policy > Policy Overview

This section explains how to configure QoS parameters from the CLI.

To configure QoS parameters on a device, first define a classification. In Cisco vManage NMS: 

Device(config)# policy class-map class class-name queue number

class-name is the name of the class. It can be a text string from 1 through 32 characters long.

For hardware, each interface has eight queues, numbered from 0 through 7. Queue 0 is reserved for low-latency queuing (LLQ), so any class that is mapped to queue 0 must be configured to use LLQ. The default scheduling method for all is weighted round-robin (WRR).

For Cisco IOS XE SD-WAN devices, each interface has eight queues, numbered from 0 through 7. Queue 0 is reserved for control traffic, and queues 1, 2, 3, 4, 5, 6 and 7 are available for data traffic. The scheduling method for all eight queues is WRR. LLQ is not supported.

To configure QoS parameters on a Cisco IOS XE SD-WAN device, you must enable QoS scheduling and shaping. To enable QoS parameters for traffic that the Cisco IOS XE SD-WAN device receives from transport-side interfaces: 

Device(config)# policy cloud-qos

To enable QoS parameters for traffic that the Cisco IOS XE SD-WAN device receives from service-side interfaces: 

Device(config)# policy cloud-qos-service-side

Next, configure scheduling:

Device(config)# policy qos-scheduler scheduler-name
Device(config-qos-scheduler)# class percentage
Device(config-qos-scheduler)# buffer-percent percentage
Device(config-qos-scheduler)# drops (red-drop | tail-drop)
Device(config-qos-scheduler)# scheduling (llq | wrr)

scheduler-name is the name of the QoS scheduler. It can be a text string from 1 through 32 characters long.

class-name is the name of the forwarding class and can be a text string from 1 through 32 characters long. The common class names correspond to the per-hop behaviors AF (assured forwarding), BE (best effort), and EF (expedited forwarding).

The bandwidth percentage is the percentage of the interface's bandwidth to allocate to the forwarding class. The sum of the bandwidth on all forwarding classes on an interface should not exceed 100 percent.

The buffer percentage is the percentage of the interface's buffering capacity to allocate to the forwarding class. The sum of the buffering capacity of all forwarding classes on an interface should not exceed 100 percent.

Packets that exceed the bandwidth or buffer percentage are dropped either randomly, using random early detection (red-drop), or from the end of the queue (tail-drop). Low-latency queuing (LLQ) cannot use random early detection.

The algorithm to schedule interface queues can be either low-latency queuing (llq) or weighted round-robin (wrr).

Then, assign the scheduler to a QoS map:

Device(config-policy)# qos-map map-name qos-scheduler scheduler-name

map-name is the name of the QoS map, and scheduler-name is the name of the scheduler you configured above. Each name can be a text string from 1 through 32 characters long.

Finally, to configure a rewrite rule to overwrite the DSCP field of a packet's outer IP header:

Device(config)# policy rewrite-rule rule-name class class-name loss-priority
dscp dscp-value layer-2-cos number

rule-name is the name of the rewrite rule. It can be a text string from 1 through 32 characters long.

class-name is the name of a class you configured with the qos-scheduler class command. The packet loss priority (PLP) can be either high or low. To have a DSCP value overwrite the DSCP field of the packet's outer IP header, set a value from 0 through 63. To include an 802.1p marking in the packet, specify a number from 0 through 7.

Policer Parameters

To configure policing parameters, create a policer that specifies the maximum bandwidth and burst rate for traffic on an interface, and how to handle traffic that exceeds these values.

In Cisco vManage NMS, you configure policer parameters from:

  • Configuration > Policies > Centralized Policy > Add Policy > Create Groups of Interest > Policer

  • Configuration > Policies > Custom Options > Centralized Policy > Lists > Policer

In the CLI, you configure policer parameters as follows:

vSmart(config)# policy policer policer-name
vSmart(config-policer)# rate bps
vSmart(config-policer)# burst bytes
vSmart(config-policer)# exceed action

rate is the maximum traffic rate. It can be a value from 0 through 264 – 1 bits per second.

burst is the maximum traffic burst size. It can be a value from 15000 to 1000000 bytes.

exceed is the action to take when the burst size or traffic rate is exceeded. action can be drop (the default) or remark. The drop action is equivalent to setting the packet loss priority (PLP) bit to low. The remark action sets the PLP bit to high. In centralized data policy, access lists, and application-aware routing policy, you can match the PLP with the match plp option.

Sequences

An access list contains sequences of match–action pairs. The sequences are numbered to set the order in which a packet is analyzed by the match–action pairs in the access lists.

In Cisco vManage NMS, you configure sequences from:

  • Configuration > Policies > Localized Policy > Add Policy > Configure Access Control Lists > Add Access Control List Policy > Add ACL Sequence

  • Configuration > Policies > Custom Options > Localized Policy > Access Control List Policy > Add Access Control List Policy > Add ACL Sequence

In the CLI, you configure sequences with the policy access-list sequence command.

Each sequence in an access list can contain one match condition and one action condition.

Match Parameters

Access lists can match IP prefixes and fields in the IP headers.

In the Cisco vManage NMS, you configure match parameters from:

  • Configuration > Policies > Localized Policy > Add Policy > Configure Access Control Lists > Add Access Control List Policy > Add ACL Sequence > Add Sequence Rule > Match

  • Configuration > Policies > Custom Options > Localized Policy > Access Control List Policy > Add Access Control List Policy > Add ACL Sequence > Add Sequence Rule > Match

In the CLI, you configure the match parameters with the policy access-list sequence match command.

Each sequence in an access-list must contain one match condition.

For access lists, you can match these parameters:

Table 5.

Description

vManage Configuration/ CLI Configuration Command

Value or Range

Classification map

Match Class

class class-name

Name of a class defined with a policy class-map command.

Group of destination prefixes

Match Destination Data Prefix

destination-data-prefix-list list-name

Name of a data-prefix-list list.

Individual destination prefix

Not available in vManage NMS

destination-ip prefix/length

IP prefix and prefix length

Destination port number .

Match Destination Port

destination-port number

0 through 65535; specify a single port number, a list of port numbers (with numbers separated by a space), or a range of port numbers (with the two numbers separated with a hyphen [-])

DSCP value

Match DSCP

dscp number

0 through 63

Internet Protocol number

Match Protocol

protocol number

0 through 255

Packet length

Match Packet Length

packet-length number

Length of the packet. number can be from 0 through 65535. Specify a single length, a list of lengths (with numbers separated by a space), or a range of lengths (with the two numbers separated with a hyphen [-])

Group of source prefixes

Match Source Data Prefix

source-data-prefix-list list-name

Name of a data-prefix-list list.

Packet loss priority (PLP)

Match PLP

plp

(high | low) By default, packets have a PLP value of low. To set the PLP value to high, apply a policer that includes the exceed remark option.

Individual source prefix

Match Source Data Prefix

source-ip prefix/length

IP prefix and prefix length

Source port number .

Match Source Port

source-port address

0 through 65535; specify a single port number, a list of port numbers (with numbers separated by a space), or a range of port numbers (with the two numbers separated with a hyphen [-])

TCP flag

Match TCP

tcp flag

syn

Action Parameters

When a packet matches the conditions in the match portion of an access list, the packet can be accepted or dropped, and it can be counted. Then, you can classify, mirror, or police accepted packets.

In the Cisco vManage NMS, you configure match parameters from:

  • Configuration > Policies > Localized Policy > Add Policy > Configure Access Control Lists > Add Access Control List Policy > Add ACL Sequence > Add Sequence Rule > Action

  • Configuration > Policies > Custom Options > Localized Policy > Access Control List Policy > Add Access Control List Policy > Add ACL Sequence > Add Sequence Rule > Action

In the CLI, you configure the actions parameters with the policy access-list sequence action command.

Each sequence in an access list can contain one action condition.

In the action, you first specify whether to accept or drop a matching data packet, and whether to count it:

Table 6.

Description

vManage Configuration/ CLI Configuration Parameter

Value or Range

Accept the packet. An accepted packet is eligible to be modified by the additional parameters configured in the action portion of the access list.

Click Accept

accept

—

Count the accepted or dropped packets.

Action Counter

Click Accept, then action Counter

count counter-name

Name of a counter. To display counter information, use the show policy access-lists counters command on the Cisco IOS XE SD-WAN device.

Discard the packet. This is the default action.

Click Drop

drop

—

For a packet that is accepted, the following actions can be configured:

Table 7.

Description

vManage Configuration/ CLI Configuration Parameter

Value or Range

Classify the packet.

Click Accept, then Class

class class-name

Name of a QoS class defined with a policy class-map command.

Mirror the packet.

Click Accept, then Mirror List

mirror mirror-name

Name of mirror defined with a policy mirror command.

Police the packet.

Click Accept, then Policer

policer policer-name

Name of a policer defined with a policy policer command.

Packet's DSCP value.

Click Accept, then DSCP

set dscp value

0 through 63.

Next-hop address.

Click Accept, then Next Hop

set next-hop ipv4-address

IPv4 address.
Default Action

If a packet being evaluated does not match any of the match conditions in a access list, a default action is applied to this packet. By default, the packet is dropped.

In the Cisco vManage NMS, you modify the default action from:

  • Configuration > Policies > Localized Policy > Add Policy > Configure Access Control Lists > Default Action

  • Configuration > Policies > Custom Options > Localized Policy > Access Control List Policy > Default Action

In the CLI, you modify this behavior with the access-list default-action accept command.

Apply Access Lists

For an access list to take effect, you must apply it to an interface.

In the Cisco vManage NMS, you apply the access list in one of these interface feature configuration templates:

  • Configuration > Templates > VPN Interface Bridge

  • Configuration > Templates > VPN Interface Cellular

  • Configuration > Templates > VPN Interface Ethernet

  • Configuration > Templates > VPN Interface GRE

  • Configuration > Templates > VPN Interface PPP

  • Configuration > Templates > VPN Interface PPP Ethernet

In the CLI, you apply the access list as follows:

Device(config)# vpn vpn-id interface interface-name
Device(config-interface)# access-list list-name (in|out)

Applying the policy in the inbound direction (in) affects prefixes being received on the interface. Applying it in the outbound direction (out) affects prefixes being transmitted on the interface.

For an access list that applies QoS classification, apply any DSCP rewrite rules to the same interface to which you apply the access list: 

Device(config)# vpn vpn-id interface interface-name rewrite-rule rule-name

Note that you can also apply a policer directly to an interface, which has the effect of policing all packets transiting the interface, rather than policing only the selected packets that match the access list. You can apply the policer to either inbound or outbound packets: 

Device(config)# vpn vpn-id interface interface-name
Device(config-interface)# policer
policer-name (in|out) interface-name
Explicit and Implicit Access Lists

Access lists that you configure through localized data policy using the policy access-list command are called explicit ACLs. You can apply explicit ACLs to any interface in any VPN on the device.

The device's tunnel interfaces in VPN 0 also have implicit ACLs, which are also referred to as services. Some services are enabled by default on the tunnel interface, and are in effect unless you disable them. Through configuration, you can also enable other services. You configure and modify implicit ACLs with the allow-service command: 

Device(config)# vpn 0
Device(config-vpn)# interface interface-name
Device(config-interface)# tunnel-interface
Device(config-tunnel-interface)# allow-service service-name
Device(config-tunnel-interface)# no allow-service service-name

On Cisco IOS XE SD-WAN devices, the following services are enabled by default: DHCP (for DHCPv4 and DHCPv6), DNS, and ICMP. These three services allow the tunnel interface to accept DHCP, DNS, and ICMP packets. You can also enable services for BGP, Netconf, NTP, OSPF, SSHD, and STUN.


Note

If a connection is initiated from a device, and if NAT is enabled on the device (for example, Direct Internet Access (DIA) is configured), return traffic is allowed by the NAT entry even if the implicit ACL has been configured as no allow-service. You can still block this traffic with an explicit ACL.

Do not confuse an explicit ACL with an IOS XE ACL. An IOS XE ACL does not interact with a Cisco SD-WAN explicit and an implicit ACL and cannot override an implicit ACL or explicit ACL. IOS XE ACLs are executed later in the order of traffic processing operations.

When data traffic matches both an explicit ACL and an implicit ACL, how the packets are handled depends on the ACL configuration. Specifically, it depends on:

  • Whether the implicit ACL is configured as allow (allow-service allow-service) or deny (no allow-service service-name). Allowing a service in an implicit ACL is the same as specifying the accept action in an explicit ACL, and a service that is not allowed in an implicit ACL is the same as specifying the drop action in an explicit ACL

  • Whether, in an explicit ACL, the accept or deny action is configured in a policy sequence or in the default action.

The following table explains how traffic matching both an implicit and an explicit ACL is handled:

Table 8.

Implicit ACL

Explicit ACL: Sequence

Explicit ACL: Default

Result

Allow (accept)

Deny (drop)

—

Deny (drop)

Allow (accept)

—

Deny (drop)

Allow (accept)

Deny (drop)

Allow (accept)

—

Allow (accept)

Deny (drop)

—

Allow (accept)

Deny (drop)

Configure Localized Data Policy for IPv4 Using the CLI for Cisco IOS XE SD-WAN Devices

Following are the high-level steps for configuring an access list using the CLI on Cisco IOS XE SD-WAN devices:

  1. Create lists of IP prefixes, as needed:
    Device(config)# policy lists data-prefix-list ipv4_prefix_list
Device(config-data-prefix-list-ipv4_prefix_list)
# ip-prefix 192.168.0.3/24
  2. For QoS, configure the class-map ios:
    Device(config)# class-map match-any class1
Device(config)#  match qos-group 1
class-map match-any class6
match qos-group 6
class-map match-any class7
match qos-group 7
class-map match-any class4
match qos-group 4
class-map match-any class5
match qos-group 5
class-map match-any class2
match qos-group 2
class-map match-any class3
match qos-group 3
class-map match-any class1
match qos-group 1
end

    Note

    queue2 is optional here since we are using class-default.

  3. For QoS, define rewrite rules to overwrite the DSCP field of a packet's outer IP header, if desired:
    Device(config)# policy rewrite-rule rule1
Device(config-rewrite-rule-rule1)# class class1 low dscp 3
Device(config-rewrite-rule-rule1)# class class2 high dscp 4
Will be a table to map class-id → QoS-Group, QID, DSCP, Discard-Class
  4. For QoS, map each forwarding class to an output queue, configure a QoS scheduler for each forwarding class, and group the QoS schedulers into a QoS map:
    Device(config)# policy class-map class class1 queue 1
<0..7>[1]

  5. For Qos map configuration, merge with interface shaping configuration, if shaping is configured.

    If shaping is not configured, you can apply the policy-map generated for the qos-map. 

    Device(config)# policy-map qos_map_for_data_policy
<name:string
Device(config-pmap)# class class1<name:string>
Device(config-pmap-c)# bandwidth<percentage>
Device(config-pmap-c)# random-detect

  6. Configure a WAN interface without a shaping configuration:

    Device(config)# policy-map qos_map_for_data_policy <name:string
Device(config-pmap)# class class1<name:string>
Device(config-pmap-c)# bandwidth<percentage>
Device(config-pmap-c)# random-detect

  7. Configure a WAN interface with a shaping configuration:

    Device(config)# policy-map shaping_interface
Device(config-pmap)# class class-default
Device(config-pmap-c)# shape average 100000000(rate-in-bps)
Device(config-pmap-c)# service-policy qos_map_for_data_policy

  8. Associate a service-policy to a Cisco IOS XE SD-WAN device: 

    Device(config)# sdwan interface GigabitEthernet 1
Device(config-if)# rewrite-rule rule1 
Device(config-if)# service-policy output qos_map_for_data_policy

  9. Define policing parameters:​

    Device(config)# policy policer policer_On_gige
Device(config-policer-policer_On_gige)# rate ?
Description: Bandwidth for 1g interfaces: <8..1000000000>bps; for 10g interfaces: 
<8..10000000000>bps
Possible completions:<0..2^64-1>
Device(config-policer-policer_On_gige)# burst
Description: Burst rate, in bytes
Possible completions:<15000..10000000>
Device(config-policer-policer_On_gige)# exceed drop

  10. Associate an access list set to policer:

    Device(config)# policy access-list ipv4_acl
Device(config-access-list-ipv4_acl)# sequence 100
Device(config-sequence-100)# match dscp 10
Device(config-match)# exit
Device(config-sequence-100)# action accept
Device(config-sequence-100)# action count dscp_10_count
Device(config-sequence-100)# policer policer_On_gige
Device(config-sequence-100)# action drop
vm5(config-action)#

  11. Associate an access list to a LAN or a WAN interface:

    Device(config)# sdwan interface GigabitEthernet5
Device(config-interface-GigabitEthernet5)# access-list ipv4_acl
Device(config-interface-GigabitEthernet5)# commit

Localized Data Policy for IPv6

This topic provides procedures for configuring IPv6 localized data policy This type of data policy is called access lists, or ACLs. You can provision simple access lists that filter traffic based on IP header fields. You also use access lists to apply policing to data packets.

For IPv6, you can apply access lists only to interfaces in the transport VPN, VPN 0.

In Cisco vManage NMS, you configure localized data policy from the Configuration > Policies screen, using a policy configuration wizard. In the CLI you configure these policies on the Cisco IOS XE SD-WAN device.

Configuration Components

An access list consists of a sequences of match–action pairs that are evaluated in order, from lowest sequence number to highest sequence number. When a packet matches one of the match conditions, the associated action is taken and policy evaluation on that packets stops. Keep this in mind as you design your policies to ensure that the desired actions are taken on the items subject to policy.

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

The following figure illustrates the configuration components for IPv6 access lists:

Configure Localized Data Policy for IPv6 Using vManage

To configure IPv6 localized data policy, use the Cisco vManage policy configuration wizard. The wizard is a UI policy builder that consists of five screens, and you use four of them to configure IPv6 localized policy components:

  • Groups of Interest, also called lists—Create data prefix lists and policer parameters that group together related items and that you call in the match or action components of a policy.

  • Access Control Lists—Define the match and action conditions of ACLs.

  • Route Policies—Define the match and action conditions of route policies.

  • Policy Settings—Define additional policy settings.

You configure some or all these components depending on the specific policy you are creating. To skip a component, click the Next button at the bottom of the screen. To return to a component, click the Back button at the bottom of the screen.

Step 1: Start the Policy Configuration Wizard

To start the policy configuration wizard:

  1. In Cisco vManage NMS, select the Configure > Policies screen. When you first open this screen, the Centralized Policy tab is selected by default.

  2. Select the Localized Policy tab.

  3. Click Add Policy. The policy configuration wizard opens, and the Create Groups of Interest screen is displayed.

Step 2: Create Groups of Interest

In the Create Groups of interest screen create lists to use in the localized data policy:

  1. Create news lists of groups, as described in the following table:

    List Type

    Procedure
    AS Path

    Permit or deny prefixes from certain autonomous systems.

    1. In the left bar, click AS Path.

    2. Enter a name for the list.

      For Cisco IOS XE SD-WAN devices: Enter a number from 1 to 500.

    3. Set the preference value for the list in the Add AS Path field.

    Community

    1. In the left bar, click Community.

    2. Click New Community List.

    3. Enter a name for the list.

    4. In the Add Community field, enter one or more data prefixes separated by commas.

    5. Click Add.

    Data Prefix

    1. In the left bar, click Data Prefix.

    2. Click New Data Prefix List.

    3. Enter a name for the list.

    4. In the Internet Protocol field, click IPv4 or IPv6.

    5. In the Add Data prefix field, enter one or more data prefixes separated by commas.

    6. Click Add.

    Extended Community

    1. In the left bar, click Extended Community.

    2. Click New Extended Community List.

    3. Enter a name for the list.

    4. In the Add Extended Community field, enter one or more data prefixes separated by commas.

    5. Click Add.

    Class Map

    Map a class name to an interface queue number.

    1. In the left bar, click Class Map.

    2. Click New Class List. The Class List popup displays.

    3. Enter a name for the list. The class name can be a text string from 1 to 32 characters long.

    4. Select a queue number between 0 and 7 from the Queue drop-down menu.

    5. Click Save.

    Mirror

    Define the remote destination for mirrored packets, and define the source of the packets.

    1. In the left bar, click Mirror.

    2. Click New Mirror List.

    3. Enter a name for the list.

    4. Enter the Remote Destination IP address in the left field, where the mirrored traffic should be routed.

    5. Enter the Source IP address of the mirrored traffic in the right field.

    6. Click Add.

    Policer

    1. In the left bar, click Policer.

    2. Click New Policer List.

    3. Enter a name for the list.

    4. Define the policing parameters:

      1. In the Burst field, enter the maximum traffic burst size, a value from 15,000 to 10,000,000 bytes.

      2. In the Exceed field, select the action to take when the burst size or traffic rate is exceeded. It can be drop, which sets the packet loss priority (PLP) to low, or remark, which sets the PLP to high.

      3. In the Rate field, enter the maximum traffic rate, a value from 0 through 264 – 1 bits per second (bps).

    5. Click Add.

    Prefix

    1. In the left bar, click Prefix.

    2. Click New Prefix List.

    3. Enter a name for the list.

    4. Click either IPv4 or IPv6.

    5. Under Add Prefix, enter the prefix for the list. (An example is displayed.) Optionally, click the green Import link on the right-hand side to import a prefix list.

    6. Click Add.

  2. Click Next to move to Configure Forwarding Classes/QoS in the wizard. For IPv6 localized data policy, you cannot configure QoS.

  3. Click Next to move to Configure Access Lists in the wizard.

Step 3: Configure ACLs

  1. In the Configure Access Control Lists screen, click Add Access Control List Policy, and choose Add IPv6 ACL Policy from the drop-down.

  2. Enter a name and description for the ACL.

  3. From the left column, click Add ACL Sequence.

  4. Click Sequence Rule to open the ACL match/action sequence menu.

  5. Click a match condition. See Match Parameters for a full description of these options.

  6. On the left side, enter the values for the match condition.

  7. On the right side, enter the action or actions to take if the policy matches. See Action Parameters for a full description of these options.

  8. Repeat Steps 3 through 7 to add match–action pairs to the ACL.

  9. To rearrange match–action pairs in the ACL, drag them to the desired position in the right pane.

  10. To remove a match–action pair from the ACL, click the X in the upper right of the condition.

  11. Click Save Match and Actions to save a sequence rule.

  12. To copy, delete, or rename an ACL sequence rule, in the left pane, click the More Options menu (three dots) next to the rule's name and select the desired option.

  13. If no packets match any of the ACL sequence rules, the default action is to drop the packets. To change the default action:

    1. Click Default Action in the left pane.

    2. Click the Pencil icon.

    3. Change the default action to Accept.

    4. Click Save Match and Actions.

  14. Click Next to move to Configure Route Policy in the wizard.

  15. Click Next to move to the Policy Overview screen.

Step 4: Configure Policy Settings

In Policy Overview, configure policy settings:

  1. Enter a name and description for the ACL.

  2. Under Policy Settings, select one of the following policy options:

    Policy Settings Options

    Description

    Netflow

    Application

    Cloud QoS

    Cloud QoS Service side

    Implicit ACL Logging

    Log the headers of all packets that are dropped because they do not match a service configured by an Allow Service parameter on a tunnel interface.

  3. Click Preview to view the full policy in CLI format.

  4. Click Save Policy.

Step 5: Apply a Localized Data Policy in a Device Template

  1. In Cisco vManage NMS, select the Configuration > Templates screen.

  2. If you are creating a new device template:

    1. In the Device tab, click Create Template.

    2. From the Create Template drop-down, select From Feature Template.

    3. From the Device Model drop-down, select a Cisco IOS XE SD-WAN device.

    4. In the Template Name field, enter a name for the device template. This field is mandatory and can contain only uppercase and lowercase letters, the digits 0 through 9, hyphens (–), and underscores (_). It cannot contain spaces or any other characters.

    5. In the Description field, enter a description for the device template. This field is mandatory, and it can contain any characters and spaces.

    6. Continue with Step 4.

  3. If you are editing an existing device template:

    1. In the Device tab, click the More Actions icon to the right of the desired template, and click the pencil icon.

    2. Click the Additional Templates tab. The screen scrolls to the Additional Templates section.

    3. From the Policy drop-down, select the name of a policy that you have configured.

  4. Click the Additional Templates tab located directly beneath the Description field. The screen scrolls to the Additional Templates section.

  5. From the Policy drop-down, select the name of the policy you configured in the above procedure.

  6. Click Create (for a new template) or Update (for an existing template).

Structural Components of Configuration for Access Lists

Following are the structural components required to configure access lists. Each one is explained in more detail in the sections below. 


policy
   remote-dest ip-address source ip-address
   policer policer-name
      rate bandwidth
      burst bytes
      exceed action
policy ipv6
   access-list list-name
      sequence number
         match match-parameters
         action
            drop
            count counter-name
            log
            accept
               class class-name
               mirror mirror-name
               policer policer-name
     default-action (accept | drop)
vpn vpn-id
   interface interface-name
      ipv6 access-list list-name (in | out)
Policer Parameters

To configure policing parameters, create a policer that specifies the maximum bandwidth and burst rate for traffic on an interface, and how to handle traffic that exceeds these values.

In the Cisco vManage NMS, you configure policer parameters from:

  • Configuration > Policies > Localized Policy > Add Policy > Create Groups of Interest > Policer > New Policer List

  • Configuration > Policies > Custom Options > Localized Policy > Lists > Policer > New Policer List

In the CLI, you configure policer parameters as follows:

Device(config)# policy policer policer-name
Device(config-policer)# rate bps
Device(config-policer)# burst bytes
Device(config-policer)# exceed action

  • rate is the maximum traffic rate. It can be a value from 0 through 264 – 1 bits per second.

  • burst is the maximum traffic burst size. It can be a value from 15000 to 1000000 bytes.

  • exceed is the action to take when the burst size or traffic rate is exceeded. action can be drop (the default) or remark. The drop action is equivalent to setting the packet loss priority (PLP) bit to low. The remark action sets the PLP bit to high. In centralized data policy, access lists, and application-aware routing policy, you can match the PLP with the match plp option.

Sequences
Sequences

An access list contains sequences of match–action pairs. The sequences are numbered to set the order in which a packet is analyzed by the match–action pairs in the access lists.

In the Cisco vManage NMS, you configure sequences from:

  • Configuration > Policies > Localized Policy > Add Policy > Configure Access Control Lists > Add Access Control List Policy > Add ACL Sequence

  • Configuration > Policies > Custom Options > Localized Policy > Access Control List Policy > Add Access Control List Policy > Add ACL Sequence

In the CLI, you configure sequences with the policy ipv6 access-list sequence command.

Each sequence in an access list can contain one match condition and one action condition.

Match Parameters

Access lists can match IP prefixes and fields in the IP headers.

In the Cisco vManage NMS, you configure match parameters from:

  • Configuration > Policies > Localized Policy > Add Policy > Configure Access Control Lists > Add Access Control List Policy > Add ACL Sequence > Add Sequence Rule > Match

  • Configuration > Policies > Custom Options > Localized Policy > Access Control List Policy > Add Access Control List Policy > Add ACL Sequence > Add Sequence Rule > Match

In the CLI, you configure the match parameters with the policy ipv6 access-list sequence match command.

Each sequence in an access list must contain one match condition.

For access lists, you can match these parameters:

Description vManage Match Tab / CLI Command Value or Range
Enter a Destination port number.

Destination Port

destination-port number

0 through 65535; specify a single port number, a list of port numbers (with numbers separated by a space), or a range of port numbers (with the two numbers separated with a hyphen [-])
Select the Next Header protocol.

Protocol

next-header number

0 through 255, corresponding to an Internet Protocol number
Specify the packet length

Packet Length

packet-length number

Length of the packet. number can be from 0 through 65535. Specify a single length, a list of lengths (with numbers separated by a space), or a range of lengths (with the two numbers separated with a hyphen [-])
Specify the packet loss priority (PLP)

PLP

plp

(high | low)By default, packets have a PLP value of low. To set the PLP value to high, apply a policer that includes the exceed remark option.
Select a Source data prefix list
Enter a Source port number

Source Port

source-port address

0 through 65535; specify a single port number, a list of port numbers (with numbers separated by a space), or a range of port numbers (with the two numbers separated with a hyphen [-])
Enter a Destination Data Prefix
TCP

TCP

tcp flag

syn
Set the packet's DSCP value

Class

set class value

0 through 63
Traffic class

Traffic Class

traffic-class value

0 through 63
Action Parameters

When a packet matches the conditions in the match portion of an access list, the packet can be accepted or dropped, and it can be counted. Then, you can classify, mirror, or police accepted packets.

In Cisco vManage NMS, you configure match parameters from:

  • Configuration > Policies > Localized Policy > Add Policy > Configure Access Control Lists > Add Access Control List Policy > Add ACL Sequence > Add Sequence Rule > Action

  • Configuration > Policies > Custom Options > Localized Policy > Access Control List Policy > Add Access Control List Policy > Add ACL Sequence > Add Sequence Rule > Action

In the CLI, you configure the actions parameters with the policy ipv6 access-list sequence action command.

Each sequence in an access list can contain one action condition.

In the action, you first specify whether to accept or drop a matching data packet, and whether to count it:

For a packet that is accepted, the following actions can be configured:

Description vManage Action Tab / CLI Command Value or Range
Accept the packet. An accepted packet is eligible to be modified by the additional parameters configured in the action portion of the access list.

Click Accept.

accept

 —
Count the accepted or dropped packets.

Counter Name

count counter-name

 Name of a counter. To display counter information, use the show ipv6 policy access-lists counters command on the Cisco IOS XE SD-WAN device.
Designate the next hop router.

Next Hop

Traffic Class

set traffic-class value

 0-63
Mirror the packet.

Mirror List

mirror mirror-name

 Name of mirror defined with a policy mirrorcommand.
Set the packet's DSCP value.

Class

 0 through 63
Police the packet.

Policer

policer policer-name

 Name of a policer defined with a policy policer command.
Discard the packet. This is the default action.

Click Drop.

drop

 —
Default Action

If a packet being evaluated does not match any of the match conditions in a access list, a default action is applied to this packet. By default, the packet is dropped.

In the Cisco vManage NMS, you modify the default action from:

  • Configuration > Policies > Localized Policy > Add Policy > Configure Access Control Lists > Default Action

  • Configuration > Policies > Custom Options > Localized Policy > Access Control List Policy > Default Action

In the CLI, you modify this behavior with the access-list ipv6 default-action accept command.

Apply Access Lists

For an access list to take effect, you must apply it to a tunnel interface in VPN 0.

In the Cisco vManage NMS, you apply the access list in one of the interface feature configuration templates.

In the CLI, you apply the access list as follows:

vEdge(config)# vpn 0 interface  interface-name
vEdge(config-interface)# ipv6 access-list list-name (in | out)

Applying the policy in the inbound direction (in) affects prefixes being received on the interface. Applying it in the outbound direction (out) affects prefixes being transmitted on the interface.

Explicit and Implicit Access Lists

Access lists that you configure through localized data policy using the policy access-list command are called explicit ACLs. You can apply explicit ACLs to any interface in any VPN on the router.

The router's tunnel interfaces in VPN 0 also have implicit ACLs, which are also referred to as services. Some services are enabled by default on the tunnel interface, and are in effect unless you disable them. Through configuration, you can also enable other services. You configure and modify implicit ACLs with the allow-service command: 

Device(config)# vpn 0
Device(config-vpn)# interface interface-name
Device(config-interface)# tunnel-interface
Device(config-tunnel-interface)# allow-service service-name
Device(config-tunnel-interface)# no allow-service service-name

On Cisco IOS XE SD-WAN devices, the following services are enabled by default: DHCP (for DHCPv4 and DHCPv6), DNS, and ICMP. These three services allow the tunnel interface to accept DHCP, DNS, and ICMP packets. You can also enable services for BGP, Netconf, NTP, OSPF, SSHD, and STUN.


Note

If a connection is initiated from a device, and if NAT is enabled on the device (for example, Direct Internet Access (DIA) is configured), return traffic is allowed by the NAT entry even if the implicit ACL has been configured as no allow-service. You can still block this traffic with an explicit ACL.

Do not confuse an explicit ACL with an IOS XE ACL. An IOS XE ACL does not interact with a Cisco SD-WAN explicit and an implicit ACL and cannot override an implicit ACL or explicit ACL. IOS XE ACLs are executed later in the order of traffic processing operations.

When data traffic matches both an explicit ACL and an implicit ACL, how the packets are handled depends on the ACL configuration. Specifically, it depends on:

  • Whether the implicit ACL is configured as allow (allow-service allow-service) or deny (no allow-service service-name). Allowing a service in an implicit ACL is the same as specifying the accept action in an explicit ACL, and a service that is not allowed in an implicit ACL is the same as specifying the drop action in an explicit ACL.

  • Whether, in an explicit ACL, the accept or deny action is configured in a policy sequence or in the default action.

The following table explains how traffic matching both for an implicit and an explicit ACL is handled:

Implicit ACL

Explicit ACL: Sequence

Explicit ACL: Default

Result

Allow (accept)

Deny (drop)

—

Deny (drop)

Allow (accept)

—

Deny (drop)

Allow (accept)

Deny (drop)

Allow (accept)

—

Allow (accept)

Deny (drop)

—

Allow (accept)

Deny (drop)

Configure Localized Data Policy for IPv6 Using the CLI

Following are the high-level steps for configuring an access list using the CLI:

  1. Define policing parameters:​ 

    Device(config)# policy policer policer_On_gige
Device (config-policer-policer_On_gige)# rate ?
Description: Bandwidth for 1g interfaces: <8..1000000000>bps;for 10g interfaces: 
<8..10000000000>bps Possible completions: <0..2^64-1>
Device(config-policer-policer_On_gige)# burst
Description: Burst rate, in bytes Possible completions:<15000..10000000>
Device(config-policer-policer_On_gige)# exceed drop
  2. Create an access list instance:​
    Device (config)# policy ipv6 access-list ipv6_access_list
  3. Create a series of match–action pair sequences:
    Device(config-access-list-ipv6_access_list)# sequence 100
    The match–action pairs are evaluated in order, by sequence number, starting with the lowest numbered pair and ending when the route matches the conditions in one of the pairs. Or if no match occurs, the default action is taken (either rejecting the route or accepting it as is).
  4. Define match parameters for packets:
    Device(config-sequence-100)# match traffic-class 10
Device(config-match)# exit
  5. Define actions to take when a match occurs:
    Device(config-sequence-100)# action accept count traffic_class10_count
Device(config-sequence-100)# action drop
Device(config-sequence-100)# action accept class class1
Device(config-sequence-100)# action accept policer policer_On_gige

  6. Create additional numbered sequences of match–action pairs within the access list, as needed.

  7. If a packet does not match any of the conditions in one of the sequences, it is rejected by default. If you want nonmatching packets to be accepted, configure the default action for the access list:

  8. Apply the access list to an interface:
    Device(config)# sdwan interface GigabitEthernet5
Device(config-interface-GigabitEthernet5)
# ipv6 access-list ipv6_access_list in
Device(config-interface-GigabitEthernet5)
# commit
    Applying the access list in the inbound direction (in) affects packets being received on the interface. Applying it in the outbound direction (out) affects packets being transmitted on the interface.

Localized Data Policy Configuration Examples

This topic provides some straightforward examples of configuring localized data policy to help you get an idea of how to use policy to influence traffic flow across the Cisco SD-WAN domain. Localized data policy, also known as access lists, is configured directly on the local Cisco vEdge devices.

QoS

You can configure quality of service (QoS) to classify data packets and control how traffic flows out of and in to the interfaces on a Cisco vEdge device and on the interface queues. For examples of how to configure a QoS policy, see Forwarding and QoS Configuration Examples.