When a friend who works for a major telecom/ISP operator in Karachi asked me to provide an awareness session on Software Defined Networking (SDN), I was happy to oblige.
His organization was making the move to an SDN-based data centre from a traditional data centre, and they were likely to adopt an SDN Wide Area Network (WAN) further down the track. But there was a problem: They didn’t have knowledge of SDN and didn’t know where to start.
This was in 2016 and I happily conducted a hands-on workshop for the organization. Ever since then, I have been fielding similar requests from various ISPs and telco operators. While teaching them, I too was learning about their challenges and bottlenecks. There were common challenges, even among hardcore networking professionals who are very experienced in networking.
From that, I have some observations that may help others who are looking to get into SDN. These observations are about challenges faced by networking professionals in their learning journey of SDN and they are more-or-less applicable to those who are coming from traditional networking environments/platforms.
SDN Controllers love Linux
The first thing I always emphasize is to have some exposure to Linux. It doesn’t matter which Linux distribution is being used. Any familiarity with any distribution should be good enough to get started. You don’t need to be a Linux admin or guru, but you should at least be able to play with Linux and use basic commands with ease. I feel privileged I was able to start my career when Windows was not dominant and therefore, we all had to learn UNIX/Linux for our computing needs. Open-source SDN Controllers (including OpenDaylight, Floodlight, ONOS, Ryu, NOX, POX, to name a handful) require some Linux know-how for installation and configuration of features. Even commercial SDN Controllers (without taking names here) require Linux familiarity for troubleshooting/configurations. In most cases, these SDN controllers are actually Linux servers with controller software installed.
SDN is about software control of hardware
I hear this question frequently from infrastructure professionals who start learning Cloud Computing and SDN: “Can we stay away from APIs, scripts, Apps, Python, Restconf, xml, Postman, service fabric, micro services, and so on, and still be a good designer of cloud computing solutions?”
Unfortunately, my answer is “No”.
SDN is about software (programming) so we (networking professionals) have to get involved to some degree with software, even if we skipped this aspect while in school.
We have to understand that software is now an integral part of our data centre infrastructure so we just can’t rely on hardcore networking skills to survive. This doesn’t mean you need to be an ‘app developer’ or ‘code warrior’ but a reasonable understanding is required. I love Python and so I encourage everyone in the networking field to learn it. Modern day networking is a bit incomplete without Python. Mininet, which is used as a Data Plane (aka Transport Plane) alternative in a simulated SDN lab environment, uses Python for managing hosts and resources. The scripts you’re going to run in Mininet are mostly written in Python.
This is the era of virtualization
Another skill I emphasize is virtualization. The time of physical servers is long gone, unless you have to maintain one due to compliance requirements. All cloud computing data centres of major cloud operators are virtualized and use SDN-based data centres. This makes it necessary to be knowledgeable in hypervisors, virtualization, containers, Kubernetes, Docker and so forth.
Also, SDN tends to be complemented by network function virtualization, which uses the ‘coded/software form’ of several network appliances including routers, switches, firewalls, security appliances, load balancers, traffic engineering tools, intrusion detection systems and so on. These usually run inside containers as apps. This is why I encourage learners to have a reasonable understanding of virtualization. Your virtualization journey can be as simple as playing with VirtualBox.
Benefitting from open-source tools, apps and protocols
My last piece of advice is that learners explore the power of open-source software and tools. One example of open-source software is OpenFlow, which is used as a Southbound protocol in SDN. OpenFlow helps the controller learn about the topology/graph of network devices/appliances. OpenFlow also interprets controller instructions for the data plane to understand and act upon. There are also open-source appliances that we can use in SDN environments including Open vSwitch. Open vSwitch is a virtual switch that can be programmed using OpenFlow. Similarly, there are several open-source APIs and apps available that are used for Northbound (between the Control and Application planes). It is just a matter of searching for open-source resources and taking advantage of them.
Thanks for reading this blog post! Keep reading and enjoying APNIC blog posts from various experts on different topics to gain and widen your knowledge base.
Azhar Khuwaja is a Telecom/IT Trainer with over 20 years of industry and training experience.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.