Analysis of the role of SDN switches in cloud computing networks in different scenarios

SDN technology has been around for several years, while cloud computing has an even longer history. Their combination has become a powerful use case for SDN, gaining significant attention in recent years. Many well-known consulting firms have reported steady growth in the SDN market. This assertion primarily refers to the application of SDN in cloud computing networks.

Regarding SDN in cloud computing networks, there are currently two main approaches: the "soft" side, represented by VMware, and the "hard" side, represented by Cisco. The former involves implementing the core logic of network virtualization within the hypervisor on the server, with the physical network acting merely as a transport layer. The latter, however, implements the core logic of network virtualization directly in the physical network, typically at the top-of-rack (TOR) switch, or on dedicated devices if the switch cannot handle it. Both approaches have their own strengths and loyal user bases.

However, the world is not unipolar or bipolar—it's multipolar. Real-world networks have many unconventional needs that these two approaches may not fully address, or even if they do, not optimally, in terms of implementation difficulty, performance, or cost. As a long-term provider of hardware-based SDN solutions, I’d like to introduce how real-world hardware SDN switches can tackle specific scenarios in cloud computing environments, whether public or private. Private clouds, in particular, often come with more customized requirements.

It should be noted that these scenarios can be handled by Cisco’s ACI, as its core idea is to use hardware SDN to support network virtualization. However, many users avoid ACI due to factors such as high costs, vendor lock-in, or the desire for local solutions. While I personally appreciate ACI from a technical standpoint, the need for alternative solutions remains valid.

Many people still hold misunderstandings about the use of SDN switches in cloud computing networks. Two common misconceptions are: first, someone always asks which controller we use and whether it can integrate with OpenDayLight, Ryu, or ONOS. Second, they assume that any SDN switch can support a cloud computing scenario, regardless of the vendor. These misunderstandings stem from a lack of understanding that SDN requires application-specific customization. It's not just about using a generic tool; it's about designing for a specific scenario. In cloud computing networks, the function is usually focused, and the controller may even be embedded directly into the cloud platform, such as in OpenStack Neutron Server. Therefore, a general-purpose SDN controller cannot be used directly in this context. Similarly, SDN switches must also be customized for cloud computing, making it impossible for any random SDN switch to support these scenarios. Our Shengke Network, for example, has developed specialized controllers and switches tailored for cloud computing environments.

In this scenario, users deploy network virtualization using tunnel overlays such as VXLAN or NvGRE. However, the vSwitch's handling of tunnel operations can significantly impact performance, leading to low throughput, high latency, and jitter. To address this, an SDN TOR switch can be used to offload the tunnel processing, reducing the burden on the server. All other operations remain unchanged. In this setup, the SDN TOR switch functions as an extension of the vSwitch. Going further, distributed elements can be moved to the L3 Gateway on the SDN TOR, allowing it to deeply participate in network virtualization.

Not all users embrace this model, but some find it highly beneficial. We’ve deployed this scenario in several small and medium-sized private clouds and a well-known IDC cloud. The biggest advantage for these environments is improved performance and stability. The data flow is illustrated in the figure below.

Many people assume that all servers in a cloud data center are virtualized. In reality, this is far from the truth. There are still numerous physical servers in both public and private clouds, and in some cases, they form the majority. Many cloud providers have encountered this need in practice. Reasons vary: some servers lack virtualization capabilities, others run resource-intensive applications where VMs perform poorly, and some are custom-built or kept isolated for security reasons. Regardless of the reason, these are real customer demands.

If VLANs are used, it’s relatively straightforward to manage, and SDN switches can still work. But when tunnels are involved, the problem becomes more complex. Where should the VTEP be configured? Some suggest placing a single VM on the server and installing a vSwitch, but this affects performance and isn’t ideal. Others propose a special vSwitch, but that adds complexity and workload. If the user’s device cannot be moved, neither solution works. For this, many professional network virtualization providers, including VMware, use a hardware SDN switch as the VTEP gateway to connect physical servers to the virtual network without requiring any changes on the server itself.

This scenario places additional demands on the SDN switch. It must support both tunnel bridging and routing, which most large-scale switch chips currently cannot do. Cisco’s ACI can, thanks to its custom chip. Shengke Networks’ SDN switches, built with self-developed chips, support both from the first generation. These switches are now widely deployed in public clouds, as shown in the architecture diagram below.

Hardware firewalls are commonly used in cloud computing networks, especially in corporate private clouds, hosted clouds, and even public clouds. Many customers insist on using their own hardware firewalls, which presents a challenge. In traditional networks, connecting a firewall is simple, but in cloud environments, firewalls may serve only certain users or applications and cannot be physically connected to the network exit.

Dynamic policy configuration is needed, and SDN switches are ideally suited for this. They enable dynamic strategy enforcement, which is a core feature of Cisco’s ACI. If tunnels are used, the issue becomes more complex, as many hardware firewalls don’t support them. A tunnel must be terminated and converted to VLAN before reaching the firewall, and the SDN switch is the best place to handle this.

Some argue that VLANs are limited to 4K, but in this case, each port can have a unique VLAN, eliminating the need for global uniqueness. Shengke’s SDN switches support this requirement effectively.

While multiple hypervisors are common, the most frequent hybrid scenario involves VMware and others. KVM and Xen are well-supported by open-source platforms, and cloud platforms can fully manage them. However, VMware is closed-source and harder to control. Many customers use legacy VMware products and want to support VPC, especially based on tunnel overlay.

Although VMware offers NSX, it is expensive and not always feasible. Customers want to use open-source solutions like KVM or Xen but still keep VMware. An effective solution is to use an SDN switch to connect VMware servers. The cloud platform configures VMware via its interface, uses VLANs to identify tenants, and converts VLANs to tunnels on the SDN switch. This approach has been successfully deployed by one of our industry cloud partners who extensively uses VMware. Many private clouds have similar needs: they don’t want to spend on NSX but want its features.

This scenario is not universally required, but some customers care deeply about it. In many small private clouds, VLANs are still used for their simplicity and performance. However, VLAN networking has limitations, such as poor scalability compared to tunnel overlays. Another issue is that when VMs move, VLANs must follow, which complicates management. In traditional VLAN setups, switches must pre-configure all possible VLANs, leading to unnecessary traffic and potential security risks.

A simple and effective solution is to use an SDN switch to dynamically configure VLANs as needed, improving efficiency and security.