Keith Bromley
Sr. Manager, Product Marketing at Ixia

Software Defined Networks (SDN): The ABCs of Network Visibility

March 26, 2019 by Keith Bromley

If you have been involved in networking over the last several years, then you have heard the term software defined networking (SDN). While adoption has been slow, it is starting to grow. According to an April 2018 study sponsored by Verizon, approximately 15 percent of organizations surveyed have deployed SDN. That number is expected to rise to 57 percent by 2020.

The reason for SDN adoption is simple—it decouples network communications from the data plane, which allows greater flexibility to create and modify new applications on the network. It also enables the automation and orchestration of those applications.

What is SDN?

SDN is a computer networking architecture that splits apart the control plane (signaling) from the data transmission plane. It has been discussed for years as one of the best ways to deploy scalable resources at the speed of business.

The SDN model consists of three layers:

  • Hardware infrastructure
  • Control
  • Applications

The following figure shows the three individual components and how they work together to form an architecture.


After this basic overview of SDN, things can get murky quick. For instance, how do you implement SDN? Immediately you encounter a fork in the road because you could deploy an OpenFlow-based solution, Cisco’s ACI architecture, Juniper’s SDN, cloud SDN, or something else—as the list goes on and on.

There is no magic here. The answer as to what you should deploy depends upon how your network is architected and what you want to accomplish. For instance, if you don’t have a public cloud instance, or are not thinking in that direction long-term, then cloud SDN is not for you. If you have a Cisco infrastructure or a Juniper infrastructure, then this helps you with that decision. However, don’t think you need to go with an infrastructure provider’s solution. The main driver is the type of services and applications that you want your network to provide. A second consideration is cost. Proprietary solutions are a lot more costly and go against the premise of open networking.

Typical Use Cases

Here are some specific situations in which SDN architectures are particularly useful.

When you want to reduce the time to implementation of new services and new users – A fundamental use case is the need to deliver applications at the speed your business demands. For instance, the network needs to be able to automatically add users and devices. Changes can occur often in a large network. If manual intervention is required, then this will dramatically increase your costs and may very well negate any anticipated ROI.

Ability to respond to dynamic changes in the network – Security threats and performance problems are key items you want to reduce and/or eliminate. This means having systems that are automated and can implement changes semi-autonomously without human intervention. One example is a RESTful interface from a SIEM to an IDS or other security device. The SIEM can send a message to the security appliance to investigate a specific threat. If a packet broker is connected to the network as well, then the SIEM can direct the packet broker to capture the requisite data and send that data to the IDS, which can then process the data and look for any threats. All of this can happen without human intervention.

Controlling monitoring costs – Another use case is to insert a network packet broker within your network to optimize your monitoring solution. Depending upon the specific SDN architecture, duplicate packets and headers (like VXLAN) can be added to the data traversing your network. If you want to monitor your network, you will need a way to remove the unnecessary duplicate traffic as well as removal of unwanted packet headers. If you don’t do this, your monitoring costs may increase substantially as the end monitoring tool will need to perform those functions. An NPB can reduce/prevent device slowness and make those tools more efficient.


When it comes to SDN architectures, here are some other things to keep in mind about your implementation:

Scale – The network obviously needs to scale. Automation and orchestration can be used to help your solution make this an automated task. Make sure your solution takes advantage of protocols like REST to implement this automation.

Flexibility – Another key factor is flexibility. We all know that the network will change over the next coming years so make sure your architecture can handle change. This includes traffic speeds. Many networks have already gone to 40 GE but 100 GE may be in your network’s not-so-distant future. There is also the question of technology. There is still a lot of physical on-premises equipment out there but newer technologies like public cloud and SD-WAN have entered the scene. Technology changes occur frequently, so as long as the design is flexible enough to handle change, you should be in a good position.

Performance – Performance is king. If the network design looks good but it runs slow, you will receive numerous unkind complaints. Make sure you optimize all of your network, including the monitoring pieces so that you have the visibility you need into the need to see where any bottlenecks and slowdowns can occur. This includes understanding when to implement appliance-based components and when to use software components. Some activities just do better when an appliance (that has dedicated FPGAs to process traffic at line rate) is used.

More Information on SDN

While SDN network architecture designs should consider that factors above, another important factor is network monitoring. Make sure you deploy the right monitoring solution to help you. It should have the same three considerations as the SDN solution itself:  scale, flexibility, and performance. See this brochure on the Ixia SDN solution