Grab your diary and jot down the date, as Ubuntu 26.10 ‘Stonking Stingray’ is going to be released on 15 October, 2026. The Ubuntu 26.10 release date and those of other notable milestones in the next development cycle have now been shared by Canonical but, given the nature of development, should be considered tentative – plans can and do change. The most significant date in the 26.10 schedule, besides the final release, is that of feature freeze on August 10, 2026. This is the date at which (in theory) new features stop being added so that the focus can move to […]
Launchpad, the home of Ubuntu development, has finally received some design attention. Canonical last updated the site’s homepage back in 2024, but many of the pages that the distro’s developers actually use or reference on a regular basis have remained untouched for the best part of a decade. Now that’s starting to change. Canonical UX designer Enzo Deng has announced that the company has “begun […] a complete redesign of the series page” for Ubuntu 26.04 LTS, describing it as the start of “the journey of modernizing the Launchpad user experience” (sic). Save for a line on how the company […]
Canonical has released Ubuntu 26.04 LTS ‘Resolute Raccoon’ – the first LTS in Ubuntu’s history to ship without an Xorg desktop session. It runs on the latest Linux 7.0 kernel with the GNOME 50 desktop, and includes new video player and system monitor apps. Deb package management features are available in App Center. Support-wise, Ubuntu 26.04 LTS receives a minimum of 5 years of updates, and an additional 5 years of security coverage with Ubuntu Pro. For a full rundown of what’s changed since Ubuntu 25.10, see my features overview. If you’re upgrading from Ubuntu 24.04 LTS my deeper-dive on […]
Framework’s new 13 Pro laptop is the company’s first to ship as certified for Ubuntu, who say you can buy it knowing you’ll get “guaranteed support right out of the box”. Framework hardware have been popular with Linux users for years, not just for the company’s ethos around upgradeable and repairable hardware but their kernel contributions and financial support for open-source projects and developers. Specs wise, the new Framework 13 Pro is powered by Intel Core Ultra Series 3 or AMD Ryzen AI 300 series processors. It uses LPCAMM2 memory (modular LPDDR5X), available with up to 64GB (higher densities will […]
In the late 1990s, the DHCP (Dynamic Host Configuration Protocol) quietly catalyzed a revolution in digital connectivity. Before DHCP was introduced, connecting devices to a network involved manual entry of IP addresses, DNS servers, subnet masks, and gateways. Networks were fragile, prone to errors, and severely limited in scalability. The introduction of DHCP changed everything and became a game-changer for networking.
With widespread adoption across operating systems, DHCP made networking a plug-and-play experience. This fundamental change accelerated the adoption of Wi-Fi, standardized enterprise networks using DHCP-based addressing, and propelled the mobile Internet to viability. While DHCP simplified network connectivity by automating IP address assignments, it also introduced the world to the essence of effortless connectivity.
Fast forward to today, connectivity remains effortless, yet escalating threats continuously challenge digital trust. Just as DHCP revolutionized connectivity, we are primed for a transformation of equal magnitude concerning digital trust. The solution is clear: we must automate trust through Secure Zero-Touch Provisioning (SZTP).
SZTP: Secure Zero-Touch Provisioning
Modern digital infrastructure, spanning cloud nodes, edge systems, IoT sensors, industrial robotics, home gateways, and AI-centered factories, necessitates robust security measures. To maintain secure environments, each device in this extensive ecosystem must autonomously verify its needs. This includes self-authentication, receiving verified firmware, installing necessary credentials, and joining orchestrated environments without human intervention, which DHCP alone cannot accomplish.
Secure Zero-Touch Provisioning (SZTP), as defined in RFC 8572, steps up to address these needs in our complex digital reality. It builds trust by automating the exchange of essential artifacts and certificates required for seamless device bootstrapping: verifying hardware identity, delivering trusted firmware and OS images, applying patches, injecting cryptographic credentials, and setting up a complete runtime environment automatically, without manual interaction.
SZTP is based on open standards, making it vendor-neutral and ideal for large-scale deployments. As digital ecosystems grow in complexity, SZTP promises a future in which AI agents can autonomously request and deploy secure infrastructure within minutes, enhancing operational efficiency and security simultaneously.
Step-by-Step: Implementing SZTP in Your Infrastructure
Device Identification and Authentication
Begin by integrating SZTP in your network infrastructure. Once a device powers on, it must first establish identity through a secure channel. This is typically done using hardware-based security measures, such as a TPM (Trusted Platform Module), to provide hardware attestation.
Firmware Verification and Secure Image Delivery
Implement policies to verify firmware integrity. Use cryptographic signatures to ensure firmware authenticity. SZTP can fetch secure firmware and OS images from trusted repositories. For instance, create a policy that requires all devices to verify their firmware against a centralized manifest.
Credential Injection and Environment Initialization
Devices securely receive cryptographic credentials and configuration files. Use automated scripts to distribute these credentials from a central management server. Next, deploy containerized workloads using tools such as Kubernetes to orchestrate the environment.
Lifecycle Management and Patch Automation
With SZTP, configure automated patch management systems to apply security patches and software updates. Implement CI/CD pipelines that automatically redeploy updated firmware images, ensuring devices run the latest software versions.
SZTP is ideal for AI and Edge Clouds
AI factories rely on specialized processors, such as DPUs, to offload networking, storage, and security tasks from GPUs. Linux Foundation’s OPI project has adopted SZTP as a standard initialization method for these devices.
Here’s how SZTP simplifies AI and edge cloud deployment:
Device Identity and Trust Management
SZTP serves DPUs like DHCP did for laptops, answering questions crucial to trust: “Who are you?” and “Can you be trusted?” Use open-source libraries to develop trust protocols integrated with SZTP, enhancing the security posture.
Automated Secure Provisioning
Ensure your infrastructure is secure by default. Initiate hardware attestation, verify boot components, and use automated tools to deliver secure images and deploy cryptographic credentials. Platforms like HashiCorp Vault can manage secrets during this process.
Comprehensive Software Stack Deployment
SZTP allows for defining a device’s mission by automating the deployment of OS components, runtimes, and security agents. Leverage Docker and Kubernetes to handle container runtimes and orchestration, ensuring efficient management of service mesh layers and logging telemetries.
Scalable Client Implementations
Establish open-source client initiatives to enhance adoption. Encourage device manufacturers and OS vendors to integrate this client to promote SZTP adoption further and reduce integration complexity.
Conclusion
Open clients enabled DHCP to transform networking, and they will guide SZTP in defining secure, automated infrastructure’s next era for AI-enabled applications. Automate your edge and AI factory environments with SZTP, elevating digital trust to unprecedented levels.
By following these steps and leveraging SZTP technology, organizations can enhance their network security, automate deployment processes, and prepare their infrastructure for a future driven by AI and IoT.
The networking industry is undergoing a fundamental architectural transformation, driven by the relentless demands of cloud-scale data centers and the rise of software-defined infrastructure. At the heart of this evolution is the principle of disaggregation: the systematic unbundling of components that were once tightly integrated within proprietary, monolithic systems.
This movement began with the separation of network hardware from the network operating system (NOS), a paradigm shift championed by hyperscalers to break free from vendor lock-in and accelerate innovation.
In this blog post, we will explore how disaggregated networking takes shape, when the SONiC control plane meets the VPP data plane. You’ll see how their integration creates a fully software-defined router – one that delivers ASIC-class performance on standard x86 hardware, while preserving the openness and flexibility of Linux-based systems.
Disaggregation today extends to the software stack, separating the control plane from the data plane. This decoupling enables modular design, independent component selection, and more efficient performance and cost management.
The integration of Software for Open Networking in the Cloud (SONiC) and the Vector Packet Processing (VPP) framework represents the peak of this disaggregated model.
SONiC, originally developed by Microsoft and now a thriving open-source project under the Linux Foundation, has established itself as the de facto standard for a disaggregated NOS, offering a rich suite of L3 routing functionalities hardened in the world’s largest data centers.1 Its core design philosophy is to abstract the underlying switch hardware, allowing a single, consistent software stack to run on a multitude of ASICs from different vendors. This liberates operators from the constraints of proprietary systems and fosters a competitive, innovative hardware ecosystem.
Complementing SONiC’s control plane prowess is VPP, a high-performance, user-space data plane developed by Cisco and now part of the Linux Foundation’s Fast Data Project (FD.io).
VPP’s singular focus is to deliver extraordinary packet processing throughput on commodity commercial-off-the-shelf (COTS) processors. By employing techniques like vector processing and bypassing the traditional kernel network stack, VPP achieves performance levels previously thought to be the exclusive domain of specialized, expensive hardware like ASICs and FPGAs.
The fusion of these two powerful open-source projects creates a new class of network device: a fully software-defined router that combines the mature, feature-rich control plane of SONiC with the blistering-fast forwarding performance of VPP.
This architecture directly addresses a critical industry need for a network platform that is simultaneously programmable, open, and capable of line-rate performance without relying on specialized hardware.
The economic implications are profound. By replacing vertically integrated, vendor-locked routers with a software stack running on standard x86 servers, organizations can fundamentally alter their procurement and operational models. This shift transforms network infrastructure from a capital-expenditure-heavy (CAPEX) model, characterized by large upfront investments in proprietary hardware, to a more agile and scalable operational expenditure (OPEX) model.
The ability to leverage COTS hardware drastically reduces total cost of ownership (TCO) and breaks the cycle of vendor lock-in, democratizing access to high-performance networking and enabling a more dynamic, cost-effective infrastructure strategy.
Deconstructing the Components: A Tale of Two Titans
To fully appreciate the synergy of the SONiC-VPP integration, it is essential to first understand the distinct architectural philosophies and capabilities of each component. While they work together to form a cohesive system, their internal designs are optimized for entirely different, yet complementary, purposes. SONiC is engineered for control, abstraction, and scalability at the management level, while VPP is purpose-built for raw, unadulterated packet processing speed.
SONiC: The Cloud-Scale Control Plane
SONiC is a complete, open-source NOS built upon the foundation of Debian Linux. Its architecture is a masterclass in modern software design, abandoning the monolithic structure of traditional network operating systems in favor of a modular, containerized, microservices-based approach. This design provides exceptional development agility and serviceability.
Key networking functions, such as:
Border Gateway Protocol (BGP) routing stack
Link Layer Discovery Protocol (LLDP)
platform monitoring (PMON)
each run within their own isolated Docker container. This modularity allows individual components to be updated, restarted, or replaced without affecting the entire system, a critical feature for maintaining high availability in large-scale environments.
The central nervous system of this distributed architecture is an in-memory Redis database engine, which serves as the single source of truth for the switch’s state.
Rather than communicating through direct inter-process communication (IPC) or rigid APIs, SONiC’s containers interact asynchronously by publishing and subscribing to various tables within the Redis database. This loosely coupled communication model is fundamental to SONiC’s flexibility. Key databases include:
CONFIG_DB: Stores the persistent, intended configuration of the switch.
APPL_DB: A high-level, application-centric representation of the network state, such as routes and neighbors.
STATE_DB: Holds the operational state of various components.
ASIC_DB: A hardware-agnostic representation of the forwarding plane’s desired state.
The cornerstone of SONiC’s hardware independence, and the very feature that makes the VPP integration possible, is the Switch Abstraction Interface (SAI). SAI is a standardized C API that defines a vendor-agnostic way for SONiC’s software to control the underlying forwarding elements. A dedicated container, syncd, is responsible for monitoring the ASIC_DB. Upon detecting changes, making the corresponding SAI API calls to program the hardware. Each hardware vendor provides a libsai.so library that implements this API, translating the standardized calls into the specific commands required by their ASIC’s SDK. This elegant abstraction allows the entire SONiC control plane to remain blissfully unaware of the specific silicon it is running on.
VPP: The User-Space Data Plane Accelerator
While SONiC manages the high-level state of the network, VPP is singularly focused on the task of moving packets as quickly as possible. As a core component of the FD.io project, VPP is an extensible framework that provides the functionality of a router or switch entirely in software. Its remarkable performance is derived from several key architectural principles.
Vector Processing
The first and most important is vector processing. Unlike traditional scalar processing, where the CPU processes one packet at a time through the entire forwarding pipeline, VPP processes packets in batches, or “vectors”. A vector typically contains up to 256 packets. The entire vector is processed through the first stage of the pipeline, then the second, and so on. This approach has a profound impact on CPU efficiency. The first packet in the vector effectively “warms up” the CPU’s instruction cache (i-cache), loading the necessary instructions for a given task. The subsequent packets in the vector can then be processed using these cached instructions, dramatically reducing the number of expensive fetches from main memory and maximizing the benefits of modern superscalar CPU architectures.
User-Space Orientation & Kernel Bypass
The second principle is user-space operation and kernel bypass. The Linux kernel network stack, while powerful and flexible, introduces performance overheads from system calls, context switching between kernel and user space, and interrupt handling. VPP avoids this entirely by running as a user-space process. It typically leverages the Data Plane Development Kit (DPDK) to gain direct, exclusive access to network interface card (NIC) hardware. Using poll-mode drivers (PMDs), VPP continuously polls the NIC’s receive queues for new packets, eliminating the latency and overhead associated with kernel interrupts. This direct hardware access is a critical component of its high-throughput, low-latency performance profile.
Packet Processing Graph
Finally, VPP’s functionality is organized as a packet processing graph. Each feature or operation-such as an L2 MAC lookup, an IP4 route lookup, or an Access Control List (ACL) check-is implemented as a “node” in a directed graph. Packets flow from node to node as they are processed. This modular architecture makes VPP highly extensible. New networking features can be added as plugins that introduce new graph nodes or rewire the existing graph, without requiring changes to the core VPP engine.
The design of SAI was a stroke of genius, originally intended to abstract the differences between various hardware ASICs.
However, its true power is revealed in its application here. The abstraction is so well-defined, that it can be used to represent not just a physical piece of silicon, but a software process. The SONiC control plane does not know or care whether the entity on the other side of the SAI API is a Broadcom Tomahawk chip or a VPP instance running on an x86 CPU. It simply speaks the standardized language of SAI.
This demonstrates that SAI successfully abstracted away not just the implementation details of a data plane, but the very notion of it being physical, allowing a purely software-based forwarder to be substituted with remarkable elegance.
Feature
SONiC
VPP
Primary Function
Control Plane & 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 (Linux-based)
Pure User-space (Kernel Bypass)
Core Performance Mechanism
Distributed State Management via Redis
Vector Processing & CPU Cache Optimization
Primary Configuration Method
Declarative (config_db.json, Redis)
Imperative (startup.conf, Binary API)
Creating a High-Performance Software Router
The integration of SONiC and VPP is a sophisticated process that transforms two independent systems into a single, cohesive software router.
The architecture hinges on SONiC’s decoupled state management and a clever translation layer that bridges the abstract world of the control plane with the concrete forwarding logic of the data plane. Tracing the lifecycle of a single route update reveals the elegance of this design.
The End-to-End Control Plane Flow
The process begins when a new route is learned by the control plane. In a typical L3 scenario, this happens via BGP.
Route Reception: An eBGP peer sends a route update to the SONiC router. This update is received by the bgpd process, which runs within the BGP container. SONiC leverages the well-established FRRouting (FRR) suite for its routing protocols, so bgpd is the FRR BGP daemon.
RIB Update: bgpd processes the update and passes the new route information to zebra, FRR’s core component that acts as the Routing Information Base (RIB) manager.
Kernel and FPM Handoff: zebra performs two critical actions. First, it injectsa route into the host Linux kernel’s forwarding table – via a Netlink message. Second, it sends the same route information to the fpmsyncd process using the Forwarding Plane Manager (FPM) interface, a protocol designed for pushing routing updates from a RIB manager to a forwarding plane agent.
Publishing to Redis: The fpmsyncd process acts as the first bridge between the traditional routing world and SONiC’s database-centric architecture. It receives the route from zebra and writes it into the APPL_DB table in the Redis database. At this point, the route has been successfully onboarded into the SONiC ecosystem.
Orchestration and Translation: The Orchestration Agent (orchagent), a key process within the Switch State Service (SWSS) container, is constantly subscribed to changes in the APPL_DB. When it sees the new route entry, it performs a crucial translation. It converts the high-level application intent (“route to prefix X via next-hop Y”) into a hardware-agnostic representation and writes this new state to the ASIC_DB table in Redis.
Synchronization to the Data Plane: The final step in the SONiC control plane is handled by the syncd container. This process subscribes to the ASIC_DB. When it detects the new route entry created by orchagent, it knows it must program this state into the underlying forwarding plane.
This entire flow is made possible by the architectural decision to use Redis as a central, asynchronous message bus.
In a traditional, monolithic NOS, the BGP daemon might make a direct, tightly coupled function call to a forwarding plane driver. This creates brittle dependencies. SONiC’s pub/sub model, by contrast, ensures that each component is fully decoupled. The BGP container’s only responsibility is to publish routes to the APPL_DB; it has no knowledge of who will consume that information.
This allows the final consumer the data plane-to be swapped out with zero changes to any of the upstream control plane components. This decoupled architecture is what allows VPP to be substituted for a hardware ASIC so cleanly and implies that other data planes could be integrated in the future – simply by creating a new SAI implementation.
The Integration Foundation: libsaivpp.so
The handoff from syncd to the data plane is where the specific SONiC-VPP integration occurs.
In a standard SONiC deployment on a physical switch, the syncd container would be loaded with a vendor-provided shared library (e.g., libsai_broadcom.so). When syncd reads from the ASIC_DB, it calls the appropriate standardized SAI API function (e.g., sai_api_route->create_route_entry()), and the vendor library translates this into proprietary SDK calls, to program the physical ASIC.
In the SONiC-VPP architecture, this vendor library is replaced by a purpose-built shared library: libsaivpp.so. This library is the critical foundationof the entire system. It implements the full SAI API, presenting the exact same interface tosyncd as any hardware SAI library would.
However, its internal logic is completely different. When syncd calls a function like create_route_entry(), libsaivpp.so does not communicate with a hardware driver. Instead, it translates the SAI object and its attributes into a binary API message that the VPP process understands.
It then sends this message to the VPP engine, instructing it to add the corresponding entry to its software forwarding information base (FIB). This completes a “decision-to-execution” loop, bridging SONiC’s abstract control plane with VPP’s high-performance software data plane.
Component (Container)
Key Process(es)
Role in Integration
BGP Container
bgpd
Receives BGP updates from external peers using the FRRouting stack.
SWSS Container
zebra, fpmsyncd
zebra manages the RIB. fpmsyncd receives route updates from zebra and publishes them to the Redis APPL_DB.
Database Container
redis-server
Acts as the central, asynchronous message bus for all SONiC components. Hosts the APPL_DB and ASIC_DB.
SWSS Container
orchagent
Subscribes to APPL_DB, translates application intent into a hardware-agnostic format, and publishes it to the ASIC_DB.
Syncd Container
syncd
Subscribes to ASIC_DB and calls the appropriate SAI API functions to program the data plane.
VPP Platform
libsaivpp.so
The SAI implementation for VPP. Loaded by syncd, it translates SAI API calls into VPP binary API messages.
VPP Process
vpp
The user-space data plane. Receives API messages from libsaivpp.so and programs its internal forwarding tables accordingly.
In the second part of our series, we will move from architecture to action – building and testing a complete SONiC-VPP software router in a containerized lab.
We’ll configure BGP routing, verify control-to-data planesynchronization, and analyze performance benchmarks that showcase the real-world potential of this disaggregated design.
Grab your diary and jot down the date, as Ubuntu 26.10 ‘Stonking Stingray’ is going to be released on 15 October, 2026. The Ubuntu 26.10 release date and those of other notable milestones in the next development cycle have now been shared by Canonical but, given the nature of development, should be considered tentative – plans can and do change. The most significant date in the 26.10 schedule, besides the final release, is that of feature freeze on August 10, 2026. This is the date at which (in theory) new features stop being added so that the focus can move to […]
Launchpad, the home of Ubuntu development, has finally received some design attention. Canonical last updated the site’s homepage back in 2024, but many of the pages that the distro’s developers actually use or reference on a regular basis have remained untouched for the best part of a decade. Now that’s starting to change. Canonical UX designer Enzo Deng has announced that the company has “begun […] a complete redesign of the series page” for Ubuntu 26.04 LTS, describing it as the start of “the journey of modernizing the Launchpad user experience” (sic). Save for a line on how the company […]
Canonical has released Ubuntu 26.04 LTS ‘Resolute Raccoon’ – the first LTS in Ubuntu’s history to ship without an Xorg desktop session. It runs on the latest Linux 7.0 kernel with the GNOME 50 desktop, and includes new video player and system monitor apps. Deb package management features are available in App Center. Support-wise, Ubuntu 26.04 LTS receives a minimum of 5 years of updates, and an additional 5 years of security coverage with Ubuntu Pro. For a full rundown of what’s changed since Ubuntu 25.10, see my features overview. If you’re upgrading from Ubuntu 24.04 LTS my deeper-dive on […]
Framework’s new 13 Pro laptop is the company’s first to ship as certified for Ubuntu, who say you can buy it knowing you’ll get “guaranteed support right out of the box”. Framework hardware have been popular with Linux users for years, not just for the company’s ethos around upgradeable and repairable hardware but their kernel contributions and financial support for open-source projects and developers. Specs wise, the new Framework 13 Pro is powered by Intel Core Ultra Series 3 or AMD Ryzen AI 300 series processors. It uses LPCAMM2 memory (modular LPDDR5X), available with up to 64GB (higher densities will […]