Cisco DNA Center User Guide, Release 1.3.1.0

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

Cisco DNA Center User Guide, Release 1.3.1.0

Chapter Title

Configure Policies

Results

Updated:
September 4, 2019

Chapter: Configure Policies

Configure Policies

Policy Overview

Cisco DNA Center enables you to create policies that reflect your organization's business intent for a particular aspect of the network, such as network access. Cisco DNA Center takes the information collected in a policy and translates it into network-specific and device-specific configurations required by the different types, makes, models, operating systems, roles, and resource constraints of your network devices.

Using Cisco DNA Center, you can create virtual networks, access control policies, traffic copy policies, and application policies.

Group-Based Access Control Policies

Cisco DNA Center implements Software-Defined Access in two ways:

  • Virtual Networks (VNs) provide macro-level segmentation. For example, to separate IoT devices from the corporate network.

  • Group-based policies provide micro-level segmentation. For example, to control what types of network traffic to permit or deny between engineering and HR groups.

The Group-based access control policy menu allows you to monitor and manage your scalable group access policies. These policies provide the following benefits:

  • Rich identity-based access control functionality with network automation and assurance benefits.

  • Granular access control.

  • Scalable groups apply to all virtual networks, which simplifies policy management.

  • Policy views help you to understand the overall policy structure, and create or update required access control policies.

  • Eliminates the need to switch between different applications to manage scalable groups and define protected assets.

  • Provides enhanced features for deploying enterprise-wide access control policies.

  • Restricts lateral movement of threats like ransom ware before you have identity or Network Admission Control (NAC) applications in place.

  • Provides an easy migration path to Cisco Identity Services Engine (Cisco ISE) for users who are using third-party identity applications, but want to move to Cisco ISE.

For information about creating IP pools, sites, and virtual networks in Cisco DNA Center, see the Cisco Digital Network Architecture Center User Guide.

For information about configuring Cisco DNA Center for Cisco ISE, see the Cisco Digital Network Architecture Center Installation Guide.

For information about configuring Cisco ISE for Cisco DNA Center, see the Cisco Identity Services Engine Administrator Guide.

First define the scalable groups and contracts, then create access control policies. The access control policies define which network traffic can pass from a source scalable group to a destination scalable group.

  • Scalable Group: A classification category, to which you can assign users, network devices, or resources. Scalable groups are used in access control policies. You can associate scalable groups with virtual networks based on your organization's network configuration, access requirements, and restrictions.

  • Contract: An access contract is a set of rules that controls the type of network traffic that is allowed to pass between the source and destination scalable groups. In other words, a contract is a traffic filter definition. Access contracts define the actions (permit or deny) performed when the traffic matches a network application, protocol, and port. The default action is to use the Catch All rule when no other rules match.

  • Group-Based Access Control Policies: A group-based access control policy identifies a specific source and destination group pair and associates an access contract. The access contract specifies what types of traffic are permitted or denied between the source group and the destination group. These policies are unidirectional.

    Scalable groups and access contracts are the basic building blocks of access control policy. While creating the access control policy, you can use the scalable groups and contracts that you have created before or create new scalable groups and contracts while creating the policy. If you want to specify the network resources that can be accessed from a specific source group, you can create an access control policy with a single source and multiple destination groups. On the other hand, if you want to specify the source groups that are permitted to access a particular network resource, you can create an access control policy with a single destination and multiple source groups. For example, if you want to specify the network resources that can be accessed by the users associated with the "contractors" source scalable group, you can create an access control policy with a single source and multiple destination groups. If you want to specify the source groups that are permitted to access the "Finance Servers" destination scalable group, you can create an access control policy with single destination and multiple source groups.

    You can specify the default policy to use when no contract is specified for a source and destination scalable group combination. The default policy is Permit. You can change this policy to Deny, Permit_IP_Log, or Deny_IP_Log, if necessary. You can set the default policy based on your network type, an open or closed network.


    Note

    We recommend that you change the default policy from "Permit" to "Deny" only if you have created explicit policies to permit necessary network traffic for all your network infrastructure devices. Failure to do so can result in loss of network connectivity.

List View

Click the List icon at the top right of the Group-Based Access Control window to launch the List view.

  • Source View: This view displays a list of existing policies organized based on the source groups. You can expand each row to view the specific source-destination policy details.

  • Destination View: This view displays a list of existing policies organized based on the destination groups. You can expand each row to view the specific source-destination policy details.

To see which destination groups are available from a specific source group, use the Source view. To see which source groups are permitted to access a particular destination group, use the Destination view. For example, to see which destination groups are available to users who are part of the "Contractors" source scalable group, use the Source view. To see which source groups can access the "Finance servers" destination scalable group, use the Destination view.

Click Deploy to deploy the updated policies to the network devices. When you click Deploy, Cisco DNA Center requests the Cisco Identity Services Engine (Cisco ISE) to send notifications about the policy changes to the network devices.

Matrix View

Click the Grid icon at the top right of the Group-Based Access Control window to launch the Matrix view. The Matrix view is a core policy view, which provides an overview of all policies for all scalable groups (whether explicit or default). You can use the Matrix view to view all source and destination policies and understand the overall policy structure. You can view, create, and update access control policies from the Matrix view.

The Matrix view contains two axes:

  • Source Axis: The vertical axis lists all the source scalable groups.

  • Destination Axis: The horizontal axis lists all the destination scalable groups.

Place the cursor on a cell to view the policy for a given source scalable group and a destination scalable group. The color of a cell is based on the policy that applies to that cell. The following colors indicate which policies are applied to each cell:

  • Permit: Green

  • Deny: Red

  • Custom: Gold

  • Default: Gray

Place the cursor on the Permit, Deny, Custom, or Default icon that is displayed at the top of the matrix to view the cells to which that policy is applied.

Click a cell to open the Create Policy or Edit Policy slide-in pane that allows you to create or edit the policies for the selected cell. The Create Policy slide-in pane shows the source and destination scalable groups as read-only fields. You can update the policy status and access contract.

You can use the Filter option to view a subset of the policy matrix, for a selected set of source and destination groups. You can create a filter to focus only on the policies that you are interested. To create the filter, select the source and destination groups that you want to include.

You can navigate through the matrix by dragging the matrix content area with the cursor or by using horizontal and vertical scroll bars. You can also use the mini-map to navigate through the matrix. The mini-map helps you to easily navigate through the matrix when the matrix size is large and it extends beyond the screen size. You can move and place the mini-map anywhere on your screen. The mini-map provides the whole matrix view. The light gray portion in the mini-map represents the portion of the matrix that is currently displayed on your screen. You can drag that area to scroll through the matrix.


Note

The mini-map is closed by default. Click the Expand icon to expand and view the mini-map.

The Matrix view highlights the cell and the corresponding row (source scalable group) and column (destination scalable group) when a cell is selected. The coordinates (source and destination scalable groups) of the selected cell are displayed near the matrix content area.

Click Deploy to deploy the updated policies on the network devices. When you click Deploy, Cisco DNA Center requests Cisco ISE to send notifications about the policy changes to the network devices.

Cisco DNA Center integrates with Cisco ISE. Cisco ISE provides the runtime policy platform for providing policy download to the network devices on behalf of Cisco DNA Center. The TrustSec Workcenter user interface screens for Security Groups, Security Group Access Control Lists (SGACLs), and Egress Policy are displayed in Read-Only mode in Cisco ISE to prevent policy synchronization issues.

Policy Creation Overview

  1. Define categorizations for your organization, or the portion of your organization that you plan to start with.

  2. Create scalable groups for the categorizations that you identified.

  3. Create access contracts for the types of network traffic you wish to control. There are predefined sample access contracts to Permit or Deny all traffic, and also some example contracts showing more specific traffic filtering. You can create additional, more granular access contracts based on specific application definitions.

  4. Decide which categories of network users require access to particular network resources, such as application servers and connections to other networks.

  5. Create access policies, associate a source group, a destination group, and an access contract, to define how traffic is allowed to flow from the source to the destination.

Create Scalable Groups

Before you begin

To perform the following task, you must be a Super Admin or Network Admin.

Procedure

Step 1

Choose Policy > Group-Based Access Control > Scalable Groups.

Step 2

Click Create Scalable Group.

The Create Scalable Group slide-in pane appears.
Step 3

In the Create Scalable Group slide-in pane, enter a name and description (optional) for the scalable group.

Note 

The following characters are supported for the Name field:

  • alphanumeric characters

  • underscore ( _ )

The scalable group name must start with an alphabetic character.

Cisco DNA Center generates the tag value. You can update this value, if necessary. An error message is displayed if the value that you specify is already used by an existing scalable group. The valid range is from 2 to 65519.

Step 4

Choose the Virtual Networks to be associated with this scalable group from the drop-down list. By default, the default virtual network (DEFAULT_VN) is selected.

Step 5

Check the Propagate to ACI check box if you want the scalable group to be propagated to Cisco Application Centric Infrastructure (ACI).

Step 6

Click Save.

The Scalable Groups window displays the scalable group name, tag value, assigned virtual networks, and associated policies. You can also view the sample scalable groups in this window. You can use or delete those scalable groups.

Click the link in the Policies column of a scalable group to view the access control rules that use that scalable group and the policy to which it belongs.

An orange triangle icon is displayed next to a scalable group if synchronization with Cisco ISE is not completed.

You can edit or delete the scalable groups from the Scalable Groups window. You cannot edit or delete the scalable groups that are learned from ACI. You cannot delete a scalable group if it is used in any access policy.

Cisco ISE supports packets coming from ACI to the TrustSec domain by synchronizing the Internal Endpoint Groups (IEPGs) and creating correlating read-only scalable groups in Cisco ISE. These scalable groups are displayed in the Scalable Groups window with the value ACI in the Learned From field. You cannot edit or delete the scalable groups that are learned from ACI, but you can use them in the policies.

When an IEPG is updated in ACI, the corresponding scalable group configuration is updated in Cisco ISE. A new EEPG is created in ACI, when a scalable group is created in Cisco ISE.

Click the Scalable Group Name link to view the details of a scalable group. Click Edit in the View Scalable Group window to update the scalable group details. When you click Deploy, Cisco DNA Center requests Cisco ISE to send notifications about the changes to the network devices. You can check the deployment status in the Deploy column.


Note

You cannot create a scalable group with the name "ANY" or tag value 0xFFFF/65535. Scalable Group ANY/65535 is a reserved internal scalable group that is used for the Cisco DNA Center default policy.

While synchronizing the scalable groups in Cisco DNA Centerwith Cisco ISE:

  • If a scalable group is present in Cisco DNA Center and is not present in Cisco ISE, it is created in Cisco ISE.

  • If a scalable group is present in Cisco ISE and is not present in Cisco DNA Center, it is created in Cisco DNA Center.

  • If the scalable group name is same in both Cisco DNA Center and Cisco ISE, but the description and ACI data are different, Cisco DNA Center is updated with the data specified in Cisco ISE.

  • If the scalable group name is same in Cisco DNA Center and Cisco ISE, but the tag values are different, a new scalable group with the tag value specified in Cisco ISE is created in Cisco DNA Center. The name of the existing scalable group in Cisco DNA Centeris updated with the suffix _DNAC.

  • If the tag value is same but the scalable group name is different, the scalable group name in Cisco DNA Center is updated with the name specified in Cisco ISE.

