Design and Implementation of an SD-WAN Based Network Acceleration Platform

Background

As the company's business complexity and node coverage increase, flexible network access for various business nodes imposes higher requirements on network construction and operation. To meet these demands, an SD‑WAN (Software‑Defined Wide Area Network) based architecture was adopted, and a Network Acceleration Platform was built on top of iQIYI's existing infrastructure. The platform creates an overlay plane that enables flexible inter‑node communication and separates business management, policy control, and data forwarding functions, providing differentiated acceleration services for physical hosts, virtual machines, and other business users.

The platform automates and unifies the management of acceleration services, reducing operational overhead caused by the growing number of links and complex scheduling policies, and improves both management and network performance. Differential routing policies introduce target nodes, provide unified path planning, and dynamically adjust routes based on network status.

Solution Overview

Platform Architecture

The platform consists of three layers from top to bottom: the Business Control Layer, the Routing Control (Overlay) Layer, and the Underlay Data Forwarding Layer. The overlay is built on top of the physical underlay. Administrators manage services through the Business Control Layer, which communicates with the data forwarding layer via FAST, SSH, NETCONF, and other southbound protocols. The Business Control Layer monitors path quality and network status to provide optimal forwarding paths for user traffic.

Business Architecture

The platform is divided into three planes from left to right: Business Access Plane, Routing Control Plane, and Data Forwarding Plane.

Business Access Plane : Serves as the network entry point, connects to the Routing Control Plane, and configures primary and backup links. Different business types access specific network planes through appropriate devices, enabling dedicated Internet access paths.

Routing Control Plane : Carries aggregated routes from major carriers and accelerated routes from smaller carriers, applying routing policies (e.g., link length, cost) to steer traffic from various access devices to appropriate network planes.

Data Forwarding Plane : Interconnects with the Routing Control Plane or directly with specific access devices. Exported routes are limited to carrier‑aggregated public routes; the forwarding devices do not accept public address routes from the control plane, acting also as exit gateways.

Routing Control Details

The platform supports two main traffic directions: inbound and outbound. Inbound traffic receives all neighbor routes by default, while outbound traffic sends tunnel‑interconnected IP prefixes to establish IGP. EBGP neighbors are configured with MED values to differentiate primary and backup routes for north‑south traffic. IBGP neighbors are set up between control plane routers (acting as route reflectors) without additional policies, aggregating routes from major carriers, QNET, and all small carriers.

Routing Policy Example

Direction/Level

Access

Control

Forwarding

Inbound

Receive all neighbor routes; default routes require separate policies.

Receive all EBGP neighbor routes.

Accept only tunnel‑interconnected IP prefixes to build IGP.

Outbound

Send tunnel‑interconnected IP prefixes to establish IGP.

Default send all routes to access routers; no policy control unless specific business nodes require it.

ISPs export aggregated routes via EBGP with no‑export attribute; small carriers receive predefined community values.

Service Scenarios

Specific Network Exit or Target Node Access

For cases where a particular data center host needs to reach a remote network node, gateway devices are deployed at the required exit. Each gateway establishes EBGP with the control plane, publishing reachable routes. The control plane then creates EBGP sessions with access devices, directing traffic to the specific exit based on the business node served.

Remote Network Local Sinking

Using iQIYI's MPLS‑VPN based QNET network with L2VPN services, a large Layer‑2 network is built across multiple sites, allowing remote IP prefixes to be sunk to distributed nodes without altering Ethernet MAC addresses. This simplifies distributed deployment and enhances service flexibility.

Default Route to Specific Gateway

Traditional methods use tunnels to external gateways. The platform provides a default‑route‑based approach where a “Qi‑Road” gateway establishes VPN tunnels with multiple external gateways. Hosts use DNS to resolve external services, and policy routing on the gateway directs traffic to the selected ISP exit, with unified access control.

Domain Routing

Hosts can select paths based on domain names. The platform uses dnsmasq to resolve domains, then writes static or policy‑driven routes to the host routing table, ensuring traffic to specific domains follows the optimal exit. This is useful for services like multiple payment providers that require distinct routing.

Summary and Outlook

The Network Acceleration Platform, as a key component of iQIYI's SDN ecosystem, provides flexible inter‑node communication and targeted access solutions through dynamic routing protocols, overlay acceleration planes, and differentiated scheduling strategies. Built on SD‑WAN principles, it offers unified management, QoS‑aware path switching, and fault‑tolerant routing. Future work includes expanding support for east‑west and north‑south traffic, increasing ingress/egress coverage, mixing dedicated lines with public Internet, and enhancing full‑stack routing from Layer‑2 to Layer‑7 to better support diverse business needs.