Introduction to Controller-Based

Networking
This chapter covers the following exam topics:
1.0 Network Fundamentals
1.1 Explain the role and function of network components
1.1.f Endpoints
1.1.g Servers
1.2 Describe characteristics of network topology architectures
1.2.c Spine-leaf
6.0 Automation and Programmability
6.1 Explain how automation impacts network management
6.2 Compare traditional networks with controller-based networking
6.3 Describe controller-based and software defined architectures (overlay,
underlay, and fabric)
6.3.a Separation of control plane and data plane
6.3.b Northbound and southbound APIs

www.itroute.com.au 1
Why SDN ?
• Networking devices forward data in the form of
messages, typically data-link frames like Ethernet
frames.
• Network programmability and Software Defined
Networking (SDN) take those ideas, analyze the
pieces, find ways to improve them for today’s
needs, and reassemble those ideas into a new way
of making networks work.
• At the end of that rearrangement, the devices in
the network still forward messages, but the how
and why have changed.

www.itroute.com.au 2
Why SDN?

www.itroute.com.au 3
The Data, Control, and
Management Planes
• Everything that networking devices do can be
categorized as being in a particular plane.
• This section takes those familiar facts about how
networking devices work and describes the three
planes most often used to describe how network
programmability works:
• the data plane
• the control plane
• the management plane.

www.itroute.com.au 4
www.itroute.com.au 5
The Data Plane
• The term data plane refers to the tasks that a networking device does to
forward a message. In other words, anything to do with receiving data,
processing it, and forwarding that same data.
• Common Data plane protocols:
• De-encapsulating and re-encapsulating a packet in a data-link frame
(routers, Layer 3 switches)
• Adding or removing an 802.1Q trunking header (routers and switches)
• Matching an Ethernet frame’s destination Media Access Control (MAC)
address to the MAC address table (Layer 2 switches)
• Matching an IP packet’s destination IP address to the IP routing table
(routers, Layer 3 switches)
• Encrypting the data and adding a new IP header (for virtual private
network [VPN] processing)
• Changing the source or destination IP address (for Network Address
Translation [NAT] processing)
• Discarding a message due to a filter (access control lists [ACLs], port
security)

www.itroute.com.au 6
The Control Plane
• The term control plane refers to any action that
controls the data plane.
• Common control plane protocols:
• Routing protocols (OSPF, Enhanced Interior
Gateway Routing Protocol [EIGRP], Routing
Information Protocol [RIP], Border Gateway
Protocol [BGP])
• IPv4 ARP
• IPv6 Neighbor Discovery Protocol (NDP)
• Switch MAC learning
• STP
www.itroute.com.au 7
The Management Plane
• Telnet and Secure Shell (SSH) are two of the most
obvious management plane protocols.
• To emphasize the difference with control plane
protocols, think about two routers: one configured
to allow Telnet and SSH into the router and one
that does not.
• Both could still be running a routing protocol and
routing packets, whether or not they support Telnet
and SSH.

www.itroute.com.au 8
www.itroute.com.au 9
Controllers and Software-
Defined Architecture
• A controller, or SDN controller, centralizes the
control of the networking devices. The degree of
control, and the type of control, varies widely..
• Alternately, the controller can simply be aware of
the ongoing work of the distributed data, control,
and management planes on the devices, without
changing how those operate.
• First, the controller sits anywhere in the network
that has IP reachability to the devices in the
network. The networking devices do not populate
their forwarding tables.

www.itroute.com.au 10
www.itroute.com.au 11
The Southbound Interface

• In a controller-based network architecture, the

controller needs to communicate to the networking
devices. There is an interface between the
controller and those devices, the interface came to
be known as the southbound interface, or SBI.

www.itroute.com.au 12
• Several different options exist for the SBI. The
overall goal is network programmability, so the
interface moves away from being only a protocol.
• An SBI often includes a protocol, so that the
controller and devices can communicate, but it
often includes an application programming
interface (API).
• An API is a method for one application (program) to
exchange data with another application. Programs
process data, so an API lets two programs exchange
data.

www.itroute.com.au 13
The Northbound Interface
• What kind of information would your program need to
gather before it could attempt to add something like
MAC table entries or IP routes to a network?
• You might think of these:
• A list of all the devices in the network
• The capabilities of each devices
• The interfaces/ports on each device
• The current state of each port
• The topology—which devices connect to which, over
which interfaces
• Device configuration—IP addresses, VLANs, and so on
as configured on the devices
www.itroute.com.au 14
• A controller’s northbound interface (NBI) opens the
controller so its data and functions can be used by
other programs, enabling network
programmability, with much quicker development.
• Programs can pull information from the controller,
using the controller’s APIs.
• The controller is software, running on some server,
which can be a VM or a physical server. An
application can run on the same server as the
controller and use an NBI, which is an API, so that
two programs can communicate.