Create Access Contracts

An access contract is a set of rules that controls the type of network traffic that is allowed to pass between the source and destination scalable groups. Access contracts define the actions (permit or deny) performed when the traffic matches a network application, protocol, and port.


Note

Security Group Access Control List (SGACL) in Cisco ISE is called Access Contract in Cisco DNA Center.

Before you begin

To perform the following task, you must be a Super Admin or Network Admin.

Procedure

Step 1

Choose Policy > Group-Based Access Control > Access Contracts.

Step 2

Click Create Access Contract.

Step 3

In the Create Access Contract slide-in pane, enter a name and description for the contract.

Step 4

Create the traffic filter rules:

  • From the Action drop-down list, choose Deny or Permit.

  • From the Application drop-down list, choose the application for which you want to apply that action. The port and protocol are automatically selected based on the application that you select.

    If you want to specify the transport protocol, source port, and destination port, choose the Advanced option in the Application drop-down list.

You can create multiple rules. To create multiple rules to a contract, click the Plus symbol and choose the settings for the Action and Application columns. The rules are checked in the order in which they are listed in the contract. Use the handle icon at the left end of a rule to drag and change the order of the rule.

You can enable or disable logging for any traffic filter rule (including the default action) by using the Logging toggle. Logging is disabled by default. When logging is enabled, the network device sends a syslog message when the traffic filter rule is hit. This might be helpful in troubleshooting and initial testing of a policy. However, we recommend that you use this option sparingly because it might have resource and performance impact on the network devices.

Step 5

From the Default Action drop-down list, choose Deny or Permit.

You can enable logging for the default action, if required.
Step 6

Click Save.

You can view, create, duplicate, update, and delete contracts from the Access Contracts listing window.

You can also view the sample contracts in the Access Contracts window. You can use or delete those sample contracts. However, you cannot delete the default contracts (Permit IP, Deny IP, Permit_IP_Log, and Deny_IP_Log).

You can use the Filter option to search for the contracts that you look for.

An orange triangle icon is displayed next to a contract if synchronization with Cisco ISE is not completed.

Click the Contract Name link in the Access Contracts window to view the details of a contract. Click Edit in the View Contract window to edit the contract details.

You can view the number of rules used in each contract in the Rules Count column.

When you update the scalable groups, contracts, or policies, you must deploy the changes on the network devices. If you update the policies and do not deploy the updated policies, notifications about the policy changes are not sent to the network devices and the policies that are currently active in the network may not be consistent with the policy information displayed in Cisco DNA Center. To resolve this situation, you must deploy the updated policies on the network devices. The deployment status is displayed in the Deployed column.

Click the link in the Policies column of a contract to view the policies that use that contract.

You cannot delete a contract if it is used in a policy. You must delete the contract from that policy before you delete the contract.

You can duplicate an existing contract and create a new contract by editing the required details. When you duplicate a contract, all information in the existing contract is copied and the copied contract has the existing contract name with the string "Copy" appended at the end.

While synchronizing the access contracts in Cisco DNA Center with Cisco ISE:

  • If a contract is present in Cisco DNA Center and is not present in Cisco ISE, it is created in Cisco ISE.

  • If a contract is present in Cisco ISE and is not present in Cisco DNA Center, it is created in Cisco DNA Center.

  • If the contract name is same in Cisco DNA Center and Cisco ISE, but the description and traffic rule content are different, Cisco DNA Center is updated with the data specified in Cisco ISE.

  • If the contract name and rule are same, but the description is different, Cisco DNA Center is updated with the description specified in Cisco ISE.

  • Text SGACL command lines in Cisco ISE are migrated as non-parsable content. You can edit these contracts but no parsing or syntax checking is done in Cisco DNA Center. The changes that you make in Cisco DNA Center are reflected in Cisco ISE as well.

  • If a policy has multiple SGACLs in Cisco ISE, those contracts are migrated as default policies in Cisco DNA Center.

Create Group-Based Access Control Policy

Scalable groups and access contracts are the basic building blocks of access control policy. While creating the access control policy, you can use the scalable groups and contracts that you have created before or create new scalable groups and contracts while creating the policy. If you want to specify the network resources that can be accessed from a specific source group, you can create an access control policy with a single source and multiple destination groups. On the other hand, if you want to specify the source groups that are permitted to access a particular network resource, you can create an access control policy with a single destination and multiple source groups. For example, if you want to specify the network resources that can be accessed by the users associated with the "contractors" source scalable group, you can create an access control policy with a single source and multiple destination groups. If you want to specify the source groups that are permitted to access the "Finance Servers" destination scalable group, you can create an access control policy with single destination and multiple source groups.

To create a group-based access control policy:

Procedure

Step 1

From the Policy List or Matrix view, click Create Policies.

Step 2

Click Source to Destination(s) to create an access control policy with a single source and multiple destination groups.

  1. Click the radio button next to the source scalable group that you want to select. If the scalable group that you need does not exist, click Create Scalable Group to create a new scalable group. For more information, see Create Scalable Groups.

  2. Click Next.

  3. Choose the destination scalable groups to which the selected source scalable group must be mapped.

    You can view the scalable group details and edit the scalable groups, if necessary.

    An orange triangle icon is displayed near a scalable group, if a policy already exists between the source and destination.

  4. Click Next.

  5. Click the radio button next to the contract that you want to select. If the contract that you need does not exist, click Create Contract to create a new contract. For more information, see Create Access Contracts.

    You can view and edit the contract details, if necessary.

    Note 
    You can choose only one contract for a policy.

  6. Click Next.

    The Summary window lists the policies that are created based on the selected scalable groups and contract.

  7. Click Save.

Step 3

Click Destination to Source(s) to create an access control policy with a single destination and multiple source groups.

  1. Click the radio button next to the destination scalable group that you want to select. If the scalable group that you need does not exist, click Create Scalable Group to create a new scalable group. For more information, see Create Scalable Groups.

  2. Click Next.

  3. Choose the source scalable groups to which the selected destination scalable group must be mapped.

    You can view the scalable group details and edit the scalable groups, if necessary.

    An orange triangle icon is displayed near a scalable group, if a policy already exists between the source and destination.

  4. Click Next.

  5. Click the radio button next to the contract that you want to select. If the contract that you need does not exist, click Create Contract to create a new contract. For more information, see Create Access Contracts.

    You can view and edit the contract details, if necessary.

    Note 
    You can choose only one contract for a policy.

  6. Click Next.

    The Summary window lists the policies that are created based on the selected scalable groups and contract.

  7. Click Save.

    Note 

    You can toggle between the List view and the Drag and Drop view using the Toggle button displayed in the upper right corner of the Scalable Group listing area. The Drag and Drop view allows you to drag and drop the scalable groups to the Source and Destination fields while creating the access control policy. However, only the first 50 scalable groups are listed in the Drag and Drop view. You can use the Drag and Drop view if you have a smaller number of scalable groups (up to 50). You will need to use the List view if you have a larger number of scalable groups (more than 50) to view all the scalable groups.

While synchronizing the policies in Cisco DNA Center with Cisco ISE:

  • If a policy is present in Cisco DNA Center and is not present in Cisco ISE, it is created in Cisco ISE.

  • If a policy is present in Cisco ISE and is not present in Cisco DNA Center, it is created in Cisco DNA Center.

  • If a policy contract is different in Cisco ISE, Cisco DNA Center is updated with the contract specified in Cisco ISE.

  • Policy mode information (Enabled, Disabled, or Monitor) is also imported from Cisco ISE.

Cisco ISE has an option to allow multiple SGACLs for a single policy (this option is not enabled by default in ISE). Cisco DNA Center does not support the use of multiple access contracts for a single policy. During policy synchronization, if a policy in Cisco ISE has multiple SGACLs, the Cisco DNA Center administrator will be given the option to change that policy to have no contract selected (to use the default policy). The administrator can select a new or existing access contract for that policy after the policy synchronization is complete.

IP-Based Access Control Policies

An IP-based access control policy controls the traffic going into and coming out of a Cisco device in the same way that an Access Control List (ACL) does. As with an ACL, an IP-based access control policy contains lists of permit and deny conditions that are applied to traffic flows based on various criteria, including protocol type, source IP address, destination IP address, or destination port number.

IP-based access control policies can be used to filter traffic for various purposes, including security, monitoring, route selection, and network address translation.

An IP-based access control policy has two main components:

  • IP Network Groups: IP network groups comprise IP subnets that share the same access control requirements. These groups can be defined only in Cisco DNA Center. An IP network group may have as few as one IP subnet in it.

  • Access Contract: An access contract is a common building block that is used in both IP-based and group-based access control policies. It defines the rules that make up the access control policies. These rules specify the actions (permit or deny) performed when traffic matches a specific port or protocol and the implicit actions (permit or deny) performed when no other rules match.

Workflow to Configure an IP-Based Access Control Policy

Before you begin

  • To create IP network groups from the Policy > IP Based Access Control > IP Network Groups window, make sure that you have integrated Cisco ISE with Cisco DNA Center. However, Cisco ISE is not mandatory if you are adding groups within the Policy > IP Based Access Control > IP Network Groups window while creating a new IP-based access control policy.


    Note
    Editing an IP network group on the Policy > IP Based Access Control window is possible without Cisco ISE. But the creation of IP network groups from the IP Based Access Control window requires Cisco ISE.

  • Make sure that you have defined the following global network settings and provision the device:

Procedure

Step 1

Create IP network groups.

For more information, see Create an IP Network Group.

Step 2

Create an IP-based access control contract.

An IP-based access control contract defines a set of rules between the source and destination. These rules dictate the action (allow or deny) that network devices perform based on the traffic that matches the specified protocols or ports. For more information, see Create an IP-Based Access Control Contract.

Step 3

Create an IP-based access control policy. The access control policy defines the access control contract that governs traffic between the source and destination IP network groups.

For more information, see Create an IP-Based Access Control Policy.

Configure Global Network Servers

You can define global network servers that become the default for your entire network.


Note

You can override global network settings on a site by defining site-specific settings.

Procedure

Step 1

From the Cisco DNA Center home page, choose Design > Network Settings > Network.

Step 2

In the DHCP Server field, enter the IP address of a DHCP server.

Note 

You can click the plus icon and enter both IPv4 and IPv6 addresses.

You must define at least one DHCP server in order to create IP address pools.
Step 3

In the DNS Server field, enter the domain name of a DNS server.

Note 

You can click the plus icon and enter both IPv4 and IPv6 addresses.

You must define at least one DNS server in order to create IP address pools.
Step 4

(Optional) You can enter Syslog, SNMP Trap, and NetFlow Collector server information. Click Add Servers to add an NTP server.

Note 

