Avatar

Overview

In this episode of our ongoing DNA Center Automation Series, our focus is on the automation provided by DNA Center in the areas of Application Visibility and Policy deployment. During this lab, we will discuss Application Visibility and deploy Controller-Based Application Recognition (CBAR). Additionally, you will define an Application Policy (QoS) using Differential Services methodologies and deploy that to the network. CBAR allows DNA Center to learn about applications used on the network infrastructure dynamically and helps the administrator tweak which QoS policy to which they conform. This enables you, the network administrator, the ability to configure network devices in an ongoing and programmatic manner from within DNA Center to make sure application policies are consistent throughout the network irrespective of whether you use SD-Access or Traditional Campus methods. Please be aware that this set of concepts does require Advantage Licensing and is the only place in this set of labs where that is the case.

Challenges

There are several hurdles when applying Quality of Service. Suppose we study the Quality of Service whitepaper. In that case, there are still hours of work to determine the correct MQC policies and to deploy for the various linecards and chassis within our network. DNA Center allows us to do three things:

  1. Update all protocol packs
  2. Update dynamic URLs used for Application Discovery.
  3. Deploy a consistent end-to-end QoS policy.
  4. Monitor application usage to assure application and user satisfaction.

To accomplish this, we will discuss all the relevant aspects of these goals and how we execute them in this lab.

What will I learn in the Application Visibility Lab?

We will use Application Policies and apply Quality of Service (QoS) within DNA Center during the lab. We will also discuss, set up, and use Controller-Based Application Recognition. This will allow Network Administrators the ability to configure network devices in an ongoing and programmatic manner. Using DNA Center, we will make certain application policies are consistent throughout networks, whether using SD-Access or Legacy Network Concepts.

Controller-Based Application Recognition

The Application Visibility service lets you manage your built-in and custom applications and application sets. The Application Visibility service, hosted as an application stack within Cisco DNA Center, lets you enable the Controller-Based Application Recognition (CBAR) function on a specific device to classify thousands of network and home-grown applications and network traffic. This allows us to deal with applications beyond the capabilities of NBAR 2, which is some 1400 applications currently.

Application Visibility

External Authoritative Sources

The Application Visibility service lets Cisco DNA Center connect with external authoritative sources like Cisco’s NBAR Cloud, Infoblox, or the Microsoft Office 365 Cloud Connector to help classify the unclassified traffic or help generate improved signatures. Through CBAR, we can discover applications from sources such as Cisco’s NBAR Cloud, Infoblox, or Microsofts 0365 and categorize them for use on our network. Additionally, unclassified traffic can come from any flow that the CBAR-enabled device identifies but is not recognized by the NBAR engine. In such cases, we can classify applications with a meaningful bit rate and add them to application sets within Cisco DNA Center.

External Authoritative Sources

Protocol Packs

CBAR helps to keep the network up to date by identifying new applications as they continue to increase and allow updates to protocol packs. If Application Visibility is lost from end-to-end through outdated protocol packs, this can cause incorrect categorization and subsequent forwarding. This will cause not only visibility holes within the network but also incorrect queuing or forwarding issues. CBAR solves that issue by allowing the push of updated protocol packs across the network.

External Authoritative Sources

As the application flows between various network devices and different network domains, the applications will use consistent markings. Additionally, the forwarding and queuing of the applications will be appropriate. This aids in removing the chance of asynchronous flows causing poor application performance.

Applying Application Policies

Quality of Service (QoS) refers to the ability of a network to provide preferential or deferential service to selected network traffic. When configuring QoS, you ensure that network traffic is forwarding in such a way that makes the most efficient use of network resources. At the same time, it may still adhere to the business’s objectives, such as guaranteeing that voice quality meets enterprise standards or ensures 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 determined based on Cisco Validated Design (CVD). You can modify some of these parameters to align more closely with your objectives.

Site Scope

Sites to which an application policy is applied. If you configure a wired policy, the policy applies 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 applies to all wireless devices with the SSID defined in the scope.

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

Queueing

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 everyday 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 entirely predictable deployment.

Business-Relevance Groups

A business relevance group classifies a given application set according to its relevance 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. As such, it may include a variety of applications, including voice, video, streaming, 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 use 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.

We group applications into application sets and sort them 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.

With that, the lab covers these topics in-depth;

