Keith Bromley
Sr. Manager, Product Marketing at Ixia

What You Need To Know About Monitoring SDN

September 26, 2017 by Keith Bromley

Software defined networking (SDN) got its roots several years ago. The basic idea was, “Wouldn’t it be great if all these packets routed themselves and any routing issue that pops up would dynamically fix itself, without any intervention?” Unfortunately, as you might imagine, the implementation is a little more complicated than the thought, but the spirit lives on with protocols and architectures being created that separate the control plane from the data plane for data networks.

For example, there are two popular concepts for SDN right now. The first is to use a protocol called OpenFlow. OpenFlow was first introduced in 2011. This protocol is used to forward packets through network switches with minimal intervention by IT. Per Wikipedia, “OpenFlow allows remote administration of a layer 3 switch's packet forwarding tables, by adding, modifying and removing packet matching rules and actions.” This is intended to streamline the effort needed by IT to program the data path.

A second, and different, implementation of SDN is the Cisco Application Centric Infrastructure (ACI). This was introduced in 2013 and is both a data center and a cloud solution that integrates the management of the virtual and physical IT network. This is an architectural approach to SDN, versus the protocol approach of OpenFlow. The new architecture uses a leaf/spine design and is designed for higher speed networks, typically 40 Gbps to 100 Gbps.

With new technology like this comes new challenges for your security and monitoring solutions. Let’s look at OpenFlow first. One of the biggest drawbacks centers around issues associated with features and capabilities supported by the controller switches. Here’s a list of potential issues:

  • Limited functions for the controller switches - i.e. they may not support de-duplication, data masking, load balancing, header stripping, payload slicing, port tagging, time stamping, etc.
  • The controller often has simplistic filter rules. This means that you can perform some data filtering but it often doesn't do what you really need it to do.
  • There can be data delays because features are not processed at line rate due to the architectural design of the controller switch. This is especially important if you want to deploy inline monitoring and security solutions that need real-time data routing / manipulation.
  • Interoperability between different controllers can be a problem. They all may support the OpenFlow protocol but not implement features or filtering in the same way. Now you have vendor lock in again.
  • Security is always a concern. If the OpenFlow-based controller is hacked, then you can lose control of data routing on your network.

In regards to the Cisco ACI architecture, this solution can also create various headaches for existing monitoring solutions. Use of the BiDi taps is an improvement over capturing data from SPAN ports. See this document for a review of SPAN port limitations. However, the architecture itself creates new issues that will need to be addressed.

Here is a list of some items to consider:

  • Duplicate packets are created by the BiDi taps and leaf and spine architecture. If not addressed, this duplicate traffic will require considerable, and unnecessary, investments in additional security and monitoring tools to process the additional traffic.
  • The ACI architecture uses VXLAN headers. Several of the security and monitoring tools on the market don't understand this routing protocol and won't work in the new ACI design.
  • Common ACI implementations run at 40 or 100 Gbps. Security and monitoring tools at those speeds can be expensive, to very expensive, so this extra cost needs to be accounted for.

The good news is that a network packet broker solution can easily overcome the new monitoring challenges created by the ACI architecture. See this document on how to overcome these challenges.

For more information on solutions that can help IT personnel resolve these monitoring challenges and other problems, read this whitepaper on monitoring best practices and/or visit this webpage for additional resources.