To trigger the fabric compliance checks, configure the SNMP server with the IP address of Cisco DNA Center. For more information, see Add a Device to a Fabric.

Step 5

Click Save.

Create an IP Network Group

Procedure

Step 1

From the Cisco DNA Center home page, choose Policy > IP Based Access Control > IP Network Groups.

Step 2

Click Add Groups.

Step 3

In the Name field, enter a name for the IP network group.

Step 4

In the Description field, enter a word or phrase that describes the IP network group.

Step 5

In the IP Address or IP/CIDR field, enter the IP addresses that make up the IP network group.

Step 6

Click Save.

Edit or Delete an IP Network Group

Procedure

Step 1

From the Cisco DNA Center home page, choose Policy > IP Based Access Control > IP Network Groups.

Step 2

In the IP Network Groups table, check the check box next to the group that you want to edit or delete.

Step 3

Do one of the following tasks:

  • To make changes to the group, click Edit. For field definitions, see Create an IP Network Group.
  • To delete the group, click Delete and then click Yes to confirm.

Create an IP-Based Access Control Contract

Procedure

Step 1

From the Cisco DNA Center home page, choose Policy > IP Based Access Control > Access Contract.

Step 2

Click Add Contract.

Step 3

In the dialog box, enter a name and description for the contract.
Step 4

From the Implicit Action drop-down list, choose either Deny or Permit.

Step 5

From the Action drop-down list in the table, choose either Deny or Permit.

Step 6

From the Port/Protocol drop-down list, choose a port or protocol.

  1. If Cisco DNA Center does not have the port or protocol that you need, click Add Port/Protocol to create your own.

  2. In the Name field, enter a name for the port or protocol.

  3. From the Protocol drop-down list, choose UDP, TDP, or TCP/UDP as the protocol.

  4. In the Port Range field, enter the port range.

  5. If you want Cisco DNA Center to configure the port or protocol as defined, and not report any conflicts, check the Ignore Conflict check box.

Step 7

(Optional) To include more rules in your contract, click Add and repeat Step 5 and Step 6.

Step 8

Click Save.

Edit or Delete an IP-Based Access Control Contract

If you edit a contract that is used in a policy, the policy's state changes to MODIFIED in the IP Based Access Control Policies window. A modified policy is considered to be stale because it is inconsistent with the policy that is deployed in the network. To resolve this situation, you need to redeploy the policy to the network.

Procedure

Step 1

From the Cisco DNA Center home page, choose Policy > IP-Based Access Control > Access Contract.

Step 2

Check the check box next to the contract that you want to edit or delete and do one of the following tasks:

  • To make changes to the contract, click Edit, make the changes, and, click Save. For field definitions, see Create an IP-Based Access Control Contract.
    Note 

    If you make changes to a contract that is used in a policy, you need to deploy the modified policy by choosing Policy > IP-Based Access Control > IP-Based Access Control Policies, checking the check box next to the policy name, and clicking Deploy.

  • To delete the contract, click Delete.

Create an IP-Based Access Control Policy

Create an IP-based access control policy to limit traffic between IP network groups.

  • Multiple rules can be added to a single policy with different configurations.

  • For a given combination of IP groups and contract classifiers, rules are created and pushed to the devices. This count cannot exceed 64 rules as Cisco WLC limits an ACL to have a maximum of 64 rules.

  • If a custom contract or the IP group that is used in a Deployed policy is modified, the policy is flagged with status as Modified, indicating that it is Stale and requires a redeployment for the new configurations to be pushed to the device.

Procedure

Step 1

From the Cisco DNA Center home page, choose Policy > IP Based Access Control > IP Based Access Control Policies.

Step 2

Click Add Policy.

Step 3

Complete the following fields:

Field Description

Policy Name

Name of the policy.

Description

Word or phrase that identifies the policy.

SSID

Lists FlexConnect SSIDs and non-FlexConnect SSIDs that were created during the design of SSIDs. If the selected SSID is configured in a FlexConnect mode, then the access policy is configured in FlexConnect mode. Otherwise, it will be configured in a regular way.

Note 

If an SSID is part of one policy, that SSID will not be available for another policy.

A valid site-SSID combination is required for policy deployment. You will not be able to deploy a policy if the selected SSID is not provisioned under any devices.

Site Scope

Sites to which a policy is applied. If you configure a wired policy, the policy is applied to all wired devices in the site scope. Likewise, if you configure a wireless policy for a selected service set identifier (SSID), the policy is applied to all of the wireless devices with the SSID defined in the scope. For more information, see Site Scope.

Source

Origin of the traffic that is affected by the contract. From the SearchSource drop-down list, choose an IP network group. If the IP network that you want is not available, click +Group to create one.

Contract

Rules that govern the network interaction between the source and destination in an ACL. Click Add Contract to define the contract for the policy. In the dialog box, click the radio button next to the contract that you want to use. Alternatively, you can select the permit (permit all traffic) or deny (deny all traffic) contract.

Destination

Target of the traffic that is affected by the contract. Click the Destination drop-down list, choose an IP network group. If the IP network that you want is not available, click +Create IP Network Group to create one.

Direction

Configures the relationship of the traffic flow between the source and destination. To enable the contract for traffic flowing from the source to the destination, select One-Way. To enable the contract for traffic flowing in both directions (from the source to the destination and from the destination to the source), select Bi-directional.

Step 4

(Optional) To create an IP network group, click Create IP Network Group.

Step 5

(Optional) To add another rule, click the plus sign.

Note 

To delete a rule, click x.

Step 6

(Optional) To reorder the sequence of the rules, drag and drop a rule in the order you want.
Step 7

Click Deploy.

The success message IP-Based Access Control Policy has been created and deployed successfully is displayed. Depending on the SSID selected, either a FlexConnect policy or a standard policy is created with different levels of mapping information and deployed. The Status of the policy is shown as DEPLOYED. A wireless icon next to the Policy Name shows that the deployed access policy is a wireless policy.

Edit or Delete an IP-Based Access Control Policy

If you need to, you can change or delete an IP-based access control policy.


Note

If you edit a policy, the policy's state changes to MODIFIED on the IP Based Access Control Policies window. A modified policy is considered to be stale because it is inconsistent with the policy that was deployed in the network. To resolve this situation, you need to redeploy the policy to the network.

Procedure

Step 1

From the Cisco DNA Center home page, choose Policy > IP Based Access Control > IP Based Access Control Policies.

Step 2

Check the check box next to the policy that you want to edit or delete and do one of the following tasks:

Step 3

If you make changes to the policy, deploy the modified policy by checking the check box next to the policy name and clicking Deploy.

Deploy an IP-Based Access Control Policy

If you make changes that affect a policy's configuration, you need to redeploy the policy to implement these changes.

Procedure

Step 1

From the Cisco DNA Center home page, choose Policy > IP Based Access Control > IP Based Access Control Policies.

Step 2

Locate the policy that you want to deploy.
Step 3

Check the check box next to the policy.
Step 4

Click Deploy.

You are prompted to deploy your policy immediately or to schedule it for a later time.
Step 5

Do one of the following:

  • To deploy the policy immediately, click the Run Now radio button and click Apply.
  • To schedule the policy deployment for a later date and time, click the Schedule Later radio button and define the date and time of the deployment.
    Note 

    The site time zone setting is not supported for scheduling application policy deployments.

Application Policies

Quality of Service (QoS) refers to the ability of a network to provide preferential or deferential service to selected network traffic. By configuring QoS, you can ensure that network traffic is handled in such a way that makes the most efficient use of network resources while still adhering to the objectives of the business, such as guaranteeing that voice quality meets enterprise standards, or ensuring a high Quality of Experience (QoE) for video.

You can configure QoS in your network using application policies in Cisco DNA Center. Application policies comprise these basic parameters:

  • Application Sets—Sets of applications with similar network traffic needs. Each application set is assigned a business relevance group (business relevant, default, or business irrelevant) that defines the priority of its traffic. QoS parameters in each of the three groups are defined based on Cisco Validated Design (CVD). You can modify some of these parameters to more closely align with your objectives. For more information, see Applications and Application Sets.

  • Site Scope—Sites to which an application policy is applied. If you configure a wired policy, the policy is applied to all the wired devices in the site scope. Likewise, if you configure a wireless policy for a selected service set identifier (SSID), the policy is applied to all of the wireless devices with the SSID defined in the scope. For more information, see Site Scope.

Cisco DNA Center takes all of these parameters and translates them into the proper device CLI commands. When you deploy the policy, Cisco DNA Center configures these commands on the devices defined in the site scope.


Note

Cisco DNA Center configures QoS policies on devices based on the QoS feature set available on the device. For more information about a device’s QoS implementation, see the corresponding device's product documentation.

CVD-Based Settings in Application Policies

The default QoS trust and queuing settings in application policies are based on the Cisco Validated Design (CVD) for Enterprise Medianet Quality of Service Design. CVDs provide the foundation for systems design based on common use cases or current engineering system priorities. They incorporate a broad set of technologies, features, and applications to address customer needs. Each one has been comprehensively tested and documented by Cisco engineers to ensure faster, more reliable, and fully predictable deployment.

The latest validated designs relating to QoS are published in the Cisco Press book, End-to-End QoS Network Design: Quality of Service for Rich-Media & Cloud Networks, 2nd Edition, available at: http://www.ciscopress.com/store/end-to-end-qos-network-design-quality-of-service-for-9781587143694. For additional information, see the following Cisco documentation:

Site Scope

A site scope defines the sites to which an application policy is applied. When defining a policy, you configure whether a policy is for wired or wireless devices. You also configure a site scope. If you configure a wired policy, the policy is applied to all the wired devices in the site scope. Likewise, if you configure a wireless policy for a selected service set identifier (SSID), the policy is applied to all of the wireless devices in the site scope with the SSID defined in the scope.

This allows you to make tradeoffs as necessary to compensate for differences in the behaviors between wired and wireless network segments. For example, wireless networks typically have lower bandwidth, lower speed, and increased packet loss in comparison to wired networks. Individual wireless segments may exhibit further variation due to local conditions of RF interference, congestion, and other factors, such as the varying capabilities of network devices. The ability to apply per-segment policies to individual wireless segments enables the adjustment of traffic-handling rules to ensure that the highest-priority traffic is least affected by degradation of the wireless network.

Business-Relevance Groups

A business-relevance group classifies a given application set according to how relevant it is to your business and operations.

Business-relevance groups are Business Relevant, Default, and Business Irrelevant, and they essentially map to three types of traffic: high priority, neutral, and low priority.

  • Business Relevant: (High-priority traffic) The applications in this group directly contribute to organizational objectives, and as such, may include a variety of applications, including voice, video, streaming, and collaborative multimedia applications, database applications, enterprise resource applications, email, file transfers, content distribution, and so on. Applications designated as business relevant are treated according to industry best-practice recommendations, as prescribed in Internet Engineering Task Force (IETF) RFC 4594.

  • Default: (Neutral traffic) This group is intended for applications that may or may not be business relevant, for example, generic HTTP or HTTPS traffic may contribute to organizational objectives at times, while at other times, such traffic may not. You may not have insight into the purpose of some applications, for instance, legacy applications or even newly deployed applications. Therefore, the traffic flows for these applications should be treated with the Default Forwarding service, as described in IETF RFC 2747 and 4594.

  • Business Irrelevant: (Low-priority traffic) This group is intended for applications that have been identified as having no contribution towards achieving organizational objectives. They are primarily consumer-oriented or entertainment-oriented or both in nature. We recommend that this type of traffic be treated as a Scavenger service, as described in IETF RFCs 3662 and 4594.

