Network Transformation: Thinking Outside the Middlebox

Stuck in the Past

The original computers were relatively dumb, single-purpose machines.  Logic was hard-wired into the circuitry, and the devices were designed for a single task – arithmetic, decryption, tabulation, etc.  Today the idea of having to use separate devices for every application or task would seem ludicrous, yet that’s essentially how networks still operate.

Current networks consist primarily of boxes.  There are routers, and switches, and signaling equipment along with other “middleboxes”, specialized devices with specific functions.  Examples of middleboxes include firewalls, load balancers, proxies, intrusion detection systems, and WAN optimization appliances.  Each of these devices requires configuration and administration.  The result is complexity and inefficiency.

Imagine a data pipeline of that passes through all these devices.  How many times must a packet be opened, inspected, and acted upon?  How many device operating systems and interfaces do systems administrators need to know/learn?  How many opportunities are there for misconfiguration or device failure?  What happens when rules on different boxes conflict?  Who can troubleshoot traffic that passes through all these devices?

Rewriting the Rules

The goal of Software Defined Networking (SDN) is to abstract network functions from dependency on hardware.  This, in turn, enables high-level programmability of the network.  In technical jargon, SDN involves separating the data plane (the devices directly involved in moving packets) from the control plane (the logic of how traffic gets from source to destination).  Rather than focusing on boxes, SDN starts with data flows, which are the building blocks of higher-level network logic and functionality.

In a software defined networking world, physical middleboxes become software programs.  This is known as Network Functions Virtualization (NFV), and it allows for functional abstraction along with a common management framework.  By virtualizing network functions in the control plane, network design can be policy-based rather than device-based.  In many ways this is analogous to other types of software development.  The developer writes code that specifies the input, output, and transformations.  Compilers and optimizers determine the most efficient machine instructions and execution logic to implement the code.

As alluded to above, networks built from boxes are complex and difficult to troubleshoot.  I’ll illustrate with an anecdote.  I used to work for a large software company that ran many online services.  Over time, our core routers became cluttered from several generations of configurations and access control lists (ACLs).  It got to the point where our network team had almost no idea which rules were still active.  Their answer – which is probably familiar to anyone who has managed a legacy network – was to sequentially turn rules off to see which applications broke.

By contrast, SDN promises a global network view.  Functional complexity is managed at the network edge, while the core primarily focuses on moving packets.  As Jennifer Rexford, one of the pioneers in the field of SDN, sees it, “SDN allows for network-wide visibility and control, which we’ve never had before.”

From Theory to Practice

Assuming the ideas discussed up to this point are of interest to you, how do you get started?  The answer is “it depends”.  As with many technologies, what is and what is not SDN can be confusing.  Some companies define SDN as a way to automate and configure their physical switches and routers.  This is the approach many network hardware vendors have taken, and it makes sense in terms of their core competencies and existing customer base.  Cisco, for example, continues to add SDN capabilities to its Nexus line of switches.

Many software vendors, on the other hand, define SDN in terms of network virtualization.  With this approach, the goal is to provide an abstraction layer that essentially commoditizes the hardware components.  This follows the same path that server virtualization has taken.  Virtualization leader VMware’s acquisition of SDN pioneer Nicira in 2012 made sense within the context of their strategy to deliver the Software Defined Data Center (SDDC).  Within a year of the acquisition, VMware had combined elements of Nicira technology with its well-established network virtual switching to form its NSX product family.

The addition of NSX to VMware’s vSphere product line means that users and administrators can create, modify, and administer networks as easily as they can manage virtual machines (VMs) – without adding a lot of expensive network gear.  The combination of VMware server virtualization and NSX network virtualization enables IT organizations to deliver services with the same agility and flexibility as the large public cloud providers.

CloudBolt is pleased to announce extensive integration of VMware NSX technology in our 5.2 product release.  CloudBolt enables enterprise IT to operate as a cloud service provider.  Our powerfully simple cloud management platform integrates on-premises resources with public clouds, automation scripting tools, and domain-specific technologies.  By delivering a responsive and agile alternative to shadow IT, CloudBolt gives users what they want, when they want it.

To learn more, contact us to schedule a demo.