How Cloud Connect Network v1 Optimizations Boost Performance and What Challenges Remain

01 Project Background

Cloud Connect Network (CCN) provides a fast, high‑quality, stable network capability that connects VPCs across regions and links multiple VPCs with on‑premise data centers, enabling an enterprise‑grade global cloud network. By creating a cloud connection and loading the required network instances (VPCs or IDC IP resources) into it, users obtain global network interconnectivity.

02 CCN V1 Optimization Overview

As business moves to the cloud, VPC‑to‑VPC traffic increased, putting pressure on the CCN gateway. In the V1 optimization, packet forwarding was changed from per‑packet processing to a session‑based model, greatly improving forwarding performance, but also introducing new issues.

03 Existing Issues

3.1 Cloud Network Architecture Description

The CCN gateway consists of a control plane (exposes APIs for creating CCSI rules) and a forwarding plane built on DPDK. Forwarding loads CCSI rules, matches packet policies, encapsulates packets with VXLAN, and forwards them. Key concepts: CCSI (cloud network instance), ROUTE (subnet route to be connected), next‑hop (source IP of the outer VXLAN header).

3.2 V1 Optimization Scheme

3.3 V1 Packet Forwarding Process

a Lookup CCSI entry by VXLAN ID hash table.

b Retrieve CCSI instance node by CCSI ID.

c Perform route match on source IP.

d Perform route match on destination IP.

e After both IP matches, use destination VXLAN ID to find VPC in hash table.

f Verify that the destination VM exists via VXLAN ID and IP.

g Encapsulate VXLAN packet and forward to the correct node.

Session‑based forwarding:

a Check if a session exists for the source‑destination IP pair.

b If found, use session information to encapsulate and forward the VXLAN packet.

3.4 Problems Caused by V1 Optimization

Although forwarding performance increased (NIC utilization from ~20% to >80%), the session creation caused heavy cleanup overhead. Session cleanup required traversing the entire session table when routes or vports were deleted, leading to slow queries, network jitter, and even BGP disconnects during bulk deletions.

04 Optimization Proposal

To avoid full‑table scans, each route structure can maintain a list of its associated session nodes. When a session is created, it is attached both to the global session table and to the route’s list. Deleting a subnet or vport then only requires iterating the route’s list.

4.1 Data Structure Before Optimization

4.2 Data Structure After Optimization

This greatly reduces query overhead, but cleanup must also remove session nodes from the route’s list when subnets, vports, or timeouts are cleared.

05 Performance Test Results

5.1 Test Environment

Gateway server equipped with a 25 Gbps Mellanox NIC, Intel Xeon Gold 5218R CPU, running CentOS 7.2.

5.2 Deleting 200 CCN Subnets

Before optimization, two VMs communicating via the CCN gateway experienced noticeable jitter and BGP disconnects.

After optimization, communication was stable with no jitter.

06 Future Optimizations

The high‑performance CCN version has been deployed in three regions for over two months. Future work includes making the session stateful to keep packet and reply handling on the same CPU core, adding redirect mechanisms, and improving session monitoring tools for better troubleshooting.