The promise of SDN is low-cost hardware used to create highly cost-effective network services to be leveraged by organizations, municipalities and individuals. Through the separation of data planes and control planes, SDN, when used with cloud and NFV solutions, have made it easier for network administrators to access a network, assign resources and cut operational costs.
This said, software defined networks, like any other major tech, faces some uphill battles. Here are the top five.
Challenge #1: Security, Guarding Against User Error
SDN decouples the data plane from the control plane. SDN effectively separates the computational aspect of hardware with the controlling portal of that hardware. Once separated, a network admin has access to the abstraction layer allowing him/her to allocate network resources where needed based on real time data feedback.
While this all sounds excellent, most network administrators aren’t programmers and thus run the risk of introducing nefarious code into the control plane. Said nefarious code carries with it the ability to infect an entire network through a distributed controller.
To fight against this, SDN security strategies must put motions in place to protect the control plane through smart authentication applied to application access. Without these guards in place, the entire network is at risk.
Challenge #2: Security, Guarding Against Outside Threat
Another major security concern for SDN isn’t user threat but outside threat. Just as a network can be taken down and infiltrated via a DDoS attack, so can the control plane of a software defined network.
Traditionally, a hacking party will attack an overall network by overloading it with traffic. This overload causes the network to spike beyond its control and to shut down. The shutdown allows outsider to infiltrate and destroy.
With SDN, hacking parties can target a single SDN controller aiming at the same goal of overload and shutdown. To protect against the outside DDoS threat, network admin’s need to maintain the health of a SND controllers through proactive network security measures and continuous SDN controller availability.
Challenge #3: Continuous Visibility
The promise of SDN is the ability to change, alter and effectively manage data throughput within a network in real time. It means network admins have the tools needed to address traffic spikes and peaks in real time without the threat of service downtown or failure.
The issue with instant resource allotment ability is network analyzation is now slower than real time data management. If you are running a SDN which can immediately alter course in real time yet you are running daily checks across your network to respond on new developments, your reporting isn’t going to match up.
To solve the issue, SDN controllers need to incorporate API’s which directly integrate with SDN applications and systems. Through direct integration, monitoring can be done on a second by second basis, in real time, as your network shifts to meet resource demand. Directly integrated API’s will ensure performance visibility and application/VM discovery in real time as opposed to 23 hours from conception.
Challenge #4: Performance Degradation
At the end of the day, network performance is what matters most. If your network has crippling latency, your network is no good. Within SDN, the very core of the solutions – the separation of the data plane and the control plane – can cause performance degradation. Within a small network, the separation of planes will not cause much issue however the larger a SDN becomes, the possibility exists for higher levels of latency. Again, latency kills your network.
A possible solution to large-scale SDN increased latency is a distributed control plane, i.e. splitting a single control plane into many different instances. While this might allow for greater quantities of data to be pushed through multiple abstraction layers monitored by network admins, it also carries with it higher level of possible failure and higher level of operational complexities. Increased operational complexity not only means additional cost, it carries with it multiple points of failure over a single point of failure.
The golden standard for large-scale SDN would be to work out a balance wherein virtualization is maintained without network performance suffering yet the avenue to achieve that balance has not been fully reached yet.
Challenge #5: Downtime for Legacy Solutions
Implementing SND within an existing network should prove easy enough for most organizations because most, if not all, network devices are SDN operable. However, when it comes to legacy systems currently in operation, the situation becomes a bit harder for the following reasons:
- It is almost guaranteed that most legacy network systems will be supporting client business
- To make the jump to SDN, most legacy systems will have to be shut down for a period of time causing client business needs to be shut down for the length of imposed downtime
The trick in question is how to integrate legacy network systems into SDN via backward compatibility. By applying backward compatibility to legacy systems for SDN integration, the aim should be like any other downtime process – reducing cost, limiting service disruption and reducing possible network security risks.
Although we touched on the issue already, another SDN concern is that of scale. As your SDN grows in size, capacity and data quantity, the central issue of how to manage the flow of information between the separate data plane and control plane will loom large.
With more data on the network, one possible solution to communication issues is to push more intelligence to the data control plane only to have that data be interspersed between multiple control planes. Yet, as your SDN gains greater size, the issue of complexity comes to hand in terms of network administrators, quantity of control planes, monitoring solutions to ensure network device accountability and the eventuality of network latency between connected planes.
How you solve this issue is a great question.
All of these issues need to be taken into account when investing in SDN. Unless you effectively manage to work through security concerns, network device and performance visibility issues and legacy system compatibility/downtime, setting up a SDN might prove more trouble than benefit.