Cisco DNA

Implementation

By : Dagem Alemayehu
10/11/2022
Ground Rules
• Create Interactive Sessions
• Ask questions
• Try to minimize use of cell phones
• Be on time
• We will have break for 15 min
 [Link] 3

Outline
 Identifying Cisco Digital Network  Implementing Cisco Enterprise Network
Architecture Vision Functions Virtualization
 Identifying Cisco Digital Network  Implementing Network Programmability in a
Architecture Solution Components Cisco DNA Architecture
 Identifying the Role of Automation and  What Is Network Analytics in Cisco DNA?
Orchestration Controllers in Cisco DNA
 Cisco DNA Analytics Architecture
 Implementing Automation in Enterprise
 Cisco DNA Analytics Proof Points
Networks
 Cisco Network Data Platform Architecture
 Implementing Cisco Network Plug and
Play Solution  Cisco CMX on Premises
 Implementing Cisco Easy QoS Solution  Context-Aware Service Architecture
 Implementing Cisco Intelligent WAN  Cisco CMX Connect
Solution
 Cisco CMX Analytics
 Troubleshooting Using Cisco APIC-EM Path
Trace Application
 Cisco CMX API
Cisco DNA Vision
Introduction
• ENTERPRISE network architectures are being challenged by
digitization of businesses
• However, the evolution toward a dynamic, ubiquitous digitalized
business does not come without risks. Universal connectivity opens
up new, and often, devastating security risks.
• The digital business network needs to quickly evolve to support
new more dynamic forms of worker and customer interaction, as
well as simplification and automation of network operations
• The architecture is built to facilitate fast and flexible network
services that support digitalized business processes.
Cont . . .
• The network is extended to embrace data center,
cloud and IoT infrastructures while maintaining
the traditional high availability, scalability and
performance characteristics.
• The DNA infrastructure is designed to deliver
services:
• Network services to enable ubiquitous connectivity
• Security services to protect data and user integrity
• Digital services to optimize business applications
Requirements
• Over the last few years, the demands on network functionality have
evolved significantly.
• Today, many employees can bring their own devices into the
workspace, which requires the necessary functionality to
authenticate and control these devices, as well as to shield corporate
data from unwanted access.
• Multimedia communication has also increased dramatically, with
video being the standard communication, whether for direct
communication or for meetings.
• Many businesses are taking advantage of digitalization to transform
their processes. Digitalized business processes require rapid service
deployments to meet the ever–increasing demands and expectations
of customers, partners, and employees.
Cont . . .
• Enterprises can identify market opportunities and
offer business services to customers to capitalize on
these opportunities by using rapid, agile application
development.
• Cloud computing allows the deployment of such
new services without lengthy and costly investments
in server or networking infrastructure.
• Application delivery is also accelerated by using
existing software stacks and drawing additional data
from a multitude of information sources.
Cont . . .
• These trends have created a significant increase
in IP traffic volume
• Management of increased number of end devices
and ensuring their security
• Requirement for enterprise network
Four Categories
• Faster Innovation Requirements
• Flexibility
• Intelligent feedback mechanism
• Application and user awareness

• Reduce Complexity and cost

• Simplicity
• Automation

• Compliance and technology

• Security
• High Availability

• Cloud Enablement
Cisco DNA
• DNA is designed to meet the enterprise network
requirements
• Service in Cisco DNA fall into the following three
categories
• Network Services
• Digital services
• Security Services
Cont . . .
• A Cisco DNA–based infrastructure is open by
design
• Open Management (eg. DNA controller)
• Open Functionality (eg. With Virtualized Network
function)
• Open Interoperability (third–party network elements)
• Open Programmability(open and standards–based
APIs)
DNA Principles
• Cloud Enablement
• Network Enablement (Collaboration, Mobility,
IOT, security )
• Automation(DNA Controllers)
• Analytics and Telemetry(Network sensors,
Communication infrastructure, Analytics engine)
• Virtualization(VLAN)
What is Cisco DNA
• Cisco DNA is defined as a controller based architecture
solution. At the core of this platform is Cisco DNA Center
that provides the automation, the policy and analytics that
are required to modify, simplify and scale operations.
• “DNA” is a very complex architecture designed from the
ground up to support “Digitalization” in every possible way
from a Business-perspective rather than a Technical-
perspective.
• Cisco DNA Center is a powerful network controller and
management dashboard for secure access to networks and
applications. It lets you take charge of your network,
optimize your Cisco investment, and lower your IT spending.
Cont . . .
• the best analogy you can do in the network world is to
compare Cisco DNA to “Wireless networks”. If you’ve been
into the network industry for a while, you have experienced the
following evolutions:
• 1st generation - You had to configure every access point
individually and they did not share any information about each
other.
• 2nd generation - You got the possibility to configure “groups of
access-points” but they were all acting independently.
• 3rd generation - You got the possibility to configure a “wireless
controller” and all the access points joined the controller and
shared the same wireless policy.
 [Link] 17

Cisco DNA Solution components

Overview
Overview
• Main Building blocks of Cisco DNA
• Network Fabric
• Virtualization
• Cloud enablement
• Network Controller
• Service Definition and Orchestration
• Analytics and telemetry application
Network Fabric
• Cisco defines this as a “transport infractructure
that is provided by the context of an enterprise
IP fabric”.
• As previously mentioned this “Network IP
Fabric” can span multiple sites and multiple
geographical areas. The architecture of course
supports multiple administrative domains where
different organizational units can provide
variations of a company-policy (domain specific
policy).
 Cont . . .
• The fabric can be organized into different domains to provide an
administrative boundary around a set of network elements.
• In this way, the end–to–end transport communication path associated with
a service in DNA can be super–imposed on various domains, each
providing a separate leg and offering domain–specific policies.
• The pertinent domains in DNA are the campus, the data center, the cloud,
and the WAN (which includes WAN aggregation and branches).
• In the campus, multiple endpoints connect to the network using either
wired or wireless access. The campus may also provide connectivity to
the data center or WAN domains, helping endpoints to reach applications
residing the data center, or to reach hosts located in branches,
respectively.
• The network elements in the fabric are predominantly hardware–based to
offer high–speed transport at scale.
Cont . . .
Virtualization
• Virtualization plays another key role in DNA,
since it is a crucial mechanism to deploy
services fast and with minimal dependencies on
the underlying hardware infrastructure.
• To support End-to-End security it’s important to
have a technical architecture that supports
segmentation of the transport within the
Network Fabric Network Engineers in general
think of this in terms of “VLAN:s and VRF:s”.
Cont . . .
• Transport virtualization: The logical separation of
traffic by means of VLANs or VRF is already a
standard tool in enterprise network architectures.
• Network function virtualization: Network function
virtualization (NFV) is part of the architecture that can
enable network functions to run anywhere in the
network infrastructure based on the availability of x86
compute resources.
Cont . . .
Cloud Enablement
• Fusing the cloud with the enterprise–operated infrastructure is
an integral part of the DNA.
• This cloud integration is crucial in order to deliver several
benefits. First, the cloud provides resources to host digitized
applications for business process delivery as if they were
hosted in the enterprise–owned infrastructure.
• In the case of virtual private cloud environments, making use
of a virtual IPsec gateway, for example, allows the
establishment of a secure tunnel into the VPC, effectively
making it another branch.
• Different VPC providers can simultaneously be integrated into
the corporate network.
Controller based Networking
Automation Architecture
• In Legacy-networks engineers usually started from
the technical part of the network and assigned
applications to IP-subnets and VLAN:s.
• They also made sure that routing worked between
users and applications.
• As a last thing, they gave some key information to
application owners about which subnets to use and
which ports to connect to.
• Then the application-provider could start working on
their end and configure their application.
Cont . . .
• The enterprise IP fabric in the Cisco DNA is governed by a controller
that oversees the configurations and operations of its network elements.
• As such, the controller has a domain–wide view of the state and the
operations of the associated network elements.
• The DNA controller is responsible for the configuration of the network
fabrics – the underlay communication and overlay services
architectures.
• It configures the user– or application–visible network services (for
example applying a service policy to a particular IP flow, or applying one
or more Layer 4–7 service functions to a user–application
communication pattern).
• Most importantly, the controller is the element in the architecture to
implement policy.
Cont . . .
Service Definition and
Orchestration Architecture

• Orchestration in DNA plays the critical role of

allowing the network operator to specify the
services offered to applications and end devices
and to associate the desired characteristics
against those services.
• The orchestrator then interfaces to the
controllers using standard APIs to instantiate
the specified services at the right time in the
right network element in the right sequence of
operations
Cont . . .
• Network orchestration refers to actions a network controller
performs in setting up devices, applications, and services in
the network to achieve objectives. It's much like an
orchestra conductor's role in directing individual musicians
as they perform a piece of music together.
• It has a brain: the network controller. The controller translates
business needs into network requirements, sets up the network to
deliver on those requirements, and monitors it to help ensure that
business needs are being met.
• It views the network as a whole and not as individual parts.
• It synchronizes all parts of the network to help achieve objectives.
Cont . . .
Analytics and
Telemetry Applications
• An infrastructure of analytics and telemetry is
another building block in DNA.
• Analytics and telemetry support is offered in the
following three ways: ·
• Data collection
• Data analysis
• Feedback and control
Cisco DNA Components
• Cisco DNA—infrastructure, automation, analytics platform, and
cloud integration—collaborate as a system to deliver the
requirements. 
Infrastructure
• The infrastructure component is made up of both hardware and
virtualized network elements.
• Hardware-based network elements are enhanced in
functionality to accommodate the Cisco DNA principles of
software driven, programmability, and security.
• While ASICs are continuing to improve in speed and
functionality, the hardware-based network elements can also
be uplifted by a software upgrade in Cisco DNA, extending the
lifecycle of the installed base.
• Hardware-based network elements in Cisco DNA also allow
high-bandwidth communication at speeds up to 100 Gbps and
beyond.
Cont. . .
• VNFs are added to the functional components of the Cisco
DNA infrastructure. They are integral to address the Cisco DNA
principles of openness, software driven, programmability, and
security.
• VNFs can perform infrastructure forwarding functions. For
example, the Cisco Cloud Services Router (CSR) 1000V
Series offers the same functionality as a hardware-based IOS
XE router (the Cisco ISR 4000 Series or the Cisco ASR 1000
Series routers), but in a software-virtualized form factor.
• This provides both operational and functional consistency
between the physical and virtual network infrastructures—
significantly enhancing simplicity and operational consistency.
• Alternatively, Layer 4–Layer 7 functions such as firewalls, DPI,
IPS/IDS, etc. can also be accommodated in Cisco DNA in a
virtual form factor if and where desired.
DNA infrastructure
Domain
 [Link] 38

Automation & Orchestration

Automation
• Network automation is the key to truly enable organizations to
comprehensively automate the infrastructure and application
delivery process end to end
• Network automation can help enterprises deliver applications
more quickly to support the business rollout of new products
and services, and to move into new markets. Automation also
helps to reduce CapEx and OpEx by making the network more
reliable and scalable
• A network automation solution should allow different IT teams
to use the build tools of choice to programmatically interact
with virtualized network infrastructure objects
Cont . . .
• Network automation is the process of automating the configuring,
managing, testing, deploying, and operating of physical and virtual
devices within a network. With everyday network tasks and
functions automated and repetitive processes controlled and
managed automatically, network service availability improves.

