Network Service
In the ZCF architecture, the cloud platform achieves network virtualization through either native networking or the ZNS Network Service. Native networking targets foundational cloud networking scenarios, providing network connectivity, isolation, access control, and common network services for VM instances, bare metal, and elastic bare metal workloads. ZNS Network Service targets software-defined networking scenarios, supporting cloud network connectivity, isolation, and scalability through independent network infrastructure and network service management capabilities.
Cloud Platform Native Network
Cloud platform native networking abstracts the physical data center network into L2 networks, L3 networks, and network services. L2 networks provide broadcast domains and Layer 2 isolation, while L3 networks organize IP addresses, gateways, and network services. Security groups, VPC firewalls, Elastic IPs, port forwarding, load balancing, IPsec, port mirroring, NetFlow, OSPF, multicast, and QoS together provide network connectivity, isolation, access control, north-south access, and bandwidth management for workloads. Port mirroring copies packets, and NetFlow exports flow records to external systems. Cloud platform native networking itself does not provide traffic analysis, visualization, or alerting capabilities.
The cloud platform native network virtualization solution abstracts switching, routing, and network services from dedicated hardware. The cloud platform centrally orchestrates these capabilities, while physical switches, host-side virtual switches, and network service instances jointly complete data forwarding. The physical network provides basic connectivity, and the cloud platform maintains the service network model and its configuration lifecycle.
The cloud platform divides the network model into L2 networks and L3 networks. An L2 network corresponds to a Layer 2 broadcast domain and provides connectivity and isolation for L3 networks. Supported L2 network types include NoVLAN, VLAN, VXLAN, and hardware VXLAN. L3 networks are built on top of L2 networks to manage IP addresses, gateways, DNS, and related network services, and mainly include flat networks, public networks, and VPC networks.
L2 Network
L2 networks serve as the foundational native network abstraction in the cloud platform, enabling virtual network connectivity for workloads such as VM instances and bare metal servers to the underlying physical data center network. The cloud platform uses L2 networks to manage both tenant and management networks, creating virtual switches on hosts within a cluster and attaching virtual NICs, physical uplink interfaces, or tunnel interfaces to the same forwarding path.
From the control plane perspective, L2 networks are loaded and unloaded at the cluster granularity. Once an L2 network is loaded onto a cluster, the cloud platform creates Linux Bridges on hosts within that cluster and configures corresponding uplink interfaces based on the network type. When a VM instance connects to an L2 network, its virtual NIC is attached to the corresponding Linux Bridge, which handles intra-host forwarding or forwards traffic to the physical network.
From the data plane perspective, L2 networks must ensure Layer 2 forwarding within the same broadcast domain while isolating broadcast traffic between different L2 networks. Cloud platform native networking supports L2 network types including NoVLAN, VLAN, VXLAN, and hardware VXLAN to accommodate different scale requirements, isolation requirements, and physical network conditions.
NoVLAN and VLAN Networks
VLAN networks carry VLAN IDs in Ethernet frames based on IEEE 802.1Q and use different VLAN IDs for Layer 2 isolation. After the cloud platform creates a VLAN-type L2 network, it creates the corresponding VLAN subinterface on the host and attaches it to a Linux Bridge. During inter-host communication, the physical switch forwards traffic based on VLAN IDs and MAC addresses.
NoVLAN networks do not add VLAN tags to service traffic. When creating a NoVLAN-type L2 network, the cloud platform creates a Linux Bridge based on the specified physical NIC. The switch port connected to that NIC is typically configured in Access mode. Hosts that load the L2 network must have physical NICs with consistent names.
When using VLAN networks, data center switch ports must be configured in Trunk mode and allow the corresponding VLANs. Because L2 networks are loaded by cluster, the physical NIC names used to carry the L2 network must be consistent across hosts in the same cluster.
Layer 2 Port Isolation (PVLAN)
PVLAN is used to restrict direct access between different service instances while they share the same L2 network. This capability is not an L2 network type parallel to NoVLAN, VLAN, or VXLAN. Instead, it is a port isolation mechanism implemented through coordination between the host side and the physical switch side.
For VM instances on the same host, the cloud platform uses Linux Bridge port isolation to restrict Layer 2 forwarding between virtual NICs. For VM instances on different hosts, physical switch port isolation or PVLAN configuration is required to prevent traffic from bypassing host-side isolation through the physical network. Therefore, to achieve complete cross-host Layer 2 isolation, the host side and switch side must be configured according to the same isolation objective.
Physical Uplinks: Bonding and Port Aggregation
Port aggregation combines multiple physical NICs into a single logical interface to reduce service impact from individual NIC failures and increase upstream link bandwidth. The cloud platform supports two Bond modes: active-backup and 802.3ad, and Bonds can be created via CLI or GUI.
When using Bond for the management network, configuration is typically completed in advance during the compute node deployment phase; the business and storage networks can be configured after physical hosts are onboarded, based on the actual network topology. When creating an L2 network, Bond can be used as a physical uplink interface to leverage port aggregation capabilities—such as high availability and increased bandwidth—at the network virtualization layer.
VXLAN Network
VXLAN networks extend L2 connectivity over L3-routable physical networks via tunneling encapsulation, making them suitable for scenarios requiring L2 business networks across L3 boundaries. Unlike VLANs, VXLAN does not require all physical hosts to reside within the same physical L2 domain and helps limit the impact scope of virtual network misconfigurations on the underlying physical network.
When the cloud platform creates an L2 network of VXLAN type, it configures VXLAN sub-interfaces on physical hosts and connects them to Linux Bridge. For inter-host communication, the source host encapsulates VM traffic into VXLAN packets and sends them to the destination host, which then decapsulates the packets and forwards the original traffic to the target VM.
Before using VXLAN networks, a VXLAN Pool must be created. The VXLAN Pool defines the available VNI range and the VTEP IP address range for physical hosts. The cloud platform uses the VTEP CIDR to identify the IP address on each physical host designated for establishing VXLAN tunnels.
Hardware-Accelerated VXLAN Network
Hardware VXLAN networking offloads VXLAN encapsulation and forwarding capabilities to data center switches. Servers still connect to the network via VLANs; switches convert traffic between VLANs and VXLAN tunnels based on preconfigured VLAN-to-VXLAN mappings, then forward VXLAN packets across the switch fabric.
This approach reduces CPU overhead on servers for VXLAN encapsulation/decapsulation and mitigates the impact of software-based VXLAN on network latency and forwarding performance. Hardware VXLAN networking requires integration with an SDN controller to provision logical networks, ports, and routing resources on switches.
SDN Controller
In hardware VXLAN scenarios, ZCF works with the data center SDN controller to map L2 networks, L3 networks, and routing resources in the cloud platform to logical network resources on the switch side. Users create service networks in ZCF, and the SDN controller delivers the corresponding configurations to switches.
ZCF currently supports integration with compatibility-verified Huawei iMaster NCE-Fabric V100R023C00SPC201 and H3C VCFC R6506. Controller integration has strict version dependencies. Before deployment, confirm that the controller model and software version meet ZCF compatibility requirements.
Huawei SDN Controller Integration
Before integrating with Huawei iMaster NCE-Fabric, prepare resources on the controller side, including a third-party system access account, VLAN and VNI ranges, Fabric, tenant, VPC, and external networks, and enable LLDP on switches and hosts. After ZCF adds the controller, it synchronizes basic information such as Fabric, tenants, VPCs, switches, and ports.
After a hardware VXLAN Pool is created and loaded to a cluster, users can create hardware VXLAN L2 networks in ZCF and deliver network resources to the specified SDN tenant. When a flat network or VPC network is created based on the L2 network, ZCF continues to create the corresponding subnets, logical routers, and connection relationships on the controller side.
H3C SDN Controller Integration
When integrating with H3C VCFC R6506, ZCF completes authentication after adding the controller and synchronizes basic information such as tenants, VDSs, and VLAN-to-VXLAN mappings. When creating a hardware VXLAN network, users select the target tenant and VNI, and ZCF validates the configuration against the resource ranges on the controller side.
Hardware VXLAN L2 networks created based on the H3C SDN controller can be used to create flat networks and VPC networks. Related subnet and gateway configurations are synchronized to the specified tenant on the controller side. This integration scope does not include all basic network services or advanced network services. L3 networks created based on H3C VCFC R6506 do not support shared load balancing.
Collaboration Boundary
The SDN controller is responsible for logical network, port, and forwarding configurations on the switch side. ZCF is responsible for mapping the service network model to controller resources. Switch onboarding, Fabric planning, VLAN/VXLAN resource pools, tenants, and external network boundaries must be prepared in advance in the SDN controller and physical network. The capabilities described in this white paper apply only to the explicitly listed controller versions and verified feature scope.
L3 Network
L3 networks include flat networks, public networks, and VPC networks. L3 networks are built on top of L2 networks and manage IP ranges, gateways, DNS, and associated network services.
A flat network directly connects VM instances to the data center network. It can assign service addresses to VM instances and supports services such as DHCP, User Data, security groups, Elastic IPs, and port mirroring. A public network is used to connect networks outside ZCF. It can serve as the upstream network of a VPC vRouter and provide external addresses for services such as Elastic IP, port forwarding, and load balancing. Here, "public network" refers to a network role and does not necessarily mean that the network is directly connected to the Internet.
A VPC network is an isolated network space that tenants can independently plan and manage. VPC networks use VPC vRouters to connect to other VPC networks or external networks, and use VPC vRouters to provide services such as DHCP, DNS, SNAT, route tables, VPC firewalls, Elastic IPs, port forwarding, load balancing, IPsec, NetFlow record export, OSPF, and multicast routing. Security groups mainly take effect on VM NICs on the host side and do not rely on VPC vRouters for traffic filtering.
VPC vRouter
A VPC vRouter is a dedicated instance running a customized Linux operating system and a network service agent. Management nodes deliver configurations to the VPC vRouter through the agent, and the VPC vRouter provides routing, address translation, firewall, and other centralized network services for its associated VPC networks. A single VPC vRouter can be associated with multiple VPC networks and is responsible for Layer 3 forwarding between these networks and between VPC networks and external networks.
Security Group
In traditional data centers, networks divide into trusted zones, DMZ zones, and untrusted zones. Perimeter firewalls enforce traffic control to ensure network security. In virtualized data centers, perimeter firewalls may struggle to handle scenarios such as network isolation between different tenants and access control between different services within the same tenant flexibly. Therefore, ZStack Cloud introduces a new component: security group. A security group is a distributed firewall focused on controlling east-west traffic and supports inbound and outbound traffic control at the VM instance NIC level.
- The set of security group rules: supports the addition, deletion, and modification of rules to control rule actions.
- The set of associated NICs: supports the binding of VM instance NICs to apply security group rules to them.
- Default policies: If no rules are added, except communication between group members, the security group denies all inbound traffic by default, and allows all outbound traffic.
- Rule flexibility: Rules support on-demand modification, including source IP, destination IP, destination port, protocol type, and priority.
- Dynamic priority adjustment: When adding a rule, you can insert it at a specific priority. When removing a rule, priorities automatically adjust to remain consecutive.
- Multiple security groups per NIC: A VM instance NIC supports association with multiple security groups. You can dynamically adjust the priority of these groups. By default, rules in the first-associated security group take effect first.
Technical Principles
- Composition of a security group:
- Source: Supports source data (for inbound direction) and destination data (for outbound direction).
- Address Type: Supports IPv4 and IPv6.
- Protocol Type and Port: Supports ICMP, TCP, UDP, and more.
- Action: Deny or allow.
- Priority of security group rules:
- Rule priority is a consecutive and unique (priority 0 indicates the highest priority by default). Lower priority numbers indicate higher precedence.
- By default, newly added rules have the lowest priority. When inserting a rule at a specified priority, subsequent rule priorities adjust automatically to ensure uniqueness.
- When traffic passes through a VM instance NIC, matching starts from the rule with the highest priority. If a match succeeds, the rule action executes. Otherwise, matching continues with the next rule.
- Import and export of security group rules:
- Existing rules support one-click export.
- Exported rules support re-import into other security groups, with rule validation provided during import.
- Associating multiple security groups with a NIC:
- A VM instance NIC can be associated with multiple security groups. The associated groups support priority ordering. A lower number indicates a higher group priority.
- When traffic passes through the VM instance NIC, matching starts from the security group with the highest priority. If a rule within that group matches, the rule action executes. Otherwise, matching proceeds to the next security group.
- NIC default policy:
- By default, the NIC's default inbound policy is Allow, and the default outbound policy is Deny. These default policies support modification.
- When traffic does not match any security group rule, the NIC's default policy executes.
Application Scenarios
- Access control among different services: Take a typical web application as an example.
- Allow any IP address to access TCP ports 80 and 443 on the Web VM instances.
- Allow the Web VM instances to access TCP port 8080 on the App VM instances.
- Allow the App VM instances to access TCP port 3306 on the DB VM instances.
Create separate security groups for the three business types (Web, App, DB) and configure corresponding rules to achieve access control among the different businesses.
Figure 11. Access Control Among Different businesses 
- Coexistence of multiple businesses: In addition to providing service capabilities, the above business VM instances also need to allow operational control (assumed to use the SSH protocol). There are two implementation options:
- Option 1: Add a new rule to each of the three security groups.
- Option 2: Create a new security group and associate it to the NICs of all the above business VM instances.
ZStack Cloud supports associating multiple security groups with a VM instance NIC. Option 2 is the preferred method for its better flexibility and controllability. You can configure two security groups for each business VM instance NIC mentioned above and adjust the security group priority and default rules as needed.
- Multi-level permission security configuration: In an IDC scenario, assume an administrator needs to prevent tenant VM instances from accessing certain external networks. There are two implementation options:
- Option 1: The administrator configures a default security group and rules for a project. The platform forces project members to associate this group when creating VM instances. From the project member's perspective, this security group is visible but cannot be disassociated.
- Option 2: The administrator configures a security group and rules for tenant VM instances. From the tenant's perspective, this security group is invisible and cannot be disassociated.
- Disabling communication within a security group:
By default, VM instances within the same security group can communicate with each other without any rule restrictions. In certain scenarios where communication between VM instances within the same group must be prohibited, you can disable the default rule: Allow for communication within the group. Note that this default rule cannot be deleted.
VPC Firewall
A VPC firewall provides Layer 3 access control in VPC network environments, and its rules are deployed on the VPC vRouter. The inbound and outbound directions of VPC firewall rules are defined from the perspective of VPC vRouter interfaces: traffic entering the VPC vRouter from the network connected to an interface is inbound, and traffic sent from the VPC vRouter to the network connected to an interface is outbound.
When a service flow passes through a VPC vRouter, it traverses the inbound direction of the ingress interface and the outbound direction of the egress interface. For example, when an external network accesses a VM instance in a VPC network, the traffic passes through the inbound direction of the public network interface and the outbound direction of the VPC network interface. When a VM instance in a VPC network accesses an external network, the traffic passes through the inbound direction of the VPC network interface and the outbound direction of the public network interface.
A VPC firewall includes system rules, default rules, and user-defined rules. System rules ensure necessary network services and basic connectivity, and their modification scope is restricted by the platform. Default rules handle traffic that does not match user-defined rules. Before modifying default rules or disabling system rules, confirm that user-defined rules can meet service connectivity requirements.
When configuring user-defined rules, first identify the interfaces through which service traffic enters and leaves the VPC vRouter, and then select the inbound or outbound direction relative to those interfaces. Do not determine the rule direction from the perspective of the VM instance.
For traffic from a VPC network to an external network, access control can be applied in the inbound direction of the VPC network interface or the outbound direction of the public network interface. For traffic from an external network to a VPC network, access control can be applied in the inbound direction of the public network interface or the outbound direction of the VPC network interface. The actual rule position should be planned consistently based on security boundaries and O&M practices.
Traffic between different VPC networks is also evaluated based on the ingress and egress interfaces. For example, when VPC network-1 accesses VPC network-2, the traffic passes through the inbound direction of the VPC network-1 interface and the outbound direction of the VPC network-2 interface.
Elastic IP and Port Forwarding
Elastic IP and port forwarding both provide public network access entries for VM instances that use private addresses. Both capabilities essentially use iptables NAT rules to modify the destination address of packets and return response traffic along the corresponding connection. Their differences lie mainly in mapping granularity and applicable network scenarios.
Flat networks support only Elastic IP. VPC networks support both Elastic IP and port forwarding. SNAT is used when VM instances actively access external networks, while Elastic IP and port forwarding are used when external clients actively access VM instances. These capabilities serve different purposes and should not be confused.
Common Implementation Principle
Elastic IP and port forwarding are both implemented based on Linux Netfilter. The platform configures address or port translation rules in the NAT table through iptables. After an external request reaches the public address, a DNAT rule translates the destination address to the private address of the VM instance. Return packets are translated back based on connection tracking information.
Flat Network: Elastic IP Only
Flat networks support only Elastic IP. The platform creates a dedicated Linux Namespace on the host where the VM instance resides, configures public-side and private-side network interfaces and iptables NAT rules in the namespace, and establishes a one-to-one mapping between the Elastic IP and the private IP address of the VM instance. The related traffic is translated locally on the host where the VM instance resides and does not pass through a VPC vRouter.
VPC Network: Elastic IP and Port Forwarding
Elastic IP and port forwarding in VPC networks are both implemented by VPC vRouters. A VPC vRouter connects the public network and VPC networks and configures iptables NAT rules on itself. This capability does not require a Linux Namespace to be created on the host where the VM instance resides.
Elastic IP establishes a one-to-one mapping between a public IP address and a private IP address of a VM instance. It is suitable when multiple services need to be exposed through the public address. Port forwarding uses public IP address, protocol, and port as matching conditions and translates access requests to the specified VM instance IP address and target port. It is suitable when only selected services need to be exposed.
For example, if a VM instance provides a Web service on TCP port 80 and other ports should not be directly exposed, configure a port forwarding rule to map the TCP port of a specified public IP address to TCP port 80 of the VM instance. The external port and the VM instance port can be the same or different.
Port forwarding in VPC networks supports both single-port mapping and port range mapping. When configuring port forwarding, specify the public IP address, protocol, external port or port range, target VM instance IP address, and target port or port range.
Load Balancing
Load balancing receives client requests through a virtual IP address and listeners, and distributes traffic to healthy backend servers according to the configured scheduling policy. Load balancing supports common protocols such as TCP, UDP, HTTP, and HTTPS, and can provide Layer 4 or Layer 7 traffic distribution capabilities based on service scenarios.
Protocols and Implementation
TCP and UDP listeners provide Layer 4 traffic distribution based on connections or datagrams, and are suitable for databases, middleware, and general network services. HTTP and HTTPS listeners can identify application-layer requests and are suitable for Web applications, API services, and scenarios that require forwarding by domain name or URI.
When client address information needs to be passed to backend servers, use Proxy Protocol or X-Forwarded-For based on the listener protocol. When Proxy Protocol is used, backend services must support the corresponding protocol parsing capability. X-Forwarded-For applies to HTTP and HTTPS traffic.
Traffic Scheduling
Load balancing can distribute access requests by using algorithms such as round robin, weighted round robin, least connections, and source address hash. Round robin applies when backend servers have similar processing capabilities. Weighted round robin can distribute more requests to backend servers with higher processing capabilities based on server weights. Least connections applies to long-lived connection services where request processing times vary significantly. Source address hash can continuously forward requests from the same source address to the same backend server.
With session persistence, load balancing can identify the access relationship between the same client and backend server and direct consecutive requests to a specified backend server to maintain service session continuity. Layer 4 session persistence is typically based on the source IP address, and Layer 7 session persistence can use cookies to implement application-layer sticky sessions.
Health Check and Access Control
Load balancing can perform health checks on backend servers and automatically adjust the traffic distribution scope based on probe results. When a backend server fails consecutive probes, load balancing stops forwarding traffic to that server. After the server becomes healthy again, it is added back to the forwarding list, reducing the impact of abnormal backends on service access.
Load balancing also supports access control lists. Blacklists or whitelists can be configured at the listener level to restrict source address ranges that are allowed or denied access.
Advanced Forwarding
HTTP and HTTPS load balancing supports advanced forwarding based on conditions such as domain names and URIs. Requests for different domains or paths can be distributed to different backend server groups. This capability applies to scenarios such as multi-site access through a single entry, static and dynamic content separation, and microservice access routing. The specific capabilities depend on the configuration items provided by the current version.
In VPC networks, load balancing can serve as a service entry and forward access from public or external networks to backend VM instances in private networks.
In flat networks, load balancing can reside in the same L2 network as backend servers and receive and forward access traffic through a virtual IP address.
Load balancing in flat networks can also work with Elastic IP to provide an external access entry by mapping public network access to the load balancing virtual IP address in the flat network.
IPsec
IPsec is used to establish encrypted tunnels between different data centers, private clouds, or public cloud networks, enabling protected subnets on both sides to securely communicate through external networks. This capability applies to scenarios such as branch interconnection, multi-region networking, and hybrid cloud connectivity.
- ESP protocol: Defines a secure transmission method for IP data. For more information, see ESP Protocol.
- IKE protocol: Defines a negotiation mechanism for generating keys used by ESP and keys used by IKE itself, as well as the authentication mechanism for IPsec. For more information, see IKE Protocol.
ESP Protocol
- Transport Mode
In this mode, typically only the payload of the IP packet is encrypted or authenticated. The unaltered or unencrypted original IP header preserves the original routing path. However, when using the authentication header (ESP Auth), the IP address cannot be modified through Network Address Translation (NAT) to avoid invalidating the hash value. The transport and application layers cannot be modified in any way, for example, by changing port numbers, as they are always secured via hashing.
Figure 23. Transport Mode-IP Packet 
- Tunnel Mode
In this mode, the entire IP packet is encrypted and authenticated. It is encapsulated into a new IP packet with a new outer IP header attached. Tunnel mode is used to create virtual private networks for network-to-network communication (for example, connecting routers at different sites), host-to-network communication (for example, remote user access), and host-to-host communication. Tunnel mode supports NAT traversal.
Figure 24. Tunnel Mode-IP Packet 
IPsec in cloud platform native networking supports tunnel mode and does not support transport mode. During deployment, ensure that gateway addresses on both sides are reachable, protected subnets do not overlap, and authentication information, encryption parameters, and subnet ranges are consistent on both sides. After the tunnel is established, service traffic must still meet routing and security policy requirements.
IKE Protocol
IKE has two versions: IKEv1 and IKEv2. We recommend using IKEv2 for IPsec in cloud platform native networking. IKEv2 can complete the negotiation of the IKEv2 SA and IPsec SA using four messages, simplifying the negotiation process compared to IKEv1.
- Initial Exchanges
- Create_Child_SA Exchange
- Informational Exchange
- The first message exchange completes the parameter negotiation for the IKE SA in plaintext. This includes negotiating encryption and authentication algorithms, exchanging ephemeral random numbers, and performing a Diffie-Hellman (DH) exchange. Based on this, the key for encrypting subsequent IKE messages can be calculated.
Figure 25. Plaintext Exchange 
- The second message exchange completes identity authentication and IPsec SA parameter negotiation in encrypted form. IKEv2 supports three authentication methods: certificate authentication, pre-shared key (PSK), and EAP authentication. Cloud platform native networking supports the PSK authentication method.
Figure 26. Encrypted Exchange (Based on PSK Authentication) 
Port Mirroring
Port mirroring copies packets from a specified VM NIC and sends the packet copies to a user-specified analysis or collection system. The mirroring process does not change the forwarding path of the original service packets and applies to scenarios such as troubleshooting, security analysis, and protocol diagnosis.
Users can select a VM NIC as the mirror source and copy inbound, outbound, or bidirectional packets as needed. Mirrored packets are sent to the specified mirror target, while the original service traffic is forwarded along the normal path. When the mirror source and mirror target are located on different hosts, the platform transmits packet copies through a GRE tunnel over an independent traffic network to avoid mixing mirrored traffic with the service network.
Port mirroring provides only packet copying and transmission capabilities. It does not provide built-in packet parsing, traffic analysis, visualization, or alerting capabilities. Users must deploy their own analysis or collection system and plan the capacity of the target system and traffic network based on the scale of mirrored traffic.
The port through which the original packets pass is called the mirror port, also known as the monitored port. The second port that receives the copied data is called the observer port, also known as the collection port or monitoring port.
- Inbound: Only copies and forwards packets received by the mirror port.
- Outbound: Only copies and forwards packets sent from the mirror port.
- Both: Copies and forwards both inbound and outbound packets of the mirror port.
- Troubleshooting suspected attacks or network failures by capturing and analyzing packets from a specific port to identify threats or root causes.
- Monitoring and observing traffic on a port with minimal disruption to production traffic.
Technical Background
- Port: Copies packets received or sent by a specified port to the observer port. This type of mirroring is called port mirroring.
- VLAN: Copies packets received by all active interfaces in a specified VLAN to the observer port. This type of mirroring is called VLAN mirroring.
- MAC Address: Copies packets within a specified VLAN that match a designated source or destination MAC address to the observer port. This type of mirroring is called MAC mirroring.
- Packet Flow: Copies packet flows that match specified rules to the observer port. This type of mirroring is called flow mirroring.
In the cloud computing era, with the development of network virtualization technology, many virtual network devices have evolved on hosts. Virtual NICs (vNICs) are no longer directly plugged into physical switches. Additionally, activities such as migration cause frequent changes in NIC locations. Therefore, port mirroring originally configured and implemented on hosts also needs to be implemented in software.
The cloud platform weakens users' awareness of the physical locations of resources. Similar to ERSPAN on physical switches, port mirroring on the cloud platform copies and forwards packets or traffic from a user's port to a device at any location, often using virtual resources such as a VM instance, for remote detection and analysis.
Technical Principle
In cloud platform native networking, network virtualization is implemented based on the open-source Linux operating system, and the corresponding port mirroring functionality is implemented using tools and libraries from the Linux ecosystem.
- Create another port on host 1: Send 1.0.
- Create a special network independent of the service network: the traffic network.
- Mirror the traffic from vNIC 1.0 to Send 1.0.
- Establish a GRE tunnel between Send 1.0 and Recv 1.0.
- The mirrored data is forwarded to VM instance 2 through the GRE tunnel.
Among these steps, flow mirroring is implemented using the Linux Traffic Control (TC) tool. The GRE tunnel operates on the independent traffic network, enabling packets and traffic to be copied and forwarded to any location in the cloud platform.
NetFlow
NetFlow is used to generate flow records from specified network interfaces of a VPC vRouter and export the records to a user-configured external collection system. It can provide data sources for capacity planning, security auditing, and traffic trend analysis.
ZCF supports exporting records in NetFlow v5 and NetFlow v9 formats. It does not provide IPFIX output or built-in collection, analysis, visualization, or alerting capabilities.
NetFlow is a traffic statistics technology widely used in network traffic statistics, network planning, network security, and other fields. NetFlow originated as a proprietary technology developed by Cisco and is now commonly supported by other network equipment vendors. The most widely used versions of NetFlow are V5 and V9. For example, the IETF technical standard IPFIX (IP Flow Information Export) is based on the V9 version.
- Exporter: Runs on a network device and collects information about the network traffic received, forwarded, and sent by the current device.
- Collector: Receives NetFlow information from exporters and stores this information.
- Analyzer: Performs traffic statistics based on the information from the collector, analyzing whether there is network congestion or traffic attacks.
In cloud platform native networking, a VPC vRouter can act as a NetFlow exporter and send NetFlow information to a collector. Users select the VPC vRouter interface whose traffic needs to be recorded and configure the address of an external collection system. The platform generates flow records and sends them to that system, while subsequent storage, analysis, and display are completed by the external system.
Technical Principle
- Kernel Module: Adds iptables rules to direct traffic to the Nflog target. Example:
iptables -t raw -A VYATTA_CT_PREROUTING_HOOK -i eth1 -j NFLOG --nflog-group 2 # A line of network configuration automatically generated when each NetFlow service is created. # eth1: The interface name of the corresponding network inside the VPC vRouter. # nflog-group 2: Specifies an NFLOG ID, which must match the iptables and Pmacctd configuration. - User-Space Program: The user-space program Pmacctd reads traffic data from the kernel via the NFLOG Netlink interface, then processes and converts it into NetFlow format for export to a collector.
OSPF
OSPF is used to dynamically exchange IPv4 routes between VPC vRouters and external routing devices, reducing static route maintenance. It applies to environments with a large number of routes or frequently changing network topologies.
| No. | Solution | Details |
|---|---|---|
| 1 | Static Routing |
|
| 2 | OSPF |
|
| 3 | Ingress Source-Aware Egress (Specific Scenario) |
|
This topic focuses on the OSPF dynamic routing protocol. A VPC vRouter can use OSPFv2 to dynamically learn external IPv4 routes and advertise reachable VPC subnets to external networks according to the configuration. The advertised scope is controlled by users.
The VPC vRouter and peer physical router must use consistent area, authentication, and interface parameters. During dynamic route convergence, transient packet loss may occur. For critical services, plan redundant links and appropriate routing policies.
Technical Principle
OSPF (Open Shortest Path First) is a link-state dynamic routing protocol developed by the IETF. OSPFv2 is used for IPv4 route synchronization, and OSPFv3 is used for IPv6 route synchronization. Cloud platform native networking supports OSPFv2.
- RouterID
- The router ID is a 32-bit integer that uniquely identifies an OSPF router within the OSPF system.
- Area
- A large-scale network system may experience problems such as excessive routing information, long routing calculation times, and slow routing convergence. Any network change triggers route recalculations on every router, potentially causing route flapping. OSPF solves this problem by dividing the large network into multiple areas, each with an area ID.
- Based on LSA distribution, areas types include: standard area, Stub area, NSSA (Not-So-Stubby Area), and totally NSSA area.
-
Figure 30. Area 
- Neighbor and Adjacency Relationships
- When OSPF protocol enables, a router periodically sends OSPF Hello packets out of its OSPF-enabled interfaces. A device that receives a Hello packet compares the parameters in the Hello packet with its interface parameters (for example, area ID). If the parameters match, a neighbor relationship forms.
- After forming a neighbor relationship, if the two devices successfully exchange Database Description (DD) packets and Link State Advertisement (LSA) packets, an adjacency relationship forms.
- Not all neighbors become adjacent.
- DR/BDR/DROther
- In broadcast or NBMA networks with multiple OSPF routers, not all pairs need to form adjacencies. Therefore, a DR (Designated Router) and a BDR (Backup Designated Router) are elected, while other routers are called DROther routers.
- Only when the DR, BDR, and all routers form adjacency relationships can OSPF packet exchange be reduced and route calculation accelerated.
- The DR and BDR are elected through an election algorithm. Election parameters include OSPF interface priority and Router ID. In practice, try to have physical routers elected as DR and BDR because VPC vRouters might be shut down due to cloud platform operations, which could cause network fluctuations throughout the data center.
-
Figure 31. Comparison Before and After Election 
- LSA
- OSPF is a protocol that calculates routing information based on network topology information. LSAs are used to describe the network topology state.
LSA Type Description Type 1 Each OSPF router generates a Type 1 LSA, which describes the device's link states and costs. It is propagated within its area. Type 2 Generated by the DR, it describes the OSPF routers connected to a broadcast network and is propagated within its area. Type 3 Generated by an ABR (Area Border Router), it publishes routes for network segments within an area to other areas. Type 4 Generated by an ABR, it describes the route to an ASBR (Autonomous System Boundary Router). Type 5 ASBRs generate and advertise external routes into the relevant OSPF areas.
- OSPF is a protocol that calculates routing information based on network topology information. LSAs are used to describe the network topology state.
Multicast
Multicast applies when one copy of data needs to be sent to multiple recipients. The sender sends only one copy, and the network replicates and forwards the data as needed based on recipient relationships, reducing bandwidth usage compared with repeated unicast transmission. ZCF provides IPv4 multicast routing capabilities for VPC networks through VPC vRouters, enabling forwarding paths between multicast sources and receivers in different networks.
- Unicast: The source sends a separate data copy to every recipient. Drawback: Numerous recipients impose high load and network bandwidth demands on the source.
- Broadcast: The source sends a piece of broadcast data, and the switch replicates the data. Drawback: Broadcast traffic cannot cross layer 3 boundaries. Exposing data to unintended recipients may cause information security risks and waste bandwidth.
- Multicast: The source sends only a piece of the data. Replication and distribution of the data occur at network nodes as far from the source as possible. Compared to unicast and broadcast, multicast uses bandwidth more efficiently, reduces network load, and enhances data transmission security.
Therefore, multicast technology effectively solves the problem of single-point transmission and multi-point reception. This technology is widely used in fields with high demands for bandwidth and real-time data interaction, such as internet TV, live streaming, distance education, telemedicine, and real-time video conferences. Before deployment, confirm that the physical network, VPC vRouter, and receivers all provide the required multicast capabilities, and plan member management and multicast routing configurations based on the support scope of the current version.
- Identifying a multicast group. See Multicast Address.
- Joining in and leaving from a multicast group. See Multicast Members Management.
- Forwarding path of a multicast packet: multicast distribution tree. See Multicast Distribution Tree.
- Establishing a forwarding path between multicast senders and receivers. See Multicast Routing Protocol.
Multicast Address
| Range | Purpose |
|---|---|
| 224.0.0.0 to 224.0.0.255 | Reserved addresses. For example, OSPF uses 224.0.0.5 and VRRP uses 224.0.0.18. |
| 224.0.1.0 to 238.255.255.255 | Multicast addresses available for user applications. |
| 239.0.0.0 to 239.255.255.255 | Local multicast addresses. |
Multicast Members Management
You can maintain the relationship between multicast groups and multicast recipients on switches and routers via multicast registration protocols.
- IGMPv1: Standardizes the basic process of querying and reporting for group members.
- IGMPv2: Adds mechanisms such as rapid departure of group members.
- IGMPv3: Adds support for the SSM model.
Multicast Distribution Tree
- Shortest Path Tree (SPT): A distribution tree rooted at the multicast source. The network must establish a tree for every multicast source sending packets to the group, resulting in a very large routing table scale. SPT is applicable to both PIM-DM and PIM-SM networks.
- Root Path Tree (RPT): A distribution tree rooted at a specific router, known as the Rendezvous Point (RP), formed by the shortest paths from the RP to all receivers. For each multicast group, the network maintains only one tree. The multicast source first sends data packets to the RP, and then the RP forwards the packets along the shared tree to all receivers. RPT is applicable to PIM-SM networks.
Multicast Routing Protocol
A commonly used multicast routing protocol is the PIM protocol. The PIM protocol operates in three modes: PIM-DM, PIM-SM, and PIM-SSM mode.
QoS
QoS (Quality of Service) is used to apply bandwidth limits and traffic shaping to network traffic, helping users control bandwidth usage for a single network object or a group of public network entries. QoS policies are configured by users, and the platform does not automatically adjust bandwidth based on runtime status.
- NIC QoS: Supports configuring QoS for a specified NIC and provides dedicated bandwidth resources and rate limiting for that NIC.
- Virtual IP QoS: Supports configuring QoS for a specified virtual IP and provides bandwidth resources and rate limiting for NICs that use the virtual IP. Users can configure multiple QoS rules for different ports of the same virtual IP.
- Shared Bandwidth: Shared bandwidth is a QoS service available to multiple virtual IPs. Virtual IPs added to the same shared bandwidth share the same bandwidth resources and are centrally rate-limited. Currently, shared bandwidth is available only for public virtual IPs. Public virtual IPs are the main entry for VM instances in VPC networks to access public networks. For example, after an Elastic IP is created based on a public virtual IP and bound to a VPC VM NIC, the VM instance can communicate with public networks through the virtual IP. If multiple VM instances use virtual IPs that belong to the same shared bandwidth, these VM instances use the same bandwidth resources and are centrally rate-limited when accessing public networks. This provides an effective way to reduce public network access costs.
Figure 35. Shared Bandwidth Architecture Diagram 
Cloud platform native networking mainly uses the tc (Traffic Control) tool to precisely control data traffic and implement advanced bandwidth management policies.
- qdisc (queuing discipline): Defines how packets passing through an interface are processed. It can be used to queue, drop, reorder, or remark packets.
- class: In qdiscs that support classification, traffic can be assigned to different classes, and each class can have its own queuing discipline and bandwidth limit.
- filter: Classifies data flows and determines the class to which each packet belongs. Filters can classify data flows based on multiple criteria, such as port numbers and IP addresses.
- Define qdisc and class based on the specified QoS policy:
- Define a root qdisc, typically HTB (Hierarchical Token Bucket), to create a hierarchical bandwidth management architecture.
- Create classes under the qdisc. Each class represents a different traffic policy and is configured with bandwidth limits.
- Configure filter: Configure filters for classes based on the specified QoS policy to ensure that access traffic is correctly classified into the corresponding classes.
- Monitoring and adjustment: Use the tc command to monitor traffic and class performance, and adjust bandwidth allocation and policies based on monitoring results to maintain network performance and responsiveness.
ZNS Network Service
ZStack ZNS is an on-demand network service component within ZCF. Through ZNS Network Center, it provides network infrastructure and network service management capabilities. Designed for cloud platform network virtualization scenarios, ZNS leverages OVN/OVS to deliver VLAN/Overlay networking, segmentation, Tier-0/Tier-1 gateways, VPC routing, NAT, and DHCP, enabling connectivity, isolation, and scalability for business networks.
ZNS Network Service can coordinate with the cloud platform's network creation process. After a user creates a business network in the cloud platform that is backed by ZNS, ZNS automatically provisions the corresponding network segment and delivers connectivity and isolation for the business network via gateways and network policies. Administrators can view the status of segments, gateways, and policies in ZNS Network Center to verify whether the underlying network resources required for the business network have been successfully provisioned.