What does provisioning mean?

In IT, when something is provisioned, it is ready for use. For example, when a user is successfully connected
to Wi-Fi, that user is said to be provisioned with Wi-Fi.

How does network provisioning benefit a business?

When done right, network provisioning can bring enterprises greater efficiency and more secure operations.
Network management staff can spend less time on setup and configurations, and business operations become
more secure and streamlined.

What are the challenges of network provisioning?

Without automation, the key challenges are related to the growth in the number and variety of devices, the
expansion of remote work settings, and the high activity present in today's business networks.

For organizations with many users connected to WANs, many temporary users, or a need to scale up or down
rapidly, network provisioning can be very time-consuming.

How does automation improve network provisioning?

With automated provisioning, network management staff spend less time creating and deploying policies,
assigning IP addresses, and configuring IP-based devices. Automation can also reduce errors that slow down
network performance.

In many cases, the automated provisioning process can be performed by one person instead of a team.
Automation tools also help monitor and enhance network optimization as the network grows and changes.
The tools provide a record of actions that can later be used to perform system audits.

Types of network provisioning

Server provisioning
To function on a network, a server--cloud-based or on-premises--must first be provisioned with the right data,
software, and configuration.

The steps in this process typically include:

 Installing an operating system, device drivers, and partitioning and setup tools

 Installing enterprise software and applications

 Setting parameters such as IP addresses

 Performing partitioning or installation of virtualization software

 Connecting to Ethernet and Wi-Fi, if applicable

 Performing an audit of the system to help ensure no fixes are needed

If the server is cloud-based, these provisioning steps will be done with a web-based interface. ISPs and cloud
providers often supply tools to make server provisioning easier, and many vendors offer solutions for
automating the server provisioning process.

Device provisioning
Before hardware can be deployed, it must be customized, configured, secured, and verified. While many
devices are assigned to specific employees, in enterprise networks, device identity and user identity are
always separated. This allows greater flexibility in deploying devices, more detailed device management, and
better management of shared devices.

Internet-access provisioning
This process begins by contracting with an ISP to connect and activate an Internet gateway.

Other steps include installing and configuring wireless access points; setting up and securing a cabled or
wireless LAN; configuring hardware for firewall software; editing software to accurately include the new
LAN; adding the new LAN to network monitoring tools; and testing the systems.

User provisioning
User provisioning involves an organization's IT and human resources departments. When employees are
onboarded, promoted, or transferred, they must be provisioned with enterprise identities along with the
hardware, software, database access, and other resources relating to their roles.

Just as important is the removal of these items when employees leave the organization.

Note that "users" can refer not just to employees, but also to contractors, partners, vendors, or customers. In
other words, "user" refers to anyone who needs dedicated hardware or access to data or applications.
Network provisioning is the process of setting up a network so that authorized users,
devices, and servers can access it. In practice, network provisioning primarily concerns
connectivity and security, which means a heavy focus on device and identity management.

What is software-defined networking?

Software-defined networking (SDN) is an architecture designed to make a network more flexible and easier
to manage. SDN centralizes management by abstracting the control plane from the data forwarding function
in the discrete networking devices.

SDN elements
An SDN architecture delivers a centralized, programmable network and consists of the following:

 A controller, the core element of an SDN architecture, that enables centralized management and
control, automation, and policy enforcement across physical and virtual network environments

 Southbound APIs that relay information between the controller and the individual network devices
(such as switches, access points, routers, and firewalls)

 Northbound APIs that relay information between the controller and the applications and policy
engines, to which an SDN looks like a single logical network device

SDN adoption
SDN has seen wide adoption across data centers (64%), WANs (58%), and access networks (40%). For more
information on SDN trends, see the 2020 Global Networking Trends report.

SDN and IBN

SDN serves as a foundational element of a comprehensive intent-based networking (IBN) architecture. SDN
has been limited to automated provisioning and configuration. IBN now adds "translation" and "assurance" so
you can automate the complete network lifecycle and continuously align the network to business needs.
Watch our Beyond SDN webinar recording to explore more ways intent is changing how we network.

Features and benefits

Simplify operations
Reduce complexity by decoupling the control and data planes, while making automation highly secure and
scalable.

Achieve faster time to market

Deploy applications and services faster by leveraging open APIs. Easily integrate third-party products.