• Any type of network can use network automation. Hardware- and

software-based solutions enable data centers, service providers,
and enterprises to implement network automation to improve
efficiency, reduce human error, and lower operating expenses.
Cont . . .
• One of the biggest issues for network managers is the growth
of IT costs for network operations. The growth of data and
devices is starting to outpace IT capabilities, making manual
approaches nearly impossible. Yet up to 95 percent of network
changes are performed manually, resulting in operational costs
2 to 3 times higher than the cost of the network. Increased IT
automation, centrally and remotely managed, is essential for
businesses to keep pace in the digital world.
Cont . . .
• With network automation, you'll quickly and easily design,
provision, and apply policy across your network. And in your
journey to automation, you choose the path and the pace. Work
with existing network and policy definitions, migrate as fast or slow
as you'd like, or start from scratch.

Step 1: network design

Inventory, discovery, topology, and site design.
• Quick, clear visibility of network devices and clients.
• Map and logical views.
• Importing with Prime Infrastructure, losing none of
your former work.
Cont . . .
Step 2: profiles and policies
Network deployment standardization with design profiles and
site-based application policies.
• Applications and services that follow policies created.
• Network performance that aligns with business intent.

Step 3: provisioning and connecting

Plug-and-play provisioning, branch virtualization, and software
image management.
• Zero-touch provisioning of off-the-shelf devices.
• Easy control of device configurations for consistency and
accuracy.
Cont . . .
• Step 4: automated lifecycle management
Automating upgrades, patches, and security updates and
executing on Cisco DNA Assurance enhancements.

• Fast and accurate deployment of patches and

updates.
• Systemwide configuration updates as driven by
assurance.
Cont . . .
Cont . . .
Cont . . .
Cont . . .
Orchestration
• Network orchestration refers to actions a network controller
performs in setting up devices, applications, and services in the
network to achieve objectives.
• Most organizations depend on their networks to help run their
businesses. Besides connecting diverse users and IoT
(Internet of Things) devices, the networks carry data all around
the enterprise, manage resources and applications in data
centers and clouds, and help to secure all elements against
threats. And since business needs change—sometimes quickly
—networks should respond quickly and inexpensively.
• It's clear that networks expected to do so much are getting
more and more difficult to manage. 
Cont . . .
• Any substantial change needs to be reflected in multiple
areas. As an example, a seemingly simple objective to set up
a new user can require modifications to a lot of switches,
routers, firewalls, AAA servers, etc. These changes enable the
user to be properly authenticated and authorized and set up
with appropriate application-access levels. 
• Deploying a new application in the public cloud may also
require many tasks. The tasks might include dynamically
acquiring compute, storage, and network resources in the
cloud, provisioning software-defined WAN (SD-WAN) to
provide quality of service (QoS) suited to the application's
traffic, and configuring switches and access points to enforce
access rights. 
• With proper orchestration, the network can accomplish such
complex steps without missing a beat.
Cont . . .
• As a rule, organizations with 20 or more network devices or
250 or more users can benefit from network orchestration.
• Growing organizations that are adding users and IoT devices,
hosting a diverse set of users with distinct needs, or using
rigorous security requirements for data protection should
explore how network orchestration can help them achieve their
objectives.
• Organizations that have employees who travel frequently, host
applications in their data centers, use applications from the
public cloud, or experience frequent changes to their networks
should also investigate how network orchestration can help
them.
Cont . . .
• Before the days of software-defined networking (SDN) and
network automation, all network setup was done manually.
Today, of course, manual setup is impossible.
• Instead, organizations use network controllers and
programmable network devices that can systematically execute
what's required.
• Network controllers are built to orchestrate this execution. They
have intimate knowledge of the network's configuration,
architecture, infrastructure elements, users and their devices,
and traffic patterns.
• Controllers that follow the intent-based networking model allow
input of business objectives that they translate into network
actions that they orchestrate
Automation vs
orchestration
• Network automation refers to performing discrete, fairly simple
tasks without manual intervention. Examples of automation
include uploading a new configuration file to a switch and
updating the switch's software image—jobs that each achieve
a single objective. 
• Orchestration refers to performing a series of related tasks to
achieve a more-complex objective. A network controller
executes automated tasks in a purposeful order and verifies
the success of each task before performing the next one.
• As an example, orchestrating a new wireless SSID might
consist of identifying and reconfiguring the appropriate access
points and wireless LAN controllers, and setting up proper
credentials, security mechanisms, allowed bandwidth, etc., for
the SSID.
NMS vs Orchestration
• Network management refers to functions for administering and
operating networks. A central network management system,
usually the network controller, uses its automation and
orchestration capabilities to perform these functions.
• In other words, network orchestration is a subset of network
management.
Automation in Enterprise
Network
 [Link] 56
Automation in Enterprise
Network

• Network devices such as routers, switches, and firewalls have

traditionally been configured by a network administrator using
the CLI
• Whenever there is a change or new feature, the necessary
configuration commands must be manually entered on all of
the appropriate devices. In many cases, this is not only time-
consuming but can also be prone to errors. This becomes a
major issue on larger networks or with more complex
configurations.
Cont . . .
 [Link] 58

Cont . . .

• Simple Network Management Protocol (SNMP) was developed

to allow administrators to manage nodes such as servers,
workstations, routers, switches, and security appliances on an
IP network.
• Using a network management station (NMS) and SNMP
network administrators can monitor and manage network
performance, find and solve network problems, and perform
queries for statistics.
• SNMP works reasonably well for device monitoring. However, it
is not typically used for configuration due to security concerns
and implementation difficulty. Although SNMP is widely
available, it cannot serve as an automation tool for today’s
networks.
 [Link] 59

Cont . . .

• You can also use APIs to automate the deployment and

management of network resources. Instead of manually
configuring ports, access lists, quality of service (QoS), and
load-balancing policies, the network administrator can use
tools to automate these configurations.
• These tools hook into network APIs to automate routine
network provisioning tasks, enabling the administrator to select
and deploy the particular network services needed.
• This automation can significantly reduce many repetitive and
mundane tasks and free up time for network administrators to
work on more important things.
 [Link] 60

Network Automation

• We are rapidly moving away from a world where a network

administrator manages a few dozen network devices to one
where an administrator is deploying and managing hundreds,
thousands, and even tens of thousands of complex network
devices (both physical and virtual) with the help of software.
• This transformation is quickly spreading from its beginnings in
the data center to all places in the network. There are new and
different methods for network operators to automatically
monitor, manage, and configure networks. As shown in these
include protocols and technologies such as REST, Ansible,
Puppet, Chef, Python, JSON, and XML.
 [Link] 61

Network Automation
 [Link] 62
Configuration management
tools
• Configuration management tools make use of RESTful API
requests to automate tasks and can scale across thousands of
devices.
• Configuration management tools maintain the characteristics of
a system, or network, for consistency.
• These are some characteristics of the network that
administrators benefit from automating:

• Software and version control

• Device attributes such as names, addressing, and
security
• Protocol configurations
• ACL configurations
 [Link] 63
Configuration management
tools
• Configuration management tools typically include automation and
orchestration. With automation, a tool automatically performs a task
on a system, such as configuring an interface or deploying a VLAN.
• Orchestration is the process in which all these automated activities
need to happen, such as the order in which they must be done,
what must be completed before another task is begun, and so on.
Orchestration involves arranging the automated tasks into a
coordinated process or workflow.
• Several tools are available to make configuration management
easier, including the following:
Ansible
Chef
Puppet
SaltStack
 [Link] 64
Configuration management
tools
• All of these tools aim to reduce the complexity and time
involved in configuring and maintaining a large-scale network
infrastructure with hundreds or even thousands of devices.
These same tools can benefit smaller networks as well.
• Ansible, Chef, Puppet, and SaltStack all come with API
documentation for configuring RESTful API requests. All of
them support JSON and YAML as well as other data formats. 
Table 14-3 compares the major characteristics of the Ansible,
Puppet, Chef, and SaltStack configuration management tools.
 [Link] 65
Configuration management
tools Characteristics
 [Link] 66
Configuration management
tools Characteristics
What programming language? Ansible and SaltStack are both built
on Python, whereas Puppet and Chef are built on Ruby. Much like
Python, Ruby is an open-source, cross-platform programming
language. However, Ruby is typically considered a more difficult
language to learn than Python.
Agent-based or agentless? Configuration management is either
agent based or agentless. Agent-based configuration management is
pull based, meaning that the agent on the managed device periodically
connects with the master for its configuration information.
Changes are made on the master and pulled down and executed by
the device. Agentless configuration management is push based: A
configuration script is run on the master, and the master connects to
the device and executes the tasks in the script. Of the four
configuration tools examined here, only Ansible is agentless.
 [Link] 67
Configuration management
tools Characteristics
How are devices managed? Management occurs with a device called
the Master in Puppet, Chef, and SaltStack. Because Ansible is
agentless, any computer can be the controller.

What is created by the tool? Network administrators use

configuration management tools to create a set of instructions to be
executed. Each tool has its own name for these instructions (for
example, playbook in Ansible, cookbook in Chef). Common tool
specifies a policy or a configuration that is to be applied to devices.
Each device type might have its own policy. For example, all Linux
servers might get the same basic configuration and security policy.
 [Link] 68

IBN AND CISCO DNA Center

• You have learned about some of the many tools and software
options that can help you automate a network. Intent-based
networking (IBN) and Cisco Digital Network Architecture (DNA)
Center can help you bring it all together to create an automated
network.
• Intent-based networking (IBN) is the emerging industry model
for the next generation of networking. IBN builds on software-
defined networking (SDN), transforming a hardware-centric
and manual approach to designing and operating networks to
an approach that is software centric and fully automated.
• Business objectives for the network are expressed as intent.
IBN captures business intent and uses analytics, machine
learning, and automation to align the network continuously and
dynamically as business needs change.
 [Link] 69

IBN AND CISCO DNA Center

• You have learned about some of the many tools and software
options that can help you automate a network. Intent-based
networking (IBN) and Cisco Digital Network Architecture (DNA)
Center can help you bring it all together to create an automated
network.
• Intent-based networking (IBN) is the emerging industry model
for the next generation of networking. IBN builds on software-
defined networking (SDN), transforming a hardware-centric
and manual approach to designing and operating networks to
an approach that is software centric and fully automated.
• Business objectives for the network are expressed as intent.
IBN captures business intent and uses analytics, machine
learning, and automation to align the network continuously and
dynamically as business needs change.
 [Link] 70

Cont . . .
• IBN captures and translates business intent into network
policies that can be automated and applied consistently across
the network.
• Cisco views IBN as having three essential functions:
translation, activation, and assurance. These functions interact
with the underlying physical and virtual infrastructure
• From the perspective of IBN, the physical and virtual network
infrastructure is a fabric. Fabric is a term used to describe an
overlay that represents the logical topology used to virtually
connect to devices.
IBN
• As the name implies, an intent-based network system begins with
the expression of business intent by an operator. Examples of such
expressions include

“This group of users can access these services.”

