This chapter covers the following topics:
■ Cloud Computing and Traditional Data Center Networks
■ The Opposite of Software-Defined Networking
■ Network Programmability
■ SDN Approaches
■ Application Centric Infrastructure
This chapter covers the following exam objectives:
- 4.1 Describe network architectures for the data center
- 4.1.b SDN
- 4.1.b.1 Separation of control and data
- 4.1.b.2 Programmability
- 4.1.b.3 Basic understanding of OpenDaylight
- 4.1.c ACI
- 4.1.c.1 Describe how ACI solves the problem not addressed by SDN
- 4.1.c.3 Describe the role of the APIC Controller
In Chapter 10, “Network Architectures for the Data Center: Unified Fabric,” you learned
about a series of technological innovations that Cisco amalgamated into a highly successful
data center network architecture: Cisco Unified Fabric. Although such architecture has
become a primary driver for the evolution of numerous data centers worldwide, it is essentially
based on concepts and abstractions that were conceived during the 1970s and 1980s,
as the Internet was being formed.
During the last half of the 2000s, inspired by the noticeable differences between networking
and other computer systems, a group of researchers began to question whether established
networking practices were actually appropriate for the future of IT. Through creativity
and healthy naïveté, these researchers proposed many breakthrough new approaches to
disrupt well-known network designs and best practices. These new approaches have been
collectively given the umbrella term Software-Defined Networking (SDN).
As the world-leading networking manufacturer, Cisco has actively participated in developing
the large majority of these cutting-edge approaches, while also creating many others.
Combining innovation and intimate knowledge about customer demands, Cisco conceived a
revolutionary data center network architecture called Cisco Application Centric Infrastructure
(ACI). Specially designed for data centers involved in cloud computing and IT automation,
ACI addresses many challenges that were overlooked by earlier SDN approaches.
As mentioned in Chapter 10, the CLDFND exam requires knowledge about two other Cisco
data center networking architectures besides Cisco Unified Fabric: Software-Defined Networking
and Cisco Application Centric Infrastructure. This chapter focuses on both, exploring
the dramatic paradigm shifts they have caused in data center infrastructure and cloud
computing projects.
Foundation Topics
Cloud Computing and Traditional Data Center
Networks
Because cloud computing is an IT service delivery model, cloud implementations become
more flexible as more infrastructure elements are orchestrated to support requests from
a cloud end user. And as the main system responsible for transporting data to users and
between cloud resources, the data center network should be included prominently in this
integration.
However, some principles that supported the evolution of networking during the past 40
years are incompatible with the expectations surrounding cloud computing. In Chapter 10,
you learned about techniques and designs created to satisfy the demands related to server
virtualization escalation in data centers. For example, data center fabrics can definitely help
cloud computing projects through the consolidation of Layer 2 silos that are still very common
in classical three-tier topologies. And as a direct consequence, a fabric can more easily
become a single pool of networking resources for a cloud software stack. Yet, the large
majority of data center networks (and fabrics) are still provisioned through practically artisanal
procedures. As an illustration, Figure 11-1 depicts a network configuration procedure
that is probably happening somewhere as you read these words.
Figure 11-1 Data Center Network Provisioning
In the figure, a network engineer must provision the network to receive a new application
consisting of virtual machines that can potentially be connected to any leaf port on this
generic fabric. After some time translating the application requirements into networking
terms, the professional performs the following operations:
Step 1. Creates three VLANs in every switch.
Step 2. Adds these VLANs to every leaf access port.
Step 3. Configures a default gateway for each VLAN at some point of this network
(border leaves in the case of Figure 11-1).
Because most network engineers still use command-line interface (CLI) sessions or a device
graphical user interface (GUI) to fulfill these steps , their resulting configurations are generally
considered very error-prone and difficult to troubleshoot. And although some corporations
maintain detailed documentation about past and current network configurations, this
practice is hardly the norm for the majority of data center networks.
This simple example should already reveal to you the great chasm that exists between
resource provisioning for networks and resource provisioning for other technologies such
as server virtualization. To make matters worse, I’m personally aware of many companies in
which VLANs can be added (or removed) only during monthly maintenance windows, invariably
making the network team the biggest contributor to application deployment delays.
As you can easily deduce, such manual operations are highly unsuitable for cloud computing
environments. For this reason alone, I completely understand why some cloud architects
plan to pre-configure all 4094 available VLANs every port of a network, avoiding additional
procedures during the provisioning of cloud resources. However, leveraging this design
decision, these architects are disregarding important aspects such as
- Flooding and broadcast traffic may severely impact all ports, inadvertently affecting other cloud tenants.
- VLANs are not the only network consumable resource. Other configurations such as access-control lists (ACLs), firewall rules, and server load balances services will still need provisioning as new tenants sign up for cloud services.
With the popularisation of cloud computing projects, and the increasing demand for automation
and standardisation in data centers, networks began to be seriously reexamined
within academic studies, service provider meetings, and boardrooms in light of the new
SDN technologies.
The Opposite of Software-Defined Networking
The formal beginning of many SDN initiatives happened in 2006 with Stanford University’s
Clean Slate Program , a collaborative research program intended to design the Internet as if
it were being created anew while leveraging three decades of hindsight.
As clearly stated in its mission, Clean Slate did not outline a precise approach, a decision
that enabled program participants to pursue extremely creative small projects and very interesting
endeavors. And even after its deactivation in 2012, the project’s legacy is apparent
today in the numerous network solutions being offered to support automation and cloud
computing deployments in enterprise corporations and service providers.
Unsurprisingly, presenting a conclusive definition for SDN is quite difficult. This difficulty
is compounded by the SDN marketing bandwagon. With huge interest in SDN turning into
hype in the early 2010s, many vendors tried to associate SDN as closely as possible with
their own approach. As an example, the following list paraphrases some definitions of SDN
I have compiled after a quick web search:
- “SDN is an approach to computer networking where IT administrators can manage networks through the abstraction of lower-level functionalities.” “SDN is an emerging architecture that can be translated into speed, manageability, cost reduction, and flexibility.”
- “SDN enables network control to become directly programmable as the underlying infrastructure is abstracted for applications and network services.”
- “SDN is the virtualization of network services in order to create a pool of data transport capacity, which can be flexibly provisioned and reutilized according to demand.”
Because this chapter will explore SDN approaches that will contradict the statements made
previously, allow me to introduce a definition for SDN in a different manner.
According to John Cleese (genius from legendary comedy troupe Monty Python and neuropsychological
studies enthusiast), nobody really knows how creativity actually happens,
but it is pretty clear how it does not. Furthermore, as Cleese jokes in his famous lectures
about creativity and the human mind, a sculptor explained his method of creating beautiful
elephant statues: simply remove from the stone what is not an elephant.
In a similar vein, allow me to propose the following question: what is the opposite of SDN
for you? Please give yourself some time for reflection before reading the next paragraph.
If you believe hardware-defined networking (HDN) is the correct answer, you are not
alone. Respectfully, I do not agree with that answer, for what I think are some compelling
reasons. Since the inception of the ARPANET in the late 1960s, networks have been based
on devices composed of both hardware and software (network operating system), the latter
of which is as carefully designed and developed as other complex applications such
as enterprise resource planning (ERP). In its current model, neither hardware nor software
defines how a network behaves, but rather a higher layer of control called Homo sapiens
defines its behaviour. Because this “layer” is directly involved in every single change on most
networks, I believe human-defined networking genuinely represents what is not SDN. (But
if you still prefer hardware-defined networking, at least we can agree on the same acronym.)
As a result, SDN can be defined as the set of technologies and architectures that allow
network provisioning without any dependence on human-based operations. In truth, such
conclusion may explain why the large majority of SDN approaches (including OpenFlow
and Cisco ACI, which will be discussed in a later section) pursue the concept of the network
as a programmable resource rather than a configurable one. And as many network professionals
can attest, manual configurations can easily become an operational headache as more
changes are required or the network scales.
The ways in which programming can help remove these repetitive menial tasks will be further
explored in the next section.