Through guided, hands-on project work, the SONiC Mentorship Program helps new contributors turn technical challenges into real-world open source impact. In this spotlight, we speak with Aditi Reddy, a graduate student at North Carolina State University, about her work on building and validating a disaggregated SONiC-VPP architecture inside a Kubernetes-based network emulation environment.
About the Mentee
My name is Aditi Reddy, a graduate student in computer science at North Carolina State University. I joined the SONiC Mentorship Program because I wanted hands-on exposure to real network operating systems and the chance to understand how modern switching platforms are built and deployed.
I am interested in modular, cloud-native networking systems, and this program was a great way to explore technologies like SONiC, VPP, and Kubernetes in a practical setting. Working directly with open-source infrastructure gave me a clearer view of how control-plane and dataplane components interact in real-world environments.
Q: What project did you work on, and why is it important to SONiC?
The integration of the VPP (Vector Packet Processing) dataplane with SONiC has traditionally followed a monolithic model, where VPP runs as a tightly coupled process inside SONiC containers. While this design works for a single virtual switch, it limits scalability and makes it difficult to build large or distributed test environments. With the Alpine–Lucius pipeline and the KNE (Kubernetes Network Emulation) cluster, there is now an opportunity to replace this monolithic model with a more modern, containerized architecture.
This project aims to separate the VPP dataplane from the SONiC control plane, running VPP as an independent Kubernetes pod inside the KNE environment while still being programmed by SONiC. Using Kubernetes orchestration, the control plane can instantiate, configure, and manage multiple VPP instances dynamically, enabling horizontal scaling and supporting more complex topologies. This disaggregated architecture also improves flexibility—allowing operators to isolate dataplane failures, allocate resources more efficiently, and manage VPP and SONiC lifecycles independently—while still preserving the operational advantages of a SONiC-based system.
Q: What were your main technical contributions?
My work centered on bringing up the disaggregated SONiC-VPP architecture inside the KNE environment and validating dataplane communication between SONiC-VPP and SONiC-Alpine. Since the upstream SONiC-VPP Docker image was broken, I first rebuilt a functional image locally using Docker, Make, and the SONiC build system. This involved debugging multistage Dockerfiles, fixing missing dependencies, and resolving build errors related to supervisor scripts and VPP startup components. Once the image was stable, I loaded it into the Kind cluster and integrated it into the existing KNE topology using protocol buffer–based topology files.
Throughout this process, I worked extensively with Kubernetes, kubectl and containerd to manage pods, load images, and inspect network interfaces inside the cluster. I also used tools
like tcpdump, iproute2 (ip link/route), and temporary debug containers to trace packets, verify interface mappings, and understand how KNE wires veth pairs between pods.
After configuring the interfaces on both SONiC-VPP and SONiC-Alpine, I successfully achieved end-to-end ping connectivity between the two pods—a key milestone proving that VPP’s dataplane path and the SONiC control-plane logic were operating correctly inside the emulated Kubernetes environment.
Q: What challenges did you face, and what did you learn?
A large part of the project involved troubleshooting and understanding how the different layers of the SONiC-VPP and KNE ecosystem interact. One of the earliest challenges was dealing with the broken SONiC-VPP Docker build, which failed due to missing base images, outdated slave images, and supervisor-script issues. Fixing these required digging through the SONiC build system, patching multistage Dockerfiles, and resolving dependency mismatches that prevented VPP from starting correctly.
The next set of issues appeared when integrating the image into Kind and KNE, where interface wiring behaves very differently from a traditional VM setup. VPP initially could not detect or bind to Kubernetes-provided interfaces, which led me to learn how Kubernetes veth pairs are created, how pods inherit network namespaces, and how those namespaces are connected through meshnet. I also had to understand how SONiC’s control-plane interfaces map onto VPP’s dataplane interfaces, and how KNE injects these links during pod creation.
There were also challenges around cluster accessibility, image loading, and pod startup failures caused by leftover cluster state. Despite these hurdles, each issue gave me a deeper understanding of the full pipeline and ultimately led to successful SONiC-VPP ↔ SONiC-Alpine communication inside KNE.
Q: What impact has this mentorship had, and what are your next steps?
With basic connectivity between SONiC-VPP and SONiC-Alpine now established inside KNE, the next phase of the project is to fully separate VPP into its own standalone dataplane container and integrate it cleanly with the SONiC-Alpine control plane. This includes creating a dedicated VPP pod template, defining stable interface mappings, and ensuring that SONiC can program VPP dynamically through standard mechanisms. Another focus area will be improving automation around topology creation—ideally allowing multiple VPP instances to be orchestrated and scaled horizontally to support larger testbeds. Finally, I plan to verify more complex traffic flows, extend support for additional interfaces, and refine the configuration so that the disaggregated SONiC-VPP architecture becomes fully reproducible and stable within modern Kubernetes environments.
Q: Is there anyone you’d like to acknowledge?
This project has been a valuable learning experience and a great introduction to working with real open-source networking systems. I’m grateful to have had the opportunity to explore SONiC, VPP, and Kubernetes in a hands-on setting, and to contribute to an architecture that moves SONiC toward a more flexible, containerized future.
I would like to thank my mentors, Brian O’Connor and Arpitha Raghunandan, for their continuous guidance, technical direction, and support throughout the project. I’m also thankful to Sreemoolanathan Iyer and Sonika Jindal from the SONiC community, whose work on SONiC Alpine and willingness to answer questions helped me overcome several critical issues. A special thanks to Kalyan Pullela, another mentee working under the same mentorship track— many of the challenges we faced were solved collaboratively through discussion and shared debugging.
Finally, I want to thank the LFX Mentorship Program and the broader SONiC community for providing this opportunity and creating such a welcoming environment for contributors.
Get Involved
Interested in contributing to SONiC? Join the community and get involved through wiki, mailing lists, and working groups.
