IP and Mobile Trends and Education


What is Software Defined Network (SDN)?



For a couple of years already, the term Software Defined Network (SDN) has been gaining popularity and it is slowly trending quite a lot. We also hear about the decreasing role of “classic” network engineers, who gained their knowledge a couple of years ago, mastering packet network theory, such as Ethernet, OSI / ISO model, and learning network device configuration commands, like switchport access vlan or ip route. Articles, such as “Sorry, network jobs are changing“, or “Do Network Professionals Need To Be Programmers?” may bother professionals, who are constantly  learning from textbooks about networks, or wanting to choose their career path. I personally see, among my fellow engineers and network administrators a little worry about how SDN can shake the market. What does this really mean for them?

What is Software Defined Network (SDN)?

Contrary to how it may appear, the answer to this question is not trivial. I have come across a lot of definitions, and more importantly, interpretations of what SDN is, which are largely dictated by someone’s idea of SDN. Vendors play a significant role in creating these definitions, claiming that they are ready for SDN era or even that they already have a ready product. In the meantime, one can say, that the No 1 principle of SDN is to separate the device abstraction that transport the network traffic (forwarding plane) from control plane abstraction, in such a way that it enables to control the network functions by the means of a software layer. In practice it can be systems, web applications or scripts. We also see this idea is called disaggregation like services disaggregation (you can watch here a nice talk about disaggregation with Russ, Jeff and Pete). The described mechanism is intended to enable the programming of network layer independently of the manufacturer’s operating systems. Hence, SDN is often referred to as network programmability and open networking. Interactions between layers of such a system, i.e. management application, SDN controller, and network devices, I would draw like this:

SDN Software Defined Network Architecture

It’s good to take a look on the communication scheme. Between SDN Application and SDN Controller, the “communication language” is API (Application Programming Interface) of the controller. So, in theory, on this link, we can use any SDN controller with API documentation and we are good to go with writing our own applications or a scripts for SDN. Further down, the communication between SDN controller and network devices is done via e.g. OpenFlow protocol (if supported by hardware manufacturer). This then means, that what happens with packets on the network devices depends on the given scenario, de facto, controlled from the Management Application Layer (aka SDN Orchestrator).

OpenFlow vs Netconf

OpenFlow is a protocol, which directly influences the data plane of the device, which means that it causes a direct entry in the routing table or switching table. Another common protocol is Netconf. By using Netconf, we are able to change the device configuration using protocols different than SSH (did you try to parse ssh and telnet outputs from linux srcipt perspective? me, yes). Taking this into account, we can say, to fulfill the principle of separation of control from data plane in SDN one can either use OpenFlow, with OpenFlow we cannot save the changes on the devices, or Netconf which doesn’t have this disadvantage . Of course, which of those protocols you will use in your implementation, is your choice.

So what is the change that SDN brings?

An infrastructure consisting of 6 Switches and 2 Routers may actually not need the SDN revolution, but administrating an infrastructure of several dozens of company’s branches and a thousand of network devices, and integration with your private cloud or something at hyper-scale is a great opportunity to utilize SDN achievements. SDN in this case can solve an issue with network order, automatic diagnosis, immediate reconfiguration and integration of many IT areas (e.g., systems, network, storage).

Is then SDN a threat for “classical” network engineer? Maybe the lovers of pure CLI form and BGP session configuration will not happily invite the SDN solution, as it will in some sense will be taking away their playground, which is command line. On the other hand, it can be a start for a new, fascinating adventure for SDN architects, who could use their skills of IP network design to design and deploy such a network. Let’s take a look also at the newly open areas and totally new specializations, such as Network Automation Engineer, SDN Engineer, which will require engineers having programming skills (not necessarily top notch) and knowledge of IP/Ethernet theory as writing scripts and developing SDN Management Applications will be an inevitable element of the SDN eco-system .

Anything else?

By it’s “openness” and “programmability”, it is SDN that opens the door to full utilization of the network devices’ potential, which by now, were still being limited by the configuration language dictated by the given producer. Let’s imagine that by using our script and NetFlow, we are able to develop an interesting functionality for us in the data plane layer. This approach to the above concept seems to be an opening more than closing!

Is it possible to get trained on SDN?

This broad issue combines in an obvious way, the programming knowledge along with the knowledge on the network architecture and Ethernet/IP. A SDN course, which we today call “Coding the Network (practicing SDN)” is something that will soon show up on our training map, so STAY CONNECTED!

Further reading

[1] “Software Defined Networks, A Comprehensive Approach”, P. Goransson, C. Black, T. Culver, Elsevier,

[2] Vendors documentation examples: Cisco APIC, Juniper Contrail, OpenStack documents



Marcin Bialy

Marcin Biały is Network and Security Architect with over 12 years of experience, with Service Provider and Enterprise networking background. He used to work for large service providers, global vendors and integration services companies as Network Architect, Leading Architect and Techincal Solution Manager positions. He designed, implemented and supported dozens large scale projects and infrastructure migrations, solved hundreds of tickets and spent hours with CLI and GUI of many flavors. Marcin is also holding industry recognizable certificates such as CCNP, CCNA, CCSI #35269, FCNSP #7207, FCNSA and more.

12 December 2017 at 12:12

Awesome and easy to understand . Thank you !


Leave a Reply

Your email address will not be published. Required fields are marked *