Types of Network Provisioning
Types of Network Provisioning
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.
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.
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.
Installing an operating system, device drivers, and partitioning and setup tools
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.
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.
Simplify operations
Reduce complexity by decoupling the control and data planes, while making automation highly secure and
scalable.
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.
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
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:
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:
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.
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:
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.
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.
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.
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.
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:
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:
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…