Build programmable networks

Eliminate manual configuration. Provision and manage data centers, campuses, and wide-area networks.
Lay the foundation for intent
Centralize configuration, management, control, monitoring, service delivery, and cloud automation.

Find the best SDN solution for you

For data center managers

Increase business agility: automate provisioning and operations, enhance security, and enable multicloud.

 Application-Centric Infrastructure (ACI)

For network managers

Design, provision, and manage highly secure networks that provide access to any application.

 Cisco DNA Center

 SD-Access
 SD-WAN
 SD-Branch
 See what customers have to say

Simplicity, scalability, security

With Cisco ACI, Ameritas has increased business agility through operational efficiency, unmatched security,
and a seamless path to multicloud.

Enhance the user experience

Montana State University has powered up intent-based networking and improved scalability with Cisco
Software-Defined Access and Cisco Digital Network Architecture.
A connected digital county
Durham County has automated data center services and policies, so engineers can spend less time managing
the data center network and more time focusing on strategic initiatives.
Introduction to SDN (Software Defined Networking)

Lesson Contents
Traditional Networking
o Control Plane
o Data Plane
o Management Plane
Limitations of traditional networking
SDN (Software Defined Networking)
o Southbound Interface
o Northbound Interface
o REST API
Conclusion
SDN (Software Defined Networking) is the latest buzzword in IT, getting more popular every year. Some network
engineers read or heard stories about how the entire network will be programmed in the future, and now fear that
their jobs will be replaced by programmers who know C/C++, Java, or Python inside out.

What is SDN, why is it becoming popular? Are those fears justified?

To answer these questions, we will have to take a closer look at “traditional” networking first. We will discuss the
current “limitations” of traditional networking, I will explain what SDN is and how SDN is supposed to solve the
“problems” that traditional networking has.

Traditional Networking
Networking has always been very traditional. We have specific network devices like routers, switches, and firewalls
that are used for specific tasks.

These network devices are sold by networking vendors like Cisco and often use proprietary hardware. Most of these
devices are primarily configured through the CLI, although there are some GUI products like CCP (Cisco
Configuration Protocol) for the routers or ASDM for the Cisco ASA firewalls.

A network device, for example, a router has different functions that it has to perform. Think for a moment about some
of the things that a router has to do in order to forward an IP packet:
  It has to check the destination IP address in the routing table in order to figure out where to forward the IP
packet to.
 Routing protocols like OSPF, EIGRP or BGP are required to learn networks that are installed in the routing
table.
 It has to use ARP to figure out the destination MAC address of the next hop or destination and change the
destination MAC address in the Ethernet frame.
 The TTL (Time to Live) in the IP packet has to be decreased by 1 and the IP header checksum has to be
recalculated.
 The Ethernet frame checksum has to be recalculated.

All these different tasks are separated by different planes. There are three planes:

 control plane
 data plane
 management plane

Let’s take a look at the difference between these three planes…

Control Plane
The control plane is responsible for exchanging routing information, building the ARP table, etc. Here are some tasks
that are performed by the control plane:

 Learning MAC addresses to build a switch MAC address table.

 Running STP to create a loop-free topology.
 Building ARP tables.
 Running routing protocols like OSPF, EIGRP, and BGP and building the routing table.

Data Plane
The data plane is responsible for forwarding traffic. It relies on the information that the control plane supplies. Here
are some tasks that the data plane takes care of:

 Encapsulate and de-encapsulate packets.

 Adding or removing headers like the 802.1Q header.
 Matching MAC addresses for forwarding.
 Matching IP destinations in the routing table.
 Change source and destination addresses when using NAT.
 Dropping traffic because of access-lists.

The tasks of the data plane have to be performed as fast as possible which is why the forwarding of traffic is
performed by specialized hardware like ASICs and TCAM tables.

Management Plane
The management plane is used for access and management of our network devices. For example, accessing our
device through telnet, SSH or the console port.

When discussing SDN, the control and data plane are the most important to keep in mind. Here’s an illustration of
the control and data plane to help you visualize the different planes:
Above you can see the control plane where we use routing protocols like OSPF and EIGRP and some static routing.
The best routes are installed in the routing table. Another table that the router has to build is the ARP table.

