Disaggregated routing with SONiC and VPP moves from theory to practice in a hands‑on lab that stitches together two virtual SONiC‑VPP routers and two Linux hosts. The demonstration validates the Switch Abstraction Interface (SAI)‑based translation layer, shows how FRRouting runs inside SONiC, and proves that the control‑plane state is faithfully mirrored into VPP’s high‑performance forwarding plane.
The testbed is built entirely with containers: two SONiC‑VPP instances act as gateways for separate LAN segments, while two generic Linux containers serve as end‑hosts. Each router runs the standard SONiC CLI, and the data plane is driven by FD.io’s Vector Packet Processing (VPP) framework, a user‑space engine that bypasses the Linux kernel’s networking stack.
Lab topology and initial configuration
Four nodes are instantiated:
- router1 – a SONiC‑VPP virtual machine handling the 10.20.1.0/24 LAN.
- router2 – a second SONiC‑VPP virtual machine handling the 10.20.2.0/24 LAN.
- PC1 – a Linux container with IP 10.20.1.1/24.
- PC2 – a Linux container with IP 10.20.2.1/24.
Inter‑router connectivity uses Ethernet0 on each router, assigned 10.0.1.1/30 on router1 and 10.0.1.2/30 on router2. The LAN‑facing interfaces (Ethernet4) carry 10.20.1.254/24 and 10.20.2.254/24 respectively. After IP assignment, the config interface startup command brings every interface up.
Static routes on the hosts point to their local router as the default gateway, completing the L3 scaffold.
Dynamic routing with FRRouting (BGP)
SONiC bundles the FRRouting suite, which is accessed through the vtysh shell. An internal BGP (iBGP) session is created between the two routers, both belonging to Autonomous System 65100. Router 1 advertises its 10.20.1.0/24 network, and router 2 advertises 10.20.2.0/24. The BGP peering configuration looks like this:
router bgp 65100 router-id 10.0.1.1 neighbor 10.0.1.2 remote-as 65100 network 10.20.1.0/24
On router 2 the same settings apply with the opposite neighbor address. The show ip bgp summary command confirms an established session, while show ip route displays the learned remote subnet.
Control‑plane and data‑plane verification
To prove that the BGP‑learned routes have been programmed into VPP, the demo accesses the VPP CLI (via the syncd container) and runs show ip fib. The forwarding information base (FIB) lists the 10.20.2.0/24 entry on router 1 and the 10.20.1.0/24 entry on router 2, confirming successful state synchronization between SONiC’s Redis‑based orchestration and VPP’s user‑space packet engine.
The final validation is a simple ping from PC1 to 10.20.2.1. Successful replies demonstrate end‑to‑end connectivity: the packet traverses the Linux host, reaches router 1, is forwarded by VPP to router 2, and finally arrives at PC2, with the return path mirroring the forward direction.
Why the SONiC‑VPP combo matters
The core of the architecture is the SAI‑to‑VPP translation layer, which lets the vendor‑agnostic SAI API drive VPP operations [source]. By moving the data plane out of the kernel, VPP achieves higher throughput and more deterministic latency, a benefit highlighted in the FD.io technology overview [source]. The open‑source nature of both projects—SONiC under the Linux Foundation [source] and VPP as a flagship FD.io project—offers operators a disaggregated stack that can run on commodity x86 servers without tying them to a specific ASIC.
Development remains active. Recent pull requests on the sonic‑platform‑vpp repository show work on extending SAI support for advanced VxLAN BGP EVPN and improving ACL testing [source]. These efforts aim to expose more of VPP’s rich feature set—such as NAT and multi‑tenant VxLAN—to the SONiC control plane, further blurring the line between software‑defined networking and traditional hardware appliances.
At a glance
| Component | Role | Key Interface |
|---|---|---|
| SONiC control plane | Orchestrates network state via Redis, runs FRR/BGP | SAI API |
| VPP data plane | User‑space packet processing, high‑throughput forwarding | SAI‑VPP translation layer |
| Linux hosts (PC1/PC2) | End‑systems for L3 traffic verification | Static IPs & routes |
Looking ahead, the community plans to deepen SAI integration, add NAT and richer VxLAN capabilities, and continue polishing the NetDevOps workflow that lets engineers treat network topology as code. As the stack matures, operators can expect more robust, open, and high‑performance routing solutions that keep pace with the demands of multi‑cloud and edge environments.
Feel free to share your thoughts on the lab setup or ask questions about deploying SONiC‑VPP in production. Your comments aid the community refine these open‑source tools.
