SDN is a rapidly evolving area, still early in its development. Early adopters of SDN will have to cope with rapidly evolving changes to infrastructure at the speed of software. This is in contrast to the more rigid slowly evolving networks of today. Rapid changes call for both performance and security validation before changes are rolled out.

SDN breaks vertical barriers

Today’s networks have “vertical integration” meaning control planes are coupled tightly to data planes on individual network nodes. This makes networks closed, locked and reliant on proprietary network operating systems such as Cisco IOS, Juniper JUNOS and HP Comware. Developing new improved versions of network operating systems is very complex with lengthy release cycles.

Configuring traditional networks is also very complex, requiring highly skilled engineers with a deep understanding of low level processes critical in the network. This means that engineers are working at a very low level of abstraction, which is very time consuming and, in turn, hampers innovation of new services.

SDN aims to break this vertical integration by moving the control plane onto logically centralized SDN controllers and presenting northbound interfaces that hides the complexity of the underlying infrastructure.

The three goals of SDN

The ultimate end goal of SDN is to make the network open and programmable. At a high level this is accomplished through:

  • A standardized and open southbound interface towards network forwarding nodes, which is used to achieve a programmable data plane.
  • An SDN controller to interact with this southbound interface, to provide core services such as topology and device management amongst others, and to provide a northbound API for application developers
  • A set of network applications built on top of SDN controllers.

The range of network applications span a wide range of topics, including:

  • Load balancing
  • QoS
  • Traffic engineering
  • Security – Firewalls, DoS protection, IDS/IPS
  • Routing and switching
  • Virtualization solutions/cloud computing
  • Performance measurement and monitoring (an area targeted by Netrounds)

With the control plane moved into the SDN controller, network nodes turn into more basic forwarding devices. Their job is limited to matching packets against forwarding rules and taking actions based on instruction sets defined by the SDN controller. Examples of such instructions are to forward to designated ports, drop packets, or to tunnel the packets to the SDN controller for further actions. For instance, incoming ARP packets are normally sent to the SDN controller for decision on which ports to forward the packets.

Rapid changes calls for performance baselines

SDN is a rapidly evolving area, still early in its development. Early adopters of SDN will have to cope with rapidly evolving changes to infrastructure at the speed of software. This is in contrast to the more rigid slowly evolving networks of today.
The types of changes SDN networks may have to endure on a rapid timeline include:

  • Evolution of hardware to support southbound interfaces like OpenFlow, such as Intel DPDK, and FPGAs.
  • Southbound protocol development. For example, there has already been five versions of OpenFlow (version 1.0 – 1.4)
  • Implementation of new or additional SDN controllers.
  • SDN controller code updates.
  • SDN controller application additions, changes and updates.
  • Controller choices, SDN application development and changes, choosing SDN controller(s).

This rapidly changing playing field will make it critical in production networks to baseline traffic performance before changes are rolled out. Netrounds can be a perfect fit to catch impact to active traffic and not just rely on documentation and assumptions arising from lab environments.

SDN security validation

Perhaps of even greater concern is the impact that the changes like the ones listed above will have to a network’s security posture.

Today, Netrounds’ features for access layer security validation provides a comprehensive toolbox to assure that a network is safe from a myriad of access layer attack vectors initiated by malicious users or software.

With the introduction of SDN comes the introduction of new attack vectors. These new vectors include denial of service attacks against an SDN controller or forwarding devices perhaps by overwhelming the ability to process flows in either the data plane or control plane.

Additionally these attacks can include address spoofing and forged or faked traffic flows in the data plane.

Measuring means knowing

With networks evolving at the speed of software, by using Netrounds’ built-in support for both performance and security validation, any network operator can benchmark data plane performance as well as look for security holes opened up after changing the SDN network configuration, for instance after a applying a controller code patch, installing a new controller application or utilizing a new version of OpenFlow in hardware.
Without measuring, there’s always a risk that something has been neglected and missed. Don’t let the end-users be the first ones to detect potential flaws in your SDN infrastructure – start measuring already today.