Network Configuration Backup and Drift Detection for University Campus Networks
Build a tool that backs up every switch, router and firewall configuration on a campus network each night, stores them in Git with readable diffs, and checks each device against a golden standard to flag drift such as Telnet left on, a missing logging server or an unknown VLAN. A network automation final year project that a university IT team can actually run.
Intermediate
A small team, or one strong student willing to learn something new.1 semester · 2 to 3 students
8 to ship
4 optional extrasSuggested stack
What you should ship
- A device inventory (YAML or a small database) with at least 15 lab devices across two vendors or platforms
- Nightly backups of every configuration into a Git repository, one file per device, with secrets masked before commit
- A web page showing each device, its last successful backup, and the diff since the previous night
- A golden configuration rule set written as data (for example: SSH only, NTP and syslog servers present, unused ports shut, banner present)
- A drift report per device listing each failed rule with the offending lines
- Alerts by email or chat when a backup fails or new drift appears
- A test lab defined as code so the whole system can be demonstrated from a clean start
- A written evaluation against a hand-audited sample of configurations
If you have time left
- Generate the remediation commands for each drift finding, reviewed by a human before sending
- Use Batfish to check reachability and ACL behaviour from the backed-up configurations
- Read the inventory from NetBox as a source of truth
- Role-based access so each campus team sees only its own buildings
The problem: nobody knows what changed
A university campus network can have hundreds of switches across departments, hostels and labs, plus routers, firewalls and wireless controllers, often managed by a small IT team. When something breaks after a change, the first question is "what changed?", and too often the answer is a guess. Configurations drift over time: an engineer enables Telnet to fix a problem and forgets to turn it off, a switch never got the new logging server, a test VLAN is still trunked everywhere. Without backups, a dead switch has to be rebuilt from memory.
What already exists and the gap
- RANCID is a long-standing open source tool that collects configurations and emails diffs, but it is dated and its reports are plain text.
- Oxidized is a popular open source backup tool with Git storage and a web view, focused on collecting configurations rather than checking them.
- SolarWinds Network Configuration Manager and similar commercial suites do backups and compliance checks, at a price and complexity many universities and small organisations avoid.
- NetBox is an open source source of truth for inventory and IP addresses, not a backup or compliance tool on its own.
- Batfish analyses configurations to predict network behaviour, but it is an analysis engine that needs expertise, not a daily operations tool.
The gap is a lightweight system a small campus team can run that combines reliable backups, readable diffs and simple, explainable compliance rules in one place.
Inspiration
Batfish grew out of academic research: the paper "A General Approach to Network Configuration Analysis" was presented at USENIX NSDI in 2015 and found real faults in production networks purely from their configuration files. Your project takes the practical first step that such analysis builds on: having every configuration, every day, in version control, and checking it against rules.
What you build
- Network engineer: sees every device, its last backup and yesterday's diff; opens the drift report before a change window.
- Team lead: sees a summary of compliance across the campus and which buildings are drifting.
- The collector: logs in to each device over SSH on a schedule, runs the right command per platform, masks secrets and commits to Git.
Main flows: nightly backup, diff view, drift check, alert on failure or new drift, and a clean demonstration from a lab defined as code.
The technically interesting part
- Reliable collection at scale. Connect to many devices in parallel with sensible timeouts and retries, and record failures instead of stopping. Handle different platforms with different commands and prompts.
- Secrets. Mask passwords, SNMP communities and keys before anything is committed, and prove it with a test.
- Parsing. Turn configuration text into structured data with a parser such as TTP or Cisco's Genie, so rules can say "every access port has BPDU Guard" instead of matching fragile strings.
- Rules as data. Store the golden standard as readable rules that a network engineer can edit without touching Python.
- Test lab. Build the network you test against with Containerlab or Cisco Modeling Labs Free, and plant known drift in it so you can measure detection.
How to evaluate it
- Coverage: percentage of devices backed up successfully each night over two weeks.
- Accuracy: compare the drift report with a manual audit of at least ten configurations; report missed and false findings.
- Safety: show that no secret appears anywhere in the Git history.
- Time saved: time for an engineer to answer "what changed on switch X since Monday" with and without the tool.
Suggested plan
- Weeks 1 to 3: lab as code, inventory, SSH collection for one platform.
- Weeks 4 to 6: Git storage, secret masking, second platform, failure handling.
- Weeks 7 to 9: parsing and the rule engine with ten rules.
- Weeks 10 to 12: web interface, alerts, planted-drift tests.
- Weeks 13 to 15: evaluation against a manual audit, report and demo.
Path to a product
Every organisation with more than a handful of network devices needs backups and compliance evidence, and auditors increasingly ask for it. Universities, hospitals, schools and mid-sized companies sit between free backup-only tools and expensive suites. A hosted or self-hosted version with ready-made rule packs for common standards, and support for the main vendors, could be sold to managed service providers who run many small networks.
Scope warning
Never push configuration changes to real devices in the core scope; this is a read-only tool. Test on lab devices, and only connect to a real campus network with written permission from its owners and read-only credentials.
Learn what you need on Sefism
- Network engineering roadmap: switching, routing, security and the automation stage this project is built on.
- Network engineering cheat sheet: Netmiko, configuration backups and drift, device hardening rules and show commands.
- Netmiko: SSH collection from many vendors in Python.
- Containerlab: define the test network as code.
- Cisco Modeling Labs Free: real Cisco images for a small test lab.
- GNS3: an alternative lab platform with multi-vendor images.
Get help with this idea
The risk is building a nice web page on top of a collector that fails on half the devices. Tauseef can help you plan the lab, the rule format and the evaluation so the core works first. If you are new here, create a free account first.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.