A Practical Look at Cisco DNA Center

Cisco DNA Center Lab Guide
LTRNMS-2500
A Practical Look at Cisco DNA Center: A better way to manage your

network in the digital era - Hands-On Lab
LAB GUIDE
Julia Guenther, Technical Marketing Engineer, Cisco Systems
Peng Xu, Technical Marketing Engineer, Cisco Systems
Prem Chandran, Technical Marketing Engineer, Cisco Systems
Jim Galvez, Technical Solutions Architect, Cisco Systems
Lab Overview
With Cisco DNA Center lab participants will be able to have a hands-on experience on the
benefits of Cisco DNA Center Automation and Assurance capabilities. In this lab, participants
will be able to test the ease of management provided by intent-based networking.
Product Overview
Cisco DNA Center
Digitization is fueled by major technology trends: mobility, the Internet of Things, and cloud
computing. To capture the opportunity, you need to adapt constantly. You need real-time
insights and personalized experiences, automation and assurance, security and compliance.
You need a network that is constantly learning. Constantly adapting. Constantly protecting.
Introducing an entirely new era of networking. The Network. Intuitive.
Your network infrastructure is the enabler for digital transformation and crucial to your
organization’s success. Cisco® Digital Network Architecture (DNA) Center is a centralized
management application for your network. Cisco DNA Center simplifies network
management so IT can move more quickly, using automation to lower costs, assurance and
analytics to improve network performance, and security to reduce risk.
Copyrighted Cisco® Systems Inc. January 2019 1
Benefits:
• Simplify network management: Manage your enterprise network over a centralized

dashboard.
• Deploy networks in minutes, not days: Using intuitive work flows, Cisco DNA Center
makes it easy to design, provision, and apply policy across your network.
• Reduce human error: Policy-driven automation reduces downtime and improves
security.
• Predict problems before they happen: Analytics and assurance use network insights
to optimize network performance and deliver the best user and application
experience
Lab Topology
POD Assignment and Access to POD
Each POD includes:
1. Multiple network devices (refer to the topology diagram)
2. Cisco DNA Center appliance
The Lab proctor will provide the specific topology for the POD together with POD IP Address
Assignments and credentials.
NOTE: Every 2 students will share 1 POD.
Lab Topology
Refer to the topology diagram below, for lab use.

Getting Started
This hand on lab consists of the exercises below:
• Lab Exercise 1: Starting with Cisco DNA Center – Visualize Network Hierarchy,
Discovery and Inventory
• Lab Exercise 2: Cisco DNA Center Automation - Day 0 provisioning with Network Plug
and Play
• Lab Exercise 3: Cisco DNA Center Automation - Standard Network Changes, Wireless
Provisioning and Software Upgrades (SWIM)
• Lab Exercise 4: Cisco DNA Center Automation - Template Editor
• Lab Exercise 5: Cisco DNA Center Automation – Application Policy
• Lab Exercise 6: Cisco DNA Center Assurance Use Case #1: Network visibility
• Lab Exercise 7: Cisco DNA Center Assurance Use Case #2: Troubleshooting
• Lab Exercise 8: Cisco DNA Center Assurance Use Case #3: Proactive Monitoring -
Sensor
• Lab Exercise 9: Cisco DNA Center Platform- Northbound API’s
• Lab Exercise 10: Cisco DNA Center Platform- Events and Notifications
Access your POD

The instructor will provide the lab access information.
Lab Exercise 1: Starting with Cisco DNA Center –

Visualize Network Hierarchy, Discovery and Inventory
Exercise Description and objective
With Cisco DNA Center, we are changing how networks are designed, deployed and
managed. One of the main advantages of Cisco DNA Center over traditional management
systems is the ability to offer massive simplification by leveraging both guided workflows
and abstractions. These guided workflows are based on business intent as opposed to
feature and CLI-based configuration.
Cisco DNA Center offers four main applications to configure and manage your network:
design, provision, policy and assurance.
In order to provide more time for advanced exercises as well as to have enough telemetry
information for the Assurance section, the network hierarchy has been configured and the
brownfield network has been discovered.
In this exercise we will take a look at network hierarchy and device inventory.
Lab Exercise Steps
Step 1 Connect to your Jump PC via RDP (Remote Desktop Client). Use the IP address
assignment and credentials provided by the instructor. You will now be
connected to a Windows PC. From this Windows PC use your Chrome Browser
to access your Cisco DNA Center UI (User Interface) and enter the credentials.
Once you enter the credentials you’ll access the Cisco DNA Center After you log
in to Cisco DNA Center, you are taken to the Cisco DNA Center home page, which
is divided into four main areas. Overall Health, Network snapshot, Network
configuration and operations and Tools.
In the snapshot below, we can see the following:
Overall Health - Shows the overall health of the network devices and wired and
wireless clients.
Network snapshot - This gives a snapshot of what is configured in the network
using Cisco DNA Center and other useful information about the network.
Network configuration and operations has the following:
Design—Create the structure and framework of your network including the
physical topology, network settings, and device type profiles that you can apply
to devices throughout your network.
Policy—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.
Provision—Prepare and configure devices, including adding devices to sites,
assigning devices to the Cisco DNA Center inventory, deploying the required
settings and policies, creating fabric domains, and adding devices to the fabric.
Assurance—Provides proactive and predictive actionable insights about the
performance and health of the network infrastructure, applications, and end
user clients.
Platform—Use DNA Center Platform, to programmatically access your network
through Intent APIs, integrate with your preferred IT systems to create end-to-
end solutions and add support for multi-vendor devices.

Step 2 Scroll down and you can then see the tools available in Cisco DNA Center. These
tools will support and integrate with the Cisco DNA Center workflows:
Step 3 When deploying Cisco DNA Center, we typically go through the following steps:
• Define the hierarchy of the organization including sites, buildings and floors.
• Enter the device credentials for our network devices and use those
credentials to discover those network devices.

• All the discovered devices will be placed in Cisco DNA Center Inventory.
• Lastly, we assign each device to the sites, building, floors that we defined in
our network hierarchy.
As mentioned above, all these steps have been taken care of. We will use the rest
of this exercise to look at this information.
Go to the Design Application (you can either use the tab at the top or scroll down
to access the different applications)
Step 4 The design tool is where we specify what attributes apply to the network.
Attributes include location information, floor plans, common services such as
DHCP, IP Addressing, Wireless SSIDs, credentials, etc.
Take a few moments to explore the different sites that have been created:

Step 5 The next step is to examine the network attributes. In the “Design” page, select
“Network Settings” followed by “Network”.
By default, we will see the attributes for the top level of the network hierarchy.
All attributes defined in the Global view will be inherited by the rest of the
hierarchy.
These are the values that have been pre-defined:
NTP: 10.2.254.1
DHCP: 1.1.1.1
DNS domain name: cisco.com
DNS:.1.1.1.1

Step 6 We can also define specific attributes for different sites as well as override
inherited parameters. Look at the “Branch Site” and observe site-specific values:
DNS: 44.44.44.44
SYSLOG: 55.55.55.55
Inherited Values
Site Specific Values
Step 7 The next step in the workflow would be adding the device credentials. We will
observe the credentials we created at the “Global” level. Select “Device
Credentials”. Observe the CLI and SNMP credentials:

Username: admin
Password: Cisco123
Enable Password: lab-cert
SNMPV2 read only community: cisco (use “RO” as Name/Description)
SNMPV2 write community: cisco123 (use “RW” as Name/Description)
Step 8 Now that everything has been defined, we need to look at the devices in our
network. Let’s use the “Inventory” tool:

Step 9 The inventory allows us to get comprehensive information on each device in our
network.
NOTE: Make sure that all devices in the inventory are in “Managed” state. If the state is “In Progress” you
just need to wait a few more minutes. If you get any errors, you need to fix the problem before moving to the
next step. You should see six network devices and two access points. Device IP address in the snapshots might
be different from the ones in your POD
Step 10 The snapshot above shows the inventory in a preset view called “Status”. This
preset view shows specific fields associated with the status of each device. We
can manually select other fields or other preset views. Select “Hardware Preset”:

Step 11 There is an “Actions” menu that allows to execute specific actions on selected
devices. We will test this functionality in the next steps. We will first select the
devices. Select “BR-R1” and “BR-SW1”:
Step 12 You can now open the “Actions” drop down menu. It will show a list of actions
you can execute on the devices we selected in the previous steps. Take a look at
the list of actions you can perform on specific devices (but we will not be
executing any actions in this step):
• Delete: Deletes the selected devices from inventory

• Update Credentials: Changes the credentials of the selected devices. In future
discoveries, these credentials are used for the selected devices instead of the
global or job-specific credentials
• Update Polling Time: Updates the polling interval of the selected devices. These
device-specific settings override the global and job-specific settings for the
selected devices.
• Resync (Resynchronize Devices): Polls the selected devices for updated device
information and status

Step 13 “Command Runner” is a very useful debugging tools that allows you to run read-
only commands on selected devices. Select all devices in the branch: BR-R1, BR-
SW1. We will test this capability by selecting this “Command Runner”:
Step 14 Type the command we want to run, in this example “show run | section name-
server”. This command allows us to see if the devices have any DNS servers
configured. We will use this information in a later exercise on device settings.
Click “Add”:

Step 15 The added command will show at the bottom. We can add multiple commands.
Add another command, for example, “show run | section domain name”. This
command allows us to see if the devices have any domain configuration. We will
use this information in a later exercise on device settings. Click “Add”. Once the
two commands show up at the bottom of the screen select “Run Command(s)”:

Step 16 For each command and for each device you will get the output of the command.
You will also get information on whether the command was successful or it
failed. Select the command to check the output. You can also copy the CLI output
to the clipboard:
We can see that BR-SW1 doesn’t have a DNS server and domain configured. We
will use this information in later a later exercise:
Step 17 Return to the inventory page. We will now take a look at the filters. Since our
inventory is very small, it’s very easy to visualize and find all devices. However,
production networks typically have a large number of devices. Filters allow us
to narrow down the view based on parameters. For this example, we will narrow
down the view to “ACCESS” as Device Role.

Step 18 (Optional) If you are interested in how devices are populated in the inventory,
scroll down to the “Tools” section and select “Discovery”.
By discovering the network, Cisco DNA Center will gain comprehensive