“This application matters to my business.”
“Infected client devices should be quarantined.”
• While operators speak the language of business, network devices
do not. As such, expressions of business intent need to
be translated into validated network device configurations.
• Cisco DNA is an IBN system for enterprise route/switch/wireless
networks. Before examining the technical details of this
architecture, let’s first consider some of the business value
propositions that it offers.
 [Link] 72

Cont . . .
 [Link] 73

Cont . . .
 [Link] 74

Cont . . .
• The overlay limits the number of devices the network
administrator must program. It also provides services and
alternative forwarding methods not controlled by the underlying
physical devices.
• For example, the overlay is where encapsulation protocols
such as IP Security (IPsec) and Control and Provisioning of
Wireless Access Points (CAPWAP) occur.
• Using an IBN solution, the network administrator can specify
through policies exactly what happens in the overlay control
plane. Notice that how the switches are physically connected is
not a concern of the overlay.
 [Link] 75

Cont . . .
• The overlay limits the number of devices the network
administrator must program. It also provides services and
alternative forwarding methods not controlled by the underlying
physical devices.
• For example, the overlay is where encapsulation protocols
such as IP Security (IPsec) and Control and Provisioning of
Wireless Access Points (CAPWAP) occur.
• Using an IBN solution, the network administrator can specify
through policies exactly what happens in the overlay control
plane. Notice that how the switches are physically connected is
not a concern of the overlay.
 [Link] 76

Cont . . .
• The underlay network is the physical topology that includes all
hardware required to meet business objectives. The underlay
reveals additional devices and specifies how these devices are
connected.
• Endpoints, such as the servers in the figure, access the
network through the Layer 2 devices. The underlay control
plane is responsible for simple forwarding tasks.
 [Link] 77

Cisco DNA
• Cisco implements the IBN fabric by using Cisco DNA. the
business intent is securely deployed into the network
infrastructure (the fabric).
 [Link] 78

Cisco DNA – Cont . . .

• Cisco DNA then continuously gathers data from a multitude of
sources (devices and applications) to provide a rich context of
information. This information can be analyzed to make sure the
network is performing securely at its optimal level and in
accordance with business intent and network policies.
• Cisco DNA is a system that is constantly learning and adapting
to support the business needs. 
 [Link] 79

Cisco DNA Solutions

SD-Access •First intent-based enterprise networking solution
built using Cisco DNA.

•Uses a single network fabric across the LAN and

WLAN to create a consistent, highly secure user
experience.

•Segments user, device, and application traffic and

automates user-access policies to establish the
right policy for any user or device, with any
application, across a network

•Enables network access in minutes for any

user or device to any application without
compromising security
 [Link] 80

Cisco DNA Solutions

SD-WAN • Uses a secure cloud-delivered architecture to
centrally manage WAN connections.

• Simplifies and accelerates delivery of secure,

flexible, and rich WAN services to connect data
centers, branches, campuses, and colocation
facilities.

• Delivers better user experiences for

applications residing on premises or in the
cloud.

• Achieves greater agility and cost savings

through easier deployments and transport
independence.
 [Link] 81

Cisco DNA Solutions

Cisco DNA Assuran • Used to troubleshoot and increase IT productivity.
ce
• Applies advanced analytics and machine learning to
improve performance and issue resolution and
predictions to assure network performance.

• Provides real-time notification for network conditions

that require attention.

• Allows you to identify root causes and provides

suggested remediation for faster troubleshooting.

• Provides an easy-to-use single dashboard with

insights and drill-down capabilities.

• Machine learning continually improves network

intelligence to help predict problems before they
occur.
 [Link] 82

Cisco DNA Solutions

Cisco DNA Security • Provides visibility by using the network as a sensor for
real-time analysis and intelligence.

• Provides increased granular control to enforce policy

and contain threats across the network.

• Reduces risk and protects the organization

against threats—even in encrypted traffic.

• Provides 360-degree visibility through real-time

analytics for deep intelligence across the network.

• Reduces complexity with end-to-end security.

 [Link] 83

Cisco DNA Center

• Cisco DNA Center is the foundational controller and analytics platform
at the heart of Cisco DNA. It supports the expression of intent for
multiple use cases, including basic automation capabilities, fabric
provisioning, and policy-based segmentation in the enterprise network.

• Cisco DNA Center is a network management and command center for

provisioning and configuring network devices. It is a hardware and
software platform that provides a single pane of glass (that is, single
interface) that focuses on assurance, analytics, and automation.

• The DNA Center interface launch page gives you an overall health
summary and network snapshot. From here, a network administrator
can quickly drill down into areas of interest.
 [Link] 84

Cisco DNA – Cont . . .

 [Link] 85

Cisco DNA – Cont . . .

Menus at the top of DNA Center provide access to five main areas:
Design: Model your entire network, from sites and buildings to devices and
links, both physical and virtual, across campus, branch, WAN, and cloud.
Policy: Use policies to automate and simplify network management,
reducing cost and risk while speeding rollout of new and enhanced services.
Provision: Provide new services to users with ease, speed, and security
across your enterprise network, regardless of network size and complexity.
Assurance: Use proactive monitoring and insights from the network,
devices, and applications to predict problems faster and ensure that policy
and configuration changes achieve the business intent and the user
experience you want.
Platform: Use APIs to integrate with your preferred IT systems to create
end-to-end solutions and add support for multivendor devices.
 [Link] 86

Plug and Play Solution

 [Link] 87

Plug and Play Solution

• It is well recognized in the Information and Communications Technology
industry that performing network deployments for enterprises and large
campuses can be challenging, and often require skilled installers to pre-
stage equipment or visit each site to perform the installation.

• The Cisco Network Plug and Play solution provides a simple, secure, unified,
and integrated offering for businesses both large and small to ease new
network rollouts or for provisioning updates to an existing network. The
solution provides a unified approach to provision networks comprised of
Cisco routers, switches, and wireless devices with a zero-touch or near zero-
touch deployment experience.

• An installer at the site can deploy a new device with minimal knowledge of
the device being deployed, while the network administrator centrally
manages the device configuration.
PnP Components.
• Cisco FindIT Network Manager
• Cisco Network Plug and Play server This embedded
application receives Network Plug and Play requests from
Cisco devices and provisions devices based on predefined
rules and criteria.
• Cisco Plug and Play Agent This agent is embedded in Cisco
devices and communicates to the Cisco Network Plug and Play
server using the Network Plug and Play protocol over HTTPS
during device deployments.
• Cisco Plug and Play Agent This agent is embedded in Cisco
devices and communicates to the Cisco Network Plug and Play
server using the Network Plug and Play protocol over HTTPS
during device deployments.
Cont . . .
Cont . . .
There are four main workflows for deploying devices using
Network Plug and Play:

■ Planned Device Deployment in a Managed Network

■ Planned Device Deployment in an Unmanaged Network
■ Unplanned Device Deployment
■ Generic Device Deployment
Cont . . .
A planned device deployment occurs when the network is prepared for
the device prior to the physical installation of that device occurring.
A managed network is one where the network services such as DHCP or
DNS are controlled by the administrator and can be used by the newly
installed device to locate the PnP server.
To deploy a device in a managed network, The following procedures
• Step 1 The network administrator sets up a DHCP server in the
network to respond to client discover requests with DHCP option 43,
which contains information necessary to contact FindIT Network
Manager.
• Alternatively, DNS can be used to locate the Manager. For DHCP and
DNS configuration details.
Planned Device
Deployment
• Step 2 The network administrator creates a Network Plug and
Play enabled device in FindIT Network Manager.
• This includes entering device information and specifying a
configuration and/or image for each device to be installed. Prior
to creating devices, it may also be necessary to create a new
Project (FindIT Network Manager version 1.x), or a new
Network and Device Group (FindIT Network Manager version
2.0 and above) to represent the network the device is to be
installed in.
• For details on configuring Cisco Network Plug and Play in
FindIT Network Manager, see the Cisco FindIT Network
Manager Administration Guide.
Cont . . .
• Step 3 The device installer installs and powers up the Cisco
network device
• Step 4 The device auto-discovers FindIT Network Manager
using DHCP or DNS, identifies itself by serial number and
product ID (PID) to the Cisco Network Plug and Play
application, and downloads any software image and/or
configuration file that were pre-provisioned by the network
administrator.
• The device will reboot after each download.
Unplanned Device
Deployment
• In an unplanned deployment, a device is physically installed
before a Network Plug and Play enabled device is created in
FindIT Network Manager.
• In this case, the device will not be automatically provisioned with
the correct image and configuration.
• However, this problem is easily resolved by following the
Unplanned Device Deployment procedure.
Step 1 The network administrator sets up a DHCP server in the
network to respond to client discover requests with DHCP option 43,
which contains information necessary to contact FindIT Network
Manager.
Alternatively, DNS can be used to locate the Manager. For DHCP
and DNS configuration details, see Server Discovery.
Unplanned Device
Deployment
• Step 2 The device installer installs and powers up
the Cisco network device.
• Step 3 The device auto-discovers FindIT Network
Manager using DHCP or DNS. The device is listed
as an Unclaimed device in FindIT Network Manager,
identified by Product ID, Serial Number and IP
address.
• Step 4 The network administrator uses FindIT
Network Manager to claim the device and provide it
with a new configuration and/or image.
Generic Device
Deployment
• In some networks, unique configurations are not
required for each device of a particular model and it
is possible to define a single, generic configuration
to be used for all devices of a particular type or
family.
• In these cases, it is often better to define generic
provisioning rules for all devices of a particular
model or type. To deploy devices using these
generic rules, use the following procedure:
Cont . . .
Step 1 The network administrator sets up a DHCP server in the
network to respond to client discover requests with DHCP option
43, which contains information necessary to contact FindIT
Network Manager. Alternatively, DNS can be used to locate the
Manager. For DHCP and DNS configuration details, see Server
Discovery.
Step 2 The network administrator creates an Auto Claim rule in
FindIT Network Manager for the Product ID of the devices. In
addition to specifying the Product ID, the network administrator
selects an appropriate configuration and/or image for devices
matching this product ID. For more details on configuring Auto
Claim in FindIT Network Manager, see the Cisco FindIT Network
Manager Administration Guide.
Cont . . .
Step 3 The device installer installs and powers up the Cisco
network device.
Step 4 The device auto-discovers FindIT Network Manager using
DHCP or DNS, identifies itself by serial number and product ID
(PID) to the Cisco Network Plug and Play application, and
downloads the software image and/or configuration file that were
specified in the Auto Claim rule. The device will reboot after each
download.
Design Consideration
• Plug and Play Server Discovery
• Secure Connectivity
• Network Reachability
• Order of Deployment
Plug and Play Server
A Network Plug and Play device will automatically find
the address of the Network Plug and Play server using
one of the following methods. Each method will be
attempted in turn until an address is found or all
methods have failed. The methods used are, in order:
. ■ Manual configuration A Network Plug and Play
enabled device may be manually configured with the
address of the server through the administration
interface. Explicit configuration always takes
precedence over other discovery methods.
■ DHCP The address of the server may be supplied to
the device in the Vendor-specific Information option
(option 43)
Plug and Play Server

■ DNS If the DHCP Vendor-specific Information option

has not been provided, then the device will perform
discovery using DNS lookups of well-known hostnames
■ Plug and Play Connect Service Finally, if no other
method has been successful, the device will attempt to
contact the Plug and Play Connect service. This
service will then redirect the device to the correct
server
 Cont . . .