www.itroute.com.au 15
PROGRAMMABILITY AND SDN

• This sections introduces three different SDN and

network programmability solutions available from
Cisco. Others exist as well. These three were
chosen because they give a wide range of
comparison points:
• OpenDaylight Controller
• Cisco Application Centric Infrastructure (ACI)
• Cisco APIC Enterprise Module (APIC-EM)

www.itroute.com.au 16
www.itroute.com.au 17
Comparing Traditional
Networks with Controller-
Based Networks
• By centralizing some of the functions in the network and
providing robust APIs, controllers enable a large number of new
operational models.
• Those models include the three most likely to be seen from Cisco
in an enterprise: Software-Defined Access (SDA), Software-
Defined WAN (SD-WAN), and Application Centric Infrastructure
(ACI).
• This changes the operating paradigm in many cases, with the
controller determining many device-specific details:
• The network engineer does not need to think about every
command on every device.
• The controller configures the devices with consistent and
streamlined settings.
• The result: faster and more consistent changes with fewer issues.

www.itroute.com.au 18
www.itroute.com.au 19
Cisco Software-Defined Access (SDA)
• This chapter covers the following exam topics:
• 1.0 Network Fundamentals
• 1.1 Explain the role and function of network components
• 1.1.e Controllers (Cisco DNA Center and WLC)
• 6.0 Automation and Programmability
• 6.1 Explain how automation impacts network management
• 6.2 Compare traditional networks with controller-based networking
• 6.3 Describe controller-based and software defined architectures
(overlay, underlay, and fabric)
• 6.3.a Separation of control plane and data plane
• 6.3.b Northbound and southbound APIs
• 6.4 Compare traditional campus device management with Cisco DNA
Center enabled device management

www.itroute.com.au 20
• Cisco Software-Defined Access (SDA) uses a software defined
networking approach to build a converged wired and wireless campus
LAN.
• SDA include a centralized controller—DNA Center—with southbound
and northbound protocols. It also includes a completely different
operational model inside SDA, with a network fabric composed of an
underlay network and an overlay network.
• SDA fills the position as Cisco’s campus offering within Cisco Digital
Network Architecture (DNA). Cisco DNA defines the entire architecture
for the new world of software defined networks, digitization, and Cisco’s
reimagining of how networks should be operated in the future. This
chapter introduces SDA, which exists as one implementation of Cisco
DNA.

www.itroute.com.au 21
www.itroute.com.au 22
SDA Overlay, UNDERLAY, AND
FABRIC
• Overlay: The mechanisms to create VXLAN tunnels
between SDA switches, which are then used to
transport traffic from one fabric endpoint to another
over the fabric.
• Underlay: The network of devices and connections
(cables and wireless) to provide IP connectivity to all
nodes in the fabric, with a goal to support the dynamic
discovery of all SDA devices and endpoints as a part of
the process to create overlay VXLAN tunnels.
• Fabric: The combination of overlay and underlay, which
together provide all features to deliver data across the
network with the desired features and attributes.

www.itroute.com.au 23
www.itroute.com.au 24
DNA CENTER AND SDA OPERATION
• Cisco DNA Center has two notable roles:

• The first role as SDA network controller gets most

of the attention and is the topic of discussion in this
second of the three major sections of this chapter.
• SDA and DNA Center go together, work closely
together, and any serious use of SDA requires the
use of DNA Center. At the same time, DNA Center
can manage traditional network devices

www.itroute.com.au 25
www.itroute.com.au 26
Cisco DNA Center
• Cisco DNA Center
exists as a software
application that Cisco
delivers pre-installed
on a Cisco DNA
Center appliance. The
software follows the
same general
controller.

www.itroute.com.au 27
• Cisco DNA Center includes a robust northbound REST API along
with a series of southbound APIs.
• You can think of these as two categories:
Protocols to support traditional networking devices/software
versions:
• Telnet, SSH, SNMP
Protocols to support more recent networking devices/software
versions:
• NETCONF, RESTCONF
• Cisco DNA Center needs the older protocols to be able to support
the vast array of older Cisco devices and OS versions.
• Over time, Cisco has been adding support for NETCONF and
RESTCONF to their more current hardware and software.

