actually, the private cloud must use software to define the network, establish a network with services separated from the underlying virtual and physical infrastructure, and finally realize network as a service (NaaS).

however, in addition to proprietary implementation technology, we still need to solve many problems in order to realize NaaS/SDN in a private cloud using multiple vendors and multiple hypervisors.

private cloud network: manage VLAN

firstly, private cloud network has two switching layers: virtual switching layer and physical switching layer. Physical switch is an Ethernet switch that we have been using for more than 2 years. The virtual switching layer is a component of various hypervisors. Most hypervisor architectures connect virtual switches through a common control panel to form a large distributed virtual switch. Some improved virtual switches in the market, as well as the open system virtual switches that are still developing, are: Open vSwitch.

Virtual and physical switches are still two different network entities, and they must implement a private cloud together. Most network architects use VLAN to connect these two devices, but this requires the physical and virtual switches to be locked.

a feasible method is to configure all possible VLAN on all lines and ports that configure the data center. However, this universal method has poor scalability, and there is a great risk of configuration errors, and there may be security and compliance problems. Another method is to implement a VLAN learning solution to dynamically manage VLANs of virtual and physical networks, especially when VM migrates. There are some solutions that work well, but they are private. Edge Virtual Bridging (EVB) IEEE 82.1qbg is a VLAN learning and mapping standard under development.

NVGRE and VXLAN: VLAN supporting layer 3 protocol

VLAN of private cloud network must use large-scale bridging technology to support VM migration and communication. This method has poor scalability and does not support 3-layer protocol load distribution. To solve these VLAN problems, there are currently two protocols supported by multiple vendors: VXLAN (Virtual Extensible LAN) and NV GRE (Network Virtualization Using General Routing Encapsulation). VXLAN and NVGRE are IFTF draft protocols, which support encapsulating MAC layer traffic in IP layer. By using the higher layer protocol, we can distribute the load on the Layer 3 protocol, while the VM remains on the Layer 2 network. This technology is very good because it breaks the inherent relationship between location and identity. This means that even if the VM moves to another subnet, it can still keep the original IP address. This method is feasible, but the performance may be affected.

disadvantages of the application of VXLAN and NVGRE in private cloud network

the appearance of vxlan and NVGRE is a great progress to realize a more dynamic and scalable private cloud network, but they are not complete solutions. They are encapsulated protocols and do not have a control panel yet. On the contrary, they also depend on other network functions. For example, VXLAN relies on protocol-independent multicast (UDP PIM), and communication between VMs must be achieved through layer 2 flooding and dynamic MAC address learning.

moreover, VXLAN and NVGRE can't solve the basic problem of extending layer 2 domain in the core network: "network trombone". Even if two VMs are located on the same switch, the traffic still needs to be forwarded to the core network first, and then reach the destination, which feels like a trombone pipe of an instrument. It's like using a student train discount ticket. You used to live in city A and then moved to city B, but if you must enjoy the discount, you can only buy a ticket from city A first, and then go to city B where your new home is located. Such an architecture is inefficient and cannot be extended. Finally, VXLAN is a virtual structure, which cannot be connected to some physical devices, such as firewalls, load balancers, etc.

in addition to VXLAN and NVGRE, we need a powerful control panel to integrate virtual and physical switches. In terms of open standards, the most exciting thing is the OpenFlow project of the Open Network Foundation (ONF). OpenFlow separates the control application (controller) from the underlying data program (switch).

OpenFlow will adopt a new method to realize packet forwarding between virtual and physical switches, thus eliminating the need for encapsulation, labeling and VLAN, but still supporting multi-tenancy, VM mobility and scalability. This will truly become an SDN for delivering NaaS as part of a private cloud.

however, the key word is "future", because the OpenFlow implementation is still changing, and the progress is not fast. Emphasis is placed on the support of switch suppliers for SDN/NaaS and OpenFlow. We need to abandon VLAN in private cloud network.