• Once the device has identified the server, it will contact the server and update
firmware and configuration as specified by the server.
• Selecting the right discovery method to use depends on the level of control
that exists over the broader network infrastructure. The use of the DHCP or
DNS methods require the administration to have some level of control over
the DHCP servers in the network and the domain name infrastructure. The
Plug and Play Connect service requires little more than Internet access to be
effective but will generally require more effort to maintain.
• In most cases, the DHCP method offers the most flexibility and should be
used if possible, especially if DHCP services are managed centrally and can
be easily updated. DNS discovery can be more easily established in networks
with many DHCP servers that are managed separately, as DNS discovery
frequently only requires updates be made to one or two DNS servers. If no
access is available to DHCP or DNS servers, then PnP Connect should be
used.
Cont . . .
• Multiple discovery methods may also be used in combination.
Setting up both DHCP and DNS discovery in the same network
provides the combination of flexibility from DHCP discovery with
a level of confidence that comes from having DNS discovery for
devices where the DHCP server has been overlooked.
• A common approach is to use PnP Connect to provide discovery
services for edge router deployment where DHCP and DNS are
operated by the ISP and so unavailable for use, but then use
DHCP for devices in the rest of the network that receive DHCP
services from the router just deployed. The manual configuration
option, although reliable and flexible, is generally only used
during testing of a newly deployed Manager. However, it can be
used as a discovery method in environments where some pre-
staging of equipment is performed.
Sever Connectivity

• The Cisco Network Plug and Play solution uses HTTPS

connections between network devices and the Network Plug
and Play server. This secure connectivity is implemented in
one of two ways, depending on the type of transport you
specify in the DHCP option or PnP Connect controller profile.
DNS discovery will always attempt to use HTTPS as the
transport protocol. For details on configuring DHCP discovery
or PnP Connect
 Cont . . .
Depending on the transport protocol used, secure connectivity is
implemented in the following ways:
• When HTTP is specified as the transport protocol (default), secure
connectivity is based on trustpoint. Trustpoint based secure
connectivity relies on the self-signed certificate that is installed by
default on FindIT Network Manager.
• This self-signed certificate is used to create a default trustpoint on
network devices, which allows devices to connect securely over
HTTPS to the Manager.
• HTTPS is used for communications with the Manager, despite the fact
that HTTP is specified as the transport protocol. Before beginning the
provisioning process, the Manager installs the certificate on the
device, and then redirects the device to use HTTPS. Configuration
and firmware updates are then performed through HTTPS
Cont . . .
• When HTTPS is specified as the transport protocol, secure connectivity is
based on trustpool. Trustpool based secure connectivity additionally requires
that you replace the self-signed certification on FindIT Network Manager with
your own CA signed certificate.
• A trustpool is a special store of certificates signed by trusted certificate
authorities and published by Cisco InfoSec. The trustpool bundle is itself
signed by Cisco, allowing it to be trusted even if downloaded using an
insecure transport such as HTTP or TFTP.
• Prior to connecting to the PnP service, the device imports the trustpool
bundle into its CA store and this allows it to validate the Manager certificate,
enabling secure communications over HTTPS.
• You can choose to host the trustpool bundle in a different location in your
network, which you can specify in the T parameter to DHCP option 43 or
using the pnptrustpool DNS name with DNS discovery. In this case, network
devices would obtain your trustpool bundle instead of the default one that is
installed in the Manager.
Network Reachability
• While it may be obvious that the devices being deployed need to be
able to contact the PnP server to complete deployment, it is less
obvious that there are other services that must also be reachable.
• Exactly which services are required will depend on the design
choices made. In an Enterprise environment, the most common
requirement for network reachability is Internet access.
• Internet access is clearly required if using the PnP Connect service
for discovery, but frequently Internet access will be required to
access NTP services as well.
• It is common to rely on the default NTP service [Link] for
clock synchronization, and accurate time is a pre-requisite for
establishing a secure connection to the PnP server. If an accurate
time source is not available, then the deployment process will fail.
 Order of Deploymnet
• When deploying multiple devices in a network, part of ensuring that
network reachability is available is bring the network up in the correct
order.
• In general, routing and upstream devices should be brought up first to
provide access to the broader network.
• Once the router and all upstream devices are up and provisioned,
switches and downstream devices can be brought up.
• Due consideration should also be given to the restarts performed
during the provisioning process. It is wise to verify that key devices
such as routers or core switches have completed provisioning and are
stable before bringing up second and third tier devices.
• Otherwise there is a possibility for a device to lose connectivity or even
power part way through an image upgrade, potentially requiring a
manual recovery to be performed.
 FindIT Network
Manager
• There is a small amount of preparation necessary to ensure FindIT
Network Manager is ready to support Network Plug and Play in a given
network.
• First, and most importantly, it is necessary to establish the server identity
so that it matches what the clients will expect. If this is not done, then the
security of the process cannot be assured, and the process may fail for
reasons that are not obvious to the user.
• Establishing the server identity is usually only done once and should
generally be done at the same time as performing the initial deployment of
the Manager. Once the server identity has been correctly established,
firmware and configuration files need to be uploaded and Network Plug
and Play enabled devices must be created for the devices to be deployed.
• This is an ongoing operation, with new devices being created as the
network expands, while configurations and firmware versions will be
updated as network requirements change over time.
 Server Identity
• When establishing a connection to a Network Plug and Play server, the client checks
to ensure the certificate presented by the server is valid and can be trusted. For the
certificate to be acceptable and the connection to proceed, the certificate must meet
the following conditions:
■ The certificate must be signed by a trusted Certificate Authority (CA), or the certificate
itself must be trusted by the client. A certificate downloaded from the
TrustpoolBundleURL learned from DHCP, or from the Plug and Play Connect service is
trusted by the client.
■ If the server identity is discovered using manual configuration, DHCP or Plug and Play
Connect, and is an IP address, then the Subject-Alt-Name field must contain that IP
address. If the server will be reached through a NAT service, then the Subject-Alt-Name
field must contain the public IP address the same IP address the client is connecting to.
■ If the server identity is discovered using manual configuration, DHCP or Plug and
Play Connect, and is a hostname, then the Subject-Alt-Name field must contain that
hostname
■ If the server identity is discovered using DNS discovery, then the Subject-Alt-Name
field must contain the wellknown hostname pnpserver.
Cont . . .
• FindIT Network Manager implements a number of mechanisms
when generating certificates to ensure these requirements are
met. In particular, when generating a Certificate Signing
Request (CSR) or re-generating the self-signed certificate, the
Manager automatically includes the following information in the
Subject-Alt-Name field:
• ■ The contents of the Common Name field
• ■ The current IP address(es). If the Manager is deployed in
AWS, the external, public IP address of the Manager is used.
• ■ The hostname that was used in the web browser to connect
to the administration GUI when generating the certificate or CS
PnP for Planned Device
• Network Plug and Play enabled devices are used to map
individual devices to the desired image and configuration file.
Devices are identified by the combination of product ID (PID)
and serial number.
• A PnP-enabled device record should be created for each
device to be deployed. When a device connects to the
Manager, the PnP-enabled device records are searched, and,
if a match is found, the image and configuration files specified
will be pushed out to the device.
• The device may reboot multiple times during this process.
 PnP for Unplanned
device
• In some networks, it may be possible to define common configurations for
all or most devices of a given type.
• Alternatively, there may be a requirement to ensure that any device of a
particular type that is connected to the network meets a certain baseline
configuration.
• In these cases, provisioning rules for unplanned devices also known as
Auto Claim rules should be created. Auto Claim rules are similar to PnP-
enabled device records, but they do not match on the device serial number
only on the product ID (PID).
• As a result, any device with the specified PID will match this rule when
connecting to the Manager so long as there is no existing device record
that matches the serial number and PID of the device.
• When a device matches an Auto Claim rule, the image and configuration
files specified in that rule will be pushed out to the device. The device may
reboot multiple times during this process. .
 [Link] 114

Cisco Easy QoS Solution

 [Link] 115

Customer Challenges

• Today there is a virtual explosion of rich media applications on the IP network. This
explosion of content and media types, both managed and unmanaged, requires
network architects to take a new look at their Quality of Service (QoS) designs.
• Virtually all businesses are looking to increase the productivity of their employees
though the effective and innovative use of collaborative applications, regardless of the
hardware-platforms these applications run on (PCs, laptops, tablets, smartphones,
etc.), the physical or geographical location of the collaborating employees, or the
types of media they wish to share on-demand.
• However, enabling and providing seamless Quality of Experience (QoE) around such
services has traditionally placed challenging demands on network operators, to the
point where the foremost barrier to enabling QoS/QoE for collaborative applications is
the not technical abilities of the infrastructure. Instead, it is the intrinsic complexity of
enabling these features across disparate devices in a comprehensive, yet cohesive,
manner.
 Cont . . .
