Software Defined Networking (SDN)

1. SOFTWARE DEFINED
NETWORKING (SDN)
(CCNA V3)
www.netprotocolxpert.in

2. SDN
• Traditional networks, where we individually configure routers and switches,
simply do not scale well nor do they adapt well to dynamic environments.
For example, maybe you run an e-commerce business, and you’re about to
announce a big sale. To handle the anticipated spike in traffic, you spin up
some virtual machines (VMs) and want to route a portion of your traffic to
those VMs just coming online. Also, you might need to adjust your quality of
service (QoS) policies to account for the increase in bandwidth demand.
Then, when your big sale is over, you want to return to your previous
configuration. Making such a change involves many moving parts, and
instead of individually visiting each network device and making changes via
the command line, you could have a centralized point of control that
oversees those changes. That’s the benefit and the promise of SDN.

3. THE CONCERN OF CISCO PROFESSIONALS
• Over the coming years, knowing how to write programs (that talk with an
SDN controller) is going to be increasingly important for Cisco professionals.
• This applies not just to those network engineers working on routers and
switches, but also to those working with most any other Cisco technology
(e.g. collaboration servers, wireless devices, security appliances, and on and
on).
• Cisco publicly announced they see a future where all network components
can be controlled by software.
• Cisco professional of tomorrow should definitely have some basic
programming skills, while simultaneously being grounded in network
theory.

4. REVIEW OF ARCHITECTURAL PLANES
• Now, let’s start getting into what SDN is all about. One benefit that SDN
offers (in some but not all situations) is having a centralized control plane.
Recall that a Cisco router or switch has three basic architectural planes of
operation
Data Plane:
The data plane is in charge of frame or packet forwarding. For example, it’s
this plane that handles things like encapsulation, decapsulation, checking a
MAC address table on a switch to determine an appropriate exit interface,
checking the IP routing table on a router to determine an appropriate exit
interface, filtering traffic with access control lists (ACLs), and encrypting
traffic.

5. Control Plane:
The control plane is controlling the data plane, in that it populates a switch’s
MAC address table and a router’s IP routing table. It’s here at the control
plane where protocols such as Spanning Tree Protocol (STP) and IP routing
protocols run.
Management Plane:
The management plane is concerned with administrative access to a network
device. For example, when you connect to a router or switch via a Telnet or
Secure Shell (SSH) session, that’s made possible by the management plane. Or
perhaps you have a network management station running Simple Network
Management Protocol (SNMP) that communicates with a network device.
That communication is occurring at the management plane.

6. DISTRIBUTED VS. CENTRALIZED CONTROL PLANES
• When we have multiple network devices, each of which have their own data,
control, and management planes, we call that a distributed control plane. To
make things more efficient, some SDN installations allow us to have a network
controller, and move the control planes from each network device and consolidate
all of them in the network controller.
Distributed Control Plan

7. • This network controller can then communicate with the routers and switches. This
communication can be two-way, in that the network controller can send instructions
to the routers and switches (e.g. telling them how to update their tables), while also
gleaning information from these devices. In such a situation, where the control
planes of our network devices are residing on a centralized network controller, we
have what is referred to as a centralized control plane.
centralized control plane

8. SDN’S PIECES, PARTS, AND PROTOCOLS
• Notice the dashed arrows in the above graphic. Those are Application
Programming Interfaces(APIs), representing how the controller
communicates with the network devices. Typically, when we draw this out,
the controller sits above the network devices. So, these APIs, which go from
the controller down to the network devices, are called southbound APIs,
or southbound interfaces(SBIs).
• Did you notice the network controller is labeled with a couple of
acronyms, APIC and ACI? Let’s discuss what these mean?

