The Role of Agents in a Software Defined Network

An edited version of this story ran on

In this article, I want to talk about network agents—what some in the industry refer to as the future of the software defined network. Agents are responsible for a great deal of flexibility and control, and the work they do can vastly impact how responsive and agile a software defined network can be. Let us dig in.

What are agents?

In almost all software defined networks, agents are the tool by which network applications expose their abilities for network controllers to modify their configuration at any given time. Network agents can live on the software defined network controller itself, providing a mechanism for the controller to talk to various applications through the controller’s northbound interface. (These northbound interfaces are generally output only—they only communicate outward to the individual SDN-aware applications.) Network agents can also live on different network elements, comprising a data path. All of these elements work together to forwarding traffic through the datapath’s external interfaces or process or terminate traffic within the element itself.


Where this all gets interesting is here: one or more of these datapaths (an agent and an engine) may live inside one physical network element—an “bucket” of welded-together communications resources, which the SDN sees and manages as a unit. But it goes further. A datapath may also be defined across multiple physical network elements. This logical datapath doesn’t care how datapaths map to actual physical assets, how those physical resources are managed or how they are abstracted away, how all of this is virtualized or how it all interrelates and interoperates, and more. It’s a completely different thing than physical wires, ports, and switches. The agent itself is responsible for communicating with the SDN controller about what the datapath is supposed to represent and how its engine is supposed to behave, and the datapath network agents do this communication across the network controller’s southbound interface.

How are network agents deployed in production SDNs?

In some networks, administrators install virtual network agents on every hypervisor host (in this scenario, each hypervisor host is a network element). The virtual network agent on each host then directs traffic toward the virtual switch. If that virtual switch recognizes that particular flow of traffic and is able to match it with a prescribed action, then it can adjust the configuration of the virtual machines on that host so that the flow of traffic exits through the host’s physical network interface card. If the virtual switch doesn’t recognize the flow, it sends a mapping request back to the agent, which queries a mapping service in the network controller so it can figure out where that traffic is supposed to flow.


In other scenarios, network agents are key to implementing virtual functions on the network. Workloads like load balancers, firewalls, threat monitors, intrusion detection, packet capture and packet and traffic forwarding, and more can all be implemented by various network agents residing in different network elements. The controller can deploy, activate, deactivate, and redeploy these agents as needed whenever traffic flows in one direction or another, and large scale SDNs can deploy multiple copies of these objects for multitenant scenarios or to respond to a breach, a distributed denial of service attack, an unusually large load during a spiky peak period, or other one time occurrence.

Putting it all together

The important element to remember when it comes to agents is actually what distinguishes a software defined network from a physical network: the fact that the physical components, the discrete switches and patch cables and ports and whatnot are completely abstracted away and the only networking we care about—and the networks to which these network agents serve and function—are the traffic “flows” created by applications.


Imagine how this would apply to human travel. SDNs in that context are essentially the difference between worrying about interstates and side roads versus the concept of traveling from Los Angeles to San Francisco. SDN cares out the route, the flow, the purpose of the traffic and its outcome, rather than concerning one’s self with which exits to take off the interstate, where to turn right, what to do if there is a traffic backup, and the like. By focusing on the flows, the need of packets and data to get from one application to another, we get the concepts of agents, the bits that carry out the instructions from the control plane and translate those into action on the data plane.


In conclusion, agents are key to the SDN experience and perform the vital role of translating instructions from the control plane to the data plane.

A Look at the Network Controller in a Software Defined Network

An edited version of this article appears on and appears to have launched on Friday, June 2, 2017. Credit: Cisco Systems Inc

One cannot have a software defined network without the network controller: that component that has a single complete view of a network and all of its components, and thus is the base for configuring the network, its paths, and perhaps most importantly, what devices lay in those paths. 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.

Network Controller Extensibility

The beauty of the network controller role is that most products are designed to be extensible. Generally there are modules or plug-ins you can install into the network controller to light up more features and enable additional functionality. In fact, many controllers, including the Cisco Open SDN Controller, offer programmatic interfaces like REST APIs that lets applications have visibility and integrate deep into the network, Java APIs that let developers create custom functions to enable support for advanced scenarios, and “southbound” 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; written and contributed to by a community of network professionals and talented developers. POX and Beacon are good examples of serviceable open source network controllers. Other network controllers are offered by enterprises and service companies to enable special integration with other types of network hardware and software. Both open source and proprietary network controllers have their role. Open source controllers are a great way to ensure a standards based network especially when used with other network devices from multiple vendors, and often have a vibrant community enhancing the solution as the state of the SDN art advances. On the other hand, proprietary network controllers often offer increased speeds and capabilities working on vendor specific hardware while also providing a support infrastructure for when things go haywire, as they eventually will.

Fault Tolerance and High Availability

Given that it is the single point of control in a software defined network, the network controller can also be a single point of failure. Simple clustering and replicating virtual machines and states across the wire is not enough in an SDN environment because network switches maintain a hard state has to be handled across boot iterations for the network controller. Good network controllers incorporate the state of switches into a transactional replication system that makes sure one can replicate instances of the network controller in the event of a fault while also maintaining a consistent switch state and without taking down the network so that the network switches can establish a consensus on the state of their switches. However, other implications of fault tolerance include the ability of the controller to continually manage all of the different devices on the software defined network after a fail over or a fail back procedure, and how well these fault tolerant procedures scale when your environment is not rather simply a corporate campus, but is a global scale cloud datacenter with hundreds of thousands of customers and thousands of hosted network configurations. Will your network controller vendor measure up?

Network Controller Serviceability

Another differentiation point with network controllers from various vendors is how serviceable they are. Often the logs from a controller will be a jofirst 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 patching the network controller both for feature enhancements as well as to repair or mitigate security flaws. Since the network controller is a key role, most controllers have a way to patch the role without bringing it down.

Consequences of the Network Controller Role in Today’s Environments

What’s the implication for today’s software defined networking environments? What are the main concerns of more decision making and centralized management happening right inside the network controller? There are a couple of points to make here:

  • The benefit is potentially a single pane of glass (or for complex network, just a few panes of glass) where your entire network strategy can be handled, monitored, and if need be, reconfigured. The network controller is the strategic control point of the network, the one place that handles all of the abstraction of resources.
  • The challenge is that one incurs more risk with many virtualized networks and components directing activity through and by the network controller: if the controller goes down, how limited is network functionality? The extent to which services are impaired really depends on each network configuration, but without fault tolerance and high availability capabilities built into your production SDN, the impact of a failed network controller could be quite severe.