• In order for QoS to be effective, it needs to be deployed end-to-end, the same way a
chain needs to be deployed end-to-end between a source and a target in order to
have utility. Every link in the chain must have a cohesive, compatible QoS policy in
order to achieve an end-to-end service level.
• However, it is the platform-by-platform variations in customizing, optimizing, and
tuning that present the biggest barrier to QoS/QoE deployments. The network
controller helps by simplifying and abstracting platform-specific complexity from the
network operator.
• Specifically, the network controller is programmed with all the linkspecific information
and Cisco best-practice knowledge so as to construct optimal end-to-end QoS
chains. An operator does not need to know the hardware or software queuing
structures of the underlying infrastructure, nor do they need to know the QoS
implications of interconnecting wired and wireless networks, nor do they need to
know how the applications are to be recognized, despite the fact that an increasing
number of these are encrypted.
• All the operator needs to know is which applications are important to his/her
business. End-to-end provisioning is done in minutes (vs. months), leveraging
industry standards and Cisco Validated Designs (CVDs).
Solutions
• Cisco Application Policy Infrastructure Controller Enterprise Module
(APIC-EM Software-Defined Networking (SDN) controller.
• APIC-EM provides the automation functionality within Cisco Digital
Network Architecture (Cisco DNA).
• EasyQoS is an application that runs on top of APIC-EM. Hence, it is an
integral part of the overall Cisco DNA architecture.
• The EasyQoS solution abstracts QoS policy by using a declarative
model as opposed to an imperative model. A declarative model focuses
on the intent or WHAT is to be accomplished, without describing HOW it
is to be accomplished.
• For example, a network operator may express that an application such
as Cisco Jabber is business-relevant meaning that it is to be treated
with the appropriate service but he/she does not specify the details of
how the QoS/QoE policies are to be configured in order to achieve this
intent.
Cont . . .
• In contrast, an imperative model focuses on the execution of
the intent (describing in detail HOW the objective is to be
realized).
• For example, an imperative policy may include assigning Cisco
Jabber to a hardware priority queue with a given bandwidth
allocation percentage on a specific network switch interface.
• Using a declarative model for policy-expression, rather than an
imperative model, frees the network operator from having to
spend extensive time-consuming cycles to deploy QoS
policies. With a network controller, changes can be made in
minutes, rather than months, resulting in agile networks that
are tightly-aligned with evolving business requirements.
Cont . . .
Cont . . .
• Not only can a network controller simplify QoS/QoE
deployments and accelerate these like never before, but it can
also deliver completely new functionality in the form of
application-integration. Traditionally applications have been
separate and at arms-length from the network infrastructure,
often with dedicated yet distinct teams of IT personnel to
administer each.
• However the role of the network isn’t primarily to forward
packets but rather to interconnect users via applications. As
such, the network controller can play a crucial new role as the
broker or intermediary between applications and the network.
In order to do so, it has to understand the languages of each,
which it does via two main types of API:
Cont . . .
• Northbound API (NB API)/Northbound Interface (NBI): this
interface allows for applications to communicate with the
network controller, informing it of network policy requirements
in real-time. Northbound APIs are commonly deployed with
Representational State Transfer (REST) models.
• Southbound API (SB API)/Southbound Interface (SBI): this
interface allows for the controller to communicate to individual
network devices to configure the application policy-
requirements. Southbound APIs include NETCONF/YANG
models, as well as more traditional methods such as command
line interface (CLI) and Simple Network Management Protocol
(SNMP).
Cont . . .
• Specific to the context of QoE for collaboration, the network
controller can receive information from the callmanager of the
collaborative application such as Cisco Unified
Communications Manager (CUCM) for Cisco Jabber or Cisco
WebEx or Cisco Spark via the Northbound APIs,
• in order to inform it of any voice and/or Specific to the context
of QoE for collaboration, the network controller can receive
information from the callmanager of the collaborative
application such as Cisco Unified Communications Manager
(CUCM) for Cisco Jabber or Cisco WebEx or Cisco Spark via
the Northbound APIs, in order to inform it of any voice and/or
Cont . . .
• In summary the following is the business value of the EasyQoS
solution:
•  The EasyQoS solution provides end-to-end orchestration of
QoS in the Enterprise network.
•  The EasyQoS solution makes QoS policy simple and easy to
deploy with an operator expressing business relevance for
applications and the controller doing the rest under the hood.
•  The EasyQoS solution works for both greenfield and
brownfield deployments.
•  The EasyQoS solution provides a declarative model that is
business-intent driven, while abstracting away the
platform/media/capability details
 QoS Design Best
Practice
• Some Cisco routers, such as Cisco Integrated Services Routers
(ISRs), perform QoS in software, which places incremental loads on
the CPU.
• The actual incremental load depends on the numerous factors,
including: the complexity and functionality of the policy, the volume and
composition of the traffic, the speed of the interface, the speed of the
CPU, the memory of the router, etc. 
• On the other hand, other devices (such as Cisco Catalyst switches)
often perform QoS in dedicated hardware—Application Specific
Integrated Circuits (ASICs).  As such, these switches can perform even
the most complex QoS policy on maximum traffic loads at line rates on
GE/10GE/40GE/100GE interfaces—all without any marginal CPU tax.
•   Thus, whenever a choice exists, Cisco recommends implementing
QoS policies in devices that perform QoS operations in hardware—
rather than software—as this will result in more efficient utilization of
network infrastructure resources.
Cont . . .
• For example, suppose an administrator has the option of
deploying classification and marking policies in a branch
network in either a Catalyst switch (in hardware) or at the LAN-
edge interface of an ISR router (in software). Because a choice
exists as to where the policy should be deployed, it would be
more efficient to classify and mark within the Catalyst switch.
• However, there may be cases where such a choice doesn’t
exist. Continuing the example: there may be a business need
to perform deep-packet inspection on branch-originated traffic
(which may not be supported on the particular Catalyst switch
model deployed at the branch), and as such the administrator
would then have to apply the required classification and
marking policies on the ISR router.
Classification & Marketing
Best practice
• When classifying and marking traffic, a recommended design best
practice is to classify and mark applications as close to their
sources as technically and administratively feasible. This principle
promotes end-to-end differentiated services and PHBs.
• In general, it is not recommended that you trust markings that can
be set by end users on their PCs or other similar devices because
end users can easily abuse provisioned QoS policies if permitted
to mark their own traffic.  
• For example, if an EF PHB has been provisioned over the
network, a PC user can easily configure all their traffic to be
marked to EF, thus hijacking network priority queues to service
their non-real-time traffic. Such abuse could easily ruin the service
quality of real-time applications throughout the enterprise. On the
other hand, if enterprise controls are in place to centrally
administer PC QoS markings, then it may be an acceptable
design option to trust them.
Cont . . .

• Following this rule, it is further recommended that you use DSCP

markings whenever possible, because these Layer 3 IP-header
markings are end-to-end, more granular, and more extensible than
Layer 2 markings. For example, IEEE 802.1p, IEEE 802.11e (now
part of the IEEE 802.11 standard) and MPLS EXP only support
three bits (values 0-7) for marking.
• Therefore, only up to eight classes of traffic can be supported with
these marking schemes and inter-class relative priority (such as
RFC 2597 Assured Forwarding drop preference markdown) is not
supported. On the other hand, Layer 3 Differentiated service code
point (DSCP) markings allow for up to 64 distinct classes of traffic.
• As the line between enterprises and service providers continues to
blur and the need for interoperability and complementary QoS
markings is critical, you should follow standards-based DSCP
PHB(Per-hop behavior) markings to ensure interoperability and
future expansion.
 Congestion management
• Business-critical applications require service guarantees
regardless of network conditions. The only way to provide
service guarantees is to enable queuing at any and every node
that has the potential for congestion.
• In addition, because each application class has unique service
level requirements, optimally each should be assigned a
dedicated queue. In such a manner, specific bandwidth
allocations and dropping policies can be assigned to each
discrete application class to meet its distinctive QoS
requirements.
• Otherwise, if multiple application classes are assigned into a
common queuing bucket, the administrator no longer can
control if bandwidth resources are being shared among these
application classes according to their individual requirements.
 Cont . . .
At a minimum, however, the following standards-based queuing
behaviors should be supported:
·         Real-time queue(s)—to support an RFC 3246 Expedite
Forwarding service
·         Guaranteed-bandwidth queue(s) —to support RFC 2597
Assured Forwarding services
·         Default queue—to support an RFC 2474 Default Forwarding
service
·         Bandwidth—constrained queue-to support an RFC 3662
Scavenger service
Cisco offers design recommendations for each of these types of
queues. These queuing best practices are illustrated in the following
figure.
.
 Cont . . .
.
 Real Time Queue
• .The Real-Time queue corresponds to the RFC 3246 EF PHB.  The
amount of bandwidth assigned to the Real-Time queue is usually
variable.  However, if the majority of bandwidth is provisioned with strict-
priority queuing (which is effectively a first-in, first-out queue), the overall
effect is a dampening of QoS functionality.  

• Remember the goal of convergence is to enable voice, video, and data

applications to transparently coexist on a single network. When real-time
applications dominate a link, non-real-time applications fluctuate
significantly in their response times, destroying the transparency of the
converged network.
 Real Time Queue
• .Cisco has done extensive testing and has found that a significant
decrease in non-real-time application response times occurs when real-
time traffic exceeds one-third of link bandwidth capacity.  

• In fact, both testing and customer deployments have shown that a

general best queuing practice is to limit the amount of strict priority
queuing to 33% of link bandwidth capacity.  This strict priority queuing
recommendation is a conservative and safe design ratio for merging real-
time applications with data applications.

• Finally, Weighted Random Early Detection (WRED)—or any similar

congestion avoidance mechanism—should never be enabled on the strict
priority queue.  Traffic assigned to this queue is often highly drop
sensitive; therefore, early dropping should never be induced on these
flows.
Assured Forwarding
Queue
At least one queue should be provisioned as an Assured
Forwarding Queue.  Per RFC 2597, up to four queues can be
provisioned with this service:
·         AF Class 1—AF11, AF12, AF13
·         AF Class 2—AF21, AF22, AF23
·         AF Class 3—AF31, AF32, AF33
·         AF Class 4—AF41, AF42, AF43
These queues should have bandwidth guarantees that correspond
with the application class requirements of the traffic assigned to it.
In addition, DSCP-based WRED should be enabled on these
queues, such that traffic marked AFx3 is (statistically) dropped
sooner and more often than AFx2, which in turn is (statistically)
dropped more aggressively than AFx1.
Best Effort Queue
• The Best Effort Queue is the default treatment for all traffic that
has not been explicitly assigned to another queue. Only if an
application has been selected for preferential/deferential treatment
is it removed from the default class.
• Because most enterprises have several thousand applications
running over their networks, adequate bandwidth must be
provisioned for this class as a whole to handle the sheer number
and volume of applications that default to it. Therefore, Cisco
recommends provisioning at least 25% of link bandwidth for the
default Best Effort class.
• In addition, it is recommended that you enable WRED on the
default class to improve throughput and reduce TCP
synchronization. Because all traffic destined to this class is to be
marked to the same DSCP value (of 0), there is no “weight”
component to the WRED dropping decision, and therefore the
congestion algorithm is effectively random early detect
Less than Best Effort
Queue
• Whenever the Scavenger Queue is enabled, it should be
assigned a minimal amount of bandwidth, such as 1% (or
whatever the minimal bandwidth allocation that the platform
supports).
• WRED is not required on the Scavenger class queue because
traffic assigned to this queue has no implied “good-faith”
service guarantee or expectation.  Therefore, there is little to
gain by adding this feature and it may even be wasteful of
router CPU resources.
 [Link] 136

Cisco IWAN
 [Link] 137

Cisco IWAN
SD-WAN
Why SD-WAN
[Link]
Cisco DNA - IWAN
 [Link] 174

Cisco APIC-EM Path Trace

Application
 [Link] 175
Cisco APIC-EM Path Trace
Application

• With Path Trace, the controller reviews and collects network topology and routing
data from discovered devices. Then it uses this data to calculate a path between two
hosts or Layer 3 interfaces.

• Optionally, you can choose to collect interface, QoS, device, and Performance
Monitor statistics for a path. You can use the information gathered through Path Trace
to monitor and debug traffic paths that are distributed among the various devices
throughout your network.

• You perform these tasks by running a path trace between two nodes in your network.
The two nodes can be a combination of wired or wireless hosts and/or Layer 3
interfaces. In addition, you can specify the protocol for the controller to use to
establish the path trace connection, either TCP or UDP.
 [Link] 176

Cont . . .

• For unknown devices within a path trace (usually non-Cisco devices), the
controller calculates the path between the unknown devices starting from the
last known Cisco device (from the Host Source IP) to the next, neighboring
Cisco device (sometimes the Destination Source IP).

• The collected IP address data about the unknown device is then sent from
this neighboring Cisco device to the controller to calculate the trace path. The
unknown device is displayed in the controller's GUI as a question mark (?).

• In certain circumstances, a path trace may flow between one of two (or more)
devices. To determine which device actually received the flow for the path
trace, the controller reads the NetFlow configurations and records on the
devices (if they exist). By reading this data from the devices, the controller
can determine the likelihood of the actual path.
 [Link] 177

Cont . . .

• Path traces from the a router's loopback interface or a wireless controler's

management interface are not supported.

• For devices connected to a voice or video endpoint (for example, Cisco IP phones),
you need to enable IP Device Tracking (IPDT) for these devices to discover
voice/data VLAN information about the endpoints. For information, see IP Device
Tracking Configuration.

• At every node in the path, the controller reports information about the device
and path. For example, if a Layer 2 protocol is used to discover a node, the
controller reports that the path is a switched path and labels it as Switched. If
the controller detects load balancing decisions being made on a discovered
device, it reports the path as an Equal cost multi path ( ECMP) path and
labels it as ECMP. 
 [Link] 178

Cont . . .

• Path Trace also supports unknown destinations, where the device is not
managed by the Cisco APIC-EM but is reachable.

• After the Cisco APIC-EM performs an initial scan, additional on-going network

scans are performed at regular intervals every few minutes. Information
captured during the on-going scans are displayed in the Devices table.

• Click Device Inventory in the navigation pane to view the Devices table.

Each time the Cisco APIC-EM performs a scan, it also reads and records
access control list, quality of service, and SPAN policy configuration
information from the network.
 [Link] 179

Supported Network Env

• Cisco APIC-EM can perform path trace calculations for both campus and
WAN networks based on physical connectivity and the protocols used by
devices within the path. Specifically, the Cisco APIC-EM supports path traces
through the following networking environments:

• Campus/data center to campus/data center

• Campus/data center to branch
• Branch to campus/data center
• Branch to branch
 [Link] 180
Supported Protocols and
Technologies
ACL

• Access Control List (ACL) Trace analyzes how a flow is affected by ACLs
programmed on the path. After the path is calculated between the source and
the destination, the ACL Trace analyzes both ingress and egress interfaces of
all devices on the path.

• Analysis is independent among the ACLs throughout the path. For example, if
an ACL has entries that would deny the traffic on an interface along the path,
the results of the analysis are reported as if the traffic had reached the
destination without being denied by the ACL.

• However, analysis of entries within an individual ACL is cumulative. That is, if

a higher priority ACE is a match, lower-priority ACEs are ignored.
 [Link] 181

Cont . . .

BGP

• When BGP is used in a network, the path trace for a given application flow
can be displayed through the controller's GUI. The user is able to determine
the exact path a particular application is taking.

• The data used for this path trace calculation is obtained during the discovery
process and stored in the controller's database where it is kept up to date.

Dynamic Multipoint VPN(DMVPN)

• Path Trace shows DMVPN dynamic tunnels between two spokes by

identifying the link information source.

• For more information, see Understanding DMVPN Path Trace Results.

 [Link] 182

Cont . . .

Enhanced Interior Gateway Routing Protocol (EIGRP )

• When EIGRP is used in a network, the path trace for a given application flow
can be displayed through the controller's GUI. The user is able to determine
the exact path a particular application is taking.

• The data used for this path trace calculation is obtained during the discovery
process and stored in the controller's database where it is kept up to date.

Equal Cost Multipath/Trace Route (ECMP/TR)

• When ECMP/TR is used in a network, the path trace for a given application
flow can be displayed through the controller's GUI. The user is able to
determine the exact path a particular application is taking.
 [Link] 183

Cont . . .

• The data used for this path trace calculation is obtained on demand by polling
the device. When performing a path trace on ECMP, Cisco Express
Forwarding (CEF) lookup is performed on the device on demand for
requested tuples.

• When a path trace detects a number of unknown or unmanaged devices in

the path, the path trace is executed on demand from the last known or
managed Cisco device and the path calculation is restarted from the first
known or managed Cisco device in the trace route result.

• The unknown or unmanaged hops discovered using path trace are added to
the path as unknown devices along with their IP addresses.
 [Link] 184

Cont . . .

Equal Cost Multi Path (ECMP)

• When an ECMP routing strategy is used in a network, the path trace for a
given application flow can be displayed through the controller's GUI. The user
is able to determine the exact path a particular application is taking.

• The data used for this path trace calculation is obtained through an on-
demand query made through the network device at the time the path
calculation request is made.

Note
The controller's GUI will display when ECMP is used between devices in a path
trace segment.
 [Link] 185

Cont . . .
Hot Standby Router Protocol

• When HSRP is used in a network, the controller automatically looks up the

HSRP active router for a given segment and calculates the path appropriately
for a path trace.

• The data used for this path trace calculation is obtained during the discovery
process and stored in the controller's database where it is kept up to date.
 [Link] 186

Cont . . .
Intermediate System-to-Intermediate System (IS-IS) Protocol
• When IS-IS is used in a network, the path trace for a given
application flow can be displayed through the controller's GUI. The
user is able to determine the exact path a particular application is
taking.
• The data used for this path trace calculation is obtained during the
discovery process and stored in the controller's database where it is
kept up to date.
Layer 3 Forwarding interface
• The controller can perform path traces between two Layer 3
forwarding interfaces or between a Layer 3 forwarding interface and
a host.
 [Link] 187

Cont . . .
MPLS-VPN(WAN)
• The controller provides path trace support for a branch-to-branch connected and
provider-managed MPLS-VPN service. Supported devices for this type of path trace
include:

• Cisco ASR 1000 Series Aggregation Services Router

• Cisco ASR 9000 Series Aggregation Services Router
• Cisco Integrated Services Routers (ISR) G2

• All customer edge (CE) routers should have NetFlow enabled with traffic running
between the hosts and routers.

• Note
• The above supported devices will be tagged as Border Routers for their Device
Role in the Device Inventory. You must keep the above supported devices
tagged as Border Routers when performing a path trace.

• The data used for this path trace calculation is obtained through an on-demand
query made through the network device at the time the path calculation request is
made.
 [Link] 188

Cont . . .
Netflow
• When Netflow is used in a network, the path trace for a given
application flow can be displayed through the controller's GUI. The
user is able to determine the exact path a particular application is
taking.
• When we have multiple border routers in the destination island, the
Netflow cache from the devices are used to find the actual ingress
border router. The Netflow record is matched from these devices on
demand for a given tuple. It is essential to configure Netflow on the
border routers. If Netflow is not configured, trace route is used to
find the ingress interfaces, which might not be accurate.
 [Link] 189

Cont . . .
Open Shortest Path First
• When OSPF is used in a network, the path trace for a given
application flow can be displayed through the controller's GUI. The
user is able to determine the exact path a particular application is
taking.
• The data used for this path trace calculation is obtained during the
discovery process and stored in the controller's database where it is
kept up to date.
Physical connectivity

• The path trace for a given application flow can be displayed over
Ethernet, Serial over SONET, and Packet over SONET.
• The data used for this path trace calculation is obtained during the
discovery process and stored in the controller's database where it is
kept up to date.
 [Link] 190

Cisco Enterprise Network

Functions Virtualization
 Washington University in St. Louis

Overview

1. What is NFV?
2. NFV and SDN Relationship
3. ETSI NFV ISG Specifications
4. Concepts, Architecture, Requirements, Use cases
5. Proof-of-Concepts and Timeline

[Link]

17-191
Four Innovations of Washington University in St. Louis

NFV

4. Standard API’s between Modules

3. Implementation in Virtual Machines

2. Network Function Modules

1. Software implementation of network

[Link]

17-192
 Network Function Virtualization
(NFV)
1. Fast standard hardware  Software based Devices
Routers, Firewalls, Broadband Remote Access Server (BRAS)
 A.k.a. white box implementation
2. Function Modules (Both data plane and control plane)
 DHCP (Dynamic Host control Protocol), NAT
(Network Address Translation), Rate Limiting,

vBase Stations
Residential Set Top
DNS DHCP CDN
LTE 3G 2G Gateway NAT Box

Hardware
Hardware Hardware
 Washington University in St. Louis

NFV (Cont)
3. Virtual Machine implementation
 Virtual appliances
 All advantages of virtualization (quick provisioning,
scalability, mobility, Reduced CapEx, Reduced OpEx, …)

VM VM VM
Hypervisor

4. Standard APIs: New ISG (Industry Specification Group)

in ETSI (European Telecom Standards Institute) set up in
November 2012
Why We need Washington University in St. Louis

NFV?
1. Virtualization: Use network resource without
worrying about where it is physically located,
how much it is, how it is organized, etc.
2. Orchestration: Manage thousands of devices
3. Programmable: Should be able to change
behavior on the fly.
4. Dynamic Scaling: Should be able to change
size, quantity
5. Automation
6. Visibility: Monitor resources, connectivity
7. Performance: Optimize network device
utilization
8. Multi-tenancy
9. Service Integration
NFV and SDN Washington University in St. Louis

Relationship
 Concept of NFV originated from SDN
 First ETSI white paper showed overlapping Venn diagram
 It was removed in the second version of the white paper
 NFV and SDN are complementary.
One does not depend upon the other.
You can do SDN only, NFV only, or
SDN and NFV.
 Both have similar goals but
approaches are very different.
 SDN needs new interfaces, control modules, applications.
NFV requires moving network applications from dedicated
hardware to virtual containers on commercial-off-the-shelf
(COTS) hardware
 NFV is present. SDN is the future.
 Virtualization alone provides many of the required features
 Not much debate about[Link]
NFV.
17-196
Mobile Network Washington University in St. Louis

Functions
 Switches, e.g., Open vSwitch
 Routers, e.g., Click
 Home Location Register (HLR),
 Serving GPRS Support Node (SGSN),
 Gateway GPRS Support Node (GGSN),
 Combined GPRS Support Node (CGSN),
 Radio Network Controller (RNC),
 Serving Gateway (SGW),
 Packet Data Network Gateway (PGW),
 Residential Gateway (RGW),
 Broadband Remote Access Server (BRAS),
 Carrier Grade Network Address Translator (CGNAT),
 Deep Packet Inspection (DPI),
 Provider Edge (PE) Router,
 Mobility Management Entity (MME),
 Element Management System (EMS)
 Washington University in St. Louis

ETSI NFV ISG

ETSI NFV ISG Network Operator’s Council

Technical Steering Committee

INF WG MANO WG SWA WG REL WG Security EG PER EG

 Industry Specification Group (ISG)’s goal is to define the

requirements.
 Four Working Groups:
 INF: Architecture for the virtualization Infrastructure
 MANO: Management and orchestration
 SWA: Software architecture
 REL: Reliability and Availability, resilience and fault
tolerance
Ref
 Washington University in St. Louis

ETSI NFV ISG (Cont)

 Two Expert Groups:
 Security Expert Group: Security
 Performance and Portability Expert Group:
Scalability, efficiency, and performance VNFs relative to
current dedicated hardware

[Link]

17-199
 Washington University in St. Louis

NFV Specifications
1. NFV Use cases (GS NFV 001)
2. NFV Architectural Framework (GS NFV 002)
3. Terminology for Main Concepts in NFV (GS NFV 003)
4. NFV Virtualization Requirements (GS NFV 004)
5. NFV Proof of Concepts Framework (GS NFV-PER 002)
 17-
201
NFV Concepts
 Network Function (NF): Functional building block with a
well defined interfaces and well defined functional behavior
 Virtualized Network Function (VNF): Software
implementation of NF that can be deployed in a virtualized
infrastructure
 VNF Set: Connectivity between VNFs is not specified, e.g.,
residential gateways
 VNF Forwarding Graph: Service chain when network
connectivity order is important, e.g., firewall, NAT, load
balancer
 NFV Infrastructure (NFVI): Hardware and software required
to deploy, mange and execute VNFs including computation,
networking, and storage.
Network Forwarding Washington University in St. Louis

Graph
 An end-to-end service may include nested forwarding graphs

VNF 2A VNF 2C
End End
VNF 1 VNF-3
Point Point
VNF 2B

Virtualization Layer

Hardware
 Washington University in St. Louis

NFV Concepts (Cont)

 NFVI Point of Presence (PoP): Location of NFVI
 NFVI-PoP Network: Internal network
 Transport Network: Network connecting a PoP to other PoPs
or external networks
 VNF Manager: VNF lifecycle management e.g., instantiation,
update, scaling, query, monitoring, fault diagnosis, healing,
termination
 Virtualized Infrastructure Manager: Management of
computing, storage, network, software resources
 Network Service: A composition of network functions and
defined by its functional and behavioral specification
 NFV Service: A network services using NFs with at least one
VNF.
[Link]

17-203
 Washington University in St. Louis

NFV Concepts (Cont)

 User Service: Services offered to end
users/customers/subscribers.
 Deployment Behavior: NFVI resources that a VNF requires,
e.g., Number of VMs, memory, disk, images, bandwidth,
latency
 Operational Behavior: VNF instance topology and lifecycle
operations, e.g., start, stop, pause, migration, …
 VNF Descriptor: Deployment behavior + Operational
behavior
 NFV Orchestrator: Automates the deployment, operation,
management, coordination of VNFs and NFVI.
 VNF Forwarding Graph: Connection topology of various
NFs of which at least one is a VNF
[Link]

17-204
 Washington University in St. Louis

NFV Architecture
Os-Ma NFV Management and Orchestration
OSS/BSS
Orchestration

Service VNF and Se-Ma

EMS 1 EMS 2 EMS 3 Or-Vnfm
Infrastructure
Description
Ve-Vnfm
VNF 1 VNF 2 VNF 3
VNF Managers
Vn-Nf
Or-Vi
NFVI
Vi-Vnfm
Virtual Computing Virtual Storage Virtual Network
Nf-Vi
Virtualized
Virtualization Layer Infrastructure
Managers
VI-Ha

Computing Hardware Storage Network Hardware

Hardware

Main NFV Reference Points Other NFV Reference Points

Execution Reference Points
NFV Reference Washington University in St. Louis

Points
Reference Point: Points for inter-module specification
1. Virtualization Layer-Hardware Resources (VI-Ha)
2. VNF – NFVI (Vn-Nf)
3. Orchestrator – VNF Manager (Or-Vnfm)
4. Virtualized Infrastructure Manager – VNF Manager (Vi-Vnfm)
5. Orchestrator – Virtualized Infrastructure Manager (Or-Vi)
6. NFVI-Virtualized Infrastructure Manager (Nf-Vi)
7. Operation Support System (OSS)/Business Support Systems
(BSS) – NFV Management and Orchestration (Os-Ma)
8. VNF/ Element Management System (EMS) – VNF Manager
(Ve-Vnfm)
9. Service, VNF and Infrastructure Description – NFV
Management and Orchestration (Se-Ma): VNF Deployment
template, VNF Forwarding Graph, service-related information,
NFV infrastructure information
NFV Framework Washington University in St. Louis

Requirements
1. General: Partial or full Virtualization, Predictable performance
2. Portability: Decoupled from underlying infrastructure
3. Performance: as described and facilities to monitor
4. Elasticity: Scalable to meet SLAs. Movable to other servers.
5. Resiliency: Be able to recreate after failure.
Specified packet loss rate, calls drops, time to recover, etc.
6. Security: Role-based authorization, authentication
7. Service Continuity: Seamless or non-seamless continuity after
failures or migration
 Washington University in St. Louis
NFV Framework Requirements
(Cont)

8. Service Assurance: Time stamp and forward copies of

packets for Fault detection
9. Energy Efficiency Requirements: Should be possible to put
a subset of VNF in a power conserving sleep state
10. Transition: Coexistence with Legacy and Interoperability
among multi-vendor implementations
11. Service Models: Operators may use NFV infrastructure
operated by other operators

[Link]

17-208
NFV Use Cases
 Cloud:
1. NFV infrastructure as a service (NFVIaaS) like IaaS
2. Virtual Network Functions (VNFs) as a service (VNFaaS)
like SaaS
3. VNF forwarding graphs (Service Chains)
4. Virtual Network Platform as a Service (VNPaaS) like
PaaS
 Mobile:
5. Virtualization of the Mobile Core Network and IMS
6. Virtualization of Mobile Base Station
 Data Center:
7. Virtualization of CDNs
 Access/Residential:
8. Virtualization of the Home environment
9. Fixed Access NFV
[Link]

17-209
NFV Proof of Concepts Washington University in St. Louis

(PoCs)
ETSI has formed and NFV ISG PoC Forum.
Following modules have been demoed:
1. Virtual Broadband Remote Access Server (BRAS) by British
Telecom
2. Virtual IP Multimedia System (IMS) by Deutsche Telekom
3. Virtual Evolved Packet Core (vEPC) by Orange Silicon
Valley
4. Carrier-Grade Network Address Translator (CGNAT) and
Deep Packet Inspection (DPI), Home Gateway by Telefonica
5. Perimeta Session Border Controller (SBC) from Metaswitch
6. Deep packet inspection from Procera
Ref: M. Cohn, “NFV Group Flocks to Proof-of-Concept Demos,” Aug 2013,
Most of these are based on Cloud technologies, e.g., OpenStack
[Link]
[Link]

17-210
 Washington University in St. Louis

Summary

1. NFV aims to reduce OpEx by automation and scalability

provided by implementing network functions as virtual
appliances
2. NFV allows all benefits of virtualization and cloud computing
including orchestration, scaling, automation, hardware
independence, pay-per-use, fault-tolerance, …
3. NFV and SDN are independent and complementary. You can
do either or both.
4. NFV requires standardization of reference points and interfaces
to be able to mix and match VNFs from different sources
5. NFV can be done now. Several of virtual functions have
already been demonstrated by carriers.
[Link]

17-211
 [Link] 212

Network Programmability in a
Cisco DNA Architecture
What is Programmable
Network
• A programmable network is one in which the behavior of
network devices and flow control is handled by software that
operates independently of network hardware. The fundamental
nature of programmable networks is to separate the underlying
physical hardware from the control software of a device.
• When the concept of programmable networks first emerged, it
was a revolutionary step in the evolution of computer networks.
It created a paradigm shift of large proportions set against the
staid methods network administrators had long used to
configure networks.
Cont . . .
• Traditionally, network admins configured each device in a
network independently of each other. They used the command-
line interface (CLI) to type hundreds of commands one by one
until a group of devices passed traffic the way they should.
• Some automation techniques existed in those days, mostly in
the form of onerous scripting languages or cutting and pasting.
For example, admins might cut and paste changing localized
device information, such as IP addresses. With the exponential
growth of networks, however, this level of automation was
simply not tenable.
Network programmability
and SDN
• By separating the hardware from the control software, network
programmability enabled software to have a broader view of
the network at large, creating a proverbial 10,000-foot
overview. Software could now be programmed in one place,
using a controller to orchestrate the configuration of the other
hardware devices making up the network.
• This development led to the birth of software-defined
networking (SDN). The term SDN has now largely supplanted
the generic term programmable networks in the common
networking lexicon.
Cont . .
Cont . .
• Using protocols, like OpenFlow and other open and proprietary
standards, network admins can now control and program
networks from one place and time. All underlying hardware
works together, as if someone had punched in all those CLI
commands on each device.

• This critical advancement enabled scalable networks that could

reach the size and scope needed to support 
growing cloud and containerization workloads that put more
stress on infrastructure.
API
• Programmable networks also facilitated the advancement of
application programming interfaces (APIs). APIs are a software
construct that have been around almost as long as computers,
enabling one piece of software to talk to another piece of
software.
• Controllers use APIs to speak to the devices under their
control. But the software controller itself can be accessed via
industry standard RESTful APIs, enabling anyone to write
custom software to orchestrate a programmable network.
Infrastructure as a
code
• The process of using APIs to control networks is now
commonplace. The scale and scope of modern networks
simply do not allow for older device-by-device configuration in
any but the smallest of networks.
• With enterprises embracing virtualization, containerization and
cloud deployments, another concept called infrastructure as
code (IaC) has taken hold. IaC is the concept of using software
to completely build a network from the ground up, including
storage and compute, on top of an abstracted hardware layer.
IaCode
• Infrastructure as code, or IaC, uses automated control scripts
to configure, manage and monitor software infrastructure. The
scripts are stored in a software code repository, like Git.
Automated processes check out the scripts and execute them
to create an entire application infrastructure efficiently without
manual intervention.
• IaC is best implemented in environments where the underlying
physical infrastructure is standardized. Adding automated tests
enables changes to applications and supporting infrastructure
to be easily tested before applying those changes to the
production environment. This process is typically known as 
continuous integration and continuous deployment. It
significantly reduces the risk of deploying a defective
application update.
Cont . . .
What is network infrastructure as code?
• IaC for networking involves similar methods to create and maintain
the physical (underlay) and virtual (overlay) networks. A network
configuration repository, like Git, houses the configuration
templates and variables. Automation tools are triggered when the
repository changes. The resulting automations check out the new
configuration definitions, perform variable replacement and deploy
the updated configurations. This is more complex than having a
few simple scripts that perform basic automation tasks, so teams
should anticipate the effort that will be required.
• Adopting network IaC is simpler when the network uses a
standardized physical and virtual network. The ideal approach
creates a few building-block network segments, like a branch site, 
data center pod, internet access block, office Wi-Fi segment, etc.
The building blocks are interconnected using well-defined
interfaces, or links.
 Cont . . .
This building-block approach has many benefits, such as the following:
• reduced variability;
• easier to create test environments;
• repeatable monitoring and troubleshooting;
• well-defined bill of materials; and
• most importantly, a consistent configuration.
• Network teams can certainly develop a full network IaC
implementation from scratch, using tools like Python and Ansible,
but that's not necessary. The alternative is to use a commercial
network configuration automation product's APIs to simplify the
effort. Keep in mind that the API approach is essential for integrating
multiple controller-based systems used for things like software-
defined WAN, data centers, Wi-Fi, security and IP address
management.
Cont . . .
• The ultimate IaC implementation employs a fully 
automated continuous integration and continuous deployment
process
. In the software and application world, this process is generally
straightforward: Fire up multiple application VMs and some test
clients, and run through a set of automated tests. If the tests
pass, deploy the application into production.
• The networking world often needs physical hardware that
includes specific features not available in virtual
implementations. Building physical test labs containing this
hardware is time-consuming and expensive. Generating test
traffic is a challenge, as is creating tests to guarantee the
network's correct operation when pushing the configuration
updates into the production network. Using standard building-
block designs helps mitigate these challenges.
Adopting
• Most organizations can easily achieve the technical process of
adopting network IaC. The real challenge, however, is the culture
change. The organization must accept that, in some cases, a site
implementation may use a building-block design that's more
expensive than a nonstandard option. The reductions in
operational cost and risk invariably cover the expense.
• Network teams must adopt an IaC mindset that all network
changes go through the defined deployment process and that
manual changes to the network are not permitted. Network
validation tests become absolutely critical to the success of the
initiative, and it can be challenging to create sufficiently
comprehensive tests.
• Note that creating the changes and identifying the test parameters
are functions an existing network engineer traditionally performs.
The automation element can be provided by commercial products
or by an IaC software development team; not everyone needs to
have software development skills.
Benefit
• Adopting network IaC has numerous benefits, including the
following:
• Track changes. It's easy to track infrastructure changes
because they're made in network configuration templates and
variables. This makes it easy to identify and revert a failed
configuration change.
• Deploy small changes regularly. An automated process with
validation testing makes it easy to deploy small changes on a
regular basis. Teams avoid big maintenance windows that
incorporate multiple configuration changes, some of which may
interact with one another.
• Overall ease. Smaller changes are much easier to understand,
easier to automate, easier to test and have fewer side effects.
Cont . . .
• Fewer errors. Network IaC eliminates manual processes and
corresponding human errors.
• Pre-change state validation. Unit tests validate the pre-change
network state, preventing a change from being applied if the
network isn't performing as expected.
• Post-change state verification. Unit tests verify that the
network's operational state is correct after the change is deployed.
• Test environments. When continuous integration and continuous
deployment processes are used, the proposed change is validated
in a test environment prior to being deployed into the production
network, significantly reducing the risk of a bad change.
The ultimate benefit of network IaC is to the business. First, it
significantly reduces the risk of network configuration changes. It also
supports Agile business processes that provide the business with a
competitive advantage.
Agile Networking
Benefits
Programmable networking has several benefits over traditional
networking, including the following:
• reduced long-term costs;
• ability for applications to maintain information about device
capabilities;
• ability for networks to respond to application status and
resource requirements;
• better allocation of bandwidth and resources;
• packet prioritization for traffic shaping; and
• improved operational flexibility and enhanced transparency.
Network Analytics in Cisco DNA
 [Link] 230

Network Analytics in Cisco DNA

• Cisco Digital Network Architecture (Cisco DNA) analytics is the
discovery and communication of business insights through the
exploration of data from various sources that attach to the network.
• Are you looking to find answers to questions such as the following?
• How can I leverage the information that traverses the network to
improve my user experience?
• Is my network secure and compliant with the applicable
regulations?
• What is the “normal” behavior for my applications?
• What are the performance levels of my network end to end?
• If so, then you need to collect, correlate, and analyze a lot of data
and present it in such a way that that it makes it useful and
actionable. This is what analytics helps you to achieve.
Analytics
• The term “analytics” is overused and applies to different disciplines
besides IT and networking. It’s becoming a buzzword and means
different things to different people. So let’s start by defining
“analytics” to set a common ground and eliminate ambiguity.
• Analytics is commonly defined as the discovery, interpretation, and
communication of meaningful patterns in data.
• Analytics is definitely about the data and may actually involve a lot
of it, to the point that it is often presented as a Big Data problem;
but that is not enough to fully describe it.
• Analytics is first of all the discovery of data, because you cannot
measure what you don’t see.
• Analytics is also the interpretation and correlation of data: digging
through the information from different data sources and correlating
it in a way that makes you discover the embedded value.
Cont . . .
• How many times have you looked through hundreds of lines of
syslog output and were not able to identify the relevant
messages you were really looking for?
• Or maybe your network is experiencing a peak in Dynamic
Host Configuration Protocol (DHCP) requests and AAA login
sessions; this could be a symptom of a security attack or an
issue in the network, but if this happens in a university at 8
a.m., then it’s absolutely normal and you should not get a
notification.
• A famous 19th-century American mathematician, John Tukey,
explains it very well: “The greatest value of a picture is when it
forces us to notice what we never expected to see.” This is
exactly what analytics is supposed to do: extracting the value
from the data.
Cont . . .
• Finally, analytics is about the communication of the discovered
meaningful patterns. It is about presenting the data in such a
way that it becomes useful and actionable.
• Giving you access to the information you want is a first great
step, but making that same data actionable is the main goal of
analytics. This is how analytics ultimately enables assurance to
verify that the business intent has been conveyed.
• If it has not, then assurance automates the necessary
changes to remediate.
Cisco DNA Analytics
• The general definition of analytics is now clear. More specifically
focusing on IT and networking, network analytics is the process of
extracting data from the network and correlating it to identify
anomalies, derive insights, and enable data-driven decisions.
• Referring to an IT industry definition and considering how the
derived information can be used, network analytics may be
represented by three different categories:
• Operations analytics: Applying analytics to large data sets for IT
operations to extract unique business insights. Examples are
security threat detection and compliance, network performance, and
user and application profiling.
• IoT analytics: The processing and analyzing of data from multiple
IoT sensors that attach to the network.
• Business analytics: The use of the network information combined
with social media and business-relevant data to extract business and
customer insights.
 Cont. . .
• If you consider the possible sources of information, network analytics is also defined
through the following extended set of categories:
• Infrastructure analytics: This refers to the analysis of the information
extracted from the network devices themselves (switches, router,
firewall, access points, etc.).
• Endpoint analytics: Gaining information from the end devices (IoT
sensors, video cameras, badge readers, etc.) attached to the network
contributes greatly to the overall knowledge of the network and its
performance.
• Application analytics: Application profiling information is crucial to
verify, for example, that SLAs are being met or to characterize traffic
patterns.
• User analytics: This is about gaining visibility on the user context,
including authentication, authorization, and movements information and
correlating it with traffic patterns.
• Policy analytics: This involves gaining insights into how the Cisco DNA
policies get applied throughout the network.
Cont . . .
• Cisco DNA Analytics is the Cisco implementation of network
analytics that leverages the Cisco network as an incredible
source of information. Just think about it, the network connects
everything (users, devices, applications, and processes) and
transports all the information that these assets produce. The
network is the ideal place to get insights.
• Cisco DNA Analytics gathers data from all the categories just
mentioned. Single data source visibility and reporting is good,
but not adequate for solving complex problems. Most of the
analytics solutions available today just look at one of these
data sets and provide a silo solution. The real value-add of
Cisco DNA Analytics is the correlation of the multiple data
sources; this is what transforms network data into actionable
insights that help customers make business decisions, reduce
operating expenses (OPEX), and create accurate forecasts.
Cisco DNA
• Cisco DNA analytics achieves this by enabling three important
benefits of the Cisco DNA architecture: closing the Cisco DNA
Assurance loop, gaining critical network insights, increasing
security by real-time and dynamic threat defense.
• Analytics plays an important and horizontal role in Cisco DNA by
providing the necessary telemetry to Cisco DNA center and
Assurance in order to verify if the business intent was met.
Second, it extract important information about the wired and
wireless devices and the user experience end to end, which helps
the administrator to effectively monitor and troubleshoot the
network.
• Last but not least, Cisco DNA Analytics provides relevant data that
enables the network itself to behave as a sensor and hence
increase the visibility of possible security threats.
Role
Data Source
• Analytics is about data. Data is defined as any valuable
information carried by the network, such as

• User context
• Device and application information
• Network device–related data
• Environmental information from sensors
• The data may be consumed by multiple “users”: network
administrators for monitoring, application developers, etc.
• When considering Network Analytics, data is gathered from
different sources; potentially everything that connects to the
network is a source of information,
Cont . . .
Telemetry
• Telemetry is not new in networking. SNMP has been around
since 1998, so for more than 30 years network administrators
have been using different types of methods to gather
information from the network. Syslog, NetFlow, and so forth are
all examples that are referred to as telemetry. Today these
traditional approaches have problems keeping up with the
scale and speed of modern networks.
• New approaches such as streaming telemetry are promising to
answer today’s challenges. This section first explains the need
for telemetry, then describes telemetry in the context of Cisco
DNA, highlighting the limitations of traditional approaches, and
wraps up by introducing the new Model-driven Telemetry
(MDT).
Cont . . .
• What is the role of telemetry in the Cisco DNA architecture?
The Cisco DNA circle of life represents how Cisco DNA brings
together automation, analytics, and assurance to provide a
closed feedback loop to the customer.
• The network administrator expresses the business intent; the
Cisco DNA controller translates it and deploys it in the network
using automation; then Cisco DNA analytics extracts the
relevant information from the network and feeds it back to the
assurance module to verify that the intent has been met.
• Telemetry is the component that is responsible for extracting
and transporting this key information,
 Why Telemetry
• Before getting into the details of the architecture, let’s start by
understanding why Telemetry is necessary. Here are few simple
questions:
• Do people complain about the network and you don’t
understand why?
• Do you often hear that the network is impacting your
organization’s ability to achieve its business goals?
• Do you know if the QoS policy you have just applied has
actually produced the wanted results?
• If you have answered yes to any of these questions, chances are you
need a solution to monitor and analyze data from your network. And
when it comes to network monitoring, everything is based on
Telemetry because the data is generated in the network devices that
are usually physically separated from where the information is stored
and analyzed.
Cisco Telemetry
Cont. . .
• Data is generated at the device level. You can have hardware
sensors (network devices or dedicated sensors) or software
sensors (software agents on user devices and servers)
streaming information to an upstream collector.
• The information comes in multiple types and formats: events
(like the ones generated by SNMP), logs (like syslog or AAA),
or metric data (like the different counters on a network device).
• On the other end of the network, the data consumption layer is
where the telemetry data is actually stored, analyzed,
visualized, and used as the basis for meaningful actions;
usually there are multiple collectors and servers utilizing
multiple types of interfaces/APIs toward the network.
Cont . . .
• Connecting the two layers, today you have many different ways
and protocols that visualize and transport the telemetry data:
Command Line Interface (CLI), SNMP, syslog, NetFlow, and
Radius, just to mention a few.
• This is a problem for a Telemetry solution because the upper
layer has to deal with multiple data formats, with often-
redundant information and with the risk of receiving too much
data. Let’s explore some of the limitations of the current
protocols and how Cisco DNA Telemetry changes the game in
terms of transport efficiency.
 [Link] 247

DNA Analytics Architecture

• Networks offer rich sets of telemetry data that include the

following:
• NetFlow records
• Device statistics (CPU and memory utilization, interface counters,
etc.)
• Simple Network Management Protocol (SNMP) data
• Internet Protocol Service Level Agreement (IP SLA) performance
measurements
• System event (syslog) records

• Collecting data from the network is not the hard part. Making
use of it, doing something interesting with it and gaining
insights, is more challenging. In other words, how do you go
from data to information, and then to knowledge?
 Cont . . .
• Imagine you are gathering analytics on a wireless network. Most of
the management tools available in the market provide information
such as top access points in terms of client count, the so-called “hot
zones.” That’s important information, but what about “cold zones,” or
wireless access points (AP) that are indicating zero clients
associated while historically they were serving users normally?
• Which information would be more indicative of a problem in the
wireless network? Probably it’s the latter because it can indicate that
something is wrong with the AP’s radios. The point is: you need to
make sure you get the right information, the information that counts.
• Gathering data can be expensive in terms of local resources on the
network device (mainly CPU and memory) and bandwidth
consumption to transport the data to a remote destination for further
analysis. So you cannot simply take all the data; it would be too
much.
 [Link] 249

DNA Analytics Proof Points

 [Link] 250

Network Data Platform Architecture

 [Link] 251

CMX on Premises
 [Link] 252

Context-Aware Service Architecture

 [Link] 253

Cisco CMX Connect

 [Link] 254

Cisco CMX Analytics

 [Link] 255

Cisco CMX API

Thank You