knowledge of each device in the network including hardware, software and
licensing information, configuration of the devices and the relationship between
devices. The information in the inventory is crucial for Cisco DNA Center to
perform the other applications.

Cisco DNA Center supports three methods for discovery: LLDP, CDP (Cisco
Discovery Protocol) and IP Range. We will use CDP discovery mechanism for
this lab. Optionally, Cisco DNA Center allows to manually enter device
information or import the inventory from other applications using a .csv file.
 End of Exercise: You have successfully completed this exercise!

Proceed to the next section…

Lab Exercise 2: Day 0 provisioning with Network Plug

and Play
Enterprises incur in major operating costs to install and deploy networking devices as part
of campus and branch deployments. Typically, every device has to be pre-staged, which
involves repetitively copying Cisco IOS® Software images and applying configurations
manually through a console connection. Once pre-staged, these devices are then shipped to
the final site for installation. The end-site installation may require a skilled installer for
troubleshooting, bootstrapping, or any change in the configuration. The entire process can
be costly, time-consuming, and prone to errors. At the same time, customers would like to
increase the speed and reduce complexity of the deployment without compromising
security.
Our Network Plug and Play solution provides enterprise customers with a simple, highly
secure, and integrated offering to ease new branch or campus device rollouts or incremental
updates to an existing network. The solution provides a unified approach to provision
enterprise networks comprised of Cisco routers, switches, and wireless access points with a
near-zero-touch deployment experience.
It reduces the burden on enterprises by greatly simplifying the process of deploying new
devices. An installer at the site can deploy a new device without any command-line interface
(CLI) knowledge, while a network administrator centrally manages device configuration.
The Cisco Network Plug and Play solution offers:
• One solution for configuration of Cisco enterprise switches, routers, and wireless
access points.
• A simple, intuitive, and integrated user interface, agnostic of device platforms.
• Automated and centrally managed remote device deployment from the Cisco DNA
Center
• Devices that can automatically discover Cisco DNA Center through Dynamic Host
Configuration Protocol (DHCP), Domain Name System (DNS), or through a plug-and-
play (PNP) mobile application. The built-in, pre-provisioned, and unplanned devices
workflows in the Cisco Plug-and-Play solution more securely simplify the deployment
of Cisco IOS Software images and device configurations.
• Mobile iOS or Android application to help an installer bootstrap devices and monitor
installation from remote sites.
• Highly secure, bi-directional device authentication using Secure Unique Device
Identification (SUDI) and highly secure communication. You use certificates stored in

a Cisco managed trustpool bundle, which includes certificates signed by trusted

authorities and published by Cisco Information Security.
Lab Exercise Steps
Step 1 For onboarding new devices, Cisco DNA Center follows the same principle of
network profiles and sites.
DESIGN DESIGN
DEVICE
TEMPLATE
PROFILE
DEVICE
SITE
New Device Onboarded
PROVISION
Plug & Play
Step 2 The main purpose of Plug & Play is to automatically push a Golden Image and config
to a new device. The network admin will need to provide the configuration for the
new device. Cisco DNA Center uses templates for this purpose. Scroll down to the
tools section in Cisco DNA Center dashboard. Select Template Editor:
Step 3 As we will see in future exercises, we can use templates to add customized
configurations to devices in our inventory. Templates are also used to input the
configuration that will be pushed to new devices being onboarded using Plug and
Play. In Template Editor add a new template within the “Onboarding Configuration”
tab.

In “Template Editor”, you will see a new system default project named “Onboarding
Configuration”, which is designed to group all day-0 onboarding templates. Only
templates in this project can be used for day-0 onboarding, while templates under
user-defined projects will be used for day-2 provisioning.
Step 4 Assign the name “C9K-Branch-PnP” to the template and select “Edit” to select the
device type for such template:
Step 5 Start typing “9300” and Cisco DNA Center will provide the correct matches to Cisco
products. Select “Cisco Catalyst 9300 Series Switches”:
Step 6 Go back to the template:

Step 7 Select “IOS-XE” as Software Type and click on “Add”:
Step 8 Click on the template we just created. A black space will become available for us to
enter the configuration for new devices. Next, users can copy and paste the template
previously defined offline or edit directly on the new template.
Template editor engine of Cisco DNA Center is based on Apache Velocity. If you
precede any string with $ sign, the following string will be variable, for example
$hostname. For our exercise, we will not be using variables.

Step 9 Open the configuration file provided in the PnP directory in the Desktop. The file is
called “PnP-Config-C9K-SW2.txt”. Once you open the file, select the full configuration
of the file and “Copy & Paste” into the black space:

Step 10 Click on “Action->Save” to save a local copy of template on Cisco DNA Center:

Step 11 After saving the template, you need to version the template. You must version the
template every time you make changes to the it. You can enter a commit note when
the Commit window appears. If you Commit without saving the template, you will
be prompted to save the changes. Click on “Action->Commit”:
Step 12 Click on “Commit”:
Step 13 As mentioned before, templates need to be assigned to network profiles. In turn,

network profiles need to be assigned to sites. We will perform these tasks in the
steps below. From the main dashboard go to “DesignNetwork Profiles”:

Step 14 Select “Switching”:
Step 15 Assign a name to the profile: “Branch-Switch-Profile”:
Step 16 Under “Onboarding Template(s)” tab, click on “Add”:
Step 17 Select “Cisco Catalyst 9300 Series Switches” for “Device Type” and “C9K-Branch-
PnP” template defined in earlier section.

Step 18 To recap, so far, we created an onboarding template and we assigned the template
to a switching profile. We now need to assign such profile to the “Branch” site. Select
“Assign Site”:
Step 19 Select “Branch” and click on “Select”:

Step 20 We are now ready to onboard a new device. Let’s go to “Provision  Devices  Plug
and Play”. So far, we have no activity in this window:
Step 21 For this exercise, we will simulate the onboarding a newly acquired Catalyst 9300
switch to our branch network. In real life deployments, we would get the new switch,
remove the switch from the box, cable and power up the switch allowing the
Network PnP process to begin. In the lab environment, the switch is already racked,
cabled and powered up. We will simulate the process by erasing the switch
configuration completely hence returning the device to factory defaults.
We will now be connecting to the Plug and Play switch. Using the Putty client connect
to the terminal server (IP address provided by the proctor and/or already saved in
Putty). Use password “labops”. There are two terminal servers available for this lab.
Connect to TS2 and look for host pX-9300-2 (where X is your pod number). If you
can’t find the host in TS2, connect to TS1 and look for host pX-9300-2 (where X is
your pod number).
APIC_TS>show hosts  look for the pX-9300-2 entry that corresponds to your POD
APIC_TS>pX-9300-2  X is your POD number
Translating "Px-9300-2" core X is your POD number
Trying PX-9300-2 (1.1.1.1, 2025)... Open
BR-SW2>enable  X is your POD number
Password:  Use password lab-cert
Step 22 From the Catalyst 9300 switch console (BR-SW2), we will turn the device into
factory defaults removing the configuration and certificates
BR-SW2#conf t
BR-SW2 (config)#crypto key zeroize
% All keys will be removed
% All router certs issued using these keys will also be removed
Do you really want to remove these keys? [yes/no]: yes  Answer “yes”
BR-SW2 (config)#end
BR-SW2#test crypto pki trustpool reset

BR-SW2#delete nvram:*.cer  Delete certificates stored in nvram
Delete filename [*.cer]? <ENTER> to confirm removal of certificates
Delete nvram:Cisco#2473CA.cer? [confirm] <ENTER> to confirm removal of certificates
Delete nvram:sdn-network-#3E95CA.cer? [confirm] <ENTER> to confirm removal of certificates
Delete nvram:sdn-network-#EDA.cer? [confirm] <ENTER> to confirm removal of certificates
BR-SW2#delete flash:vlan.dat  Delete any existing vlan database
BR-SW2#write mem
BR-SW2#write erase  Proceed to erase config

Erasing the nvram filesystem will remove all configuration files! Continue?
[confirm]  Press [Enter] to confirm
[OK]
Erase of nvram: complete
Step 23 Before we deploy our new switch in the branch, we need to enable the interface that
will be connecting to this new switch. We only need to do a “no shutdown” in
interface gig 1/0/6 of the upstream switch BR-SW1 (Catalyst 9300)
Using the Putty client connect to BR-SW1. Use ssh to connect to the IP address
10.10.64.2 (username: admin / password: Cisco123 / enable: lab-cert).

login as: admin

Password:  Use password Cisco123 (if prompted for enable
password use lab-cert)
BR-SW1#
BR-SW1#show run int gig 1/0/6  locate the interface in the BR-SW1 connected to the PNP BR-SW2
Building configuration...
Current configuration: 70 bytes

!
interface GigabitEthernet1/0/6
description SWIM 9300
switchport access vlan 64  Note the use of vlan 64
switchport mode access
shutdown  interface is currently shutdown
device-tracking attach-policy IPDT_MAX_10
end
BR-SW1#
BR-SW1#term mon
BR-SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
BR-SW1(config)#int gig 1/0/6
BR-SW1(config-if)#no shut  enable interface to the PNP switch
BR-SW1(config-if)#end
BR-SW1#write mem
Nov 12 01:18:47.262: %SYS-5-CONFIG_I: Configured from console by console

Nov 12 01:18:47.690: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/6, changed
state to down
Nov 12 01:18:50.282: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/6, changed

