Keith Bromley
Sr. Manager, Product Marketing at Ixia
Blog

Preparing For The SDN Surge

February 6, 2019 by Keith Bromley

I am sure everyone reading this blog has heard of software defined networking (SDN). It has been talked about for years. After all the hype has settled now, it appears that real deployments are happening. According to an April 2018 study  sponsored by Verizon, approximately 15 percent of organizations surveyed have already deployed SDN. That number is expected to rise to 57 percent by 2020. This is great news for everyone eagerly awaiting this technology.

However, there are two main hurdles to resolve. First, you need to understand the kind of SDN solution that are you planning to deploy. For instance, Cisco Systems has their own version of SDN called Application Centric Infrastructure (ACI). Solutions from other vendors use the OpenFlow protocol. And then there are cloud-based solutions on the market. The choice you make here, will affect how easy (or hard), complex and costly your SDN deployment will be.

This is an important consideration as another finding in the Verizon study was that 67% of respondents were concerned that the migration process would cause a disruption in service. This is a very valid concern—you do not want any self-inflicted outages or loss of user functionality. The migration process should definitely be planned out. In addition, how will the shift to a new architecture affect your network monitoring, troubleshooting, and security architecture?

Monitoring concerns should not be dismissed, if you want to avoid problems. As I have mentioned before, a visibility architecture is an important component of any security and/or troubleshooting process. When taps and network packet brokers (NPBs) are inserted into the network, it is a one-time disturbance. This allows you to make network changes (especially when it comes to security appliances, troubleshooting, and performance monitoring) to your security analysis and monitoring solutions with minimal to no delays or disturbance.

The NPB has great benefits for your SDN migration as well. For instance, if we specifically look at a Cisco ACI deployment, then the NPB provides the following benefits:

  • Improve ACI deployments with advanced L2–L4 filtering, application filtering, SSL decryption, load balancing, data masking, header stripping, and packet slicing
  • Use de-duplication to reduce unnecessary data along with security and monitoring tool costs
  • Eliminate ERSPAN encapsulation-related issues by stripping off VXLAN headers
  • Offload NetFlow/IPFIX traffic generation issues from the network switches

You can find more information on how to solve network and monitoring issues for ACI here.

No matter what you deploy for your SDN solution, you will want to deploy a monitoring solution that is flexible, powerful, and simple enough to enable your SDN choice. This means choosing a monitoring solution that gives you ultimate flexibility in the data plane by supporting any of the following deployment options for infrastructure:  pure software, whitebox switches, or vendor appliances. The trick here is that you need to weigh cost concerns versus performance. Lower cost (like pure software) options usually have a slower performance where vendor-based appliances will have better performance due to dedicated FPGAs to process functionality at wire speed. Here is an example of that type of solution.

Once you have selected your infrastructure option for the SDN monitoring solution, then you will need to determine the types of applications needed to enable and optimize your SDN solution, i.e. what monitoring features and functions (Layer 3-4 filtering, Layer 7 filtering, SSL/TLS decryption, deduplication, security threat intelligence, etc.) do you need.

Finally, you need a management solution for that monitoring functionality which can be integrated into your overall SDN solution. You need simplicity and the ability to support automation so that you keep costs down to meet your total cost of ownership goals for this project. Data visibility solutions that are simple to implement and that don’t create more complexity are what will be required to propel your SDN solution forward.

If you want more information on this topic, try reading this brochure.