SONiC and VPP: Building a High-Performance Software-Defined Router

For decades, the backbone of the internet has relied on proprietary, monolithic routers—expensive “black boxes” where the hardware and the operating system were inextricably linked. This vertical integration gave vendors immense control and created a cycle of vendor lock-in, forcing network operators to buy into a specific ecosystem for both their silicon and their software.

That paradigm is currently being dismantled. Driven by the immense scale of modern cloud data centers, the industry is shifting toward disaggregated routing with SONiC and VPP, a model that unbundles the network operating system from the underlying hardware. By treating the router as a collection of modular software components rather than a single appliance, organizations can now run high-performance networking on standard x86 servers.

This architectural shift is more than a technical curiosity; it is an economic pivot. By leveraging commercial-off-the-shelf (COTS) hardware, companies are moving from a capital-expenditure-heavy (CAPEX) model toward a more agile operational expenditure (OPEX) strategy. This democratization of high-performance networking allows for faster innovation and a drastic reduction in the total cost of ownership.

At the center of this transformation is the integration of two open-source powerhouses: Software for Open Networking in the Cloud (SONiC) and Vector Packet Processing (VPP). Together, they create a fully software-defined router capable of delivering ASIC-class performance without the necessitate for specialized, proprietary silicon.

The Architecture of Open Networking

To understand how this integration works, one must first understand the two distinct roles these systems play. In networking terms, this is the separation of the “brain” (the control plane) from the “muscle” (the data plane). SONiC acts as the brain, managing the logic and state of the network, although VPP serves as the muscle, moving packets at blistering speeds.

SONiC: The Modular Control Plane

Originally developed by Microsoft and now hosted by the Linux Foundation, SONiC is a network operating system built on Debian Linux. Unlike traditional systems, SONiC is not a single block of code; it is a collection of containerized microservices.

Critical functions—such as the Border Gateway Protocol (BGP) routing stack and platform monitoring—each run in their own isolated Docker containers. This modularity means a network operator can update or restart a specific routing protocol without crashing the entire switch, a necessity for maintaining high availability in cloud-scale environments.

The “glue” that holds these containers together is an in-memory Redis database. Instead of using rigid APIs, SONiC components communicate asynchronously by publishing and subscribing to tables within Redis. This allows the system to maintain a “single source of truth” for the network state across several key databases: CONFIG_DB for intended settings, APPL_DB for high-level application state, STATE_DB for operational status, and ASIC_DB for the forwarding plane’s desired state.

VPP: The High-Speed Data Plane

While SONiC manages the logic, VPP focuses on raw throughput. Developed by Cisco and now part of the FD.io project, VPP provides the functionality of a router entirely in software, bypassing the traditional Linux kernel network stack to avoid performance bottlenecks.

VPP achieves its speed through three primary mechanisms:

• Vector Processing: Instead of processing one packet at a time, VPP processes “vectors” (batches) of up to 256 packets. This optimizes the CPU’s instruction cache, reducing expensive memory fetches and maximizing the efficiency of modern x86 processors.
• Kernel Bypass: By using the Data Plane Development Kit (DPDK), VPP gains direct access to the network interface card (NIC). This eliminates the overhead of system calls and context switching between kernel and user space.
• Packet Processing Graph: VPP organizes its features—like MAC lookups or ACL checks—as nodes in a directed graph. This makes the system highly extensible, as fresh features can be added as plugins without altering the core engine.

Comparison of SONiC and VPP Roles

Feature	SONiC	VPP
Primary Function	Control & Management Plane	Data Plane
Architectural Model	Containerized Microservices	Packet Processing Graph
Key Abstraction	Switch Abstraction Interface (SAI)	Graph Nodes & Plugins
Operating Environment	Kernel/User-space Hybrid	Pure User-space (Kernel Bypass)
Performance Driver	Distributed State (Redis)	Vector Processing & Cache Optimization

Bridging the Gap: The Switch Abstraction Interface

The most critical piece of the puzzle is the Switch Abstraction Interface (SAI). Originally, SAI was designed to allow SONiC to run on different physical ASICs (the specialized chips from vendors like Broadcom) by providing a standardized C API. The SONiC control plane speaks “SAI,” and the hardware vendor provides a library that translates that language into specific chip commands.

The breakthrough in disaggregated routing with SONiC and VPP is the realization that the “hardware” on the other side of the SAI API doesn’t actually have to be hardware. By creating a specialized library called libsaivpp.so, developers can trick the SONiC control plane into thinking it is talking to a physical chip when it is actually talking to a VPP software process.

This allows a purely software-based forwarder to be substituted for a physical ASIC with remarkable elegance, preserving the feature-rich control plane of SONiC while utilizing the speed of VPP on standard servers.

The Lifecycle of a Route Update

To witness this integration in action, one can trace the path of a single route update. When a router learns a new path via BGP, the following sequence occurs:

1. Reception: The bgpd process in the BGP container receives a route update from a peer.
2. RIB Management: The update is passed to zebra, which manages the Routing Information Base (RIB).
3. Handoff: zebra sends the route to the fpmsyncd process via the Forwarding Plane Manager (FPM) interface.
4. Database Entry: fpmsyncd writes the route into the APPL_DB in Redis.
5. Orchestration: The orchagent sees the update in APPL_DB and translates it into a hardware-agnostic format, writing it to the ASIC_DB.
6. Synchronization: The syncd container detects the change in ASIC_DB and makes a SAI API call to program the data plane.
7. Execution: libsaivpp.so intercepts the SAI call and translates it into a binary API message that VPP understands, which then updates the software forwarding table (FIB).

SONiC-VPP Integration Component Map

Component	Key Process	Role in Integration
BGP Container	bgpd	Receives external BGP route updates.
SWSS Container	zebra, fpmsyncd	Manages RIB and publishes to Redis APPL_DB.
Database	redis-server	Asynchronous message bus (APPL_DB & ASIC_DB).
SWSS Container	orchagent	Translates intent to hardware-agnostic state.
Syncd Container	syncd	Calls SAI API to program the data plane.
VPP Platform	libsaivpp.so	Translates SAI calls to VPP binary messages.
VPP Process	vpp	Executes packet forwarding in user-space.

This decoupled architecture ensures that the data plane can be swapped or upgraded without changing a single line of code in the upstream control plane. It represents the peak of the disaggregated model, offering a programmable, open, and high-performance alternative to the proprietary routers of the past.

In the next installment of this series, we will move from theory to implementation, detailing how to build and test a complete SONiC-VPP software router in a containerized lab, including BGP configuration and performance benchmarking.

Do you think software-defined routing will eventually replace physical ASICs in the enterprise core? Share your thoughts in the comments or join the conversation on our social channels.