1.Overview
In the context of the growing networks and the increasingly complex networking modes, traditional network deployment models fall short of the increasingly diverse needs and stringent security requirements. Traditional networking modes require complex networking, high maintenance costs, and homogeneous isolation of multiple service departments, and are lack of flexible security customization capabilities. Users are looking for a technology that enables fast, flexible and reliable L2-7 layer service isolation and security protection for multiple services and departments without increasing the construction costs.
VRF or MPLS/VPN is generally used for inter-domain isolation in the current solutions. However, the deployment has two shortcomings. First, software isolation using VRF instance or MPLS tab is performed at the forwarding level, which fails to isolated at the control level and management level. Second, as system resources are shared and preemptive, there are no fixed resources in each isolation domain. Therefore, reservation and on-demand allocation of resources cannot be achieved, and flexible customization of isolation domains in accordance with user needs cannot be realized.
OVC (OS-Level Virtual Context) technology virtualizes a single physical device into multiple logical devices. After OVC virtualization, multiple logical devices on the same physical device are provided with independent hardware, software, forwarding entries, management plane and logs, without affecting each other’s operation. OVC technology realizes the virtualization of resources and management. Thanks to the resource pool of physical devices, the fast deployment and adjustment of services will be no longer restricted by the physical device itself. In this way, construction, operation and maintenance costs can be reduced, on-demand deployment can be flexibly achieved, and complete isolation of faults is enabled, thus effectively isolating multiple services and allocating resources as needed. It lays a foundation for the network and security to transform to the dynamic and flexible Cloud service model.
2.OVC Technology Introduction
2.1 Basic Technical Terms and Definitions
Public OVC: The Public OVC refers to the default OVC instance that exists in the initial state of the system. All resources are used by the public OVC in a unified manner.
Ordinary OVC: Other OVC instances except the Public OVC are called Ordinary OVC. After the ordinary OVC is created, other OVC resources in the system that are not allocated to the Ordinary OVC fall into the Public OVC.
2.2 OVC Architecture and Implementation Principles
As a virtualization technology at the operating system level, OVC enables 1:N virtualization. Please refer to Fig. 2-1 for the OVC architecture:
Fig. 2-1 OVC system architecture
The virtualization technology at the operating system level assigns a series of software and hardware resources for each OVC, including independent ports, CPU, memory, number of sessions, new connections, concurrent connections, throughput, routing entries, and number of security policies. The actual specifications of OVC is subject to flexible customization.
OVC helps the system to perform independent management of process, memory, and disk for each virtual device, eliminating resource consumption and performance loss caused by switching and scheduling between virtual devices. In the same time, the virtualization at the operating system level realize the comprehensive isolation of each OVC from the management plane, the control plane, the data plane, and the service plane to form totally independent logical devices. The operating system kernel carries out scheduling between OVC virtual devices and assigns the hardware resources to each OVC virtual device based on a preset resource template.
2.2.1 Virtualization of Management Plane
As shown in Fig. 2-2, after OVC performs 1:N virtualization of physical devices, each OVC is deemed as an independent device, and users may access and manage their own OVC through the network interfaces of each OVC. independent configuration management protocol, such as HTTP/CLI/SNMP/SYSLOG. The configuration profiles are stored separately for independent restart and configuration restoration. With their own administrator and log files, each OVC can output the system logs and operation logs to the log monitoring server. As each OVC is managed independently by its own administrator, they are invisible to each other.
Fig. 2-2 OVC configuration management
2.2.2 Virtualization of Control Plane
Each OVC will start its own management process to manage its own system resources. Besides, each OVC will also enable its own protocol process (such as OSPF, ISIS, BGP and other routing protocols) to maintain its own protocol operation, ensuring the independence of each OVC process.
As shown in Fig. 2-3, the OVC1 enables OSPF/ISIS, the OVC2 enables OSPF/RIP/BGP, and the OVC3 enables ISIS/BGP. With separate processes, the process fault of any OVC protocols will not affect the normal operation of other OVC processes.
Fig. 2-3 Virtualization of the control plane
The control plane virtualization boasts isolation of faults between OVCs. As shown in Fig. 2-4, the OSPF process crashes in the OVC2 cause its OSPF protocol to stop normal operation, but the OSPF process in other OVCs can still run normally without any impacts.
Fig. 2-4 Fault isolation between OVCs
2.2.3 Virtualization of Data Plane
When creating an OVC, the system assigns interfaces that are to be managed by each virtual data plane, realizing complete isolation between OVCs. When the traffic enters the system through an OVC interface, only forwarding entries belonging to the OVC will be queried, and the traffic will only be forwarded from the interface of this OVC. Meanwhile, various routing protocols can only run on these interfaces to ensure that the forwarding entries of each OVC contain only interfaces of the OVC, thus completely isolating routing and forwarding of different OVCs.
To forward packets on the security device, a session table entry should be established to record status information. Each OVC has an independent session table, and only its own table will be queried and maintained during packet forwarding. In this way, forwarding information of each OVC is completely isolated without affecting each other, which is helpful in achieving the complete separation of address space and forwarding information.
2.2.4 Virtualization of Service Plane
In addition to virtualization of network resources, the OVC technology also applies to the virtualization of a full range of L4 ~ 7 services such as firewall, IPS, load balancing, traffic control, and traffic cleaning. By pooling network, security and application delivery resources to form service resources of various granularities, the administrator can flexibly allocate all L2~7 service resources.
As shown in Fig. 2-5, the system resources are pooled, each OVC can independently configure the security policies of relevant services to handle its own L4 ~ 7 services, with security services of each OVC being completely isolated. In this way, L4~7 virtualization is realized.
Fig. 2-5 Virtualization of the service plane
3.OVC Configuration Management
With the OVC technology enabled, the entire physical device is deemed as a Public OVC by default, which owns all configuration management rights and all hardware management rights of the physical device. It can create and delete ordinary OVCs and assign hardware and software and hardware resources for them. Here is a step-by-step instructions on how to create and delete an OVC, and how to perform configuration management such as assigning administrator and resources.
3.1 OVC Creation and Deletion
When creating an OVC, the virtual management system of the OVC should also be specified. Public OVC does not fall into any virtual management system. Ordinary OVCs should specify whether to enable the management service or not. If enabled, the system will create a WEB service process of this OVC independently to support its login and management through the WEB interface. Please refer to Fig. 3 -1.
Fig. 3-1 Configuration interface of OVC creation and deletion
Public OVC cannot be deleted. When an ordinary OVC is deleted, all resources it owns are allocated to the public OVC.
3.2 OVC Administrator Configuration Management
OVC administrators can be divided into the following three levels:
(1) Top Administrator: Available only in the public OVC,the Top Administrator is responsible for managing all function of the operating system and checking all configuration and running statuses. Only the Top Administrator is allowed to enable or disable the OVC function, create or delete the OVC, assign hardware and software resources for each OVC, create and delete administrators, etc. Global operations such as restarting the entire machine and changing the operating version of the device can only be performed by the Top Administrator.
(2) Ordinary OVC System Administrator: The administrator is a system administrator for all ordinary OVCs except the public OVC. The Top Administrator should create an Ordinary OVC System Administrator while creating an ordinary OVC; the OVC cannot be configured and managed by other means. The Administrator can operate the system resources and manage the function modules according to the permissions specified by the Top Administrator for the OVC. Available functions include configuring IP or other attributes for this OVC interface, configuring security policies based on the OVC interface, configuring the address of the OVC system log monitoring device, etc.
(3) Ordinary OVC Administrator: The administrator exists in all ordinary OVCs. It can only perform configuration management within the configuration permissions specified by the first two levels of administrators. Its configuration management scope is a subset of the OVC system administrator configuration management scope.
System administrators of ordinary OVCs can only view and manage the administrators and other configuration of their OVCs, with OVC configuration invisible to each other.
As shown in Fig. 3-2, there are four administrators in the system, namely, admin (the Top Administrator), ovc1_admin (system administrator of virtual management system vs1), ovc2_admin (system administrator of virtual management system vs2), Ovc2_user (ordinary user of the virtual management system vs2, which is only provided with the permissions such as viewing logs).
Fig. 3-2 OVC administrator configuration
As shown in Fig. 3-3, administrators of various levels have different functions of configuration management.
Fig. 3-3 Login menu of administrators at all levels
System administrators of ordinary OVCs can only view and configure the resources of their own OVCs.
As shown in Fig. 3-4, as the Top Administrator admin assigns only vlan-if2 and vlan-if4 interfaces for ovc1, when the ovc1_admin accesses the source NAT configuration page, it can only choose an outgoing interface from the two interfaces owned by ovc1.
Fig. 3-4 ovc1 administrator ovc1_admin accesses the source NAT configuration page
Likewise, ovc2 administrator can only choose an interface from vlan-if5 and vlan-if6 of their own. Please refer to Fig. 3-5.
Fig. 3-5 ovc2 administrator ovc2_admin accesses the source NAT configuration page
3.3 OVC Resources Allocation and Management
The resources available for allocation in the OVC include physical or logical interfaces, CPU, memory, disk, number of sessions, new session rate, throughput, etc.
As shown in Fig. 3-6, when accessing the OVC resource allocation page, the public OVC system administrator admin can allocate resources for each OVC. When an ordinary OVC administrator accesses this page, he/she can only view and configure the resources of this OVC.
Fig. 3-6 admin accesses the OVC resource allocation page
4.Virtualization Combining VSM and OVC
4.1 VSM Virtualization Introduction
VSM (Virtual Switching Matrix) technology virtualizes multiple physical devices into a single logical device. Users do not need to pay any attention to collaboration between devices, thus simplifying networking and management and improving performance and efficiency. Meanwhile, thanks to the online expansion and upgrade technology, new VSM member devices can be added to the network environments where the VSM technology is deployed without changing the original network topology. This has effectively increased the hardware and software resources of the logical device and improved its processing capabilities.
4.2 Virtualization Combining VSM and OVC
VSM virtualizes multiple physical devices into one logical device, while OVC virtualizes one device into multiple logical devices at the operating system level. Perform OVC virtualization of the logical device virtualized by VSM to realize N:M virtualization. In other words, run M OVC systems on N physical devices. There is no proportional limitation between N and M.
Virtualization combining VSM and OVC is helpful in saving construction costs of OVC virtualization, achieving fast deployment, and greatly improving system reliability.
DPtech can provide N:M virtualization of the full range of L2~7 services. As shown in Fig. 4-2, by using the VSM technology, two physical devices deployed with IPS, firewall, and load balancing board form a logical device, which is then divided into multiple devices with virtual IPS, virtual firewall, and virtual load balancing virtual devices by using the OVC technology. Each virtual device can provide completely independent L2 ~ 7 services.
Forwarding table
Fig. 4-2 N:M service virtualization
5.Examples of Typical Networking
The OVC technology can be used independently in actual networking, or be used in combination with the VSM technology, depending on the scale of actual environment, networking modes, requirements of bandwidth and reliability, and other aspects. Below is an example of two typical networking environments.
5.1 Typical Networking 1: Service department isolation
There may be two user groups in a campus network: an intranet user group and an external network one. Intranet users are only allowed to access intranet servers, and external network users are only allowed to access external network servers. Traditional networking modes establish physical networks respectively for the intranet and the external network, with the traffic of the two networks physically isolated. This method consumes a lot of hardware costs, operating costs, and management costs.
With the OVC technology, only one physical network is needed between the intranet and the external network. The interfaces connected to the users/servers of the intranet and the external network are assigned respectively to different OVCs. By creating administrator accounts in the respective OVCs for management and maintenance, it substantially brings down the hardware costs and maintenance costs. Please refer to Fig. 5-1:
Fig. 5-1 Networking of service department isolation
5.2 Typical Networking 2: Multi-tenant IaaS application
In the Cloud computing era, IaaS, as an IT construction mode, is gaining popularity, with enterprise users purchasing or renting networks and security devices from operators or Cloud service providers. Therefore, it has become a challenge for operators or Cloud service providers to provide network and security services for a huge amount of enterprise users in a more cost-effective and flexible manner. OVC technology comes forward as an ideal solution.
As shown in Fig. 5-2, with the adoption of OVC technology, users purchase or rent virtual devices created by the OVC technology, rather than physical devices. The OVC virtualization technology helps form virtual devices for users by separating a part of the resources from the physical devices. It eliminates the need of separately purchasing a complete set of equipment for forming a network. With the administrator account provided by the operator, users can perform flexible configuration and management on the rent or purchased virtual devices as needed. To adjust the enterprise network scale, enterprises may also apply with the operator for increasing or decreasing the resources of their virtual devices, such as the software and hardware interfaces, without adjusting the entire network or purchasing and installing other devices.
Fig. 5-2 Multi-tenant IaaS application