state to up
Nov 12 01:18:51.297: %LINEPROTO-5-UPDOWN: Line protocol on Interface
GigabitEthernet1/0/6, changed state to up[OK]
BR-SW1#
BR-SW1#show int gig 1/0/6
GigabitEthernet1/0/6 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is c471.fe98.bc86 (bia c471.fe98.bc86)
Description: PNP BR-SW2
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:05, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
1726551 packets input, 206275214 bytes, 0 no buffer
Received 441415 broadcasts (439460 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 439460 multicast, 0 pause input
0 input packets with dribble condition detected
BR-SW1#
Step 24 Network Plug and Play supports devices using VLAN 1 by default. However, if we
want to use a different VLAN to VLAN 1 we can provide a CLI command on the
upstream device. The command is “pnp startup vlan x”. We will test this feature in
our lab. Still connected to the Catalyst 9300 switch in the branch office (BR-SW1),
we will add this command:
BR-SW1#
BR-SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.cd
BR-SW1(config)#pnp startup-vlan 64  We are using vlan 64 in the lab
BR-SW1(config)#end
BR-SW1#write mem
Step 25 From BR-SW2 Catalyst 9300 switch console, we are now ready to simulate a new
device connecting to the branch by reloading the PnP switch:
BR-SW2#reload  Proceed to reload the switch
Nov 3 10:32:16.586: %SYS-7-NV_BLOCK_INIT: Initialized the geometry of nvramd
System configuration has been modified. Save? [yes/no]: no  Select “no” if asked

Proceed with reload? [confirm]  Press [Enter] to confirm
Step 26 Once we execute the commands above, we are simulating a new device connecting
to the network. For this lab, the PnP agent located in the C9300 switch will locate
the DNAC/PnP server using DHCP (we will view this information in later steps).
Once the PnP agent locates the PnP server, it will contact it and we will see the
progress in the dashboard. In order to see the progress, click on the refresh button.
You can check the output in the C9300 console. If you do, make sure you don’t stop
the PnP process. Don’t hit any key in the console. The system dialog wizard will
time out so that the PnP process can proceed.
NOTE: Don’t hit any key in the console until the PnP process is finished. The system dialog wizard will time out
so that the PnP process can proceed.

Step 27 Once the device runs the Plug and Play process and connects with Cisco DNA Center,
the device information will show up. You can “Refresh” to see this information. The
device will show up as “Unclaimed”:
Step 28 Select the switch and click on “Action->Claim”. This process will allow us to specify
the site for this device. Since the site has a profile assigned, the template in the profile
will be pushed to the device.
Step 29 Next, at “Site Assignment”, select “Branch” as desire site and click on “Next”:

Step 30 In “Configuration” page, you can select “golden” image if you want this switch to go
through software upgrade before pushing the config to the device.
For this lab, we will not be doing a software upgrade. Click on “Skip golden image
upgrade”.
In the “Template” task, you can select onboarding template “C9K-Branch-PnP”

defined in design phase. Finally, click on “Next”:
Step 31 In “Advanced Configuration” page, you need to input values for variables in template
to complete/generate final configuration for devices. Since we don’t have any
variables in our configuration, just click on “Next”.

Step 32 Finally, in the “Summary” page, you can review the provisioning details. Please note
that in “Day-0 Configuration Preview” section, Cisco DNA Center essentially
generates CLI configuration including device credential and enabling SSH for users.
You can also observe the defined template is included as part of provisioning in
“Template CLI Preview” section. Lastly, click on “Claim” to start claiming process.

Step 33 Cisco DNA Center is now ready to onboard the new device.
NOTE: There are no action items in this step. Just wait for the Plug and Play process to complete
Step 34 Plug and Play process will resume automatically:
Step 35 (Optional) While you wait for the device to be provisioned, you can examine the
DHCP configuration in the distribution switch BR-SW1 (we are using this switch as
our DHCP server). Network PnP uses different discovery methods, that is,
mechanisms for the Network PnP agent to find the PnP server (Cisco DNA Center).

The method used in this lab is DHCP. That is, when the PnP agent of the new device
sends a DHCP request, the response packet will contain the IP address of the PnP
server populated in option 43.
Use Putty to connect to the console of the BR-SW1 and look for the DHCP
configuration. You can also check the configuration from device inventory:
BR-SW1#show run | section dhcp
!
ip dhcp pool VLAN64
network 10.10.64.0 255.255.255.0
default-router 10.10.64.1
dns-server 10.1.10.10
domain-name cisco.local
option 43 ascii "5A1D;B2;K4;I10.1.3.230;J80"  Note IP address of Cisco DNA
Center
lease infinite
!
Step 36 Plug and Play process will be completed once you get to a “Provisioned” status:
Step 37 (Optional) From the device console, you can see that BR-SW2 now has the correct
configuration deployed:

Step 38 Plug and Play will automatically add the device into the inventory. We can see that
BR-SW2 is now in “Managed” state and it’s also assigned to the “Branch” site:
Step 39 (Optional) Throughout the Plug and Play process, the network administration can
monitor the progress by clicking on the serial number of the device. Take a look at it
now:



Lab Exercise 3: Cisco DNA Center Automation - Standard

Network Changes, Wireless Provisioning and Software
Upgrades (SWIM)
Cisco DNA Center saves time by using a single dashboard to manage and automate your
network. Design your enterprise network by starting with geographical locations, creating
sites, and then adding network devices. Quickly scale your business with intuitive workflows
and reusable templates.
Configure and provision thousands of network devices across your enterprise in minutes,
not hours. With Cisco DNA Center, we can:
• Automate standard network changes across sites

• Manage software images and patch updates
• Centralize IP address management
Lab Exercise Steps
Step 1 As we’ve seen in previous exercises, Cisco DNA Center uses the concepts of sites. All
devices should be assigned to sites. This has been done already for you. We will use
the reference below:
Site: Campus
Site: Branch
Site: Branch/Floor1

NOTE: Please note, there’s no action to be done in this step. This snapshot is only meant to
provide the network topology and how we will be assigning the devices to the hierarchy.
Step 2 From the Cisco DNA Center Dashboard, select “Provision”. We will be able to see the
Site for every device in our inventory (7 devices in total). Every device should be in
“Managed” state:
Step 3 In the next steps, we will see how we can automate general parameters to our
network using business intent. In previous exercises, we defined among other
things, the syslog server for our global network as well as a specific syslog server for
our branch network. We are going to see how Cisco DNA Center allows us to
automate the roll out of this service into our whole branch without having to extend
a single CLI command. Select our switches in the “Branch” site. In the “Actions” menu
select “Provision”:
NOTE: As rule of thumb, always make sure that the devices are in “Managed” state before
provisioning

Step 4 Confirm that the we selected the correct switches and that both switches are located
in the “Branch” site. Click “Next”:
Step 5 Click “Next”:
Step 6 We haven’t created any templates yet so the advanced configuration option is empty.
Click “Next”:

Step 7 We can now see that all our branch switches will be configured with the parameters
we entered in the settings in the design phase. Check the routers and select “Deploy”:

Step 8 We can deploy the configuration now or you can schedule it for a later time. Select
“Run Now” and click on “Apply”:
Step 9 Once the configuration has been deployed, you will receive the log messages from
Cisco DNA Center:

Step 10 Using the “Command Runner” from the inventory tools, we will confirm that the
configuration has been pushed correctly:
Since Cisco DNA Center allows to push the configuration for these services by
expressing business intent, we don’t need to worry about specific CLI configuration
for a router or a switch or a WLC. By leveraging the Provision workflow, we just
configured, a syslog, NTP and DNS server in multiple devices without issuing a CLI
command.
For verification purposes, we will issue the CLI commands in the command runner.

Step 11 Verify the output of the commands, like we are showing in the examples below:

Step 12 In the next few steps, we will see how easily we can automate wireless deployments
using DNA-Center. We will show how we can leverage network profiles to
consistently deploy wireless configuration across the Enterprise. We will be
following the process below:

1 DESIGN
PROFILE
SITE
2 PROVISION
DEVICE
Step 13 (Optional) You can check the existing configuration in the WLC:
Step 14 Cisco DNA Center supports wireless deployments in brownfield environments. This
means we can import the existing wireless configuration (SSIDs, dynamic interfaces,
etc) into Cisco DNA Center profiles.
As you’ve already seen, we have a WLC and an AP already deployed in our

environment. The WLC has an SSID and a dynamic interface defined. In this exercise,
Cisco DNA Center will learn the existing configuration from the brownfield WLC.

These parameters will be learnt by Cisco DNA Center and can be then reused to
provision other WLC’s.
We will then add an extra SSID to the same WLC.
To learn the configuration from the existing WLC, go to the Provision tab.
Step 15 Select the WLC and, from the “Actions” menu, select the option to “Learn Device
Config”:
Step 16 The WLC should be in the “Campus” Site. Click on “Next”:

Step 17 In this section we now see the wireless parameters learnt from the WLC. We can see
the network settings as well as the SSID with its security level. At the bottom we can
see the dynamic wireless interface.

Step 18 We are using pre-shared key in our environment. You are required to enter the pre-
shared key value. Enter “cisco123” is the passphrase field.
Step 19 Cisco DNA Center learns specific parameters from the WLC. Any additional
configuration will be discarded from the learning process. Discarded configuration
is not learnt from the WLC but it’s not removed from the WLC. The discarded
configuration is shown in this section. Click on “Next”:

Step 20 The next step is adding the learnt configuration into a network profile. Network
profiles are associated with sites. Network profiles have different features defined.
Every time we go through the provision workflow, Cisco DNA Center leverages the
parameters defined in the Network Profile.
By adding these parameters in a network profile, we can them reuse them across
our network, greatly simplifying the roll-out of wireless services.
Cisco DNA Center offers a profile name. We will change it for “Wprofile”. Once done,
click on “Save”:

Step 21 Go to Design  Network Settings  Wireless tab. This is where wireless parameters
are defined. We can see the SSID and dynamic interface that we learnt from our
WLC:

Step 22 For this exercise, we will be adding a new SSID as well as a new dynamic wireless
interface. In the “Wireless Interfaces” section, click on “Add”

Step 23 Enter the following parameters for the wireless interface:
Interface Name: wireless-dnac

VLAN ID: 23
Step 24 Let’s say we want to have a consistent SSID across our entire enterprise network
which consists of numerous sites. We can leverage Cisco DNA Center to deploy
wireless services consistently across the network. In order to do this, we use
network profiles. In previous steps we automatically created the “Wprofile” wireless
profile. In order to leverage the profile, we need to assign it to the site. Go to the
learnt SSID and click on “Edit”

Step 25 Click on “Next”
Step 26 Notice there are no sites assigned to the profile. Select “Edit” to add the sites:

Step 27 Notice that the proper dynamic wireless interface has been populated automatically.
Select the sites as per the snapshots below. Click on “Save”:

NOTE: Another option to add the site configuration is from the “Network Profile” tab.
Step 28 Make sure you click on “Finish”:

Step 29 You can create the SSID at the global level or at the regional level in the hierarchy.
We will create the SSID at the global level. We will now create a new SSID for
Enterprise wireless services, select “Add” as shown below:
Step 30 Enter the following parameters for the Enterprise SSID:
SSID: ciscolive
Security: WPA2 Personal
Pre-Shared Key: cisco123
Site: Campus, Branch, Floor1
Wireless Profile Name: Wprofile
Fast Transition: Disable

Step 31 Click on “Wprofile”. The pop-up window will show up. Make sure you select a non-
fabric deployment and the wireless-dnac interface. Once you save the configuration,
click on “Finish”:

Step 32 Confirm that the Enterprise Wireless Network has been added successfully:

Step 33 To recap, we learnt an SSID and wireless interface from the existing brownfield WLC.
We also defined a new SSID and wireless interface. Both these SSID’s are now part
of the Wprofile configuration.
Now we are ready to deploy wireless services across our network. In this lab network,
we have a single WLC which we will use for demo purposes. For production networks,
you can use the same profile to deploy wireless services across your entire network.
You can have the same profile across your network, or use different profiles on
different areas of the network based on specific characteristics.
As you note, once we learn the configuration from the brownfield devices, we need to
re-deploy this configuration for the device to become fully managed by Cisco DNA
Center.
Go to the “Provision” tab, locate the WLC and click on “Provision” in the “Actions”
menu:
NOTE: Since our network is small, we can easily find the devices. For larger networks, we can leverage
filtering capabilities. If you want to test these out, search for “Wireless Controller” in the “Device Type” field
Step 34 Confirm that the WLC is in the correct site, Campus, and Click “Next”:

Step 35 In this step, we will first specify the site where the AP’s managed by this WLC are
located. In our lab, they are located in Branch/Floor1. Click on “Save”

Step 36 Once that’s done we will define the parameters for the dynamic wireless interfaces.
Click on “Add”
Step 37 Complete the pop-up window with the following values:
Interface Name: wireless-data

Interface IP address: 10.1.22.2
Mask: 24
Gateway IP address: 10.1.22.1
Port Number: 1

Step 38 Click on “Add” for the second interface:
Step 39 Complete the pop-up window with the following values:
Interface Name: wireless-dnac

Interface IP address: 10.1.23.2
Mask: 24
Gateway IP address: 10.1.23.1
Port Number: 1

Step 40 Confirm that all parameters are correct and click “Next”:
Step 41 Click “Next”:
Step 42 Check the parameters that will be deployed into your network. Scroll down and click
“Deploy”:


Step 43 Select “Run Now” and click “Apply”:
Step 44 Wait for the messages that the configuration has been successfully deployed.
Step 45 (Optional) You can also log into the WLC GUI to confirm that the provisioning has
been successful:

Step 46 In the next step, we will be configuring the Access Point. Go to the “Provision” tab,
mark the access point and select “Provision” in the “Actions” menu:

Step 47 We will select “Branch/Floor1”. Once done, click on “Next”:
Step 48 You can select from the RF Profiles that are included in Cisco DNA Center by default.
You can also define your own RF profile. In this lab, we will select the RF profile
“TYPICAL” and then click on “Next”:

Step 49 Review the parameters for each access point and then click on “Deploy”. When
prompted, select to “Run Now”. Also, when prompted about the need to reboot the
AP click on “OK”:

Step 50 Confirm that the Access Points have been successfully provisioned:
Step 51 (Optional) Log into the WLC and make sure the AP’s are associated with the correct
AP Group (note that the last 5 characters in the AP Group name are random so these
will vary from your view):
NOTE: Make sure you see ap2 in the current AP Group before going to the next step. This make take a few
minutes.
Step 52 (Optional) Check the “Clients” tab to see that you have clients associated to the new
SSID:

In later exercises, we will review the insights generated by Cisco DNA

Center’s analytics engine in Assurance. For this purpose, we need to
configure telemetry in the network devices. From the main
Dashboard, scroll down to the “Tools” section. Select the “Telemetry”
tab:
Cisco DNA Center supports the collection of multiple types of network device
telemetry including: Syslog, SNMP, SNMP Traps, Netflow and streaming telemetry
via a REST based API. Streaming telemetry is currently only available for the
Wireless LAN Controller.
From the main Dashboard, scroll down to the “Tools” section. Select the “Telemetry”
tab:
Step 53 This page lists the default Telemetry Profiles on the system. Click on next to the
“Maximal Visibility” profile to review the standard settings

Step 54 By default, in the “Maximal Visibility” Telemetry Profile, Syslog, SNMP Traps and
Netflow are configured on network devices. This profile is not suitable for all devices
in our lab since Netflow can only be automatically configured on routers running IOS
16.x or newer. We will be creating custom Telemetry profiles.

Step 55 Click on “Add Profile” and create a custom Telemetry Profile for switches with the
following settings.
Profile Name: Custom_Switch_Max

Syslog: Informational
SNMP Traps: V2C
Netflow: Disabled

Step 56 Click on “Add Profile” and create a custom Telemetry Profile for routers with the
following settings.
Profile Name: Custom_ISR_Max

Syslog: Informational
SNMP Traps: V2C
Netflow: Disabled
Step 57 Click on “Site View”
Step 58 Now we want to apply the Telemetry Profiles we created.
Select all of the switches that were discovered on your network. Click on “Actions”
and then “Custom_Switch_Max”
Select BR-R1 which is the ISR G2. Click on “Actions” and then “Custom-ISRG2_Max”
Select HQ-R1 which is an ISR4400. Click on “Actions” and then “Maximal Visibility”.
Since this router is running IOS 16.x, the Maximal Visibility profile which has Netflow
enabled is supported. Netflow from HQ-R1 will be used to populate the Application
information in Application Health Dashboard and Application Experience in Client
360.

NOTE: Streaming telemetry is configured on the WLC once it is discovered by Cisco DNA Center. Therefore,
you do not need to configure any Telemetry Profiles for the WLC.
Step 59 Cisco DNA Center will log on to the selected devices and configure the telemetry
options defined in the profile. The configuration will look this this:
logging host <DNAC-IP>
!
snmp-server enable traps
snmp-server host <DNAC-IP> version 2c tesseract-traps
Using “Putty” you can log into one of the branch switches and confirm that the
configuration has been pushed correctly:
SSH to BR-SW2 (10.10.64.7)

Username: admin
Password: Cisco123
Enable: lab-cert
The Cisco DNA Center IP address that telemetry should be sent to is 10.1.3.230.
The system has also enabled a variety of SNMP traps.

Step 60 The Wireless LAN Controller supports streaming telemetry over a REST based https
API. Each time there is an event on the Wireless infrastructure, such as a client
associating, the WLC will push this information to Cisco DNA Center.
Using “Putty” you can log on to the WLC (10.1.5.50) and execute “show network
assurance summary”
SSH to WLC (10.1.5.50)

Username: admin
Password: Cisco123
We need to ensure:
• The correct Cisco DNA Center IP is configured (10.1.3.230)
• The WSA service is enabled
• The “Last Success” is newer than “Last Error”; and
• The “JWT Last Success” is newer than “JWT Last Failure”

Step 61 The last part of this exercise is to explore the Software and Image Management
(SWIM) capabilities in Cisco DNA Center. Cisco DNA Center provides workflows for
Intent Based Software upgrades. These workflows are based on golden images for
both the main device image as well as for software maintenance updates (SMUs).
Cisco DNA Center allows you to designate software images and SMUs as golden. A
golden software image or SMU is a validated image that meets the compliance
requirements for the particular device type.
Designating a software image or SMU as golden saves you time by eliminating the need
to make repetitive configuration changes and ensures consistency across your devices.
You can designate an image and a corresponding SMU as golden to create a standardized
image. You can also specify a golden image for a specific device role.
For example, if you have an image for the Cisco 4431 Integrated Service Routers device
family, you can further specify a golden image for those Cisco 4431 devices that have the
Access role only.
From the Cisco DNA Center dashboard, go to Design  Image Repository. Make sure,
you are located in “Global” within the network hierarchy.
Open up the arrow for Catalyst 9300 switches:
Step 62 Cisco DNA Center provides the information of all the unique software images
according to image type and version. You can view, import, and delete software
images.
From this view we can quickly see that our environment has 1 image deployed in
Catalyst 9300 series: IOS-XE 16.6.3. We have two C9300 switches in our inventory
that have this image. BR-SW1 is using bundle mode while BR-SW2 is using install
mode. Next to each image name, DNA Centre provides a number. This number
indicated the number of devices that currently has the specific image deployed.

Step 63 We can click on the number next to the image name 16.6.3. We will get information
on the specific devices running the image as well as the device role:
Step 64 In order to proceed with our exercise, we want to remind you that we defined BR-
SW1 as a distribution role and BR-SW2 as access role. Both switches are Catalyst
9300 Series, both switches currently have 16.6.3 IOS-XE image but they are both
deployed in different roles. There’s no action item in this step. But we will be using
this information to show that Cisco DNA Center allows to define golden images based
on device role:
Step 65 Even though DNA Centre is showing the images deployed in our infrastructure, not
all images are actually uploaded into image repository. An easy way to identify an
image that has been uploaded is the “trash can” icon next to the image name. If the
“trash can” icon is greyed out, it means that the image hasn’t been uploaded into
repository.
DNA Centre uploads images into image repository either by doing manual upload or
by marking an existing image as golden. We can only automatically import images
from devices, when the image has been deployed in bundle mode. DNA Centre fully
supports install mode, since it’s the recommended boot mode. However, the image
needs to be manually uploaded into repository. This fact is indicated in the message
below:
Step 66 We will first mark 16.6.3 as Golden Image for Catalyst 9300 devices deployed in
distribution role:
Step 67 For Catalyst 9300 switches deployed in the access, we want to select a new image
(16.8.1a). Since none of the C9300 deployed have IOS-XE 16.8.1a, we need to
manually upload the image. We already uploaded the image using the “Import”
option.
Select the option “Show Tasks” to see that the image has been already uploaded:

Step 68 Scroll down until you find image 16.8.1a. In this view there are a few interesting
things to note:
a) The “trash can” icon is enabled, which means the image is now in repository
b) The image we just uploaded has been correctly marked as being deployed in zero
devices
Step 69 We will now mark 16.8.1a as Golden Image for Catalyst 9300 devices deployed in
access role:

