Listening to some SDN pundits one gets an impression that SDN brings peace to Earth, solves all networking problems and makes networking engineers obsolete.
An SDN solution that abstracts the dirty details of whatever networking functionality (example: Tail-F NCS) is definitely an improvement over today’s CLI-driven box-by-box mentality. If you can disable manual bypasses (it’s always easier to tweak a device configuration than to modify the service definition), you’ll get a consistent behavior across all devices managed by the SDN controller.
Will that make a network more reliable? It might, but do keep in mind that most network problems arise from operator errors. Making a configuration error on an SDN controller just increases the blast radius (listen to the Software Gone Wild podcast with Jeremy Schulman for more details) – instead of misconfiguring a single device, the SDN controller helps you misconfigure the whole network. Role-based access controls and other checks are thus even more important in the SDN world than they are in the traditional world of networking.
Finally, there’s the (in)famous separation of control and data plane. To illustrate what might be lurking in that part of the SDN world, consider these questions: did you ever have to upgrade a stack of stackable switches, or suffered a bad case of brain-dead supervisor module that looked OK to the backup supervisor module (which thus refused to take over)?
Fabrics implemented with controller-based centralized control plane (example: OpenFlow controller like Open Daylight) are functionally identical to stackable switches (or Cisco’s VSS, Juniper’s Virtual Chassis or HP’s IRF). Why should they work better than other centralized control plane implementations?
From theory to practice
Want to know more about data center fabric architectures? Check out this webinar.
Want a second opinion on your SDN strategy? Get in touch and we’ll figure it out.