Applications are grouped into application sets and sorted into business-relevance groups. You can include an application set in a policy as-is, or you can modify it to meet the needs of your business objectives and your network configuration.

For example, YouTube is member of the consumer-media application set, which is business-irrelevant (by default), because most customers typically classify this application this way. However, this classification may not be the true for all companies, for example, some businesses may be using YouTube for training purposes. In such cases, an administrator can move the YouTube application into the streaming-video application set, which is business relevant by default.

Consumers and Producers

You can configure relationships between applications such that when traffic from one application is sent to another application (thus creating a specific a-to-b traffic flow), the traffic is handled in a specific way. The applications in this relationship are called producers and consumers, and are defined as follows:

  • Producer: Sender of the application traffic. For example, in a client/server architecture, the application server is considered the producer because the traffic primarily flows in the server-to-client direction. In the case of a peer-to-peer application, the remote peer is considered the producer.

  • Consumer: Receiver of the application traffic. The consumer may be a client end point in a client/server architecture or it may be the local device in a peer-to-peer application. Consumers may be end-point devices, but may, at times, be specific users of such devices (typically identified by IP addresses or specific subnets). There may also be times when an application is the consumer of another application's traffic flows.

Setting up this relationship allows you to configure specific service levels for traffic matching this scenario.

Marking, Queuing, and Dropping Treatments

Cisco DNA Center bases its marking, queuing, and dropping treatments on IETF RFC 4594 and the business relevance category that you have assigned to the application. Cisco DNA Center assigns all of the applications in the Default category to the Default Forwarding application class and all of the applications in the Irrelevant Business category to the Scavenger application class. For applications in the Relevant Business category, Cisco DNA Center assigns traffic classes to applications based on the type of application. The following table lists the application classes and their treatments.

Table 1. Marking, Queuing, and Dropping Treatments
Business Relevance Application Class Per-Hop Behavior Queuing and Dropping Application Description

Relevant

VoIP1

Expedited Forwarding (EF)

Priority Queuing (PQ)

VoIP telephony (bearer-only) traffic; for example, Cisco IP phones.

Broadcast Video

Class Selector (CS) 5

PQ

Broadcast TV, live events, video surveillance flows, and similar inelastic streaming media flows; for example, Cisco IP Video Surveillance and Cisco Enterprise TV. (Inelastic flows refer to flows that are highly drop sensitive and have no retransmission or flow-control capabilities or both.)

Real-time Interactive

CS4

PQ

Inelastic high-definition interactive video applications and audio and video components of these applications; for example, Cisco TelePresence.

Multimedia Conferencing

Assured Forwarding (AF) 41

Bandwidth (BW) Queue and Differentiated Services Code Point (DSCP) Weighted Random Early Detect (WRED)

Desktop software multimedia collaboration applications and audio and video components of these applications; for example, Cisco Jabber and Cisco WebEx.

Multimedia Streaming

AF31

BW Queue and DSCP WRED

Video-on-Demand (VoD) streaming video flows and desktop virtualization applications,such as Cisco Digital Media System.

Network Control

CS6

BW Queue only2

Network control-plane traffic, which is required for reliable operation of the enterprise network, such as EIGRP, OSPF, BGP, HSRP, IKE, and so on.

Signaling

CS3

BW Queue and DSCP

Control-plane traffic for the IP voice and video telephony infrastructure.

Operations, Administration, and Management (OAM)

CS2

BW Queue and DSCP3

Network operations, administration, and management traffic, such as SSH, SNMP, syslog, and so on.

Transactional Data (Low-Latency Data)

AF21

BW Queue and DSCP WRED

Interactive (foreground) data applications, such as enterprise resource planning (ERP), customer relationship management (CRM), and other database applications.

Bulk Data (High-Throughput Data)

AF11

BW Queue and DSCP WRED

Noninteractive (background) data applications, such as email, file transfer protocol (FTP), and backup applications.

Default

Default Forwarding (Best Effort)

DF

Default Queue and RED

Default applications and applications assigned to the default business-relevant group. Because only a small number of applications are assigned to priority, guaranteed bandwidth, or even to differential service classes, the vast majority of applications continue to default to this best-effort service.

Irrelevant

Scavenger

CS1

Minimum BW Queue (Deferential) and DSCP

Non-business related traffic flows and applications assigned to the business-irrelevant group, such as data or media applications that are entertainment-oriented. Examples include YouTube, Netflix, iTunes, and Xbox Live.

1 VoIP signaling traffic is assigned to the Call Signaling class.
2 WRED is not be enabled on this class because network control traffic should not be dropped.
3 WRED is not enabled on this class because OAM traffic should not be dropped.

Service Provider Profiles

Service provider (SP) profiles define the class of service for a particular WAN provider. You can define 4-class, 5-class, 6-class, and 8-class models.

When application policies are deployed on the devices, each SP profile is assigned a certain service-level agreement (SLA) that maps each SP class to a DSCP value and a percentage of bandwidth allocation.

You can customize the DSCP values and the percentage of bandwidth allocation in a SP profile when configuring an application policy.

After you create the SP profile, you need to configure it on the WAN interfaces.

Table 2. Default SLA Attributes for SP Profiles with 4 Classes
Class Name DSCP Priority Class SLA
Bandwidth (%) Remaining Bandwidth (%)

Voice

EF

Yes

10

—

Class 1 Data

AF31

—

—

44

Class 2 Data

AF21

—

—

25

Default

0

—

—

31
Table 3. Default SLA Attributes for SP Profiles with 5 Classes
Class Name DSCP Priority Class SLA
Bandwidth (%) Remaining Bandwidth (%)

Voice

EF

Yes

10

—

Class 1 Data

AF31

—

—

44

Class 2 Data

AF21

—

—

25

Class 3 Data

AF11

—

—

1

Default

Best Effort

—

—

30
Table 4. Default SLA Attributes for SP Profiles with 6 Classes
Class Name DSCP Priority Class SLA
Bandwidth (%) Remaining Bandwidth (%)

Class 1 Data

AF31

—

—

10

Class 3 Data

AF11

—

—

1

Video

AF41

—

—

34

Voice

EF

Yes

10

—

Default

0

—

—

30

Class 2 Data

AF21

—

—

25
Table 5. Default SLA Attributes for SP Profiles with 8 Classes
Class Name DSCP Priority Class SLA
Bandwidth (%) Remaining Bandwidth (%)

Network-Control Management

CS6

—

—

5

Streaming Video

AF31

—

—

10

Call Signalling

CS3

—

—

4

Scavenger

CS1

—

—

1

Interactive Video

AF41

—

—

30

Voice

EF

Yes

10

—

Default

0

—

—

25

Critical Data

AF21

—

—

25

Queuing Profiles

Queuing profiles allow you to define an interface's bandwidth allocation based on the interface speed and the traffic class.


Note

Queuing profiles do not apply to WAN-facing interfaces that are connected to a service provider profile.

The following interface speeds are supported:

  • 100 Gbps

  • 10/40 Gbps

  • 1 Gbps

  • 100 Mbps

  • 10 Mbps

  • 1 Mbps

If the speed of an interface falls between two interface speeds, Cisco DNA Center treats the interface at the lower interface speed.


Note

Cisco DNA Center attempts to detect the operational speed of the interface in order to apply the correct policy. However, if a switch port is administratively down, Cisco DNA Center cannot detect the speed. In this case, Cisco DNA Center uses the interface's supported speed.

You define a queuing policy as part of an application policy. When you deploy the application policy, the devices in the sites that are selected in the site scope are configured with the assigned LAN queuing policy. If no LAN queuing policy is assigned, the application policy uses the default CVD queuing policy.

If you change the queuing policy in an application policy that has already been deployed, the policy becomes stale, and you need to redeploy the policy for the changes to be configured on the devices.

Note the following additional guidelines and limitations of queuing policies:

  • You cannot delete a LAN queuing profile if it is used in a policy.

  • If you update a queuing profile that is associated with a policy, the policy is marked as stale. You need to redeploy the policy to provision the latest changes.

  • Traffic class queuing customization does not affect interfaces on Cisco service provider switches and routers. You should continue to configure these interfaces without using Cisco DNA Center.

Table 6. Default CVD LAN Queuing Policy
Traffic Class Default Bandwidth (Total = 100%)4

Voice

10%

Broadcast Video

10%

Real-Time Interactive

13%

Multimedia Conferencing

10%

Multimedia Streaming

10%

Network control

3%

Signaling

2%

OAM

2%

Transactional Data

10%

Bulk Data

4%

Scavenger

1%

Best Effort

25%
4 We recommend that the total bandwidth for Voice, Broadcast Video, and Real-Time Interactive traffic classes equals no more than 33%.

Processing Order for Devices with Limited Resources

Some network devices have a limited memory (called TCAM) for storing network ACLs and access control entries (ACEs). So, because ACLs and ACEs for applications are configured on these devices, the available TCAM space is used. When the TCAM space is depleted, QoS settings for additional applications cannot be configured on that device.

To ensure that QoS policies for the most important applications get configured on these devices, Cisco DNA Center allocates TCAM space in the following order:

  1. Rank: Number assigned to custom and favorite applications, but not to existing, default NBAR applications. The lower the rank number, the higher the priority. For example, an application with rank 1 has a higher priority than an application with rank 2, and so on. Having no rank is the lowest priority.


    Note

    • Custom applications are assigned rank 1 by default.

    • If we mark the NBAR application as favorite, the rank is set to 1000.

  2. Traffic Class: Priority based on the following order: Signaling, Bulk Data, Network Control, Operations Administration Management (Ops Admin Mgmt), Transactional Data, Scavenger, Multimedia Streaming, Multimedia Conferencing, Real Time Interactive, Broadcast Video, and VoIP Telephony

  3. Popularity: Number (1–10) that is based on CVD criteria. The popularity number cannot be changed. An application with a popularity of 10 has a higher priority than an application with a popularity of 9, and so on.


    Note

    • Custom applications are assigned popularity 0.

    • Default NBAR applications are assigned a popularity number (1–10) that is based on CVD criteria. When you mark an application as a favorite, this does not change the popularity number; only the rank is changed.

  4. Alphabetization: If two or more applications have the same rank and popularity number, they are sorted alphabetically by the application’s name, and assigned a priority accordingly.