Step 70 Our environment is now ready for Intent Based Software Upgrade (golden image
driven). Click on “Update Devices”:
Step 71 This action takes us to the “Provision” section. For better visibility, we will use the
“Filter” option. We will filter the device list to show Catalyst 9300 devices only:

Step 72 Cisco DNA Center provides a specific “Preset View” to show relevant fields related
to software upgrades. Follow the steps below to set the “Image Pre-Check” preset
view. Click “Apply”
Step 73 Let’s review our goal for Intent Based Software Upgrades:
We specified that Catalyst 9300 Switches running as distribution role, should run
version 16.6.3. We specified that BR-SW1 is currently deployed in distribution role.
Also, BR-SW1 is already running 16.6.3. For this reason, the image status is showing
“UPTODATE”
We specified that Catalyst 9300 Switches running as access role, should run version
16.8.1a. We specified that BR-SW2 is currently deployed in access role. Also, BR-SW2
is running 16.6.3. For this reason, the image status is showing “OUTDATED”

Step 74 Hover on the name of the “Golden Image” to see that it’s 16.8.1a:
Step 75 Cisco DNA Center performs a series of checks to device readiness for the update.
There are a few ways to see that BR-SW2 passed the pre-checks. The first option is
to look at the “Image Pre-check Status” column and see that the value is “Success”.
The second is the green checkmark next to the “Oudated” message. Click on the
“Outdated” link to have more information on pre-checks. Cisco DNA Center checks
things like flash space, config-register, existence of startup-config, etc

