The 2025 SONiC Hackathon brought together 31 participating groups from 12 organizations, evaluated by a panel of 9 expert judges, showcasing some of the most innovative thinking across the SONiC community. Among this year’s standout contributors was Kalyan Pullela, a PhD student at Oklahoma State University and the sole member of the OSUCowboys team. His exceptional ability to transform a mentorship project into a fully automated, CI-ready validation pipeline earned him the Rising Star Award, recognizing emerging contributors who demonstrate outstanding potential and meaningful impact. His project, AutoSONiC, impressed judges with its technical rigor, clarity, and immediate value to both SONiC developers and operators. Below, we dive into his winning proposal.
Introduction:
My name is Kalyan Pullela, and I am a PhD student at Oklahoma State University. I entered the SONiC Hackathon as a single member of the OSUCowboys team. For this hackathon, I built on work from the SONiC mentorship program, where I first began using the new SONiC Alpine virtual switch platform.
The idea behind my project, AutoSONiC, was to take what was already possible with Alpine and transform it into a fully automated validation environment. It establishes a small but realistic multi-port topology, drives traffic with Ixia-c via Open Traffic Generator (OTG) APIs, and performs health and conformance checks, end-to-end and hardware-free.
The problem:
SONiC images are often tested in ways that do not reflect how they will actually be used:
- We need a fast, repeatable, CI-ready way to test features, traffic, and conformance in multi-tier topologies.
- SONiC images are often tested in isolation, but their behavior changes when embedded in real network contexts.
- Physical labs are costly, slow, and complicated to share. Drift and misconfiguration lead to ‘too-perfect’ but meaningless runs.
- Testing relies on a few hand-written tests instead of a repeatable pipeline.
- Minimal or no realistic traffic, and little visibility into behavior under impairment
Once a SONiC image is deployed into a real fabric with multiple links, flows, and failure modes, subtle issues begin to surface: port mapping mistakes, orchestration problems, and behavior changes across different deployment scenarios.
On the other side, physical labs are expensive and fragile. They are hard to share across teams, slow to reset, and prone to configuration drift. A lot of time gets spent just getting a testbed “back into a good state” rather than actually testing SONiC.
For both developers and operators, this creates three core pain points:
- Slow experimentation – trying new features or SAI changes requires access to scarce hardware.
- Limited automation – CI systems can run unit tests, but not complete multi-node traffic tests.
- Low repeatability – results depend on the current state of a lab rather than on a defined, reproducible environment.
AutoSONiC is my answer to those problems: a way to treat the testbed itself as code, and to make multi-node, traffic-driven validation something that can run in a repeatable way.
What and Why Alpine?
The project is built on sonic-alpine, which combines:
- A virtual SONiC image
- A data plane driven by Lucius (a lightweight open-source SAI dataplane)
- Integration with gRPC SA, and KNE/Kubernetes
This combination enables the execution of SAI-backed SONiC behavior without physical ASICs, entirely within a containerized environment. For AutoSONiC, that meant I could focus on orchestrating tests and traffic instead of worrying about getting access to hardware.
The Hackathon Solution:
AutoSONiC is an automated validation pipeline that ties together:
- Alpine virtual SONiC switches
- Ixia-c traffic generation controlled via OTG
- Kubernetes Network Emulation (KNE) for topology orchestration
The base setup is a two-DUT Alpine topology, connected via multiple Lucius-backed front-panel ports. That provides sufficient structure to model realistic behaviors (multiple links, multiple flows, and impairments) without overwhelming complexity.
From a user’s perspective, AutoSONiC is a single command that:
- Brings up the KNE cluster and Alpine topology
- Runs health checks and OpenConfig-based conformance tests
- Drives traffic with Ixia-c
- Applies impairments
- Generates a structured report (tables and charts)
Everything is defined in scripts and simple configuration YAML files, allowing the same run to be reproduced on another machine or in a CI environment.
How it works: Architecture and Workflow
At a high level, AutoSONiC has three layers:
- Orchestration layer (KNE/Kubernetes)
- A KIND cluster hosts Alpine VS containers and the OTG controller.
- A topology file defines how nodes and links are wired.
- A small set of make targets and shell scripts manages bring-up, reset, and teardown.
- Validation layer
- A conformance phase verifies the health of the container, the SONiC version, port mappings, and basic services.
- OpenConfig profile checks verify that key configuration and telemetry expectations are met before any traffic is sent.
- Traffic and reporting layer (OTG + impairment)
- OTG drives bidirectional traffic between selected ports on the two DUTs.
- A scale matrix sweeps flows and rates to explore behavior under different loads.
- An impairment phase injects loss and delay, enabling A/B comparisons of “clean” vs “impaired” runs.
- Results (pps, bps, loss, latency, and jitter) are exported as CSV files and summarized in Markdown with accompanying charts.
Impacts and Benefits:
AutoSONiC is designed to enhance both developer velocity and operator confidence.
- Fast feedback
Because bring-up, health checks, conformance, and traffic are all scripted, a complete run can be triggered from a single command. If something in the lab is broken, the configuration phase fails quickly with an explicit error, rather than silently producing strange traffic numbers. - Configuration flexibility
Topology parameters, traffic patterns, and impairment knobs are all configurable via environment variables and YAML, rather than being hard-coded. The same pipeline can be reused for smoke tests, stress tests, and regression runs by swapping configurations. - Hardware-free, CI-ready validation
As everything runs in containers, AutoSONiC can be integrated into CI systems like Azure Pipelines, GitHub Actions, or GitLab CI. A CI job can spin up the KNE cluster, deploy Alpine, run AutoSONiC, and attach the generated reports as build artifacts, all without consuming any physical lab capacity.
This is useful for:
- Vendors and developers who want quick iteration on new features or SAI changes.
- Operators who want to evaluate SONiC images before hardware arrives or before rolling changes into production.
- The SONiC community benefits from a reproducible reference for Alpine and OTG-based validation.
A complete end-to-end run, as shown here, took approximately 18 minutes.
Lessons learned:
A few key lessons came out of building AutoSONiC:
- Making everything scriptable turned out to be essential, as it helps with staging and reproducibility.
- Enabling the configuration and conformance checks early in the pipeline made failures obvious and reduced debugging time. Broken containers and mismapped ports were some recurring failures this helped mitigated.
Next Steps:
AutoSONiC is a starting point, not the final word. Planned next steps include:
- Upstream the code to the sonic-alpine repository. (This has been done!)
Check it out here: https://github.com/sonic-net/sonic-alpine/tree/master/deploy/kne/alpine-otg
- Growing beyond the initial two-DUT topology to spine-leaf or multi-tier fabrics, reusing the same orchestration pipeline.
- Tight integration with CI pipelines, so every new SONiC image can automatically trigger an AutoSONiC run.
- Validating the same AutoSONiC test plans with Ixia-c traffic on physical SONiC hardware, to ensure that the behaviors observed in Alpine-based virtual labs remain grounded in real switch behavior and production-like conditions.
- Enable one-click deployment to physical hardware networks for performance testing, bridging virtual validation with real-world conditions.
The long-term vision is for AutoSONiC-style pipelines to become a standard method for validating SONiC images in virtual labs, introducing realistic, traffic-driven testing into everyday development rather than reserving it for special occasions with hardware.