For example, let us assume that you define a policy that has the following applications:

  • Custom application, custom_realtime, which has been assigned rank 1 and popularity 10 by default.

  • Custom application, custom_salesforce, which has been assigned rank 1 and popularity 10 by default.

  • Application named corba-iiop, which is in the transactional data traffic class, and you have designated as a favorite, giving that application a ranking of 10,000 and popularity of 9 (based on CVD).

  • Application named gss-http, which is in the Ops Admin Mgmt traffic class, and you have designated as a favorite, giving that application a ranking of 10,000 and popularity of 10 (based on CVD).

  • All other, default NBAR applications, which have no rank, but will be processed according to their traffic class and default popularity (based on CVD).

According to the prioritization rules, the applications are configured on the device in this order:

Application Configuration Order Reason

1. Custom application, custom_realtime

Custom applications are given highest priority. Given that the custom_salesforce and custom_realtime applications have the same rank and popularity, they are sorted alphabetically, custom_realtime before custom_salesforce.

2. Custom application, custom_salesforce

3. Favorite application, gss-http

Because both of these applications have been designated as favorites, they have the same application ranking. So, Cisco DNA Center evaluates them according to their traffic class. Because gss-http is in the Ops Admin Mgmt traffic class, it is processed first, followed by the corba-iiop application, which is in the Trasactional Data traffic class. Their popularity does not come into play because the processing order has been determined by their traffic class.

4. Favorite application, corba-iiop

5. All other, default NBAR applications

 All other applications are next and are prioritized according to traffic class and then popularity, with the applications having the same popularity being alphabetized according to the application’s name.

Policy Drafts

When you create a policy, you can save it as a draft without having to deploy it. Saving it as a draft allows you open the policy later and make changes to it. You can also make changes to a deployed policy, and save it as a draft.


Note

After you save or deploy a policy, you cannot change its name.

Draft policies and deployed policies are related to one another, but they have their own versioning, as follows:

When you save a policy as a draft, Cisco DNA Center appends the policy name with (Draft), and increments the version number. When you deploy a policy, Cisco DNA Center increments the version number of the deployed policy.

For example, as shown in the figure below, you create a policy named testPolicy1 and save it as a draft. The policy is saved as testPolicy1 (Draft), version number 1. You make a change to the draft and save it again. The policy has the same name, testPolicy1 (Draft), but its version number is incremented to 2.

You decide you like the policy, and you deploy it to the network. The policy is deployed with the name testPolicy1 and its version number is 1. You make a change to the deployed policy and save it as a draft. The draft policy, testPolicy1 (Draft) is incremented to version number 3. When you ultimately deploy that version, testPolicy1 is incremented to version 2.

Figure 1. Deployed Policy and Draft Policy Versioning

Any time you modify and save either a draft policy or a deployed policy, the draft policy version number is incremented. Similarly, any time you deploy either a draft policy or a modified deployed policy, the deployed policy version is incremented.

Just as with deployed policies, you can display the history of draft policies and roll them back to previous versions.

For more information about viewing the history of policy versions and rolling back to a previous version, see Policy Versioning.

Policy Preview

Before you deploy a policy, you can generate the CLI that will be applied to a device.

The Preview operation generates the CLI commands for a policy, compares them with the CLI commands in the running configuration on the device, and returns only the remaining CLI commands that are required to configure the policy on the device.

After reviewing the preview output, you can deploy the policy to all of the devices in the scope, or you can continue to make changes to the policy.

Policy Precheck

When you create an application policy, you can verify if it will be supported on the devices in the site scope before you deploy it. The precheck function verifies if the device type, model, line cards, and software images support the application policy that you created. If any of these components are not supported, Cisco DNA Center reports a failure for the device. Cisco DNA Center also provides possible ways to correct the failures. If these remedies do not fix the failure, you can remove the device from the site scope.

If you deploy the application policy as-is, the policy will fail to deploy on the devices that reported a failure during the precheck process. To avoid the failure, you can remove the device from the site scope or update the device components to a level that the application policy supports. For a list of supported devices, see the Cisco DNA Center Supported Devices document.

Policy Scheduling

After you create or change a policy, you can deploy or redeploy the policy to the devices associated with it. You can deploy or redeploy a policy immediately or at a specific date and time, for example, on a weekend during off-peak hours. You can schedule a policy deployment for wired or wireless devices.

After you have scheduled a policy to be deployed, the policy and site scope are locked. You can view the policy, but you cannot edit it. If you change your mind about deploying the policy, you can cancel it.


Note

When the scheduled event occurs, the policy is validated against the various policy components, for example, applications, application sets, and queuing profiles. If this validation fails, the policy changes are lost.

Policy Versioning

Policy versioning allows you to do the following tasks:

  • Compare a previous version to the current (latest) one to see the differences.

  • Display previous versions of a policy and select a version to reapply to the devices in a site scope.

Editing one version of a policy does not affect other versions of that policy or the components of the policy, such as the application sets that the policy manages. For example, deleting an application set from a policy does not delete the application set from Cisco DNA Center, other versions of that policy, or even other policies. Because policies and application sets exist independent of each other, it is possible to have a policy version that contains application sets that no longer exist. If you attempt to deploy or roll back to an older version of a policy that references an application set that no longer exists, an error occurs.


Note

Policy versioning does not capture changes to applications (such as rank, port, and protocol), application set members, LAN queuing profiles, and sites.

Original Policy Restore

The first time that you deploy a policy to devices, Cisco DNA Center detaches the device's original Cisco Modular QoS CLI policy configurations, but leaves them on the device. Cisco DNA Center stores the device's original NBAR configurations in Cisco DNA Center. This allows you to restore the original Modular QoS CLI policies and NBAR configuration onto the devices later, if needed.


Note

Because the Modular QoS CLI policies are not deleted from the device, if you remove these policies, you will not be able to restore them using the Cisco DNA Center original policy restore feature.

When you restore the original policy configuration onto a device, Cisco DNA Center removes the existing policy configuration that you deployed and reverts to the original configuration that was on the device.

Any Modular QoS CLI policy configurations that existed before you deployed application policies are reattached to the interfaces. However, queuing policies, such as multilayer switching (MLS) configurations, are not restored; instead, the devices retain the MLS configurations that were last applied through Cisco DNA Center.

After you restore the original policy configuration to the device, the policy that is stored in Cisco DNA Center is deleted.

Note the following additional guidelines and limitations for this feature:

  • If the first attempt to deploy a policy to a device fails, Cisco DNA Center automatically attempts to restore the original policy configurations onto the devices.

  • If a device is removed from an application policy after that policy has been applied to the device, the policy remains on the device. Cisco DNA Center does not automatically delete the policy or restore the QoS configuration on the device to its original (pre-Cisco DNA Center) configuration.

Stale Application Policies

An application policy can become stale if you change the configuration of something that is referenced in the policy. If an application policy becomes stale, you need to redeploy it for the changes to take affect.

An application policy can become stale for any of the following reasons:

  • Change to applications referenced in an application set.

  • Change to interfaces, such as SP Profile assignment, WAN subline rate, or WAN or LAN marking.

  • Change to the queuing profile.

  • New site added under a parent site in the policy.

  • Device added to a site that is referenced by the policy.

  • Devices moved between sites in the same policy.

  • Change in interfaces exclusion/inclusion.

  • Change in device Controller-Based Application Recognition (CBAR) status

Application Policy Guidelines and Limitations

  • Cisco DNA Center cannot learn multiple Wireless LANs (WLANs) with the same SSID name on a Wireless Controller (WLC). At any point, Cisco DNA Center will have only one entry for a WLAN with a unique name although it is possible for the WLC to contain multiple entries with the same name and different WLAN Profile Names.

    You might have duplicate SSID names per WLC by design, or you might have inadvertently added a WLC with a duplicate SSID name using Cisco DNA Center. In either case, having duplicate SSID names per WLC is problematic for several features:

    • Learn Config: Cisco DNA Center learns only one randomly chosen SSID name per WLC and discards any remaining duplicate SSID names. (Learn Config is typically used in a brownfield scenario.)

    • Application Policy: When deploying an application policy, Cisco DNA Center randomly applies the policy to only one of the duplicate SSID names and not the others. In addition, policy restore, CLI preview, EasyQoS Fastlane, and PSK override features either fail or have unexpected outcomes.

    • Multiscale Network: In a multiscale network, multiple duplicate SSID names on multiple devices can also cause issues. For example, one device has a WLAN configured as a non-fabric SSID, and a second device has the same WLAN, but it is configured as a fabric SSID. When you perform a Learn Config, only one SSID name is learned. The other SSID name from the other device is discarded. This behavior can cause conflicts especially if the second device supports only fabric SSID names, but Cisco DNA Center is trying to perform operations on the device with non-fabric SSID names.

    • IPACL Policy: When deploying an IPACL policy, Cisco DNA Center randomly applies the policy to only one of the duplicate SSIDs. In addition, scenarios involving Flex Connect are also impacted.

  • Cisco DNA Center does not recommend out-of-band (OOB) changes to device configurations. If you make OOB changes, the policy in Cisco DNA Center and the one configured on the device become inconsistent. The two policies remain inconsistent until you deploy the policy from Cisco DNA Center to the device again.

  • The QoS trust functionality cannot be changed.

Manage Application Policies

The following sections provide information about how to manage application policies.

Prerequisites

To configure Application policies, make sure that you address the following requirements:

  • Cisco DNA Center supports most of the Cisco LAN, WAN, WLAN devices. To verify whether the devices and software versions in your network are supported, see Cisco DNA Center Supported Devices.

  • Make sure that your Cisco network devices, such as the ISR-G2, the ASR 1000, and Wireless LAN Controller, have the AVC (Application Visibility and Control) feature license installed. For information, see the NBAR2 (Next Generation NBAR) Protocol Pack FAQ.

  • AVC support is available for switches running IOS-XE version 16.9 only if auto-QoS is not configured on the switches. You must upgrade the switches with auto-QOS configuration to IOS-XE version 16.11 or later to get AVC support.

  • For Cisco DNA Center to identify the WAN interfaces that need policies, you must specify the interface type (WAN), and optionally, its subline rate and service-provider Class-of-Service model. For more information, see Assign a Service Provider Profile to a WAN Interface.

  • Verify that the device roles that were assigned to devices during the Discovery process are appropriate for your network. If necessary, change the device roles that are not appropriate. For more information, see Change Device Role (Inventory).

Create an Application Policy

This section provides information about how to create an application policy.
Before you begin

  • Define your business objectives. For example, your business objective might be to improve user productivity by minimizing network response times or to identify and deprioritize nonbusiness applications. Based on these objectives, decide which business relevance category your applications fall into.

  • Make sure that you have devices in your inventory. If not, discover devices using the Discovery feature.

  • Verify that the device roles that were assigned to devices during the Discovery process are appropriate for your network. If necessary, change the device roles that are not appropriate. For more information, see Change Device Role (Inventory).

  • Add devices to sites. For more information, see Add a Device to a Site.

  • If you have applications that are not defined in Cisco DNA Center, you can add them and define their QoS attributes. For more information, see Custom Applications.

  • If you plan to configure this policy with an SP profile for traffic that is destined for an SP, make sure that you have configured an SP Profile. After creating the application policy, you can return to the SP Profile and customize its SLA attributes and assign the SP profile to WAN interfaces. For more information, see Configure Service Provider Profiles.

  • If you want some applications configured before others on devices, mark these applications as favorites. For more information, see Mark an Application as Favorite.