Information from the routing and ARP table is then used to build the forwarding table. When the router receives an IP
packet, it will be able to forward it quickly since the forwarding table has already been built.

If you want to learn exactly how the different planes work and how ASICs / TCAMs are used then you
might want to read my CEF (Cisco Express Forwarding) lesson.

Limitations of traditional networking

Everything I described above is the way we have done things for the last ~30 years so it’s not like there is something
“wrong” with traditional networking. However, nowadays there are some business challenges that ask for different
solutions.

Let’s look at a scenario.

Above we see the network infrastructure of a company’s data center. At the bottom, we find a VMware ESXi server
with a number of virtual machines. This server is connected to some switches in the access and aggregation layers.
We also see two ASAs that protect our server and two routers for access to the outside world. On top, there is
another router with a host device.

Let’s say this company has a business requirement for a new application that requires four new virtual machines to
be installed on the VMware server. For security reasons, each virtual machine should be in a different VLAN. A user
that is using H1 behind R3 should be able to access the application that runs on these virtual machines.

Let’s consider some of the things we have to configure on our network to make this happen:

 The VLANs have to be created on all switches.

 We have to configure a root bridge for the new VLANs.
 We have to assign four new subnets, one for each VLAN.
 We need to create new sub-interfaces with IP addresses on the switches.
 We need to configure VRRP or HSRP on the switches for the new VLANs.
 We have to configure the firewalls to permit access to the new applications / subnets.
 We have to advertise the new subnets in a routing protocol on our switches, routers, and firewalls.

Although there are network automation tools to help us, we often use the CLI to configure all of these devices, one-
by-one. It’s a slow, manual process that a human has to do. While it only takes a few minutes to spin up a new
virtual machine, it might take a few hours for the network team to prepare the network. Changes like these are also
typically done during a maintenance window, not during business hours.

Server virtualization is one of the reasons why businesses are looking for something that speeds up the process
described above. Before virtualization, we used to have one physical server with a single operating system.
Nowadays we have multiple physical servers with hundreds of virtual machines.

These virtual machines are able to move automatically from one physical server to another. When they cross an L3
boundary, you don’t want to wait for the network team to make the required changes to routing or access-lists. It
should be automatic.

The “trend” nowadays is that everything should be virtual. It’s not strange to see that this is also happening to
networking. Large companies like Cisco that used to sell only proprietary hardware are now also offering virtual
routers, ASAs, wireless LAN controllers, etc. that you can run on VMWare servers.

SDN (Software Defined Networking)

Like the buzzword “cloud” a few years ago, every organization or vendor has a different opinion about what SDN
exactly is and different products that they offer.

Traditional networking uses a distributed model for the control plane. Protocols like ARP, STP, OSPF, EIGRP, BGP
and other run separately on each network device. These network devices communicate with each other but there is
no central device that has an overview or that controls the entire network.

One exception here (for those that are familiar with wireless networking) are the wireless LAN controllers (WLC).
When you configure a wireless network, you configure everything on the WLC which controls and configures the
access points. We don’t have to configure each access point separately anymore, it’s all done by the WLC.

With SDN, we use a central controller for the control plane. Depending on the vendor’s SDN solution, this could
mean that the SDN controller takes over the control plane 100% or that it only has insight in the control plane of all
network devices in the network. The SDN controller could be a physical hardware device or a virtual machine.

Here’s an illustration to help you visualize this:

Above you can see the SDN controller which is responsible for the control plane. The switches are now just “dumb”
devices that only have a data plane, no control plane. The SDN controller is responsible for feeding the data plane
of these switches with information from its control plane.

There are some advantages and disadvantages of having a distributed vs a central control plane. One of the
advantages of having a central controller is that we can configure the entire network from a single device. This
controller has full access and insight of everything that is happening in our network.

Let’s add some more detail to this story. The SDN controller uses two special interfaces, take a look at the image
below:
The interfaces are called the northbound interface (NBI) and southbound interface (SBI). Let me explain both…

Southbound Interface
The SDN controller has to communicate with our network devices in order to program the data plane. This is done
through the southbound interface. This is not a physical interface but a software interface, often an API (Application
Programming Interface).

An API is a software interface that allows an application to give access to other applications by using pre-defined
functions and data structures. I’ll explain more about this in a minute.