NOTE: If any of the pre-checks show orange warning signs, go ahead and do a “Recheck”.
Step 76 (Optional) Using “Command Runner” from the “Inventory” tool, you can check the
IOS-XE version on BR-SW2::

Step 77 (Optional) Also take a moment to verify that both binary files for 16.6.3 and 16.8.1a
are present in flash. The reason for this, is to minimize the time consumed in this
exercise:
Step 78 Select BR-SW2. From the “Actions” menu select “Update OS Image”:

Step 79 You can schedule different times for image distribution (copying the image in flash)
and activation (reloading the device with the new image). For this lab, we will select
to perform all actions “Now””

Step 80 Image Upgrade is now in process:

Step 81 You can monitor the upgrade process by leveraging the “Upgrade Status” tab:
Step 82 Since the image is already present in flash, Cisco DNA Center will not distribute the
image to the device.
Step 83 (Optional) You can leverage the option to monitor the upgrade process directly in
the device using the Putty client in the Desktop.

Step 84 From Cisco DNA Center, confirm that the upgrade process has been successful. Cisco
DNA Center now updated the Image Status to “UPTODATE”. This makes it easier for
network administrators to keep track of devices that aren’t compliant with the
golden software version:
Step 85 (Optional) To further verify the software image, you can log into the device using
“Command Runner” from “Inventory” by running the “show version” command:




Lab Exercise 4: Cisco DNA Center Automation - Template

Editor
In the previous exercises, we tested Cisco DNA Center capabilities of rolling out standard
network changes using Cisco DNA Center’s intent-driven automation engine. This allows
network administrators to save time and avoid mistakes caused by manual configuration.
We also saw how we can seamlessly roll out policy across the network within seconds and
in accordance to Cisco CVD best practices.
Network administrators do not have to deal with the differences in command line interface
(CLI) across platforms.
In some cases, however, network administrators need to deploy customized configuration

to network devices. For this purpose, Cisco DNA Center provides a template programmer.
Template programmer core capabilities:

• The framework is ready to ensure policy CLI cannot be programmed by supporting
blacklisted commands
• Config template and rollback template
• Auto-complete gnome parser
• Provisioning: Form Viewer
• Mapped to profile to be deployed to the network
Lab Exercise Steps
Step 1 We will start with creating a configuration template for an access switch. We will use
the template for basic configuration, for example, adding a description to an
interface and adding a DHCP server. We will also do basic testing of the template-
editor capability to support variables. From the Cisco DNA Center dashboard, scroll
down to the “Tools” section. Select “Template Editor”

Step 2 Follow the steps below to create a project called “C9K-Templates”:
Step 3 Select “Add Template” within the “C9K-Templates” project:

Step 4 Assign the name “C9K-Branch-Template” to the template. For “Device Type” start
typing “9300”. Cisco DNA Center will populate the devices that match with the input.
select “Cisco Catalyst 9300 Series Switches” from the drop-down menu. For
“Software Type” select “IOS-XE”. Click on “Add”:

Step 5 The editor now becomes available to enter the commands for the template:

Step 6 The CLI commands for the template programmer are provided in the file “Template-
Programmer-Commands-POD.txt” located in the Jump PC Desktop:
Use the commands in the section called “FIRST PART”.
With these commands, we are also testing the capability to use variables in the
templates.

Step 7 Save the template from the “Actions” menu:
Step 8 After saving the template, you need to version the template. You must version the
template every time you make changes to the template. To do that, from the Actions
drop-down list, select Commit. You can enter a commit note when the Commit
window appears. If you Commit without saving the template, you will be prompted
to save the changes. Go to the “Actions” menu and “Commit”:

Step 9 Now that the template has been created, we will create a network profile. Cisco DNA
Center is leveraging profile-based deployment. Network profiles are standardized
configurations for routers, switches and WLC’s. We can design and create the profile
one and reuse across multiples sites in the network. This approach provides:
simplified network deployment, configuration consistency and integrated IT
process flows.
In previous exercises, we used wireless profiles for wireless configuration. We also

created a switching profile for device onboarding. In this exercise, we will follow a
similar process using the existing switching network profile.
The diagram below shows how we will be using the profiles:

1 DESIGN
PROFILE
DEVICE
SITE
2 PROVISION
Step 10 From the main Cisco DNA Center Dashboard, go to the “Design” menu and select
“Network Profiles”. Locate the profile with name “C9K-PnP-Branch” and click on
“Edit”:
Step 11 In previous exercises we attached an onboarding template to this profile. In this

exercise, we will attach a Day-N template so click on this tab:
Step 12 Select “Add”:

Step 13 From the “Device Type” start typing “9300” to get suggestions provided by Cisco
DNA Center. Select “Cisco Catalyst 9300 Series Switches”. Select the Template “C9K-
Branch-Template” we created in previous steps:
Step 14 Click on “Save”:
Step 15 So far, we created a template but still haven’t pushed the template to the device.
Before doing so, let’s check that the device doesn’t actually have the configuration
we will be pushing. We will be using “Command Runner” for these “show
commands”. In order to do this, we need to go to the “Inventory” tool.
Recommendation: since we will be checking the configuration a few times, we

recommend you open a second tab in the browser. Access Cisco DNA Center a second
time.

Username: admin
Password: Cisco123
Scroll down to “Tools” and select “Inventory”
From “Inventory” and select BR-SW2. From the pull-down menu select “Launch
Command Runner”
Step 16 A window for “Command Runner” will open. The selected device should be “BR-
SW2”. Add each of the commands below. Enter each command and select “Add”.
Once all three commands show up at the bottom, select “Run Command”.
show run int gig 1/0/4

show run | section dhcp
show run | section alias

Enter the commands here
Step 17 Once the results are returned, click on each command to look at the output.

Step 18 To recap, we created a template and we associated a template to a network profile.

When doing Plug and Play we already associated the network profile to a site (which
in turn associates the network profile to the devices in the site). We are now ready
to push the template to the devices.
Leave the tab with “Command Runner” for later use. From the original Cisco DNA
Center tab, go to the “Provision” menu, select the branch switch BR-SW2. From the
“Actions” menu, select “Provision”:

Step 19 We will follow the same workflow we used for standard network provisioning:

Step 20 Continue the workflow for provisioning:
Step 21 In the “Advanced Configuration” step, the template we just created is showing up.
Make sure the BR-SW2 is selected. Since our templates has variables, we need to
provide the values for those fields.
Interface: Gigabitethernet 1/0/4

Description: Description pushed by DNAC v01
Click “Next”:
Step 22 We can see the template as part of the configuration tasks. Click on “Deploy”. When
prompted select to deploy the configuration now:


Step 23 Once you receive the message that the configuration has been successful, go back to
the browser tab where you ran “Command Runner”
Run the commands again and check the results:

Step 24 We will now test what happens if we change the content of the template. Go back to
the “Template Editor” and select the template we just created:

Step 25 In this step we will add an extra “alias exec” command to the template. You can
Copy & Paste all the commands from the file called “Template-Programmer-
Commands-POD.txt” located in the Jump PC Desktop. Use the commands in the
second part of the file. You can also choose to add the single last command.

Step 26 Select “Save” from the “Actions” menu:
Step 27 Select “Commit” from the “Actions” menu. Check how the second version of the
template is created:

Step 28 Before pushing the template into the devices, we will take a moment to view the
versioning that Cisco DNA Center is doing with the different template changes:

Step 29 From the “Provision” menu, we will select BR-SW2 device. Since we made changes
to the template, we can see that the device is being flagged as “Out of Date”:
Step 30 Once again, we will follow the same workflow we used for standard network
provisioning:

Step 31 In the “Advanced Configuration” step, the template we just created is showing up.
Make sure the template is selected. Since our templates has variables, we need to
provide the values for those fields.
Interface: Gigabitethernet 1/0/4

Description: Description pushed by DNAC v02
Click “Next”:

Step 32 Click “Deploy”:
Step 33 Once you receive the message that the configuration has been successful, use
“Command Runner” and check that the configuration has effectively been deployed:




Lab Exercise 5: Cisco DNA Center Automation -