Procedure
Step 1

From the Cisco DNA Center home page, choose Policy > Application > Application Policies.

Step 2

Click Add Policy.

Step 3

In the Application Policy Name field, enter a name for the policy.

Step 4

Click either the Wired or Wireless radio button.

Step 5

For Wireless networks, select an SSID which is provisioned from the SSID drop-down list.

Step 6

Click Site Scope and check the check box next to the sites where you want to deploy the policy.

Note 

For policies of wired devices, you cannot select a site that is already assigned to another policy. For policies of wireless devices, you cannot select a site that is already assigned to another policy with the same SSID.

Step 7

For policies of wired devices, you can exclude devices or specific interfaces from being configured with the policy:

  1. From the Site Scope pane, click next to the site you are interested in.

    A list of devices in the selected scope is displayed.

  2. Locate the device that you want to exclude and click the toggle button in the corresponding Policy Exclusions column.

  3. To exclude specific interfaces, click Exclude Interfaces.

  4. From the list of Applicable Interfaces, click the toggle button next to the interfaces that you want to exclude.

    By default, only the Applicabale Interfaces will be shown. You can choose All from the Show drop-down list to view all the interfaces.

  5. Click < Back to Devices in Site-Name.

  6. Click < Back to Site Scope.

Step 8

For WAN devices, you can configure specific interfaces:

  1. From the Site Scope pane, click next to the site you are interested in.

  2. From the list of devices in the site, click Configure in the SP Profile Settings column next to the device you are interested in.

    Note 

    This option is only available for routers.

  3. In the WAN Interface column, from the Select Interface drop-down list, choose an interface.

  4. In the Role column, from the Select Role drop-down list, choose a role according to the type of interface you are configuring:

    • Physical interface—Choose WAN. This role is the only valid role for a physical interface.

    • Tunnel interface—Choose either DMVPN Branch or DMVPN Hub. If you choose DMVPN Hub, you can also define the bandwidth to its corresponding branches.

      Note 

      Make sure that the tunnel interfaces have been created on the devices before deploying these policy settings.

  5. In the Service Provider Profile column, from the Select Profile drop-down list, choose an SP profile.

  6. (Optional) If necessary, in the Sub-Line Rate (Mbps) column, enter the upstream bandwidth that the interface requires.

  7. (Optional) To configure additional WAN interfaces, click + and repeat Step c through Step f.

  8. Click Save.

  9. Click < Back to Site Scope.

Step 9

From the Site Scope pane, click OK.

Step 10

(Optional) If the CVD queuing profile (CVD_QUEUING_PROFILE) does not meet your needs, create a custom queuing profile.

  1. Click Queuing Profiles.

  2. Select a queuing profile from the list in the left pane.

  3. Click Select.

Step 11

(Optional) If this policy is for traffic that is destined for an SP, customize the SP profile SLA attributes:

  1. Click SP Profile.

  2. Choose an SP profile.

  3. Customize the SLA attributes (DSCP, SP Bandwidth %, and Queuing Bandwidth %).

Step 12

(Optional) Configure the business relevance of the application sets used in your network.

Cisco DNA Center comes with application sets that are preconfigured into business-relevancy groups. You can keep this configuration or modify it by dragging and dropping an application set from one business-relevancy group to another.

Applications marked as a favorites are listed at the top of the application set. To change favorites, go to the Applications registry. For information, see Mark an Application as Favorite
Step 13

(Optional) Customize applications by creating consumers and assigning them to applications, or by marking an application as bidirectional:

  1. Expand the application group.

  2. Click the gear icon next to the application that you are interested in.

  3. From the Traffic Direction area, click the Unidirectional or Bi-directional radio button.

  4. To choose an existing consumer, from the Consumer drop-down list, choose the consumer that you want to configure. To create a new consumer, click + Add Consumer and define the Consumer Name, IP/Subnet, Protocol, and Port/Range.

  5. Click OK.

Step 14

Configure host tracking. Click the Host Tracking toggle button to turn host tracking on or off.

When deploying an application policy, Cisco DNA Center automatically applies ACL entries to the switches to which collaboration end points (such as Telepresence units or Cisco phones) are connected.

The ACE matches the voice and video traffic generated by the collaboration end point, ensuring that the voice and video traffic are correctly marked.

When host tracking is turned on, Cisco DNA Center tracks the connectivity of the collaboration end points within the site scope and to automatically reconfigure the ACL entries when the collaboration end points connect to the network or move from one interface to another.

When host tracking is turned off, Cisco DNA Center does not automatically deploy policies to the devices when a collaboration end point moves or connects to a new interface. Instead, you need to redeploy the policy for the ACLs to be configured correctly for the collaboration end points.

Step 15

(Optional) Preview the CLI commands that will be sent to devices. For more information, see Preview an Application Policy.

Step 16

(Optional) Precheck the devices on which you plan to deploy the policy. For more information, see Precheck an Application Policy.

Step 17

Do one of the following tasks:

  • Save the policy as a draft by clicking Save Draft. For more information, see Policy Drafts.
  • Deploy the policy by clicking Deploy. You can deploy the policy now or schedule it for a later time.

    To deploy the policy now, click the Now radio button and click Apply.

    To schedule the policy deployment for a later date and time, click the Later radio button and define the date and time of the deployment. For more information, see Policy Scheduling.

    Note 

    Site time zone setting is not supported for scheduling application policy deployments.

View Application Policy Information

You can display various information about the application policies that you have created and deployed.

Before you begin

You must have at least one deployed application policy.

Procedure
Step 1

From the Cisco DNA Center home page, choose Policy > Application > Application Policies.

Step 2

Sort the policies by name, or filter them by name, status, or queuing profile.

Step 3

View the list of policies and the following information about each:

  • Policy Name—Name of the policy.

  • Version—Iteration of the policy. Each time a policy is deployed or saved as a draft, it is incremented by one version. For example, when you create a policy and deploy it, the policy is at version 1. If you change the policy and deploy it again, the version of the policy is incremented to version 2. For more information, see Policy Drafts and Policy Versioning

  • Policy Status—State of the policy. If the policy applied on Cisco Catalyst 3850, Catalyst 4500, and Catalyst 9K devices, is impacted by the port channel update (create/modify/delete), an alert is shown in the policy status.

  • Deployment Status—State of the last deployment (per device). Presents a summary of the following

    • Devices that were successfully provisioned.

    • Devices that failed to be provisioned.

    • Devices that were not provisioned due to the deployment being aborted.

    Clicking the state of the last deployment displays the Policy Deployment window, which provides a filterable list of devices on which the policy is deployed. For each device, the following information is displayed:

    • Device details (name, site, type, role, and IP address)

    • Success deployment status. Clicking the gear icon next to the status displays the details of the effective marking policy that was deployed to the device. For devices that have limited TCAM resources or an old NBAR protocol pack, only a subset of the applications that are included in the policy can be provisioned, and they are shown in the view.

    • Failure status shows the reason for the failure.

  • Scope—Number of sites (not devices) that are assigned to the policy. For policies of wireless devices, the name of the SSID to which the policy applies is included.

  • LAN Queuing Profile—Name of the LAN queuing profile that is assigned to the policy.

Edit an Application Policy

You can edit an application policy.

Before you begin

You must have created at least one policy.

Procedure
Step 1

From the Cisco DNA Center home page, choose Policy > Application > Application Policies.

Step 2

Use the Filter field to locate the policy that you want to edit.

Step 3

Click the radio button next to corresponding policy.
Step 4

From the Actions drop-down list, choose Edit.

Step 5

Make changes to the application policy, as needed.

Step 6

You can change the business relevance of an application by moving application set between business relevant, business irrelevant, and default groups.

For information about the application policy settings, see Create an Application Policy.

Step 7

To update the queuing profile, click Queuing Profiles, and select a queuing profile from the list in the left pane.

Step 8

Click Select.

Step 9

Do one of the following tasks:

  • Save the policy as a draft by clicking Save Draft. For more information, see Policy Drafts.
  • Deploy the policy by clicking Deploy. You can deploy the policy now or schedule it for a later time.

    To deploy the policy now, click the Run Now radio button and click Apply.

    To schedule policy deployment for a later date and time, click the Schedule Later radio button and define the date and time of the deployment. For more information, see Policy Scheduling.

    Note 

    Site time zone setting is not supported for scheduling application policy deployments.

Save a Draft of an Application Policy

When creating, editing, or cloning a policy, you can save it as a draft so that you can continue to modify it later. You can also make changes to a deployed policy and save it as a draft.

Procedure
Step 1

From the Cisco DNA Center home page, choose Policy > Application > Application Policies.

Step 2

Create, edit, or clone a policy.

Step 3

Click Save Draft.

For more information, see Policy Drafts.

Deploy an Application Policy

If you make changes that affect a policy's configuration, such as adding a new application or marking an application as a favorite, you should redeploy the policy to implement these changes.


Note

Before deploying the policy, Auto-QoS config is automatically removed from Cisco Catalyst 3850, Catalyst 3650, and Catalyst 9K devices with IOS version 16.x or higher.

Procedure
Step 1

From the Cisco DNA Center home page, choose Policy > Application > Application Policies.

Step 2

Use the Filter field to locate the policy that you want to deploy.

Step 3

Click the radio button next to the policy that you want to deploy.
Step 4

From the Actions drop-down list, choose Deploy.

  1. If you redeploy the policy, you will be prompted to take an appropriate actions for the devices that were removed from the policy scope. Choose any one of the following appropriate actions.

    • Delete policy from the devices (Recommended)

    • Remove devices from policy scope

    • Remove devices from policy scope and restore devices to brownfield configuration

  2. Click Apply.

Step 5

You are prompted to deploy your policy now or to schedule it for a later time. Do one of the following:

  • To deploy the policy now, click the Run Now radio button and click Apply.
  • To schedule policy deployment for a later date and time, click the Schedule Later radio button and define the date and time of the deployment.
    Note 

    Site time zone setting is not supported for scheduling application policy deployments.

Cancel a Policy Deployment

After you click Deploy, Cisco DNA Center begins to configure the policy on the devices in the site scope. If you realize that you have made a mistake, you can cancel the policy deployment.

The policy configuration process is performed as a batch process, in that, it configures 40 devices at a time. So, if you have 40 devices or less and you cancel a policy deployment, your devices might be configured anyway, because the deployment to the first batch of devices would have already taken place. However, if you have hundreds of devices, then canceling the policy deployment can be useful when needed.

When you click Abort, Cisco DNA Center cancels the configuration process on devices whose configuration has not yet started, and changes the device status to Policy Aborted. Cisco DNA Center does not cancel the deployments that are in the process of being completed or have been completed. These devices retain the updated policy configuration and reflect the state of the policy configuration, whether it is Configuring, Successful, or Failed.