Some popular southbound interfaces are:

 OpenFlow: this is probably the most popular SBI at the moment, it’s an open source protocol from the Open
Networking Foundation. There are quite a few network devices and SDN controllers that support OpenFlow.
 Cisco OpFlex: this is Cisco’s answer to OpenFlow. It’s also an open source protocol which has been
submitted to the IETF for standardization.
 CLI: Cisco offers APIC-EM which is an SDN solution for the current generation of routers and switches. It
uses protocols that are available on current generation hardware like telnet, SSH, and SNMP.

Northbound Interface
The northbound interface is used to access the SDN controller itself. This allows a network administrator to access
the SDN to configure it or to retrieve information from it. This could be done through a GUI but it also offers an API
which allows other applications access to the SDN controller. You can use this to write scripts and automate your
network administration. Here are some examples:
  List information from all network devices in your network.
 Show the status of all physical interfaces in the network.
 Add a new VLAN on all your switches.
 Show the topology of your entire network.
 Automatically configure IP addresses, routing, and access-lists when a new virtual machine is created.

Here’s an illustration to help you visualize this:

Through the API, multiple applications are able to access the SDN controller:

 A user that is using a GUI to retrieve information about the network from the SDN controller. Behind the
scenes, the GUI is using the API.
 Scripts that are written in Java or Python can use the API to retrieve information from the SDN controller or
configure the network.
 Other applications are able to access the SDN controller. Perhaps an application that automatically configures
the network once a new virtual machine is created on a VMware ESXi server.

REST API
I have mentioned a few times that the north- and southbound interfaces use APIs. Let’s take a closer look at what an
API is. SDN controllers typically use a REST API (Representational State Transfer).

The REST API uses HTTP messages to send and receive information between the SDN controller and another
application. It uses the same HTTP messages that you use when you browse a webpage on the Internet or when
you enter a contact form online:

 HTTP GET: used when we want to retrieve information.

 HTTP POST/PUT: used when we want to upload or update information.

It is similar browsing a webpage, only this time, you are not requesting a webpage or picture but a particular object
from the SDN controller, for example, a list with all VLANs in the network.
When the SDN controller receives the HTTP GET request, it will reply with an HTTP GET response with the
information that was requested. This information is delivered in a common data format. The two most used data
formats are:

 JSON (JavaScript Object Notation)

 XML (eXtensible Markup Language)

Here’s an example to help you visualize this:

Above we have a python script that is using HTTP GET to fetch the following URL through the API:

https://192.168.1.1:8443/sdn/v2.0/net/nodes

This URL will retrieve some of the variables that are available, for example, information about all nodes (hosts) on
the network.

Once the API receives this, it will respond with an HTTP GET response message:

The variables that were requested will be supplied in JSON format. Here’s what this looks like:
{

"nodes": [

"ip": "172.16.1.1",

"mac": "fa16.3e5d.f1f4",

"vid": 0,

"dpid": "00:00:00:00:00:00:00:03",

"port": 1

}, {

"ip": "172.16.1.2",

"mac": "fa16.3e5d.f1f5",

"vid": 0,

"dpid": "00:00:00:00:00:00:00:03",

"port": 2

Even if you have never seen JSON before, the output above is easy to read. It tells us that we have two nodes on
the network, their IP, and MAC addresses.

Conclusion
I hope this lesson has helped to get a global understanding of what SDN is about and why the market is looking for
solutions like this. In some other lessons, I will give you some configuration examples of SDN solutions like Open
SDN, Openflow, OpenDayLight, Cisco ACI and Cisco APIC-EM.

Time will tell what networking will look like in the future. It’s likely that we will be using APIs more often than the CLI
in the future. Is this a problem? If you ask me, not really. First of all, a programmer might be very strong in
programming languages like C/C+, Java or Python but he/she also requires networking knowledge. Understanding
how to use a programming language to run some basic scripts will be very helpful, you don’t have to build an entire
application from scratch…that’s a programmer’s job.

It might be wise though to spend some time learning a programming language like Python and how to use APIs. At
the moment we don’t know how popular SDN will be but this scenario might be a bit similar to what happened to
analog telephony. There are a lot of “telephony veterans” that refused to learn about VoIP because they thought
analog telephony has always worked. A few years later, they are dinosaurs in a world dominated by VoIP…