Application Policy
Description and objective
Application Policy enables customers to deploy quality of service (QoS) policies consistently
across the network. It also provides a layer of abstraction, which allows customers to focus
on the business policy leaving Cisco DNA Center to figure out the differences in
implementation among network devices.
Using Cisco DNA Center, we can apply these policies to a single site or to multiples sites at
once. Cisco DNA Center pre-populates the application registry with 1400+ applications. All
these applications are already categorized in the right traffic classes. Customers can create
their own custom applications as well.
Cisco DNA Center takes your business intent on QoS policies, translates them into the proper
device configurations, and deploys the configurations onto those devices.
Lab Exercise Steps
Step 1 Before we start with this exercise, we will go through terminology that will allow us
to better understand QoS policies. We will use the concepts below throughout this
exercise.
A QoS policy defines how network traffic should be handled so that you can make the
most efficient use of network resources while still adhering to the objectives of the
business (such as guaranteeing voice quality meets enterprise standards or ensuring
a high Quality of Experience (QoE) for video). To achieve these goals, a policy
comprises the following elements:
Applications—Software programs or network signaling protocols that are being

used in your network. Cisco DNA Center includes the NBAR2 application library of
approximately 1400 distinct applications.
Traffic Classes—Groups of applications that make configuring policies easier,

because the groups contain applications that have similar traffic needs.
Business-relevance—Attribute that classifies a given application according to how

relevant it is to your business and operations. The attributes are business relevant,
default, and business irrelevant.
Cisco DNA Center comes with the Cisco NBAR2 applications preconfigured into
application categories and sorted into business-relevancy groups. You can apply this
preconfigured policy to your network devices, or you can modify it to meet the needs
of your business objectives and your network configuration.
For example, YouTube is set as 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 change this
business-relevancy setting to business-relevant to align with their business
objectives.
You can configure QoS in your network using application policies in Cisco DNA Center.
Application policies comprise these basic parameters:
Application Sets—Set 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.
Site Scope—Sites to which an application 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.
Step 2 From the main dashboard, select Policy:
Step 3 We will land in the “Policy” dashboard. This section is all about Application Policy and
QoS. Click on “Application”:

Step 4 We will land in the “Application Policy” dashboard. Before creating policies, we will
be checking the application registry first. Select the “Applications” tab.
By default, Cisco DNA Center provides a large number of applications with their
corresponding signatures pre-loaded. For each application Cisco DNA Center has a set
of preconfigured rules to identify the application as well as the correct traffic class for
such application. Later in this exercise, we will see that by default, applications are
grouped into logical groups called “Application Sets”:
Step 5 To see an example on the pre-loaded application signatures, we will look into the
“Exchange” application. In the search box, type “Exchange”:

Step 6 We can see how Cisco DNA Center is already programmed with hundreds of
applications signatures. For each application, we can see how that application is being
identified in the network, what “Application Set” the application belongs to as well as
the correct QoS traffic class. Take a look at the “Exchange” application and then close
the window by clicking “Cancel”:
Step 7 As mentioned before, Cisco DNA Center provides logical groupings for applications
for easier management. These groupings are call “Application Sets”. Let’s take a looks
at these by clicking the “Application Set” tab. We will see that “Exchange” is part of
the “Email” Application Set.

Step 8 Even though Cisco DNA Center is already programmed with hundreds of application
signatures, there are environments where we need to define our own custom
applications. For this exercise, we will create our own custom video application as
well as our own “Application Set”. To create a new application set, select “Add
Application Set”
Step 9 When prompted type Custom_Video_Set as the name of the “Application Set” and click
“OK”:

Step 10 Confirm that your custom application set has been added successfully:
Step 11 Go back to the “Applications” tab. We will be creating our custom application and we
will place the custom application in the Custom-Apps application set. Select “Add
Application”:
Step 12 Enter all the parameters for the new custom application:
Application Name: Custom_Video

Type: Server IP/Port (Select IP/Port Classifier)
IP/Subnet: 100.100.100.100
Protocol: UDP
Port/Range: 5004
You now have the option to manually input the QoS Traffic class. However, this might
not be known. If this is the case, we can indicate that this application is similar to
another application that already exists in the registry. By doing this, the traffic class
will be populated on our behalf. In this example, we are going to indicate that the
new custom application is similar to “telepresence-media”. Please note that once we

start typing, Cisco DNA Center will populate the application list that matches the
characters entered.
Step 13 We are going to place our newly created application in the “Custom_Video_Set”
application set that we created a few steps back. Confirm that all parameters are
correct and select “OK”:

Step 14 Make sure the registry is sorted by “Traffic Class”. Look for the “Real Time Interactive”
traffic class. You should see two applications: telepresence-media and Custom_Video:

Step 15 You can also make sure the “Custom_Video_Set” contains the new custom application.
Do this in the “Application Sets” tab:
Step 16 Now that our application registry has been completed we are ready to create our
application policy. Navigate to “Application Policies” tab and select “Add Policy”

Step 17 We saw that all applications in the default registry have been assigned to application
sets. These application sets have also been categorized by default into three buckets:
business relevant, business irrelevant and default. We can change these defaults by
dragging and dropping each application set into another bucket.
Custom Application Sets are not assigned business relevance by default. Scroll down
to the bottom to the page and look for the “Unassigned Application Sets”. Click on
Custom-Apps application set and drag it to the “Business Irrelevant” column

Step 18 Confirm that the Custom-Apps application set is now on the “Business Irrelevant”
column
Step 19 Next step is to define which portion of the network to roll out this policy. Click on “Site
Scope”. In this case, we will deploy our application policies in our Branch site.

Step 20 Assign a name to the policy. Let’s use “Branch-App-Policy”.
Step 21 We are now ready to deploy our QoS policy in the branch site. Before doing so, we can
optionally preview and pre-check the configurations that will be pushed to the
network devices. We will check out these capabilities by selecting “Preview Changes”.

Step 22 We will now see a list of all devices in our scope. For each device, we can generate and
view the changes. We will select a router and a switch.
In both cases, look at how different configurations are being pushed to different
network devices. Also find our custom application in the configuration being pushed.
Once you look at the configuration for both devices, make sure to select “Back to all
devices:”


NOTE: ISR Routers and Catalyst switches have very different QoS capabilities. Note that we didn’t have to
analyse these capabilities nor figure out the different commands and implementation. We only needed to
define our business intent and Cisco DNA Center figures out the correct QoS implementation based on each
device capabilities. Cisco DNA Center leverages the information on each network device stored in its
inventory. This level of abstraction makes Cisco DNA Center extremely powerful.
Step 23 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.
We are going to test this capability by clicking on the “Pre-Check” button:


Step 24 Since the pre-check was successful, we are now ready to deploy the policy. Click on
“Deploy”. We can deploy the policy now or we can schedule for a later time. We will
be running it now:
Step 25 You can now follow up the progress of the policy deployment. Once all the devices
have been successfully deployed, we will check out the changes in the configurations.


Step 26 Use “Command Runner” to look at the configuration pushed by Cisco DNA Center.
Putty to ssh into the different devices and check the QoS config pushed by Cisco DNA
Center. From Inventory, select switch BR-SW2 and launch command runner:
Step 27 Since we defined that our custom application is “Business irrelevant”, this application
will be marked in the Scavenger class. Look for the ACL for the Scavenger class and
find the access control entry for our custom application.
For this purpose, add and run the following commands:
show ip access-list DNA-APIC_QOS_IN#SCAVENGER__acl

show ip access-list DNA-APIC_QOS_IN#REALTIME__acl

Enter the commands here
Step 28 When Command Runner returns the results, click on each of those results. You will
see the ACL for our custom application within the Scavenger class. You will see that
the Realtime ACL is empty.

NOTE: Command Runner typically opens up in a new tab within the browser. Leave that tab opened since we
will be using it again in future steps. You will not have to re-type the commands..
Step 29 Let us assume that the custom application we created earlier now does support our
business. For this reason, it should have been classified as business relevant. We will
go ahead and adjust the policy. Go back to the policy section in the Cisco DNA Center
dashboard. Select the policy we created and use “Edit” in the “Actions” tab:
Step 30 Find “Custom-Video-Set” application set. Drag and drop into the Business Relevant
category:

Step 31 Before deploying the changes, we are going to do a Pre-Check to make sure the
changes will be successful. Select “Preview” and then “Pre-Check”:

Step 32 Select “Deploy” to push these changes to the network devices.

Step 33 Monitor the roll out of the policy until all devices have been successfully deployed.

Step 34 Let’s go back to the Command Runner tab that is already opened in your browser. Re-
run the same commands as before. You can do so by clicking on the “Go Back” button
at the end of the page.
Once you run the commands, you will see that the custom application is no longer in
the Scavenger class but in the Realtime class.



Lab Exercise 6: Cisco DNA Center Assurance Use Case

#1: Network visibility
DNA Assurance uses network insights to optimize network performance and deliver the best
user and application experience. The advanced analytics engine built in to Cisco DNA Center
receives the network telemetry that you set up earlier in this guide, and conducts stream
processing, correlation and analytics to provide the visibility into the network.
DNA Assurance aims at providing a compact, easy to leverage, yet multi-level view into the
network. This view is divided into two main areas, Client Health and Network Health.
Client Health - When hundreds or thousands of clients are present in the network at any
time, providing a view to each client is often considered as noise. You need to know the
general state of the clients, which includes visibility into the number of clients that are in
good health and a way to determine which clients’ health has degraded and require attention.
Network Health - You are likely not only concerned with the health of clients connecting to
their network, but also with the health of the network infrastructure itself. Every network
device has KPI details including CPU, memory, temperature, control plane and data plane
statistics, monitored. The result of these KPIs is a generated health score in DNA Assurance
to help you easily identify issues.
There is also the Application Health dashboard which provides an insight into what types of
applications are running over the network, and how well they are performing. A health score
is derived for each application which is based upon packet loss, network latency and
application server delay.
The aim of this exercise is you orient you around the DNA Assurance interface.
Lab Exercise Step
Step 1 Select the “Assurance” section in Cisco DNA Center dashboard.
Step 2 Review the Overall Health page.
The Overall Health page gives you a quick view into the health of the wired and
wireless Clients and Network devices.
(1) You can hide or unhide the table view as well as switch between table and map
view
(2) Clicking on the icon next to the location the Map view takes you to the client
health page for that location.

(1) Client health score provides an indication of how many healthy client devices are
on the network
(2) Network health score provides an indication of how many healthy network
infrastructure devices are on the network
(3) If there is a major issue that has occurred on the network, it will be listed here.

