Overview

In this episode of our ongoing Catalyst Center Automation Series, our focus is on the automation provided by Catalyst Center in the areas of ApplicationVisibility and Policy deployment. During this lab, we will discuss ApplicationVisibility and deployController-BasedApplication Recognition (CBAR). Additionally, you will define an Application Policy (QoS) using Differential Services methodologies and deploy that to the network. CBAR allows Catalyst 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 Catalyst 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 requireAdvantage Licensingand is the only place in this set of labs where that is the case.

Within this series, we cover the following;

1. PnP Preparation -explains the overall Plug and Play set up steps
2. Onboarding Templates -explains in-depth how to deploy Day 0 templates
3. Day N Templates -dives into Day N template constructs with both regular and composite templates and use cases
4. Application Policys-explores Application Policys and SD-AVC in Catalyst Center and their use
5. Telemetry -explains how to deploy Telemetry for assurance
6. Advanced Automation -explores Advanced Automation techniques
7. Dynamic Automation -a deployment lab for dynamic automation

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. Catalyst 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 Catalyst Center during the lab. We will also discuss, set up, and use Controller-BasedApplication Recognition. This will allow Network Administrators the ability to configure network devices in an ongoing and programmatic manner. Using Catalyst Center, we will make certain application policies are consistent throughout networks, whether using SD-Access or Legacy Network Concepts.

Controller-Based Application Recognition

TheApplication 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 Catalyst Center, lets you enable theController-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.

External Authoritative Sources

The Application Visibility service lets Cisco Catalyst 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 Catalyst Center.

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.

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 Catalyst 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 Catalyst Centertakes all of these parameters and translates them into the proper device CLI commands.Cisco Catalyst Centerconfigures 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 aScavenger 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 Catalyst 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 Catalyst 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, thesample templates and JSON files supplied are for easy import into Catalyst 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 Catalyst Center automation, you may utilize the above labs as they have been designed to work within DCLOUD's Cisco Enterprise Networks Hardware Sandbox Labs in either:

1. Cisco Enterprise Networks Hardware Sandbox West DC
2. Cisco Enterprise Networks Hardware Sandbox East DC

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 use with a web-based browser client for VPN-less connectivity, access as well as AnyConnect VPN client connectivity for those who prefer it. You may choose from labs hosted out of our San Jose Facilities by selecting US West. Choose the Cisco Enterprise Network Sandbox. To access this or any other content, including demonstrations, labs, and training in DCLOUD please work with your Cisco Account team or Cisco Partner Account Team directly. 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 Catalyst Center Templates earlier in May 2021.

Additional Information

Catalyst CenterTemplate Labs

The previously named DNAC Template LABS within theDNAC-TEMPLATES GitHub repository aim to guide you through the typical steps required to enable the various automation tasks delivered by Catalyst Center. This lab will give examples of templates used in Catalyst Center that we can modify for our use and test on equipment within the LAB environment. Additional information within the lab provides a well-rounded explanation of Automation methods with Templates. Lastly, the lab allows for customers to use Catalyst Center workflows to practice deploying Onboarding, DayN Templates, and Application Policy automation 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.

The goal of this lab is for it to be a practical guide to aid engineers to rapidly begin using Catalyst Center automation and help them work towards a deployment strategy. Additionally, this lab will give customers a permanent place to try out the configurations for various use cases. Finally, this environment will enable engineers to reduce the time and effort needed to instantiate the network.

As a result, you will gain experience in setting up Plug and Play onboarding and templates and utilizing all features. Additionally, you will use advanced templating methods and troubleshooting tools. These may help during faultfinding to determine what is failing in a deployment.

Catalyst Center Labs

Please use this menu to navigate the various sections of this GitHub repository. Within the multiple folders are examples and explanation readme files for reference. There are now two sets of labs, and these are being continually expanded upon.

New Catalyst Center Lab Content

This newer and more modular lab approach is designed to deal with and includes concepts from the legacy labs in a newer more modular format.

1. Lab 1 Wired Automation -Covers green and brownfield use cases (allow 4.0 hrs)
2. Lab 2 Wireless Automation -Covers traditional wireless automation (allow 4.0 hrs)

Legacy Lab Content

In this section you will continue to find all the existing labs which deal with specifics in separate easy to do labs.

• PnP Preparation -The lab covers setup for Plug and Play (allow 1.5 hrs)
• Onboarding Templates -The lab covers in depth topics in deploying Day 0 templates (allow 1.5 hrs)
• Day N Templates -The lab covers Day N template constructs and use cases (allow 0.5 hrs)
• Composite Templates -This lab covers building a composite template on Cisco Catalyst Center (allow 0.5 hrs)
• Application Policys -This lab covers Application Policy & SDAVC in Cisco Catalyst Center (allow 1.0 hrs)
• Telemetry -This lab explains how to deploy Streaming Telemetry for Cisco Catalyst Center Assurance (allow 0.5 hrs)
• Advanced Automation -This lab will explore Advanced Automation examples (allow 1.5 hrs)
• Dynamic Automation -This lab will explore additional Advanced Automation examples (allow 2.0 hrs)
• Rest-API Orchestration -This lab uses Postman Collections to automate Cisco Catalyst Center (allow 2.0 hrs)
• Wireless Automation -This lab covers Traditional Wireless Automation (allow 6.0 hrs)
• Orchestration -This lab covers Postman and Ansible orchestration (allow 4.0 hrs)
• CICD Orchestration This lab covers Python, Ansible and JENKINS to orchestrate via REST-API (allow 4.0 hrs)

We will share additional labs and content in an ongoing effort to fulfill all your automation needs with Catalyst 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