9. • Cisco ACI, which stands for Application Centric Infrastructure, is the name
Cisco gives its SDN architecture. So, Cisco ACI is not something different
than SDN. Rather, it’s how Cisco brands their SDN solution.
• APIC, which stands for Application Policy Infrastructure Controller, is a
component of Cisco ACI that acts as an SDN network controller. The APIC
commonly uses a southbound API called OpFlexwhen it communicates with
network devices. OpFlex can communicate with multiple Cisco and third-
party devices supporting OpFlex.

10. • However, how does our network controller know what to control? Well, we can have applications
that talk with the network controller. For example, an application might tell a network
controller to create a VLAN on a couple of switches or to configure an OSPF routing process on
a couple of routers. Remember how we had southbound APIs to talk from the controller down to
the network devices? Well, you guessed it, we have northbound APIs, or northbound
interfaces (NBIs), that go from the network controller up to the applications (since we typically
draw the applications above (i.e. north of) the network controller).
Applications Communicating via NBIs

11. • These NBIs allow us to not only send instructions to the controller, but we
can retrieve monitoring information from the controller (e.g. to monitor
processor utilization on our network devices). NBIs also give us a layer
of abstraction, meaning that we can tell an application what we want to
happen in the network (e.g. give voice traffic 2 Mbps of priority bandwidth)
rather than issuing the specific commands to make it happen.

12. • Earlier, we mentioned that we might be using OpFlex as the API between
our APIC and our network devices. This begs the question, how are we
communicating between our applications and the APIC?
• We typically use Representational State Transfer (REST) APIs. Some of the
literature refers to these as RESTful APIs, and they use HTTP messages
(e.g. GET or PUT) to send information between an application and an SDN
controller. If we wanted to retrieve information from a controller, we could
use the GET message. Similarly, we could use the PUT message to send
information to a controller. To two most common formats we use when
configuring these RESTful APIs are JavaScript Object Notation (JSON)
and Extensible Markup Language (XML).

13. APIC-EM
• Interestingly, SDN does not always use a centralized control plane. For example, we might have
lots of traditional Cisco routers and switches in our network that have no knowledge of OpFlex
or the concept of a centralized control plane. Devices such as these must have and maintain
their own local control plane, meaning that we need to be running in a distributed control plane
environment. For situations like this, Cisco gives us another type of SDN network controller.
It’s called the Application Policy Infrastructure Controller Enterprise Module (APIC-EM).

14. • The APIC-EM is a Cisco SDN network controller that can communicate with
traditional routers and switches via more familiar southbound interfaces
such as Telnet, SSH, or SNMP. This brings up the question, if the APIC-EM
is not centralizing the control planes of network devices, what is it doing?
• For one thing, the APIC-EM collects tons of diagnostic information from our
network devices. We can also centrally make configuration changes and then
push out those changes to our network devices. Basically, the APIC-EM
supports network programmability but does not support a centralized
control plane.

15. • The APIC-EM also supports a variety of apps. One such app is the Discovery app, which lets
the APIC-EM discover a network’s topology.
DiscoveryApp

16. • Another app is the APIC-EM Path Trace app, which takes information
collected by the Discovery app and simulates what would happen if a specific
type of traffic was sent from a specified source to a specified destination.
This is accomplished without actually sending any traffic through the
network.
• The list of topics for the CCNA R/S v3 exam specifically lists the APIC-EM
Path Trace ACL Analysis Tool, which is a component of the Path Trace app.
What this tool does is a synthetic path trace (i.e. no data is actually sent),
while accounting for any ACLs configured in our network devices. Therefore,
if traffic is blocked because of an ACL, we get to see exactly where that ACL
is applied, and even what instruction in the ACL blocked the traffic.

17. APIC-EM PATH TRACE ACL ANALYSIS TOOL

18. FOLLOW US ON
https://www.facebook.com/N
etProtocolXpert/
https://www.linkedin.com/c
ompany/netprotocol-xpert
https://plus.google.com/u/
0/collection/AYQ-EB
https://www.instagram.com
/netprotocol_xpert/
https://twitter.com/NPX_cisc
o
https://branded.me/netprot
ocolxpert