Step 3 Select “View Client Health” under client in the Overall Health Summary
Step 4 It is possible to filter the view based on time which allows you to zoom in to periods
of reduced health scores so that you can understand what caused the score to dip.
Move the slider to a time that you want to focus on. The data below will change based
on the time you selected.

Step 5 Review the Client Health page.
(1) The Client Health Summary is divided into Wireless and Wired clients
(1) Client Onboarding Times monitor how long it takes for a wireless client to go
through the Association, AAA, and DHCP process, and for a dot1x enabled wired
client to go through AAA and DHCP. If there was a threshold breach or onboarding
failure, this allows you to identify which one of these onboarding steps caused it.
(2) Connectivity RSSI displays the RSSI data for wireless clients on the network and
highlights clients with poor RF
(3) Connectivity SNR provides insight into the signal to noise ratio for wireless clients
There are several other dashlets on this screen. Feel free to click on “View Details”
to explore any of these further.

Step 6 Change the Client Devices table filter so that you can see all the devices on the
network. Click on Type: All, Health: All and then Apply.
Here you can see all of the devices on the lab network with their corresponding health
score. UserID is only available on wired ports and SSIDs with 802.1x authentication
enabled and Device Type is available for wireless clients profiled by the WLC, or Wired
clients if ISE integration is configured.

Step 7 Select the wireless client in your pod to go to Client 360.
(1) The current health score for the client and username (if known). In this lab, the
username is not available since PSK authentication is used. Hover over the “I” next
to the health score to get more information on how the score is calculated.
(2) If this user had multiple devices logged on to the network, we will see them listed
in tabs here. This correlation is only possible with 802.1x username-based
authentication
(3) The health chart provides a health score view of the past 24 hours by default and
can be customized. Hover over any period in the chart to see what metric caused
the change in health score. Client events are also represented at the bottom of the
chart

(1) The onboarding status of the client is displayed here showing whether AAA and
DHCP was successful. The chart provides a view on how the client is connected to
the network and it is possible to see the health score of the client, as well as the
health score of the AP and WLC.
(2) Event viewer will display the client events from the WLC such as Association,
DHCP, etc. Click on an event to see more information.
(1) We will set up a path trace and review Application Experience in the next section
(2) At the bottom of the page, more detailed information about the client is available.
Click on “Connectivity” and then “RF”.

Step 8 Navigate to the Wired Client that is located at the Branch. We are going to look at
what Application data is being collected for this device. You can find the client
manually on the Client Devices table in Client Health, or search for a client in the
10.10.64.0/24 subnet.

Scroll down to Application Experience in client 360 to review the applications running on the
client. Click on the business irrelevant and Default tabs to see more applications.
Application experience allows you to monitor business critical applications through qualitative
insights. NBAR2 is used to get visibility into 2400+ applications.
Step 9 Navigate to the Application Health screen by clicking on Health and then Application.

Step 10 Review the Application Health page.
The Application Health Page will allow you to troubleshoot application experience issues
and performance metrics in App 360 views. Applications are classified using NBAR2.
(1) The part of the page provides insight into how the Business Relevant Applications
are performing
(2) A view of the Top 10 applications by usage
At the bottom of the page under Application, Click on “24 Hours”, Type: “All” and then
Click “Apply”
(1) After you change the filter, you will see a list of applications that are running on
this network. Information such as Class, Usage, Throughput and Latency are
available for each application. Health scores are only able to be calculated for TCP
based applications.

Click on an application such as “SSH” to review the Application 360 page.
(1) A view of the application’s health score over the past 24hours is plotted on a chart.
You can highlight over any point of the chart to see how the health score was
calculated
(2) This section provides information about how well the application is performing
between different locations. This lab does not have a large network topology so
there is only one location in the list

Select the router to see the application statistics for that site.
Step 11 Navigate to the Network Health screen by clicking on Health and then Network.
Step 12 Review the Network Health page.
Information on the Network Health page is divided into the device role – Core, Access,
Distribution, Router and Wireless. The latest tab gives you the data for the last 5 minutes
and Trend gives you data for the past 24 hours.

Scroll down on the network health screen to see the AP analytics dashlets. Change the band from
2.4 to 5 Ghz on the Top N AP’s by interference to see if the data is there.
Step 13 Change the Network Devices table filter so that you can see all the devices on the
network if not already there. Select the tabs as shown and you will get a popup for
the Apply button. Click on it to set the filter.
Now you can see all of the network devices on the lab network with their corresponding health
score. If there is a device with a health score lower than 10, please feel free to explore and see if
you can find out why.




#2: Troubleshooting
One of the primary goals of Assurance is to help you quickly identify the root cause of issues.
This is achieved by providing an end to end visibility of the network, highlight potential
issues, and when an issue is identified, provide a list of suggested actions to help resolve the
issue.
In this exercise, you will get to experience what it is like troubleshooting issues in Assurance.
There will be two scenarios which you will go through today:
• Global issue
• Client not able to reach a website
Lab Exercise Steps
Step 1 Telnet to BR-R1 in your pod and do a shut and then no shut on the GigabitEthernet
0/0/2 interface. Wait for a minute or so and you should see the issue in the Overall Health
Page
Step 2 Click on the Assurance menu and scroll down to see the Top 10 issues. The first issue
we are going to troubleshoot is a Global issue which is listed in the Top 10 Issues on the
Overall Health page. Click on Interface issue to open the Issue Detail.

Step 3 In Issue Detail, suggested actions are provided to help you troubleshoot the issue. On
certain issues, such as this one, guided remediation is possible directly in the Cisco DNA
Center interface, without having to log on to any network devices.
Go through the suggested actions and click on “Run” to execute the recommended
steps. If the interface is shutdown you will see it here.
Step 4 The next issue we are going to troubleshoot is based on a call IT Service Desk received.
“Jane Baker” is having an issue reaching the HR team’s secure website at
https://10.1.64.11. Her laptop is connected to wired network and has obtained the IP
address 10.1.20.11.
Go to AssuranceHealthClient to get to the health dashboard

Scroll down to the bottom of the screen to see the client list and click on the client 10.1.20.11
MAC address.
This is the Client 360 page which is available for all clients on the network. In this example,
Jane’s laptop currently has a score of 10/10 and no issues are logged.
Step 5 Since no issues are logged, we are going to test the end to end network reachability
between Jane’s laptop and the secure HR team website using Path Trace. Click on “Run
New Path Trace”

Step 6 To set up the path trace, enter the values from the snapshot below. When finished,
click “Start”.
Source IP: 10.1.20.11

Destination IP: 10.10.64.11
Destination Port: 443
Protocol: TCP
Include Stats: Device and Interface

The result of the path trace will show you the end to end path between the source and
destination and will highlight potential problems such as interface errors/drops and ACLs.
In this example, it looks like we are being blocked by one ACL, and being permitted by
another ACL.
Step 7 To find out more information about the ACL that the trace is denied by, click on the
router.



#3: Proactive Monitoring - Sensor
On a typical network, clients are not always using all the services that the network provides, and
are not always in all locations. Sensors can represent clients in times or locations where clients
are not present, or test services that clients are not currently using. This allows you to
proactively test the network to ensure
When a sensor connects to the network to perform the tests configured, it first needs to go
through the onboarding process which is comprised of Association, AAA, and DHCP. This
step proactively tests the availability of the network’s wireless infrastructure at that location,
AAA services, and DHCP services. Once the sensor is onboarded, it can test the reachability
to other services on the network.
The aim of this exercise is run through the steps required to configure a sensor test and view
what tests are available.
Lab Exercise Steps
Step 1 In any Assurance page, click on “Manage” and then “Sensor-Driven Tests”.
Step 2 Click on “Add Test”.

Step 3 We need to define some of the settings and select the SSID that we will run tests on.
Enter the values from the snapshot below. When finished, click “Next”.
Test Name: Branch-Sensor-1

Location: Global/USA/Branch/Floor1
Interval-Hours: 30 Minutes
Radios to Test: 5Ghz on SSID apic-<POD#>
Credentials: cisco123
Step 4 On this page you can view the sensor tests that you can run. After viewing the tests
please click on Cancel to exit out of the task.


You can proceed to the next section …

Lab Exercise 9: Cisco DNA Center Platform-

Northbound APIs
Exercise Description and Objective
Cisco DNA Center Platform opens the automation and assurance capabilities of Cisco
DNA Center for a tight ecosystem integration. Cisco DNA Center Platform exposes
northbound Intent APIs for developers to integrate Cisco DNA Center into their workflows.
The Platform capabilities of Cisco DNA Center also include a Software Development Kit to
integrate 3rd party devices, as well as integration with IT Systems such as ITSM and other
network domains (see graphic below).
Platform Capabilities – APIs, Adapters & SDKs

Intent APIs
IT and Network
System Process • Assurance • Network Inventory /
Discovery
• Path Trace
• Topology
ITSM • Command Runner
• Plug- n- Play
• Template
IPAM
Programmer • Software Image
Reporting Management
(SWIM)
X- Domain Integration
3 rd Party SDKs Networking
Map 3 rd Party Network Devices to Data Model

Level 1 Operations
© 2018 Cisco and/or its affiliates.support:
All rights reserved. Cisco Confidential Global
Discovery, Inventory, Topology, Availability, Command Runner S a l e s Tr a i n i n g
In this section, you will take a few moments to explore the API information available in the
GUI and work through a few key initial use cases. This lab assumes some knowledge of
programming and exposure to basic API concepts (i.e. REST API calls, webhooks, etc).
The APIs are self-documented right in the GUI and on the Cisco Developer Network
(DevNet):
https://developer.cisco.com/docs/dna-center/#overview
The Cisco DNA Center Platform became generally available with the release of Cisco DNA
Center version 1.2.5 APIs will be released as part of the upcoming releases.
Lab Exercise Steps
Step 1 In the Cisco DNA Center UI, click on the Platform tab at the top of the screen
to access the Cisco DNA Center Platform page.

On the Platform page, select APIs from the Developer Toolkit drop-down menu to
view the DNA Center APIs and their documentation.

You can view the APIs in the API Catalog since the APIs have already been enabled in
the Bundles tab with the activation of the Cisco DNA Center REST API bundle. If this
bundle had not been enabled, you would not see the APIs.