Procedure

During a policy deployment, click Abort to cancel the policy configuration process.

Delete an Application Policy

You can delete an application policy if it is no longer needed.

Deleting policy deletes class maps, policy map, and association of policy map with wireless policy profile.

Procedure
Step 1

From the Cisco DNA Center home page, choose Policy > Application > Application Policies.

Step 2

Use the Filter field to locate the policy that you want to delete.

Step 3

Click the radio button next to the policy that you want to delete.
Step 4

From the Actions drop-down list, choose Undeploy Policy.

Step 5

In the Undeploy Policy window, click the Delete policy from devices radio button and click Apply.

Step 6

To confirm the deletion, click OK. Otherwise, click Cancel.

Step 7

When the deletion confirmation message appears, click OK again.

You can view the deletion status of the policies in the Application Policies page. If the status shows deletion failed, do the following:

  1. Click the failed state link under Deployment Status in the Application Policies page.

  2. In the Undeployment Status window, click Retry to delete the policy.

Clone an Application Policy

If an existing application policy has most of the settings that you want in a new policy, you can save time by cloning the existing policy, changing it, and then deploying it to a different scope.

Before you begin

You must have created at least one policy.

Procedure
Step 1

From the Cisco DNA Center home page, choose Policy > Application > Application Policies.

Step 2

Use the Filter field to locate the policy that you want to clone.

Step 3

Click the radio button next to the policy that you want to clone.
Step 4

From the Actions drop-down list, choose Clone.

Step 5

Configure the application policy, as needed. For information about the application policy settings, see Create an Application Policy.

Step 6

Do one of the following tasks:

  • Save the policy as a draft by clicking Save Draft. For more information, see Policy Drafts.
  • Deploy the policy by clicking Deploy. You can deploy the policy now or schedule it for a later time.

    To deploy the policy now, click the Run Now radio button and click Apply.

    To schedule the policy deployment for a later date and time, click the Schedule Later radio button and define the date and time of the deployment. For more information, see Policy Scheduling.

    Note 

    Site time zone setting is not supported for scheduling application policy deployments.

Restore an Application Policy

If you create or make changes to a policy and then decide that you want to start over, you can restore the original QoS configuration that was on the device before you configured it using Cisco DNA Center.

Procedure
Step 1

From the Cisco DNA Center home page, choose Policy > Application > Application Policies.

Step 2

Use the Filter field to locate the policy that you want to reset.

Step 3

Click the radio button next to the policy.
Step 4

From the Actions drop-down list, choose Undeploy Policy
Step 5

In the Undeploy Policy window, click the Restore devices to original configurations radio button and click Apply.

Step 6

Click OK to confirm the change or Cancel to abort it.

You can view the restoration status of the policies in the Application Policies page. If the status shows restoration failed, do the following:

  1. Click the failed state link under Deployment Status in the Application Policies page.

  2. In the Undeployment Status window, click Retry to restore the policy.

Reset the Default CVD Application Policy

The CVD configuration is the default configuration for applications. If you create or make changes to a policy and then decide that you want to start over, you can reset the applications to the CVD configuration. For more information about the CVD configuration, see Application Policies.

Procedure
Step 1

From the Cisco DNA Center home page, choose Policy > Application > Application Policies.

Step 2

Use the Filter field to locate the policy that you want to reset.

Step 3

Click the radio button next to the policy.
Step 4

From the Actions drop-down list, choose Edit.

Step 5

Click Reset to Cisco Validated Design.

Step 6

Click OK to confirm the change or Cancel to abort it.

Step 7

Do one of the following tasks:

  • To save a draft of the policy, click Save Draft.
  • To deploy the policy, click Deploy.

Preview an Application Policy

Before you deploy a policy, you can generate the CLI that will be applied to a device and preview the configuration.

Procedure
Step 1

From the Cisco DNA Center home page, choose Policy > Application > Application Policies.

Step 2

Create or edit a policy, as described in Create an Application Policy or Edit an Application Policy.

Step 3

Before deploying the policy, click Preview.

A list of the devices in the scope appears.
Step 4

Click Generate next to the device that you are interested in.

Cisco DNA Center generates the CLIs for the policy.

Step 5

Click View to view the CLIs or copy them to the clipboard.

Precheck an Application Policy

Before you deploy an application policy, you can check whether the devices in the site scope are supported. The precheck process includes validating a device's model, line cards, and software image.

Procedure
Step 1

From the Cisco DNA Center home page, choose Policy > Application > Application Policies.

Step 2

Create or edit a policy, as described in Create an Application Policy or Edit an Application Policy.

Step 3

Click Pre-check.

Cisco DNA Center checks the devices and reports failures, if any, in the Pre-Check Result column. The Errors tab shows the devices that do not support this policy. The Warnings tab shows the restirictions or features that are not supported if you chose to deploy this policy in the device. You can still deploy the policy for the devices listed under Warnings tab. To resolve the failures, bring the devices into compliance with the specifications listed in Cisco DNA Center Supported Devices.

Display Application Policy History

You can display the version history of an application policy. The version history includes the series number (iteration) of the policy and the date and time on which the version was saved.

Procedure
Step 1

From the Cisco DNA Center home page, choose Policy > Application > Application Policies.

Step 2

Click the radio button next to the policy that interests you.
Step 3

From the Actions drop-down list, choose History.

Step 4

From the Policy History dialog box, you can do the following:

  • To compare a version with the current version, click Difference next to the version that interests you.
  • To roll back to a previous version of the policy, click Rollback next to the version that you want to roll back to.

Roll Back to a Previous Policy Version

If you change a policy configuration, and then realize that it is incorrect, or that is not having the desired affect in your network, you can revert to a policy that is up to five versions back.

Before you begin

You must have created at least two versions of the policy to roll back to a previous policy version.

Procedure
Step 1

From the Cisco DNA Center home page, choose Policy > Application > Application Policies.

Step 2

Click the radio button next to the policy that interests you.
Step 3

From the Actions drop-down list, choose Show History.

Previous versions of the selected policy are listed in descending order, with the newest version (highest number) at the top of the list and the oldest version (lowest number) at the bottom.

Step 4

(Optional) To view the differences between the selected version and the latest version of a policy, click Difference in the View column.

Step 5

When you determine the policy version that you want to roll back to, click Rollback for that policy version.

Note 

If the selected site scope changed between policy versions, rollback is not done on the current (latest) selected site. Only the policy content is rolled back.

Step 6

Click Ok to confirm the rollback procedure.

The rolled back version becomes the newest version.

Manage Queuing Profiles

The following sections provide details about the various tasks that you can perform to manage queuing profiles.

Create a Queuing Profile

Cisco DNA Center provides a default CVD queuing profile (CVD_QUEUING_PROFILE). If this queuing profile does not meet your needs, you can create a custom queuing profile.
Procedure
Step 1

From the Cisco DNA Center home page, choose Policy > Application > Queuing Profile.

Step 2

Click Add Profile.

Step 3

In the Profile Name field, enter a name for the profile.

Step 4

Configure the bandwidth for each traffic class by using the slider, clicking the plus (+) or minus (-) sign, or entering a specific number in the field.

The number indicates the percentage of the total interface bandwidth that will be dedicated to the selected application class. Because the total bandwidth equals 100, adding bandwidth to one application class subtracts bandwidth from another application class.

An open lock icon indicates that you can edit the bandwidth for the application class. A closed lock indicates that you cannot edit it.

If you make a mistake, you can return to the CVD settings by clicking Reset to Cisco Validated Design.

The graph in the middle helps you visualize the amount of bandwidth that you are setting for each application class.
Step 5

(For advanced users) To customize the DSCP code points that Cisco DNA Center uses for each of the traffic classes, from the Show drop-down list, choose DSCP Values and configure the value for each application class by entering a specific number in the field.

To customize the DSCP code points required within an SP cloud, configure an SP profile.

Step 6

Click Save.

Edit or Delete a Queuing Profile

Procedure
Step 1

From the Cisco DNA Center home page, choose Policy > Application > Queuing Profile.

Step 2

From the Queuing Profile pane, click the radio button next to the queuing profile that you want to edit or delete.

Step 3

Do one of the following tasks:

  • To edit the profile, change the field values, except the profile name, and click Save. For information about the fields, see Create a Queuing Profile.
  • To delete the profile, click Delete.
    Note 

    You cannot delete a queuing profile if it is referenced in an application policy.

Manage Application Policies for WAN Interfaces

The following sections provide details about the various tasks that you can perform to manage application profiles for WAN interfaces.

Customize Service Provider Profile SLA Attributes

If you do not want to use the default SLA attributes assigned to your SP profile by its class model, you can customize the SP profile SLA attributes to fit your requirements. For more information about the default SP profile SLA Attributes see Service Provider Profiles.

Before you begin

Make sure that you have devices in your inventory. If not, discover devices using the Discovery feature.

Procedure
Step 1

From the Cisco DNA Center home page, choose Policy > Application > Application Policies.

Step 2

Use the Filter field to locate the policy that you want to change.

Step 3

Select the radio button next to the policy.
Step 4

From the Actions drop-down list, choose Edit.

Step 5

Click SP Profiles and select an SP profile.

Step 6

You can modify the information in the following fields:

  • DSCP—Differentiated Services Code Point (DSCP) value. Valid values are from 0 to 63.

    • Expedited Forwarding (EF)

    • Class Selector (CS)—CS1, CS2, CS3, CS4, CS5, CS6

    • Assured Forwarding—AF11, AF21, AF41

    • Default Forwarding (DF)

    For more information about these DSCP values, see Marking, Queuing, and Dropping Treatments.

  • SP Bandwidth %—Percentage of bandwidth allocated to a specific class of service.

  • Queuing Bandwidth %—Percentage of bandwidth allocated to each of the traffic classes. You can make one of the following changes:

    • To customize the queuing bandwidth, unlock the bandwidth settings by clicking the lock icon and adjust the bandwidth percentages.

    • To calculate the queuing bandwidth automatically from the SP bandwidth, lock the queuing bandwidth settings by clicking the lock icon and then clicking OK to confirm. By default, Cisco DNA Center automatically distributes the queuing bandwidth percentage such that the sum of the queuing bandwidth for all of the traffic classes in an SP class aligns with the SP bandwidth percentage of that class.

Step 7

Click OK.

Assign a Service Provider Profile to a WAN Interface

If you have already created an application policy and now want to assign SP profiles to WAN interfaces, you can edit the policy and perform this configuration, including setting the subline rate on the interface, if needed.

Before you begin

If you have not created a policy, you can create a policy and assign SP profiles to WAN interfaces at the same time. For more information, see Create an Application Policy.

Procedure
Step 1

From the Cisco DNA Center home page, choose Policy > Application > Application Policies.

Step 2

Use the Filter field to locate the policy that you want to edit.

Step 3

Click the radio button next to the policy.
Step 4

From the Actions drop-down list, choose Edit.

Step 5

From the Site Scope pane, click the gear icon next to the site you are interested in.