We will gain a practical understanding of the steps associated with setting up DNA Center and an environment to support applications across the network and to deliver device configuration during these labs. The labs aim to aid engineers in rapidly beginning using DNA Center automation and help them work towards an End-to-End QoS strategy. Additionally, these labs will give customers a permanent place to try out Application Visibility and Policy deployment. Finally, this environment will enable engineers to reduce the time and effort needed to instantiate the network.

  1. Setting up and deploying Application Visibility.
  2. Defining an Application Policy
  3. Deploying an Application Policy
  4. Defining a custom application and application set
  5. Modifying an existing Application Policy

How can I get started?

Within dCLOUD, several sandbox-type labs are available. These self-contained environments are there to allow you to use them as you please within the time scheduled. In addition, this allows us a place to start practicing various concepts without fear of impacting production environments.

As a result, we hope to demystify some of the complexities of setting up automation and help guide customers through the caveats. Therefore, to aid customers in the transition toward automation, we have put together a set of small helpful labs within a Github repository. In this way, these self-guided labs provide a glimpse into the fundamentals of building velocity templates and offer examples that you can download and expand from. In addition, the sample templates and JSON files supplied are for easy import into DNA Centers’ template editor for quicker adoption. Lastly, some scripts are ready-made excerpts of code that allow you to build the environment to test.

In this practical lab, Application Policys, we step by step delve into the concepts of building and deploying a QoS policy and dynamically discovering applications. Second, we provide answers and explanations to many of the questions that come up during automation workshops. We hope that you find the information both helpful and informative.

Where can I test and try these labs?

dCLOUD Lab Environment

To help customers succeed with Cisco DNA Center automation, you may utilize the above labs as they have been designed to work within dCLOUD’s Cisco Enterprise Networks Hardware Sandbox v2.1 Lab. The dCLOUD labs allow you to run these labs and gives an environment to try the various code samples. You may choose to develop and export your code for use in production environments. Also, this gives you an environment where you can safely POC/POV methods and steps without harming your production environments. The dCLOUD environment also negates the need for shipping equipment, lead times, and licensing issues needed to get moving rapidly. Please do adhere to the best practices for the dCLOUD environment when using it.

Lab Connectivity

The environment allows for a web-based browser client for VPN-less connectivity. Additionally, there is AnyConnect VPN client connectivity for those who prefer it. Choose the Cisco Enterprise Network Sandbox v2.1 or 3.1. Additionally, you may choose from our San Jose and RTP Facilities labs by either selecting US East or US West. To access this or other content, demonstrations, and labs in dCLOUD, please directly work with your Cisco or Partner Account Team. Your Account teams will schedule the session and share it for you to use. Once booked, follow the guide within Github to complete the tasks adhering to the best practices of the dCLOUD environment.

Content

The Application Policys lab content is located within the existing DNAC-TEMPLATES repository to give a one-stop-shop for all the necessary tools, scripts, templates, and code samples. Within it are seven labs, which build upon the tutorials to test the methods in a lab environment. The repository was featured in a previous post on Cisco Blogs about DNA Center Templates earlier in May 2021.

Additional Information

DNAC Template LABS

Additional labs aim to guide you through the typical steps required to enable the various automation tasks. This lab delves into the concepts of building and deploying a QoS policy and dynamically discovering applications. As a result, it also gives us suitable testing equipment within the LAB environment. Additionally, information within the lab provides a well-rounded explanation of Automation methods with Templates. Lastly, the lab enables customers ability to use DNA Center workflows. This lab gives an environment for customers to practice deploying Application Policies on both Wired and Wireless Platforms.

This lab’s goal is to be a practical aid for engineers developing a QoS automation strategy. Additionally, customers will gain a permanent place to try out the policies for various use cases. Finally, this environment will enable engineers to reduce the time and effort needed to instantiate the network.

Additional Labs

Please use this menu to navigate the various sections of this Github repository. Within the multiple folders are examples, explanation readme files for reference.

  • PnP Preparation – This lab explains the overall Plug and Play set up steps
  • Onboarding Templates – This lab demonstrates in-depth and how to deploy Day 0 templates
  • Day N Templates – This lab will dive into Day N template constructs and use cases
  • Composite Templates – This lab will explore how to build a composite template on DNA Center
  • Application Policys – This lab will explain Application Policys in DNAC and their use
  • Telemetry – This lab will explain how to deploy Telemetry for assurance
  • Advanced Automation – This lab will explain how to deploy Telemetry for assurance

We will share additional labs and content in an ongoing effort to fulfill all your automation needs with DNA Center.

In conclusion, if you found this set of labs and repository helpful,

please fill in comments and feedback on how it could be improved.


We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco on social!

Check out our Cisco Networking video channel

Subscribe to the Networking blog