Step 2 Click on the Authentication tab and note the Authentication API. You will use this
later in the exercise.

Step 3 Take some time to look through the different APIs that DNA Center currently exposes.
Notice that some of the APIs are marked with an Intent superscript. Known as Intent
APIs, these APIs condense multiple API calls into a single API call that communicates
business intent. Click on Know Your Network > Networks to view the Get Overall
Network Health API.
Step 4 Click on the Get Overall Network Health API to view details about the API, including
the API endpoint and a description of the action that this API call performs.

Notice that this API call is a GET request with the url /dna/intent/api/v1/network-
health.
Also notice that this tab contains the Parameters for the API call, as well as the
Responses and Model Schema.

Step 5 Click on Code Preview to view the API call in a programming language of your choice.
The below example shows how this would look in Python.
Step 6 Next to the Code Preview button is a Try It button where you can make the API call
from DNA Center. Click the Try It button to view additional information about the API
and make the API call from DNA Center. Go to https://www.epochconverter.com/ to
get the epoch timestamp (in milliseconds) at which you wish to see the health of the
network.

When you are ready, click Run to make the API call and view information about
network health from Assurance.

Run Assurance Script using Python (Optional)
In this exercise, you will work with some sample scripts that extract Assurance data from
Cisco DNA Center.
Python and Script Details
This script requires Python 3 to run. You should already have Python 3 installed on your
remote desktop.
The script has already been downloaded for you from the following link (where you can find
additional documentation on the scripts): https://github.com/CiscoDevNet/DNAC-
Assurance.
You can access this script from the cl-emear-2019 directory in the Command Prompt:

Step 1 Open the scripts in Sublime using the subl command in the Command Prompt as
pictured below:
You will find the files required to run these scripts in the DNAC-Assurance directory within
the cl-emear-2019 directory. First, modify the dnac_config.py file to reflect the IP address,
username, and password for the cluster in your lab setup (here 10.1.3.230, admin/Cisco123).
Step 2 In the assurance.py file, notice the parameters available when running the scripts.
You will use these parameters when running the script from the command prompt
but do not need to modify them now.

• –-mac allows you to enter a device MAC address

• --deviceName allows you to enter a device name
• --timestamp allows you to enter a timestamp
• --raw provides raw JSON data as the output
• -v provides verbose output
Step 3 Run the scripts in the assurance.py using your computer’s prompt for Python 3 (i.e.
python3 or python)*. Play around with the various parameters to see output for
different API calls. For example, you can find information about a client in the Client
360 in Cisco DNA Center Assurance.
*
To check the version of python used with the python command, type python --version in the
command line. The same works for the python3 command.
This sample API call gets more information about the client at a given time (in epoch
milliseconds ; refer to the above documentation to get the timestamp in epoch miliseconds):
Make API Calls Using Postman (Optional)
In addition to writing custom scripts, it is possible to make DNA Center API calls using API
clients such as Postman.
Postman Details
Postman is a desktop application that can be used to make API calls to various applications.
Postman is already installed on your remote desktop.
Postman Collections are an easy way to share groups of API calls. The Postman Collection for
this exercise is already installed on your remote desktop.
Step 1 In Postman, click on the Site-hierarchy Postman Collection to open the collection in
Postman.

Step 2 Select Basic Authentication and enter the username and password for the cluster
(admin/Cisco123).
Step 3 Click on the Login POST request. This POST request generates a token that allows you
to log in to DNA Center. The IP address of your cluster should already be populated.
Click Send to send the POST request. View the token in the response and copy the
token.

Step 4 Click on the Get Site Health GET request in Postman. Again, enter the IP
address in the URL. Create an epoch timestamp (in milliseconds) using the
above mentioned tool. Enter the timestamp into the Params field and paste
the token copied in the previous step into the X-Auth-Token field in the
header as shown below:

Step 5 Click Send to view the Site Health for all the sites in the cluster, as shown
above.

You can proceed to the next section …
Lab Exercise 10: Cisco DNA Center Platform- Events

and Notifications
In this section, you will learn how to configure Cisco DNA Center to send events to third-
party systems.
The DNA Center Platform provides the ability to publish event notifications that enable
third party applications to listen to any issues detected by Cisco DNA Assurance, Cisco
DNA Center System level and task based operational notifications, and more.
The platform provides the ability to receive custom notifications when events are
triggered. This is valuable for third party systems that would like to take business actions
based on the type of event. For instance, when some of the devices in the network are out
of compliance, a custom application may want to receive notifications and execute a
software upgrade action.
Imagine performing automation workflows on Cisco DNA Center which require a

stipulated time. In a vanilla environment, an end application may poll Cisco DNA center
frequently to get a status update for the task. By subscribing to the task completion event
and receiving notifications, polling can be completely avoided. This allows you to
optimize the extra network and compute costs involved with polling resources.
In order to receive events and notifications, a user must provide a receiving URL (also
called as Webhook call back URL). Cisco DNA Center Platform can then publish events to
the call back URL via HTTP POST information.
Webhook Details
This exercise uses a 3rd party webhook https://webhook.site. The webhooks exposed
by this site do not require a username or password, so use whatever one you want in the
Cisco DNA Center required field for username and password (i.e. ‘username’, ‘password’
works well).
Step 1 In the Cisco DNA Center Platform Portal, click on Bundles under the Manage tab.

Step 2 Navigate to https://webhook.site and create a REST endpoint to point the API
bundle toward.
Step 3 DNA Center Platform exposes REST APIs that allow you to send Network and
Software Image Management events to 3rd party REST endpoints.
On the Bundles page of DNA Center Platform, click Configure to enable and activate
the Network Events for REST API Endpoint bundle. The webhook that you created
will not require authentication, so enter whichever username and password you wish
to use in the field below the webhook url.


Step 4 On the Configurations page, select the Assurance issues that you wish to send
data to the REST API endpoint. Click either on all of the issues or on the WLC issues
at the bottom of the list. Click save when you are finished.

Step 5 On the Integration Flows page, schedule the APIs in the Network Events for
REST API Endpoint bundle to send data to the REST endpoint. Schedule the
integration flow to run every 15 minutes, starting some time within the next few
minutes.

Step 6 Once the integration flow has run, view the response at the REST endpoint.
Step 7 Copy and paste the JSON data into https://jsoneditoronline.org/. Click the indented
paragraph button on the left to format the data.


 End of Exercise and Lab: Congratulations! You have completed the lab
Please inform your instructor and complete the survey …

A Practical Look at Cisco DNA Center

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Practical Look at Cisco DNA Center

Uploaded by

Copyright:

Available Formats

Cisco DNA Center Lab Guide

A Practical Look at Cisco DNA Center: A better way to manage your

Julia Guenther, Technical Marketing Engineer, Cisco Systems

Peng Xu, Technical Marketing Engineer, Cisco Systems

Prem Chandran, Technical Marketing Engineer, Cisco Systems

Jim Galvez, Technical Solutions Architect, Cisco Systems

Cisco DNA Center

• Simplify network management: Manage your enterprise network over a centralized

POD Assignment and Access to POD

Each POD includes:

1. Multiple network devices (refer to the topology diagram)

2. Cisco DNA Center appliance

NOTE: Every 2 students will share 1 POD.

Copyrighted Cisco® Systems Inc. January 2019 2

This hand on lab consists of the exercises below:

• Lab Exercise 4: Cisco DNA Center Automation - Template Editor

• Lab Exercise 5: Cisco DNA Center Automation – Application Policy

• Lab Exercise 9: Cisco DNA Center Platform- Northbound API’s

Access your POD

The instructor will provide the lab access information.

Lab Exercise 1: Starting with Cisco DNA Center –

and device-specific configurations required by the different types, makes,

Copyrighted Cisco® Systems Inc. January 2019 5

Copyrighted Cisco® Systems Inc. January 2019 6

Copyrighted Cisco® Systems Inc. January 2019 7

Copyrighted Cisco® Systems Inc. January 2019 8

Site Specific Values

Copyrighted Cisco® Systems Inc. January 2019 9

Copyrighted Cisco® Systems Inc. January 2019 10

Copyrighted Cisco® Systems Inc. January 2019 11

• Delete: Deletes the selected devices from inventory

Copyrighted Cisco® Systems Inc. January 2019 12

Copyrighted Cisco® Systems Inc. January 2019 13

Copyrighted Cisco® Systems Inc. January 2019 14

Copyrighted Cisco® Systems Inc. January 2019 15

By discovering the network, Cisco DNA Center will gain comprehensive

Copyrighted Cisco® Systems Inc. January 2019 16

 End of Exercise: You have successfully completed this exercise!

Copyrighted Cisco® Systems Inc. January 2019 17

Lab Exercise 2: Day 0 provisioning with Network Plug

The Cisco Network Plug and Play solution offers:

Copyrighted Cisco® Systems Inc. January 2019 18

a Cisco managed trustpool bundle, which includes certificates signed by trusted

Lab Exercise Steps

Copyrighted Cisco® Systems Inc. January 2019 19

Step 6 Go back to the template:

Copyrighted Cisco® Systems Inc. January 2019 20

Step 7 Select “IOS-XE” as Software Type and click on “Add”:

Copyrighted Cisco® Systems Inc. January 2019 21

Copyrighted Cisco® Systems Inc. January 2019 22

Copyrighted Cisco® Systems Inc. January 2019 23

Step 12 Click on “Commit”:

Step 13 As mentioned before, templates need to be assigned to network profiles. In turn,

Copyrighted Cisco® Systems Inc. January 2019 24

Step 14 Select “Switching”:

Step 15 Assign a name to the profile: “Branch-Switch-Profile”:

Step 16 Under “Onboarding Template(s)” tab, click on “Add”:

Copyrighted Cisco® Systems Inc. January 2019 25

Step 19 Select “Branch” and click on “Select”:

Copyrighted Cisco® Systems Inc. January 2019 26

BR-SW2#test crypto pki trustpool reset

BR-SW2#delete flash:vlan.dat  Delete any existing vlan database

BR-SW2#write erase  Proceed to erase config

Copyrighted Cisco® Systems Inc. January 2019 28