www.itroute.com.au 28
DNA Center Differences with
Traditional Management
• There are several fundamental differences between
Cisco DNA Center and traditional network management
platforms like Cisco PI.
The largest difference:
• Cisco DNA Center supports SDA, whereas other
management apps do not. Cisco PI still had some
traditional management features not found in Cisco
DNA Center.
• So think of PI as comprehensive to traditional device
management, with Cisco DNA Center having many of
those features, while focusing on future features like
SDA support.
www.itroute.com.au 29
Cisco DNA Center features
1. Easier initial installation, simplify the work to
implement features that traditionally have challenging
configuration, and use tools to help you notice issues
more quickly.
2. Easy QoS: Enables Cisco DNA to use algorithms to
recognize security threats even in encrypted traffic
3. Device 360 and Client 360: Gives a comprehensive
view of the health of the device Network time travel:
4. Path trace: Discovers the actual path packets would
take from source to destination based on current
forwarding tables.

www.itroute.com.au 30
www.itroute.com.au 31
Understanding REST and JSON
• This chapter covers the following exam topics:
• 6.0 Automation and Programmability
• 6.5 Describe characteristics of REST-based APIs
(CRUD, HTTP verbs, and data encoding)
• 6.7 Interpret JSON encoded data

www.itroute.com.au 32
 Understanding REST
and JSON
• To automate and program networks, some automation
software does several tasks. The software analyzes data
in the form of variables, makes decisions based on that
analysis, and then may take action to change the
configuration of network devices or report facts about
the state of the network.
• The different automation functions reside on different
devices.
• The network engineer’s device, a server, a controller,
and the various network devices themselves. For these
related automation processes to work well, all these
software components need useful well-defined
conventions to allow easy communication between
software components.
www.itroute.com.au 33
www.itroute.com.au 34
REST-BASED APIS
• Applications use application programming interfaces (APIs)
to communicate. To do so, one program can learn the
variables and data structures used by another program,
making logic choices based on those values, changing the
values of those variables, creating new variables, and
deleting variables.
• APIs allow programs running on different computers to
work cooperatively, exchanging data to achieve some goal.
In an API software world, some applications create an API,
with many other applications using (consuming) the API.
• Software developers add APIs to their software so other
application software can make use of the first application’s
features. When writing an application, the developer will
write some code, but often the developer may do a lot of
work by looking for APIs that can provide the data and
functions, reducing the amount of new code that must be
written.
www.itroute.com.au 35
Client/Server Architecture
• Like many applications, REST applications use a
client/server architectural model.
• 1. The REST client on the left executes a REST API
call, which generates a message sent to the REST
server.
• 2. The REST server on the right has API code that
considers the request and decides how to reply.
• 3. The REST server sends back the reply message
with the appropriate data variables in the reply
message.

www.itroute.com.au 36
www.itroute.com.au 37
REST APIs and HTTP
• APIs exist to allow two programs to exchange data. Some
APIs may be designed as an interface between programs
running on the same computer, so the communication
between programs happens within a single operating
system. Many APIs need to be available to programs that
run on other computers, so the
• API must define the type of networking protocols supported
by the API—and many REST-based APIs use the HTTP
protocol.
• HTTP’s logic matches some of the concepts defined more
generally for REST APIs. HTTP uses the same principles as
REST: it operates with a client/server model; it uses a
stateless operational model; and it includes headers that
clearly mark objects as cacheable or not cacheable. It also
includes verbs— words that dictate the desired action for a
pair HTTP Request and Reply—which matches how
applications like to work.
www.itroute.com.au 38
Software CRUD Actions and HTTP
Verbs
• The software industry uses a memorable acronym—CRUD—
for the four primary actions performed by an application.
• Those actions are
• Create: Allows the client to create some new instances of
variables and data structures at the server and initialize
their values as kept at the server
• Read: Allows the client to retrieve (read) the current value
of variables that exist at the server, storing a copy of the
variables, structures, and values at the client
• Update: Allows the client to change (update) the value of
variables that exist at the server
• Delete: Allows the client to delete from the server different
instances of data variables

www.itroute.com.au 39
www.itroute.com.au 40
DATA SERIALIZATION AND JSON

