Docker and the CNCF will partner on an open spec to make agent permissions portable
Docker Sandbox Kits let you package an AI agent together with exactly what it is allowed to do, so anyone can pull the same agent with the same limits, review changes to those limits, and enforce them. Now, Docker has published the Docker Sandbox Kit Spec, the open specification behind Kits, under Apache 2.0 and is committing to contributing the spec to the Cloud Native Computing Foundation for neutral governance.
A Kit is an ordinary OCI container image that carries three things: the agent, the tools it uses, and a typed list of everything it asks to reach, such as network hosts, credentials, and volumes. That list lives inside the image, so pinning the image pins the agent and its requests together. A Kit builds, pushes, pulls, signs, and scans like any container image, because it is one.
“Standards are what let an ecosystem move fast without fragmenting, and few companies understand that better than Docker. By delivering Sandbox Kits as standard OCI images, Docker is giving the industry an open, repeatable way to package an AI agent, its tools, and its guardrails as one artifact. OCI is the foundation the cloud native ecosystem is built on, so a standard for agents that builds on OCI reaches the whole ecosystem at once. The CNCF welcomes this, and we’re excited to work with Docker and the community on making it broadly adopted.”
Chris Aniszczyk, CTO of the CNCF
Why the OCI image is not enough on its own
An OCI image tells a runtime how to build and start a piece of software. It has no place to state which hosts that software may call, which credentials it may use, or which files it may keep between runs. Those decisions are made outside the image, at launch: in docker run flags, a Compose file, a CI job, an onboarding doc. For a web service, that was fine. The program was fixed, it needed a network and a port, and the flags rarely changed.
Agents are different. Claude Code and Codex decide at runtime what to do: install packages, call APIs, use credentials, change the environment they run in. So the access they need is granted piece by piece, by hand, usually to get a task unblocked. A few months in, nobody can answer a simple question: what is this agent allowed to do? The answer is spread across shell history, dashboards, and someone’s memory, and it cannot be handed to a teammate or compared with last week.
Every team answers that question on its own today, and every runtime vendor could ship its own format for the answer. That is the fragmentation OCI was created to prevent, and it is why Docker is now proposing one artifact, built on OCI, governed in the open by the CNCF community.
How a Sandbox Kit Spec fills the gap
The Sandbox Kit Spec does not fork or replace any OCI specification. It uses the annotation extension point OCI already defines to carry the agent’s requests in the image manifest. Nothing in a registry, scanner, or signing tool needs to change.
Kits began as a feature of Docker Sandboxes, Docker’s product for running agents inside isolated microVMs, where a Kit defined one sandbox: the agent, its tools, and what it could reach. The Sandbox Kit Spec turns that definition into a standard OCI image and opens the format so any runtime can implement it. Docker Sandboxes is the first runtime that enforces it. It should not be the only one, and under Linux Foundation governance it will not be.
Two things follow for anyone running agents. The answer travels with the agent: a teammate can pull it, a reviewer can diff it, and a conforming runtime can enforce it. And when a new version asks for more, the change shows up as added lines someone can refuse.
Kits from across the ecosystem
Kits for tools from AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks, and Snyk are available now, covering cloud, observability, security, artifact management platforms and more.
That is what a shared format makes possible. A database vendor can publish a Kit that connects any agent to its service with the scope it recommends. An agent maker can publish its own Kit, so the request list comes from the people who built the agent. A platform team can publish one for the company, and every engineer starts from the same place.
Containers made software portable. Kits make authority portable: the set of things you deliberately hand an agent travels with the agent, in the same image, and means the same thing wherever a conforming runtime opens it. Docker looks forward to formally submitting Kits to the CNCF and working with the community to ensure Kits further the goal of secure, reliable agentic AI and AI governance.
Build a Kit
If you make a tool that agents use, publish a Kit for it. If you run agents, start from one and share it with your team. The Docker Sandbox Kit Spec, its capability pages, and a worked tour of a real Kit are available at docker/sandbox-kit-spec. If there is a Kit you cannot express, or a rule a runtime cannot implement, open an issue.
The consumer data broker Radaris.com has long had a reputation for ignoring requests to remove personal information from its vast empire of people-search services online. That reputation caught up with the company recently in a lawsuit alleging Radaris violated a New Jersey privacy law that provides for hefty fines against data brokers that publish personal information on state law enforcement officials. In the face of repeated stonewalling and prevarication by attorneys for Radaris, the judge in the case ordered that radaris.com and more than a dozen other data broker domains be transferred to the plaintiffs.
The radaris.com website, prior to the domain transfer to Atlas.
In February 2024, Radaris was sued by Atlas Data Privacy Corp, a company that has been pursuing data brokers alleged to be violating a New Jersey statute called Daniel’s Law. The statute allows state law enforcement officials, government personnel, judges and their families to have their information completely removed from commercial data brokers and people-search services, and provides for fines of $1,000 per violation against companies that ignore removal requests.
Less than a month after Atlas sued Radaris, KrebsOnSecurity published a deep dive into the Radaris co-founders — Igor and Dmitry Lubarsky (also spelled Lybarsky) — Russian-born brothers living in Massachusetts who operate a dizzying array of people-search companies as well as a number of Russian language dating services and affiliate programs.
Attorneys for the Lubarsky brothers threatened to sue for defamation if the story wasn’t removed and an apology issued. Their attorney asserted that our reporting was wildly inaccurate, and that the true owners of the company were Ukrainians living in Ukraine.
The Lubarsky brothers Dmitry or “Dan” (left) and Gary/Igor.
KrebsOnSecurity doubled down and showed how the Lubarsky brothers built and operated Radaris and other data broker companies using a fictitious CEO’s name. Our follow-up story noted that Radaris’s attorney — a lawyer with the Boston Law Group named Val Gurvits — admitted his clients had invented the CEO pseudonym “Gary Norden,” and that Radaris also had issued multiple press releases over the years that quoted the fake CEO while seeking money from potential investors.
Attorneys for Radaris waited until the last minute to appear in court and contest what was all but certain to be a default judgment in favor of the plaintiffs, and then told the court that Atlas had failed to serve the real owners and operators of Radaris and several of its sister data broker companies.
Atlas re-filed the lawsuit in June 2025, this time dramatically expanding the number of Radaris family data brokers accused of violating Daniel’s Law. Matt Adkisson, president and CEO of Atlas, said Radaris turned to a tried-and-true playbook: Delaying in court until the last possible minute, and playing shell games with Radaris’s true country of origin and the individuals listed as owners and operators of these sites.
“We refer to this period as their island-hopping phase. Privacy policies changed constantly, and new entities kept appearing from places like the Marshall Islands, the British Virgin Islands, and Seychelles,” Adkisson told KrebsOnSecurity. “Behind the scenes, it felt like a shell game. Defense lawyers told the court that certain entities merely operated the domains and were the proper parties to sue. But by the time a judgment neared, those entities would be discarded and new entities would appear. Meanwhile, the lawyers claimed the other entities that actually owned the domains should not be held responsible.”
Adkisson said when the defendants updated their terms of service to state that Radaris was suddenly managed by a company in the Marshall Islands, Atlas hired an investigator in that country and soon learned the brand new entity that Radaris claimed was managing the company didn’t even exist yet.
Mr. Gurvits stepped forward as Radaris’s attorney in a class action lawsuit the company temporarily lost in 2017 because it never contested the claim in court. When the plaintiffs told the judge they couldn’t collect on the $7.5 million default judgment, the court ordered the domain registry Verisign to transfer the radaris.com domain name to the plaintiffs.
Mr. Gurvits appealed that verdict, arguing the lawsuit hadn’t named the actual owners of the Radaris domain name — a Cyprus company called Bitseller Expert Limited — and thus taking the domain away would be a violation of their due process rights.
The judge in the 2017 case ruled in Radaris’ favor — halting the domain transfer — and told the plaintiffs they could refile their complaint. Soon after, the operator of Radaris changed from Bitseller to Andtop Company, an entity formed (PDF) in the Marshall Islands in Oct. 2020. The plaintiffs never re-filed their lawsuit.
A mind map of various entities tied to Radaris and the company’s co-founders. Click to enlarge.
“That seemed to be their modus operandi,” said Raj Parikh, a partner at PEM Law in New Jersey who handles most of the Daniel’s Law litigation for Atlas. “In the past, they won by attrition. Plaintiffs’ attorneys tired of the procedural games and just gave up. That strategy worked for a decade, and it probably would have worked in this case too, since any financial recovery from foreign actors will be difficult. But we were acutely aware of the threat this website posed to law enforcement officers and other public officials in New Jersey, and decided early on to commit whatever time and resources were necessary to remove that threat.”
On August 26, the judge in the New Jersey case found the defendants were given multiple chances to appear and defend the claims against them but had failed to do so. Mr. Gurvits declined to comment on the case, saying it had been assigned to another attorney, a Mr. Victor Worms. In response to questions, Mr. Worms asserted the New Jersey court transferred Radaris.com to Atlas as part of a default judgment against Radaris.com, which is not a legal entity.
“We have made a motion to vacate that default judgment on the grounds that it is void since a non-entity has no legal capacity to sue or be sued,” Worms replied. “We also intend to pursue all appropriate appeals because we believe the transfer of Radaris.com amounts to a forfeiture in violation of various constitutional principles.”
While radaris.com still comes up prominently in results when searching online for U.S. residents by name, the domain no longer sells detailed personal dossiers on millions of Americans. Its homepage now displays a notice from Atlas, as well as links to our previous reporting on Radaris.
EMAIL CONFIRMATIONS
Atlas told KrebsOnSecurity that it has obtained more than 10,000 emails and documents in the course of litigation, and that those messages confirm our previous reporting on the owners and operators of Radaris and its myriad companies.
Atlas said the emails clearly establish that the nominal legal vehicles — Radaris America, Inc.; Bitseller Expert Limited; Digital Orbit Corp; Core Solutions Group Inc; Lucky Solutions Inc; Virtura Corp; Veripages Inc.; Nuform Solutions Inc.; Growth Data Advisors Inc.; Property Experts, Inc — are all administered by the same three or four people from the same mailboxes, share one bank or payment card set, and are all managed from one virtual office address.
“The corpus establishes, with documentary evidence generated independently by banks, payment processors, hosting providers, registrars, software-as-a-service vendors and the operators’ own systems, that radaris.com and at least twenty-five other people-search websites are one operation run by a small Boston-area group whose administrative, financial and technical functions sit on the difive.com mail domain and its successors (centerex.com, scienteco.com, eprofit.com, realmo.com, pub360.com),” reads a summary shared by Atlas.
Atlas said the emails show Radaris.com earns approximately $42,000 a month, while Veripages.com earns around $45,000 monthly via its partnership with the Lifetime Value Company, a marketing and advertising firm whose brands include PeopleLooker, PeopleSmart, NumberGuru, and Bumper, a car history site.
According to Atlas, the emails also showed the Radaris family of websites earns as much as $25,000 each month from their partnership with Onerep, a company that claims to help people remove their information from people-search sites. In March 2024, KrebsOnSecurity revealed how the Belarusian founder of Onerep had launched and operated dozens of people-search sites over the years and was continuing to operate one of them (Nuwber), effectively spreading the disease and selling the cure.
The domain radaris.com now redirects to this notice from Atlas about the court-ordered domain transfer.
All told, the New Jersey court has so far transferred 14 domain names from the Radaris family of companies to Atlas. Radaris.com now redirects to a notice of the court-ordered domain transfer.
THE ROAD AHEAD
The Radaris family of companies is still potentially facing fines of $1,000 per alleged violation of Daniel’s Law. For the time being, however, Daniel’s Law is facing a constitutional challenge from virtually all of the 150 other consumer data broker firms being sued by Atlas.
The data broker industry responded by having at least 70 of the Atlas lawsuits moved to federal court, challenging the New Jersey statute as overly broad and a violation of the First Amendment. The U.S. Court of Appeals for the Third Circuit has not yet issued a decision on the constitutional challenge, but either way the case is widely expected to be appealed all the way to the U.S. Supreme Court.
Meanwhile, at least 14 other states have now passed laws modeled after the New Jersey statute, with more states considering similar measures. However, West Virginia’s Daniel’s Law was ruled facially unconstitutional under the First Amendment by a federal district court in August 2025.
Justin Sherman is a privacy expert and author of the forthcoming book “The Middlemen,” which examines how the data broker industry powers modern surveillance. Sherman said federal lawmakers have long faced intense lobbying by the technology industry against more restrictive U.S. data privacy laws, but that many powerful industries are now working against passing comprehensive data privacy legislation.
“These days at the federal level, add in the intense amount of lobbying against these laws from social media companies, big tech, cryptocurrency firms, and now AI proponents in the mix who claim that limiting their data scraping is somehow going to collapse the whole U.S. economy under Chinese rule,” he said.
Sherman said people-search companies will continue to thrive unless and until Congress enacts meaningful consumer privacy and data protection laws that are relevant to life in the 21st century. That’s because virtually all state privacy laws exempt records that might be considered “public” or “government” documents, including voting registries, property filings, marriage certificates, motor vehicle records, criminal records, court documents, death records, professional licenses, bankruptcy filings, and more.
At least 25 states have passed or implemented laws requiring age verification for residents seeking to access adult content online, but there is no federal law that limits how the companies that are scanning everyone’s drivers license can use, share or keep the data provided. Had such restrictions been enshrined in law, we may have avoided the recent breach at IDScan.net, which exposed the drivers license information on more than 153 million Americans when the records were briefly turned into a point-and-click identity theft service on the dark web.
“The average person can look at Daniel’s Law and have a perfectly normal reaction, which is that everyone should be covered, not just police and judges,” Sherman said. “But we don’t need more wake-up calls. We’ve had eight million wake-up calls already on the need for better privacy laws. The lack of comprehensive federal privacy law is not for a lack of knowledge, and anyone claiming otherwise is either not reading the news or kidding themselves.”
You change one line in a large file. Your “incremental” backup re-uploads the whole thing anyway.
Nine times out of ten, it’s not the network, and it’s not your storage backend. It’s the algorithm deciding where to cut your data into pieces.
Every deduplication system works the same way: split data into pieces, hash each piece, keep one copy per distinct hash. A piece is named after its own content, so two identical pieces are, by definition, the same piece. Snapshot a filesystem today and again tomorrow, and if most of the data hasn’t changed, most pieces are already in the store. The second snapshot costs you almost nothing.
That’s not a nice-to-have. A backup that actually survives an incident needs to be encrypted, frequent, immutable, replicated and verified, and each of those requirements multiplies what you store. When deduplication is weak, those multipliers stack until backing up everything becomes unaffordable, and teams quietly retreat to backing up only what they call “critical.” Good deduplication is what makes backing up everything affordable again.
And all of it rests on one assumption: unchanged data should yield unchanged pieces.
Where fixed-size chunking falls apart
The obvious way to split a file is to cut every N bytes. It’s fast. It also wrecks deduplication the moment you touch the file.
Add one byte near the front and every boundary after it slides over by one. Nothing lines up with where it used to be, so every hash downstream is “new,” so the store treats the entire rest of the file as fresh data. Edit one line in a 40 GB file and you re-upload close to 40 GB of it. Nothing meaningful changed, only the offsets did, and fixed-size boundaries are glued to offsets.
How content-defined chunking fixes it
Content-Defined Chunking (CDC) picks boundaries based on what the data is, not where it happens to sit.
Slide a small window over the byte stream and keep a rolling hash, cheap enough to update incrementally that the whole scan stays linear, then cut a boundary wherever that hash matches an agreed pattern.
Now insert a byte. The boundaries right around the edit shift. But once the window slides past the change, the hash sequence goes back to matching what it was before, and the boundaries fall back into place on their own. One piece changes. Everything else deduplicates cleanly against the previous snapshot. That self-resynchronizing behaviour is the whole point of CDC.
Picking an algorithm
There’s more than one way to build a rolling hash and a cut rule.
Rabin fingerprinting is the textbook original, correct but slow and allocation-heavy by today’s standards. FastCDC swapped the polynomial hash for a much cheaper Gear hash and normalized the chunk-size distribution, and it became the field’s workhorse. UltraCDC trades a bit of speed for fewer, larger chunks. JC is a newer design that turns out to be strikingly fast. There are also keyed variants, where the hash table is seeded from a secret so two different stores cut the same data at different points, which matters if you care about not leaking which chunks you hold.
We benchmarked these in go-cdc-chunkers, the open-source chunking library behind our backup engine, Plakar, on 1 GiB of random data, the worst case since there’s no structure to exploit. JC hits 3747 MB/s, comfortably ahead of the Gear-based FastCDC variants. Rabin runs about 7.5x slower and allocates roughly 3.3 MB per operation versus a few KB for the others, which on a busy host is the difference between a run you notice and one you don’t. Full benchmarks and charts are published separately.
Using it is trivial:
// One interface for the whole family.
c, _ := chunkers.NewChunker("jc", reader) // or "fastcdc", "ultracdc", "kfastcdc"
for {
chunk, err := c.Next()
// ... hash and store the chunk ...
if err == io.EOF {
break
}
}
Determinism is the feature that matters most
Here’s the part that gets too little respect.
Give it enough time and “FastCDC” stops meaning one thing. Every implementation picks up small departures from the paper: a mask off by a bit, a window starting a byte early, a threshold nudged for taste. Harmless for a benchmark. For a storage system it’s a slow-motion disaster, because boundaries are part of your data’s identity. Change how you cut and yesterday’s pieces stop matching today’s, so deduplication degrades with no error and no warning. The store just grows faster than it should.
The fix is to publish spec-faithful, explicitly versioned variants and treat the version number as a promise: a given version cuts a given input the same way, on any machine, forever. Improvements ship under a new name people adopt on purpose, so nothing re-cuts existing data out from under anyone. Versioning also buys you cross-language conformance vectors, published inputs with expected boundaries that any implementation, in any language, can check itself against, byte for byte. That’s what turns “spec-faithful” from a claim into something you can actually test.
So whatever you pick, hold out for two things: a pinned, versioned spec of exactly how boundaries get computed, and published test vectors you can verify yourself. Speed is negotiable. Determinism isn’t.
Why we built this in the open
go-cdc-chunkers is open source for the same reason all of Plakar is. Backup is a trust problem before it is a technical one: you hand one system the single copy of your data meant to survive everything else, yet with most products you cannot read the code, review the cryptography, or verify the recovery path until the day you need it. Open source is the only honest answer I know, and it is the one I took from years on OpenSMTPD and OpenBSD: formats outlive vendors, a backup you cannot open in ten years is not a backup, and the community that reads the code is part of the security model.
Try it yourself
To see the deduplication effect directly, you can reproduce the experiment with an open source backup implementation that uses CDC. The following example uses Plakar.”
On macOS, brew install plakarkorp/tap/plakar; on any platform with Go 1.23.3 or newer, go install github.com/PlakarKorp/plakar@latest. Prebuilt binaries, apt and AUR packages for every platform are on the download page.
Create a local store (Plakar calls it a Kloset). It will prompt for a passphrase, since everything is encrypted before it touches disk:
plakar at $HOME/backups create
Now back up a directory:
plakar at $HOME/backups backup $HOME/Documents
The last line of the output tells you what happened:
info: backup: created unsigned snapshot dd62691d of size 6.4 KiB in 125ms (wrote 577 KiB)
Two numbers matter there: the logical size of what you backed up, and the bytes actually written to the store. Now the part that shows CDC working. Change one file, add a paragraph to a document, then run the exact same backup command again. You get a new, self-contained snapshot, but the bytes written the second time are a small fraction of the first, because every chunk that did not change was already in the store and is simply referenced rather than rewritten. Insert a few bytes at the top of a large file and the diagram above becomes concrete: the chunks after the edit resynchronise and deduplicate against the first snapshot instead of being stored again.
You can list snapshots, verify one is intact, then restore it somewhere else:
plakar at $HOME/backups ls
plakar at $HOME/backups check dd62691d
plakar at $HOME/backups restore -to $HOME/restored dd62691d
If you would rather look before installing anything, a public instance of the web UI runs at https://demo.plakar.io with real backups to browse.
Resources
It’s all open source: the chunking library is go-cdc-chunkers and the backup engine is Plakar, with the full v1.1.0 benchmarks published for anyone who wants to reproduce them.
Gilles Chehade is a long-time OpenBSD developer and the co-founding CTO of PlakarKorp. He createdPlakar.io as a personal tool in 2015 before turning it into an open backup platform that gives security and infrastructure teams “resilience as code.”
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.
In the transformative years of the late 1990s, a quiet revolution took place, fundamentally altering how we connect to networks. The introduction of DHCP answered a crucial question, “Where are you on the network?”, by automating IP address assignment. This innovation eradicated the manual configuration nightmares, paving the way for seamless connectivity. Today, as digital trust becomes increasingly vital, a new revolution is emerging—one that demands an equally transformative approach: Secure Zero-Touch Provisioning (SZTP).
Trust: The Next Frontier
As we stand on the brink of this next wave of innovation, we recognize a pressing need to automate trust. Much like DHCP revolutionized connectivity, SZTP is poised to redefine security and trust in modern networking infrastructures. The digital landscape is evolving; spanning from cloud nodes and IoT sensors to AI-driven systems and intelligent robotics, the future of secure networking lies in our ability to trust devices automatically and unequivocally.
SZTP: Pioneering the Trust Paradigm
SZTP, as defined in RFC 8572, represents a groundbreaking shift in how we establish trust across diverse digital infrastructures. This open standard is vendor-neutral, heralding a universally adoptable solution fit for large-scale deployment. It automates trust by managing the exchange of secure artifacts and certificates, ushering in an era in which devices self-authenticate, receive verified firmware, and securely initialize without human intervention.
For organizations navigating the complexities of modern digital ecosystems, SZTP is more than a protocol; it’s a strategic approach equipped to handle the challenges of autonomous, scalable, and secure operations.
Unlocking Potential: AI and Edge Clouds
One of the most compelling use cases for SZTP is its application within AI data centers—environments now likened to future-ready AI factories. Here, devices such as DPUs (Data Processing Units) and IPUs (Infrastructure Processing Units) perform critical tasks by offloading networking and security operations from traditional GPUs, running complex, containerized workloads. With SZTP, these environments are provisioned and secured at unprecedented scales, aligning perfectly with the Linux Foundation’s Open Programmable Infrastructure (OPI) project’s standards.
Additionally, edge clouds represent a burgeoning frontier. As AI-driven applications demand lower latency, bringing operations geographically closer to end users becomes crucial. With SZTP, deployment at tens of thousands of sites becomes feasible, secure, and remarkably efficient, empowering next-generation applications from autonomous vehicles to immersive synthetic realities.
Strategic Pillars of SZTP Implementation
From Addresses to Identity
Just as DHCP provides basic network connectivity, SZTP redefines the initial handshake with devices, answering the questions “Who are you?” and “What role do you play?” This trust-centric evolution reflects an essential shift towards identity verification and operational certainty from the outset.
Secure-by-Default Provisioning
Establishing secure-by-default infrastructures is increasingly critical. SZTP ensures onboarding initiates with hardware attestation, swiftly evolving devices into secure nodes through verified boot processes, secure image delivery, and cryptographic credential injection.
From Firmware to Mission-Centric Deployments
In advanced environments, SZTP delivers a complete software stack—it not only defines device roles across domains such as XR workloads and IoT pipelines but also simulates workloads pre-deployment to ensure readiness and optimal performance.
Scaling Through Open Clients and Adoption
Industry-wide adoption of SZTP mirrors DHCP’s trajectory, necessitating robust open-source client solutions. The availability of open-source SZTP clients under permissive licenses is accelerating adoption across the ecosystem.
Driving the Secure Future
As digital networks extend their reach and capabilities, securing these environments becomes not just a priority but a necessity. SZTP shines as a beacon of innovation, demonstrating that with open standards and robust automation, trust can be as effortless as connectivity once was.
By nurturing open client ecosystems, SZTP doesn’t just promise enhanced digital trust; it actively defines what secure, automated infrastructure looks like in an AI-enabled world of applications. It lays the groundwork for what digital trust should be in future network paradigms, leading the charge into a new era of connectivity redefined by trust.
Moreover, adopting SZTP empowers organizations to innovate confidently, knowing their infrastructure is resilient and agile enough to handle growth and complexity. As businesses shift toward data-driven models and consumers demand more sophisticated digital interactions, SZTP ensures security and performance are uncompromised. Organizations embracing this strategy will secure operations and cultivate trust, enhancing customer relationships and accelerating digital transformation.
Looking ahead, SZTP is more than an implementation; it is pivotal for future-proofing the digital economy, setting new benchmarks for security, efficiency, and trust in the evolving technological ecosystem.
In Part One of this series, we examined how the SONiC control plane and the VPP data plane form a cohesive, software-defined routing stack through the Switch Abstraction Interface.
We outlined how SONiC’s Redis-based orchestration and VPP’s user-space packet engine come together to create a high-performance, open router architecture.
In this second part, we’ll turn theory into practice. You’ll see how the architecture translates into a working environment, through a containerized lab setup that connects two SONiC-VPP routers and Linux hosts.
Reconstructing the L3 Routing Demo
Understanding the architecture is foundational, but the true power of this integration becomes apparent through a practical, container-based lab scenario.
The demo constructs a complete L3 routing environment using two SONiC-VPP virtual routers and two Linux hosts, showcasing how to configure interfaces, establish dynamic routing, and verify end-to-end connectivity.
Lab Environment and Topology
The demonstration is built using a containerized lab environment, orchestrated by a tool like Containerlab. This approach allows for the rapid deployment and configuration of a multi-node network topology from a simple declarative file. The topology consists of four nodes:
router1: A SONiC-VPP virtual machine acting as the gateway for the first LAN segment.
router2: A second SONiC-VPP virtual machine, serving as the gateway for the second LAN segment.
PC1: A standard Linux container representing a host in the first LAN segment.
PC2: Another Linux container representing a host in the second LAN segment.
These nodes are interconnected as follows:
An inter-router link connects router1:eth1 to router2:eth1.
PC1 is connected to router1 via PC1:eth2 and router1:eth2.
PC2 is connected to router2 via PC2:eth2 and router2:eth2.
Initial Network Configuration
Once the lab is deployed, a startup script applies the initial L3 configuration to all nodes.
Host Configuration: The Linux hosts, PC1 and PC2, are configured with static IP addresses and routes.
PC1 is assigned the IP address 10.20.1.1/24 and is given a static route for the 10.20.2.0/24 network via its gateway, router1 (10.20.1.254).
PC2 is assigned the IP address 10.20.2.1/24 and is given a static route for the 10.20.1.0/24 network via its gateway, router2 (10.20.2.254).
Router Interface Configuration: The SONiC-VPP routers are configured using the standard SONiC CLI.
router1:
The inter-router interface Ethernet0 is configured with the IP 10.0.1.1/30.
The LAN-facing interface Ethernet4 is configured with the IP 10.20.1.254/24.
router2:
The inter-router interface Ethernet0 is configured with the IP 10.0.1.2/30.
The LAN-facing interface Ethernet4 is configured with the IP 10.20.2.254/24.
After IP assignment, each interface is brought up using the sudo config interface startup command.
Dynamic Routing with BGP
With the interfaces configured, dynamic routing is established between the two routers using the FRRouting suite integrated within SONiC. The configuration is applied via the vtysh shell.
iBGP Peering: An internal BGP (iBGP) session is established between router1 and router2 as they both belong to the same Autonomous System (AS) 65100.
router1 (router-id 10.0.1.1) is configured to peer with router2 at 10.0.1.2.
router2 (router-id 10.0.1.2) is configured to peer with router1 at 10.0.1.1.
Route Advertisement: Each router advertises its connected LAN segment into the BGP session.
router1 advertises the 10.20.1.0/24 network.
router2 advertises the 10.20.2.0/24 network.
This BGP configuration ensures that router1 learns how to reach PC2’s network via router2, and router2 learns how to reach PC1’s network via router1.
Verification and Data Path Analysis
The final phase is to verify that the configuration is working correctly at every layer of the stack.
Control Plane Verification: The BGP session status and learned routes can be checked from within vtysh on either router. On router1, the command show ip bgp summary would confirm an established peering session with router2. The command show ip route would display the route to 10.20.2.0/24 learned via BGP from 10.0.1.2.
Data Plane Verification: To confirm the route has been programmed into the VPP data plane, an operator would access the VPP command-line interface (vppctl) inside the syncd container. The command show ip fib would display the forwarding table, which should include the BGP-learned route to 10.20.2.0/24, confirming that the state has been successfully synchronized from the control plane.
End-to-End Test: The ultimate test is to generate traffic between the hosts. A simple ping 10.20.2.1 from PC1 should succeed. This confirms that the entire data path is functional: PC1 sends the packet to its gateway (router1), router1 performs a lookup in its VPP FIB and forwards the packet to router2, which then forwards it to PC2. The return traffic follows the reverse path, validating the complete, integrated solution.
This practical demonstration, using standard container tooling and declarative configurations, powerfully illustrates the operational simplicity and robustness of the SONiC-VPP architecture for building high-performance, software-defined L3 networks.
Performance Implications and Future Trajectories
The elegance of the SONiC-VPP integration is matched by its impressive performance and its applicability to a wide range of modern networking challenges.
By offloading the data plane from the kernel to a highly optimized user-space framework, this solution unlocks capabilities that are simply unattainable with traditional software-based routing.
The performance gains are impressive.
VPP is consistently benchmarked as being much faster than kernel-based forwarding, with some sources claiming a 10x to 100x improvement in packet processing throughput.2
This enables use cases like “Terabit IPSec” on multi-core COTS servers, a feat that would have been unthinkable just a few years ago.3 Real-world deployments have validated this potential.
A demonstration at the ONE Summit 2024 showcased a SONiC-VPP virtual gateway providing multi-cloud connectivity between AWS and Azure. The performance testing revealed a round-trip time of less than 1 millisecond between application workloads and the cloud provider on-ramps (AWS Direct Connect and Azure ExpressRoute), highlighting its suitability for high-performance, low-latency applications.4
This level of performance opens the door to a variety of demanding use cases:
High-Performance Edge Routing: As a virtual router or gateway, SONiC-VPP can handle massive traffic volumes at the network edge, serving as a powerful and cost-effective alternative to proprietary hardware routers.5
Multi-Cloud and Hybrid Cloud Connectivity: The solution is ideal for creating secure, high-throughput virtual gateways that interconnect on-premises data centers with multiple public clouds, as demonstrated in the ONE Summit presentation.4
Integrated Security Services: The performance of VPP makes it an excellent platform for computationally intensive security functions. Commercial offerings based on this architecture, like AsterNOS-VPP, package the solution as an integrated platform for routing, security (firewall, IPsec VPN, IDS/IPS), and operations.5
While the raw throughput figures are compelling, a more nuanced benefit lies in the nature of the performance itself.
The Linux kernel, for all its power, is a general-purpose operating system. Its network stack is subject to non-deterministic delays, caused by system interrupts, process scheduling, and context switches. This introduces unpredictable latency, which can be detrimental to sensitive applications.12
VPP, by running in user space on dedicated cores and using poll-mode drivers, sidesteps these sources of unpredictability. This provides not just high throughput, but consistent, low-latencyperformance. For emerging workloads at the edge, such as real-time IoT data processing, AI/ML inference, and 5G network functions, this predictable performance is often more critical than raw aggregate bandwidth.16 The key value proposition, therefore, is not just being “fast,” but being “predictably fast.”
The SONiC-VPP project is not static; it is an active area of development within the open-source community.
A key focus for the future is to deepen the integration by extending the SAI API to expose more of VPP’s rich feature set to the SONiC control plane. Currently, SAI primarily covers core L2/L3 forwarding basics.
However, VPP has a vast library of advanced features. Active development efforts are underway to create SAI extensions for features like Network Address Translation (NAT) and advanced VxLAN multi-tenancy capabilities, which would allow these functions to be configured and managed directly through the standard SONiC interfaces.6
A review of pull requests on thesonic-platform-vpp GitHub repository shows ongoing work to add support for complex features like VxLAN BGP EVPN and to improve ACL testing, indicating a healthy and forward-looking development trajectory.6
The Future is Software-Defined and Open
The integration of the SONiC control plane with the VPP data plane is far more than a clever engineering exercise.
It is a powerful testament to the maturity and viability of the disaggregated networking model. This architecture successfully combines the strengths of two of the most significant open-source networking projects, creating a platform that is flexible, performant, and free from the constraints of proprietary hardware.
It proves that the separation of the control and data planes is no longer a theoretical concept but a practical, deployable reality that offers unparalleled architectural freedom.
The synergy between SONiC and FD.io VPP, both flagship projects of the Linux Foundation, highlights the immense innovative power of collaborative, community-driven development.1
This combined effort has produced a solution that fundamentally redefines the router, transforming it from a monolithic hardware appliance into a dynamic, high-performance software application that can be deployed on commodity servers.
Perhaps most importantly, this architecture provides the tools to manage network infrastructure with the same principles that govern modern software development.
As demonstrated by the L3 routing demo’s lifecycle-building from code, configuring with declarative files, and deploying as a versioned artifact, the SONiC-VPP stack paves the way for true NetDevOps. It enables network engineers and operators to embrace automation, version control, and CI/CD pipelines, finally treating network infrastructure as code. 7
In doing so, it delivers on the ultimate promise of software-defined networking – a network that is as agile, scalable, and innovative – as the applications it supports.
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.
Accedi
