Software-Defined Networking in the Cloud.

For several years now, it has been possible to virtualize entire IT environments. How can organizations benefit from this – both technically and commercially through shared hardware utilization?

From the Virtual Machine to the Virtual Data Center.
In the past, if you wanted to run an application in the cloud, individual virtual machines (VMs) were available from hosting providers. These VMs were directly connected to the internet via a public IP address. The administrator had to take care of the VM’s security within the operating system.

Later, the first offerings for complete virtual data centers (VDCs) emerged. A VDC is much more than a single virtual machine. It is comparable to a physical data center in which any number of VMs can be deployed. Additionally, virtual networks (SDN) can be implemented. Suddenly, it became possible to virtualize entire IT environments and benefit from the commercial advantages of shared hardware usage.

The Challenge of the Physical World.
When the first hypervisors became mature, virtual networks could already be used. Virtual machines communicated early on via isolated private networks, which was very practical. Naturally, the need grew to separate these private networks across different computers running on the hypervisor.

A virtual machine on Host A needed to communicate with a VM on Host B just as securely and privately as on a single host. The hosts were physically connected via switches. Accordingly, these switches had to support the necessary “privacy” of individual virtual networks. For many years, the only way to achieve this was by configuring VLANs on Ethernet switches. A virtual network in the hypervisor corresponded to a VLAN on the switch.

This sounds simple—and it is, as long as you are dealing with a small environment with only a few networks. However, in larger environments, scalability challenges and administrative overhead quickly become significant. In many organizations, Ethernet switches and hypervisors are managed by different teams. If the hosting team wants to deploy a new virtual network, the corresponding VLAN must be requested from the network team, which can take time. Additionally, VLAN technology is outdated and no longer meets the requirements of modern cloud platforms. The maximum number of VLANs per switch (4096) alone becomes a limitation. Managing and configuring VLANs without automation is also error-prone and time-consuming.

Everyone knows the situation: when a VLAN is no longer needed, it often isn’t removed. Reasons include unclear documentation, poor communication between teams, lack of time, and operational pressure.

The Challenge of Self-Service.
Today, infrastructure is often consumed from cloud providers instead of building in-house server farms and high-speed networks. These providers are known as IaaS (Infrastructure as a Service) providers, offering core infrastructure components such as servers, networking, and storage. In many cases, IaaS customers want direct control: spinning up new VMs, attaching different storage tiers, and configuring new networks so that VMs can communicate privately.

At this point, it becomes clear that VLAN-based setups and decentralized switch management no longer work. Customers must be able to create virtual networks with a mouse click, provisioned automatically and instantly across large network and server pools. This requires software—everything must be automated. Legacy technologies such as VLANs must be replaced with modern alternatives.

Software Defined Networking (SDN).
SDN platforms allow programmatic configuration of network services. In other words, software handles the provisioning and deprovisioning of network components. Manual administrator intervention is no longer required. Cloud environments, network fabrics, cores, and routers are centrally and automatically configured. New services can be deployed quickly and without errors. Administrators can focus on platform development instead of repetitive configuration tasks.

In addition to automation, SDN solutions aim to reduce vendor dependency and abstract underlying technologies. It should no longer matter which hypervisor, Ethernet fabric, or router is in use. However, each SDN solution has its own limitations and specialties, making the selection of the right platform a demanding task.

Network Functions Virtualization (NFV).
Virtual network functions mirror those in the physical world: firewalls, NAT gateways, DHCP servers, VPN gateways, routers, and more. Virtualizing these functions means operating them virtually, fully centralized, and automatically configurable. Some SDN vendors provide the necessary NFV tools.

Virtual network functions are often associated with virtualized server environments, but they are not limited to them. Physical core infrastructures are increasingly equipped with such capabilities. Even customer premises equipment (CPE) is evolving into centrally managed vCPE (virtual Customer Premises Equipment). In addition to firewall, DHCP, VPN, and NAT, traffic management and QoS are also part of virtual network functions.

SDN and NFV in the Cloud.
SDN is most valuable in environments with frequent configuration changes and provisioning controlled by external entities (customers, applications, APIs). A cloud platform is therefore predestined for SDN.

Alongside SDN, technologies are used to abstract the limitations of underlying hardware. Take VLANs as an example. It would have been possible to teach SDN software to automatically provision VLANs across all switches. However, the inherent VLAN limitations would remain: maximum of 4096, bound to Layer 2, and not routable. Instead, so-called network overlays are used. These are virtual network layers built on top of the physical network (underlay). Technologies such as VXLAN or IPsec encapsulation transport private networks between endpoints. The core network no longer sees VLAN tags but regular IP packets that can be routed. This also enables Layer 2 networks to extend across routed environments like the internet.

In multi-cloud environments, certain functions can also be centrally configured. It is now common to share and centrally manage a virtual LAN between a private virtualized environment and Microsoft Azure or Amazon AWS. Virtual routers from the respective SDN vendor are typically used for this purpose.

Need for Speed.
In virtualized environments, SDN and NFV play another critical role: delivering extremely high routing and firewall performance. Typically, about 70% of network traffic in virtualized environments remains local—so-called east-west traffic between servers or VMs. North-south traffic refers to data exchange between the internal environment and external networks such as the internet.

Considering that servers today are commonly connected at 20 Gbit/s or more and top-of-the-rack switches can forward 1 Tbit/s, it quickly becomes clear that no single firewall or router can handle the total traffic—physically or virtually. A single instance, regardless of size or cost, cannot process the entire east-west traffic of a major platform. This is where distributed virtual routers and firewalls come into play.

If the SDN/NFV solution is integrated into the hypervisor, these functions can be distributed across all hosts. Firewalling and routing capabilities are present on every host and configured identically. Each host can independently decide at the source whether to forward or drop a packet—regardless of where a VM is currently running. Effectively, every VM receives its own firewall directly at the network interface. In addition to significantly higher throughput, this model enables VM micro-segmentation, meaning a distributed firewall can control traffic even between two VMs within the same IP network.

SDN at Cyberlink.
Since 2013, Cyberlink AG has successfully implemented SDN within its own cloud environment. In addition to SDN, SDS (Software-Defined Storage) is deployed on a hyper-converged infrastructure. Cyberlink’s cloud platform is based on VMware technologies including ESXi, NSX, vSAN, and vCloud Director.