www.itroute.com.au 41
Nonworking example
• The REST client asks for a resource, and the server needs to
reply. In REST, a resource is a set of variables as defined by
the API, so the REST server needs to return a set of variables
to the REST client on the left. The steps run as follows:
• 1. The REST server (a JAVA application) takes a copy of the
stored variables in RAM (step 1) in response to the REST
request.
• 2. The REST API code creates the REST reply and sends it
over the network, placing an exact replica of what the REST
server had in RAM to represent the variables in that
resource.
• 3. The REST client (a Python application) receives the REST
reply message, storing the exact same bits and bytes into its
RAM, in an attempt to have a copy of the variables, data,
and data structures on the server.
www.itroute.com.au 42
www.itroute.com.au 43
www.itroute.com.au 44
Understanding Ansible, Puppet, and Chef

• This chapter covers the following exam topics:

• 6.0 Automation and Programmability
• 6.6 Recognize the capabilities of configuration mechanisms
Puppet, Chef, and Ansible By now, you have seen how to use
the IOS CLI to configure routers and switches. To configure
using the CLI, you get into configuration mode, issue
configuration commands (which change the running-config
file), and eventually leave configuration mode.
• If you decide to keep those changes, you save the
configuration to the startup-config file using the copy
running-config startup-config command. Next time the
router or switch boots, the device loads the startup-config
file into RAM as the running-config. Simple enough.
www.itroute.com.au 45
DEVICE CONFIGURATION
CHALLENGES AND SOLUTIONS
• Configuration drift becomes a much bigger problem if using
only traditional manual configuration tools. For instance:
• The on-device manual configuration process does not track
change history: which lines changed, what changed on each
line, what old configuration was removed, who changed the
configuration, when each change was made.
• External systems used by good systems management
processes, like trouble ticketing and change management
software, may record details. However, those sit outside the
configuration and require analysis to figure out what
changed.
• Referring to historical data in change management systems
works poorly if a device has gone through multiple
configuration changes over a period of time.

www.itroute.com.au 46
Centralized Configuration Files
and Version Control
• The manual per-device configuration model makes
great sense for one person managing one device.
• With that model, the one network engineer can use
the on-device startup-config as the intended ideal
configuration. If a change is needed, the engineer
gets into configuration mode and updates the
running-config until happy with the change.
• Then the engineer saves a copy to startup-config as
the now-current ideal config for the device.

www.itroute.com.au 47
ANSIBLE, PUPPET, AND CHEF BASICS
• Ansible, Puppet, and Chef are software packages. You can
purchase each tool, with variations on which package.
• However, they all also have different free options that allow
you to download and learn about the tools, although you
might need to run a Linux guest because some of the tools
do not run in a Windows OS.
• As for the names, most people use the words Ansible,
Puppet, and Chef to refer to the companies as well as their
primary configuration management products.
• All three emerged as part of the transition from hardware-
based servers to virtualized servers, which greatly increased
the number of servers and created the need for software
automation to create, configure, and remove VMs.

www.itroute.com.au 48
Ansible
• To use Ansible you need to install Ansible on some
computer: Mac, Linux, or a Linux VM on a Windows
host.
• Once it is installed, you create several text files, such as
the following:
• Playbooks: These files provide actions and logic about
what Ansible should do
• Inventory: These files provide device hostnames along
with information about each device, like device roles,
so Ansible can perform functions for subsets of the
inventory Templates Variables: Using YAML, a file can
list variables that Ansible will substitute into templates.

www.itroute.com.au 49
www.itroute.com.au 50
Puppet
• To use Puppet begin by installing Puppet on a Linux host. You can
install it on your own Linux host, but for production purposes, you
will normally install it on a Linux server called a Puppet master.
• Once installed, Puppet also uses several important text files with
different components, such as the following:
• Manifest: This is a human-readable text file on the Puppet master,
using a language defined by Puppet, used to define the desired
configuration state of a device.
• Resource, Class, Module: These terms refer to components of the
manifest, with the largest component (module) being composed
of smaller classes, which are in turn composed of resources.
• Templates: Using a Puppet domain-specific language, these files
allow Puppet to generate manifests (and modules, classes, and
resources) by substituting variables into the template.

www.itroute.com.au 51
Chef
• Chef exists as software packages you install and run.
• Once Chef is installed, you create several text files with
different components, like the following:
• Resource: The configuration objects whose state is managed
by Chef; for instance, a set of configuration commands for a
network device—analogous to the ingredients in a recipe in
a cookbook
• Recipe: The Chef logic applied to resources to determine
when, how, and whether to act against the resources—
analogous to a recipe in a cookbook Cookbooks: A set of
recipes about the same kinds of work, grouped together for
easier management and sharing
• Runlist: An ordered list of recipes that should be run against
a given device

www.itroute.com.au 52
www.itroute.com.au 53
Comparing Ansible, Puppet,
and Chef

www.itroute.com.au 54