In SDN, your network controller is the power broker

In SDN, your network controller is the power broker


by Jonathan Hassell

In software-defined networks, traffic decision making shifts from hardware to software. That brings flexibility but also greater risk.

Software-defined networking fundamentally changes where in the network the action happens. While that might not seem exciting at first, let’s break it down.

In the old world, dumb hardware decided where to route traffic, how to redistribute volume to prevent chokepoints and what to do with malicious actors. Software-defined networking (SDN) initiates a shift, with the network controller wresting power from hardware. That shift enables the network to handle far more volume and complexity– while allowing for greater automation within the network. Growing companies can handle spikes in Web traffic, and innovation can gain traction by accommodating new cloud-based applications, because the network can finally handle it.

At the same time, SDN and network controllers aren’t cure-alls for some of the problems that dumb hardware faced. The network can help navigate traffic flows and govern security, but the physical infrastructure needs to be ready to accommodate these developments as well.

So what are some important considerations when evaluating network controllers? What are some of the unique features and pitfalls that network controllers introduce? Let’s take a look.

The upside of SDN: Network controller extensibility and integration

In the old days, if you wanted more features and functionality in your network, you needed to buy new devices, rack them up in your data center, configure and add them to your management universe. Conversely, with SDN, you can purchase or source plug-ins that perform all sorts of network activities, including load balancing, firewalling, reverse-proxying, and so on.

This allows for far greater flexibility in the network, and these plug-ins work directly within the network controller and virtual switches on the network, boosting performance and flexibility. Most products are designed to be extensible and integrate well with an open controller. Generally, you can install modules or plug-ins into the network controller to enable additional functionality.

In fact, many controllers, offer programmatic interfaces, including the following:

  • REST application programming interfaces (APIs) that enable applications to integrate deeply into the network;
  • Java APIs that allow developers to create custom functions to enable advanced scenarios;
  • "southbound" (i.e., for north-south client/server traffic that travels from a data center to an external location) plug-ins for the network controller device that hook up virtual networks to physical networks to make heterogeneous network environments take the leap into an SDN world.

Open source network controllers

Many network controllers are also open source, which means they have open source code under the hood. This code is written and contributed to by a community of network professionals and developers. POX and Beacon are good examples of open source network controllers.

Various providers offer other network controllers to enable special integration among network hardware and software. Both open source and proprietary network controllers have their role.

Open source controllers ensure a standards-based network, particularly when they are used with network devices from multiple vendors. They often have a vibrant community behind them, enhancing the technology as the state of the SDN art advances. On the other hand, proprietary network controllers working on vendor-specific hardware often offer increased traffic speeds and capabilities. They also come with a support infrastructure for when things go haywire, as they eventually will.

Fault tolerance and high availability

While SDN creates a centralized point of management, it also creates a centralized point of risk. Simple clustering and replicating virtual machines and states across the wire don’t transcend hardware in an SDN environment. Network switches maintain a hard state. Most clustering and replication systems do not account for the state of individual ports—they seek to roll over the entire system into an “up” state. That’s acceptable for servers and most workloads, but not when it comes to continuous streams of data, which switches generally handle.

Good network controllers account for the state of switches into a transactional replication system. This ensures that, in the event of a fault, one can replicate instances of the network controller while also maintaining a consistent switch state—without taking down the network—so that the network switches can establish a consensus.

But fault tolerance also includes the controller’s ability to continually manage all the devices on the software-defined network after a failover or a fail-back procedure. It's important to know how well these fault-tolerance procedures scale beyond the corporate campus and to a cloud-based data center with hundreds of thousands of customers and thousands of hosted network configurations. Can your network controller vendor keep pace with that scale?

Network controller serviceability

As you consider network controllers from various vendors, a key differentiator is how serviceable they are. Often the logs from a controller will be a first source to consult when troubleshooting network issues. Are the logs easy to find? Can they be shipped to central logging facilities, where an existing network monitoring environment can capture events as they happen and proceed through alerting workflows? Another servicing concern is how easy it is to patch the network controller for feature enhancements as well as to repair or mitigate security flaws. Since the network controller is a key role, most controllers can patch the role without bringing it down.

The network controller role in today’s environments

While centralized management through a network controller opens up the possibilities for managing your network, there are, of course, caveats. As the network controller takes over more of the decision making in the environment, risks abound.

There are a couple of points to make here:

  • Benefits of a network controller approach. The clear advantage of a network controller via software-defined networking is a single location, or a single pane of glass (or a few panes in the case of complex networks), where your entire network strategy can be handled, monitored, and, if need be, reconfigured. A network controller becomes the console and point of control for the network, the one place that handles all of the abstraction of resources.
  • Challenge of a network controller approach. Environments incur more risk with many virtualized networks and components directing activity through a network controller. If the controller goes down, what kind of a stranglehold does it put on network functionality? The extent to which services are impaired depends on each network configuration. But without fault tolerance and high availability capabilities built into your production software-defined network, a failed network controller could inflict severe damage.

For more from the Cisco news corner:

For more on Cisco virtualized networks

About the author

Ahmed Elbornou, Software Engineer

Jonathan Hassell

Jonathan Hassell is an author, consultant and speaker residing in Charlotte, N.C. His books include Windows Vista: Beyond the Manual.