Step 6

Click Configure in the SP Profile Settings column for the device you are interested in.

Step 7

In the WAN Interface column, from the Select Interface drop-down list, choose an interface.

Step 8

In the Role column, from the Select Role drop-down list, choose a role according to the type of interface you are configuring:

  • Physical interface—Choose WAN. This role is the only valid role for a physical interface.

  • Tunnel interface—Choose either DMVPN Branch or DMVPN Hub. If you choose DMVPN Hub, you can also define the bandwidth to its corresponding branches.

    Note 

    Make sure that the tunnel interfaces have been created on the devices before deploying these policy settings.
Step 9

In the Service Provider Profile column, click the Select Profile drop-down field and choose an SP profile.

Step 10

If necessary, in the Sub-Line Rate (Mbps) column, enter the upstream bandwidth that the interface requires.

Step 11

To configure additional WAN interfaces, click + and repeat Step 7 through Step 10.

Step 12

Click Save.

Step 13

Click < Back to Site Scope.

Step 14

Click OK.

Step 15

Click Deploy.

You are prompted to deploy your policy now or to schedule it for a later time.
Step 16

Do one of the following:

  • To deploy the policy now, click the Run Now radio button and click Apply.
  • To schedule policy deployment for a later date and time, click the Schedule Later radio button and define the date and time of the deployment.
    Note 

    Site time zone setting is not supported for scheduling application policy deployments.

Traffic Copy Policies

Using Cisco DNA Center, you can set up an Encapsulated Remote Switched Port Analyzer (ERSPAN) configuration such that the IP traffic flow between two entities is copied to a specified destination for monitoring or troubleshooting.

To configure ERSPAN using Cisco DNA Center, create a traffic copy policy that defines the source and destination of the traffic flow that you want to copy. You can also define a traffic copy contract that specifies the device and interface where the copy of the traffic is sent.


Note

Because traffic copy policies can contain either scalable groups or IP network groups, throughout this guide, we use the term groups to refer to both scalable groups and IP network groups, unless specified otherwise.

Sources, Destinations, and Traffic Copy Destinations

Cisco DNA Center simplifies the process of monitoring traffic. You do not have to know the physical network topology. You only have to define a source and destination of the traffic flow and the traffic copy destination where you want the copied traffic to go.

  • Source: One or more network device interfaces through which the traffic that you want to monitor flows. The interface might connect to end-point devices, specific users of these devices, or applications. A source group comprises Ethernet, Fast Ethernet, Gigabit Ethernet, 10-Gigabit Ethernet, or port channel interfaces only.

  • Destination: The IP subnet through which the traffic that you want to monitor flows. The IP subnet might connect to servers, remote peers, or applications.

  • Traffic Copy Destination: Layer 2 or Layer 3 LAN interface on a device that receives, processes, and analyzes the ERSPAN data. The device is typically a packet capture or network analysis tool that receives a copy of the traffic flow for analysis.


    Note

    At the destination, we recommend that you use a network analyzer, such as a Switch Probe device, or other Remote Monitoring (RMON) probe, to perform traffic analysis.

    The interface type can be Ethernet, Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet interfaces only. When configured as a destination, the interface can be used to receive only the copied traffic. The interface can no longer receive any other type of traffic and cannot forward any traffic except that required by the traffic copy feature. You can configure trunk interfaces as destinations. This configuration allows the interfaces to transmit encapsulated traffic.


    Note

    There can be only one traffic copy destination per traffic copy contract.

Guidelines and Limitations of Traffic Copy Policy

The traffic copy policy feature has the following limitations:

  • You can create up to 8 traffic copy policies, 16 copy contracts, and 16 copy destinations.

  • The same interface cannot be used by more than one traffic copy destination.

  • Cisco DNA Center does not show a status message to indicate that a traffic copy policy has been changed and is no longer consistent with the one that is deployed in the network. However, if you know that a traffic copy policy has changed since it was deployed, you can redeploy the policy.

  • You cannot configure a management interface as a source group or traffic copy destination.

Workflow to Configure a Traffic Copy Policy

Before you begin

  • To be monitored, a source scalable group that is used in a traffic copy policy needs to be statically mapped to the switches and their interfaces.

  • A traffic copy policy destination group needs to be configured as an IP network group. For more information, see Create an IP Network Group.

Procedure

Step 1

Create a traffic copy destination.

This is the interface on the device where the traffic flow will be copied for further analysis. For information, see Create a Traffic Copy Destination.

Step 2

Create a traffic copy contract.

The contract defines the copy destination. For information, see Create a Traffic Copy Contract.

Step 3

Create a traffic copy policy.

The policy defines the source and destination of the traffic flow and the traffic copy contract that specifies the destination where the copied traffic is sent. For information, see Create a Traffic Copy Policy.

Create a Traffic Copy Destination

Procedure

Step 1

From the Cisco DNA Center home page, choose Policy > Traffic Copy > Traffic Copy Destination.

Step 2

Enter a name and description for the traffic copy destination.
Step 3

Select the device and one or more ports.
Step 4

Click Save.

Edit or Delete a Traffic Copy Destination

Procedure

Step 1

From the Cisco DNA Center home page, choose Policy > Traffic Copy > Traffic Copy Destination.

Step 2

Check the check box next to the destination that you want to edit or delete.

Step 3

Do one of the following:

  • To make changes, click Edit, make the necessary changes, and click Save.
  • To delete the destination, click Delete.

Create a Traffic Copy Contract

Procedure

Step 1

From the Cisco DNA Center home page, choose Policy > Traffic Copy > Traffic Copy Contracts.

Step 2

Click Add.

Step 3

In the dialog box, enter a name and description for the contract.
Step 4

From the Copy Destination drop-down list, choose a copy destination.

Note 

You can have only one destination per traffic copy contract.

If no copy destinations are available for you to choose, you can create one. For more information, see Create a Traffic Copy Destination.

Step 5

Click Save.

Edit or Delete a Traffic Copy Contract

Procedure

Step 1

From the Cisco DNA Center home page, choose Policy > Traffic Copy > Traffic Copy Contracts.

Step 2

Check the check box next to the contract that you want to edit or delete.
Step 3

Do one of the following:

  • To make changes, click Edit, make the necessary changes, and click Save.
  • To delete the contract, click Delete.

Create a Traffic Copy Policy

Procedure

Step 1

From the Cisco DNA Center home page, choose Policy > Traffic Copy > Traffic Copy Policies.

Step 2

Click Add Policy.

Step 3

In the Policy Name field, enter a name.

Step 4

In the Description field, enter a word or a phrase that identifies the policy.

Step 5

In the Contract field, click Add Contract.

Step 6

Click the radio button next to the contract that you want to use and then click Save.

Step 7

Drag and drop groups from the Available Groups area to the Source area.

Step 8

Drag and drop groups from the Available Groups area to the Destination area.

Step 9

Click Save.

Edit or Delete a Traffic Copy Policy

Procedure

Step 1

From the Cisco DNA Center home page, choose Policy > Traffic Copy > Traffic Copy Policies.

Step 2

Check the check box next to the policy that you want to edit or delete.
Step 3

Do one of the following:

  • To make changes, click Edit, make the necessary changes, and click Save.
  • To delete the policy, click Delete.

Virtual Networks

Virtual networks are isolated routing and switching environments. You can use virtual networks to segment your physical network into multiple logical networks.

Only the assigned user groups are allowed to enter a virtual network. Within a virtual network, users and devices can communicate with each other unless explicitly blocked by an access policy. Users across different virtual networks cannot communicate with each other. However, an exception policy can be created to allow some users to communicate across different virtual networks.

A typical use case is building management, where the user community needs to be segmented from building systems, such as lighting; heating, ventilation, and air conditioning (HVAC) systems; and security systems. In this case, you segment the user community and the building systems into two or more virtual networks to block unauthorized access of the building systems.

A virtual network may span across multiple site locations and across network domains (wireless, campus, and WAN).

By default, Cisco DNA Center has a single virtual network, and all users and endpoints belong to this virtual network. If Cisco DNA Center is integrated with Cisco Identity Services Engine (ISE), the default virtual network is populated with user groups and endpoints from Cisco ISE.

In Cisco DNA Center, the concept of virtual network is common across wireless, campus, and WAN networks. When a virtual network is created, it can be associated with sites that have any combination of wireless, wired, or WAN deployments. For example, if a site has a campus fabric deployed, which includes wireless and wired devices, the virtual network creation process triggers the creation of the Service Set Identifier (SSID) and Virtual Routing and Forwarding (VRF) in the campus fabric. If the site also has WAN fabric deployed, the VRF extends from the campus to WAN as well.

During site design and initial configuration, you can add wireless devices, wired switches, and WAN routers to the site. Cisco DNA Center detects that the virtual network and the associated policies have been created for the site, and applies them to the different devices.

Guidelines and Limitations for Virtual Networks

Virtual networks have the following guidelines and limitation:

  • VRFs are common across all domains. The maximum number of VRFs is based on the device with the fewest VRFs in the domain.

Multiple Virtual Networks for Guest Access

You can create multiple virtual networks for guest access. With this feature, you can use different virtual networks for guest traffic in places where there is no enterprise traffic. You can now map the wireless guest SSIDs to IP pools from different virtual networks with no restrictions.

Create a Virtual Network

You can create a virtual network to segment your physical network into multiple logical networks.

Procedure

Step 1

From the Cisco DNA Center home page, choose Policy > Virtual Network.

Step 2

Click to create a new Virtual Network.

Step 3

In the Network Name field, enter the name of the virtual network.

Step 4

Check the Guest Virtual Network check box, to configure the virtual network as a guest network.

Devices that are configured with special rules, which allows guests limited access.
Step 5

Drag and drop groups from the Available Scalable Groups area to the Groups in the Virtual Network area.

Step 6

Click Save.

Step 7

To create multiple guest virtual networks, repeat Step 2 through Step 6.

Edit or Delete a Virtual Network

If you move a scalable group from one custom virtual network to another custom virtual network, the mappings for the scalable groups are changed. Be aware that users or devices in the group might be impacted by this change.

Procedure

Step 1

From the Cisco DNA Center home page, choose Policy > Virtual Network.

Step 2

Do one of the following tasks:

  • To edit the virtual network, click the name of the virtual network from the left navigation pane and modify the information in the following table, except the virtual network name:
    Table 7. Virtual Network Fields

    Field

    Description

    Network Name

    Name of the virtual network. (Cannot be modified.)

    Guest Virtual Network

    Devices that are configured with special rules, which allow guests limited access. Check this check box to configure the virtual network as a guest network. You can create only one guest virtual network.

    Available Groups

    Scalable groups that you can choose to include in the virtual network. Drag and drop groups from the Available Groups area to the Groups in the Virtual Network area.

    Groups in the Virtual Network

    Scalable groups that are in the virtual network. Drag and drop groups from the Available Groups area to the Groups in the Virtual Network area.

  • To delete the virtual network, click and confirm the deletion.

Was this Document Helpful?

FeedbackFeedback

Contact Cisco