Mini Internet CI/CD
Every year, around 100 students at ETH build and operate their own mini-Internet as part of the Communication Networks course: each group runs an AS, and only if everyone cooperates does the whole network come to life [1]. Under the hood it is a large collection of FRR routers in Docker containers, held together by setup scripts, an API, and an autograder [2,3].
Running this platform is harder than it looks. Bringing it up takes a long time, and once it is running it is difficult to tell whether it actually works as intended. Failures can slip through unnoticed — in one recent edition, a misconfiguration cut the RPKI validator off from the rest of the network and went undetected. And because nothing is easy to test, even routine changes to the platform (a new FRR version, a tweaked config template) carry real risk. The tooling is also fragmented: the Autograder, the API, and a set of manual scripts each solve one narrow task, even though “did this AS react correctly to a config change?” is in many ways the same question whether you are grading a student or validating a platform update.
In this thesis, you will design a modular framework for testing and grading the mini-Internet — reusable building blocks (ideally living in the API) that serve both purposes. The framework should check the network at three levels:
- Platform health. Containers up, reasonable CPU and memory usage, a responsive API.
- Single-AS correctness. Given the correct configuration changes, does an AS behave as expected? (This is essentially what the autograder already does.)
- Network-wide integration. If everyone is configured correctly, can each AS reach the RPKI validator and every other AS? From here you can go further and fuzz configurations across ASes at different levels of “closeness” to see how failures propagate — the more research-oriented part.
For levels 2 and 3, it is also worth exploring static checking: catching bad configurations (like that RPKI cutoff) by analyzing them directly, before anything is deployed.
Milestones
- Familiarize yourself with the mini-Internet code, the API, and the autograder (including how it uses ExaBGP) to understand where correctness is, and isn’t, checked today.
- Design the framework around the three levels, with a single interface that both the autograder and platform checks can reuse. Rework the setup script so it runs with and without the autograder.
- Build levels 1 and 2: health checks, plus single-AS correctness by replaying the reference configuration and observing the result.
- Build level 3: end-to-end reachability tests and configuration fuzzing, and explore static checking alongside.
Requirements
- Familiarity with BGP and routing (ideally participated in the routing project of the CommNet lecture).
- Comfortable with Linux and Docker.
- [Optional] scripting for automation and testing (Python, Bash).
- [Optional] some exposure to fuzzing or static configuration analysis.
References
- Thomas Holterbach, Tobias Bühler, Tino Rellstab, and Laurent Vanbever. “An Open Platform to Teach How the Internet Practically Works”. ACM SIGCOMM CCR. 2020.
- Networked Systems Group, ETH Zürich. “The mini-Internet project”. GitHub.
- Networked Systems Group, ETH Zürich. “The mini-Internet API”. GitHub.
