First let’s get on the same page on what Software Defined Networking (SDN) is. I say this as a saw a report recently indicating a higher percentage of people than you might think faking they knew what cloud was in the office and during job interviews even though there’s been no shortage of cloud blogging. Computer networks conceptually are made up of three planes: the data plane which carries network traffic, the control plane which manages tables that determine how packets are forwarded, and the management plane for operations and administration. Traditionally, data and control lived in the network devices with forwarding tables (i.e. control) being populated by routing protocols or manually by configuring port groups, access control lists, QoS, VLANs, VRFs, etc … Management has traditionally occurred from a server running an element management tool, terminal emulator for command line interface access or network change and configuration management (NCCM) tool.
So to review: data and control on devices; management on servers. What changes with SDN is the control plane is moved into software on a server. So, why the change? The disadvantage of the traditional method is that if you want to change how traffic flows in your data center like, for instance, you want to create a secure virtual data center (i.e. network container) for a particular tenant you have to go to all the devices in the data center that could potentially support this virtual data center and instruct those devices on how to control the packet forwarding (i.e. you have to create VLANs, VRFs, modify QoS, etc … on the devices themselves). This is complicated and creating a virtual data center depending on the size and the extent of how far up the stack you go (i.e. do you need to include load balancing and firewall services, etc…?) can involve hundreds or thousands of individual commands to be executed. With SDN, you have a single point of control: the controller running on a server. It also means you can dumb down your network gear. So this leaves us with two clear advantages: 1) dumbed down network gear means cheaper, commoditized equipment, and 2) simplified control since just one place to go.
Great, so just do it, right. Like Nike. Where are the stumbling blocks? First, your IT staff has built a vast amount of expertise in managing the traditional network. This comes in the form of understanding of the command line interfaces and communication and routing protocols that the device vendors have been spending years honing. Are you just going to throw that aside and implement with software APIs that are not going to get it right overnight? Secondly, the word is still out on how SDN will handle the packet forwarding dependent on rules above layer 3. In an SDN network if a device comes across a packet it doesn’t know what to do with, it has to go to the controller. What’s this performance going to look like on a high speed interface with a long access control list on it? There’s bound to be other challenges, particularly in a multi-vendor environment.
So the trick, therefore, is to gracefully get to the advantages SDN brings while leveraging your current investments and expertise. What you need is a solution that gives you a single point of control of your traditional network. This method involves blueprint and automation. Your virtual data centers are blueprinted with commands your staff already uses today and then virtual data centers are stamped out from a single control point. A solution like this takes advantage of the best way to manage a network which today means going to the device, but can also leverage SDN management systems as soon as they are ready, so this gives you the best of both worlds and a graceful migration from traditional to SDN. You also get the advantage of keeping the control management on the services devices (layer 4 and above) until those kinks get worked out with the SDN solutions. This approach will allow you to use existing equipment, leverage your staff expertise, enjoy the benefits of single point of control and have a migration path to SDN. To review, just remember that the key is using a solution that provides the blueprinting but stays agnostic to the underlying network control. That network could be physical, virtual, managed with device CLI or through SDN and will include network services above layer 3.
By Dave Signori